在实际项目中，我们经常会用到本地缓存，但是往往缺少对缓存使用情况的观测。今天推荐一种用法，让你更优雅地使用本地缓存。
一、什么是 Apache Shiro？
Apache Shiro 是一个功能强大且易于使用的 Java 安全框架，表现在身份认证、授权、加密和会话管理，可用于保护任何应用程序，小到命令行应用程序、移动应用程序，大到 Web 和企业应用程序。
应用程序安全性的 4 个基石：
- 身份验证 - 证明用户身份，通常称为用户“登录”
- 授权 - 访问控制
- 加密 - 保护或隐藏数据免遭窥探
- 会话管理 - 每个用户的时间敏感状态
在我最近的项目中，经常会有给大表加字段的需求，这个过程非常耗时。
可以看到，900 万数据量的一张表，加一个字段就需要 3 个小时左右。
我们知道，给一个表加字段，或者修改字段，或者加索引，需要扫描全表的数据。假设表数据量比较大，加字段的过程将会非常耗时。
不过我最关心的是，在加字段的过程中，会不会对业务的增删改查造成影响？在询问 DBA 后，他给出的答复是不会造成影响。这不禁让我思考这背后的实现原理。
下面，我们就来一探究竟。
MyBatis 是一个流行的 Java 持久层框架，它简化了数据库访问的复杂性，为开发者提供了强大的功能。其中，MyBatis 拦截器是一个非常有用的特性，可以帮助开发者灵活地解决各种问题。
本文将探讨 MyBatis 拦截器在实际项目中的应用场景和具体实现方法。
你说你 Kafka 用了很多年了，但是位移提交的这些细节你未必清楚。
不久前有个同事出去面试了，他说在 Kafka 问题上被面试官藐视了。
本文我们将构建一个简单但完整的小型 Web 应用程序，以演示 Spring Security 的入门教程。大致逻辑是：当合法用户成功登录系统之后，浏览器会跳转到一个系统主页，并展示一些个人健康档案（HealthRecord）数据。
让我们开始吧！
本文来自我最近正在学习的课程，极客时间胡峰的专栏文章《程序员进阶攻略》，内容如下。
今年年初，我学习了梁宁的《产品思维》课，其中有一篇叫《点线面体的战略选择》，我觉得特别有感触。虽然是讲产品，但假如把个人的成长当成产品演进一样来发展，会有一种异曲同工、殊途同归之感。
在我工作的经历中就曾碰到过这么一个人，他一开始做了几年开发，从前端到后端，后来又转做测试，接触的“点”倒是不少，但却没能连接起来形成自己的体系，那他个人最大的价值就局限在最后所在的“点”上了。
其实个人的成长有很多方面，但对于程序员的成长最重要的就是知识体系的构建，这其实就是一个 “点线面体” 的演进过程。
下面我会结合自己的成长路线来梳理下这个体系的建立过程。
在我们的生产环境中有一张表：courier_consume_fail_message，是存放消息消费失败的数据的，设计之初，这张表的数据量评估在万级别以下，因此没有建立索引。
但目前发现，该表的数据量已经达到百万级别，原因产生了大量的重试消费，这导致了该表的慢查询。
因此需要清理该表数据。而实际上，使用 DELETE 命令删除数据后，我们发现查询速度并没有显著提高，甚至可能会降低。为什么？
因为 DELETE 命令只是标记该行数据为“已删除”状态，并不会立即释放该行数据在磁盘中所占用的存储空间，这样就会导致数据文件中存在大量的碎片，从而影响查询性能。所以，除了删除表记录外，还需要清理磁盘碎片。
在表碎片清理前，我们关注以下四个指标。
- 指标一：表的状态：
SHOW TABLE STATUS LIKE 'courier_consume_fail_message'; - 指标二：表的实际行数：
SELECT count(*) FROM courier_consume_fail_message; - 指标三：要清理的行数：
SELECT count(*) FROM courier_consume_fail_message where created_at < '2023-04-19 00:00:00'; - 指标四：表查询的执行计划：
EXPLAIN SELECT * FROM courier_consume_fail_message WHERE service='courier-transfer-mq';
1 | -- 清理磁盘碎片 |
以下是清理前后的指标对比。
本文来自我最近正在学习的课程，极客时间胡峰的专栏文章《程序员进阶攻略》。文中观点颇为认同，分享给你，部分内容我作了精简，内容如下。
几年前，我给团队负责的整个系统写过一些公共库，有一次同事发现这个库里存在一个 Bug，并告诉了我出错的现象。然后我便去修复这个 Bug，最终只修改了一行代码，但发现一上午就这么过去了。
一上午只修复了一个 Bug，而且只改了一行代码，到底发生了什么？时间都去哪里了？以前觉得自己写代码很快，怎么后来越来越慢了？我认真地思考了这个问题，开始认识到我的编程方式和习惯在那几年已经慢慢发生了变化，形成了明显的两个阶段的转变。这两个阶段是：
- 写得粗放，写得多
- 写得精益，写得好
最近由于一行单元测试代码没有写 Assert 断言，导致了项目在 CI 过程中没有通过，于是遭到了某位同事的吐槽，在修改我的代码后写上了一句提交信息。
我想，做为技术人，修改这条 Commit 信息还是不难的，于是我通过本文介绍的技巧完成了修改，效果如下：
其实修改历史提交信息很简单。