第一天已经完成了登录注册流程，这一天我们继续整理认证系统的核心安全设计：JWT 双令牌模式。Access Token：15 分钟有效Refresh Token：7 天有效RS256 非对称签名Redis 保存 Refresh Token 白名单支持刷新轮换、登出撤销、密码重置强制下线今天主要整理了认证系统的后半段：JWT 双令牌、RS256 签名、Redis 白名单、Token 刷新轮换和即时撤销

但是在高并发内容社区里，热门笔记会把某一行打成热点，数据库行锁、redo log 和缓存一致性压力都会比较明显。Redis 分片位图做状态事实Kafka 承接计数增量事件Redis Hash 做临时聚合桶定时任务把增量折叠到 Redis SDS 二进制计数快照读取时优先读 SDS，异常时基于位图自愈重建这套设计的核心思想是：位图负责“谁点过”，SDS 负责“有多少”，事件负责把状态变化转换成计数增

关注数粉丝数发文数获赞数following 主表follower 投影表Outbox 事件Redis ZSet 列表缓存Redis SDS 用户计数采样一致性校验自愈重建来维护用户维度计数的。因为查询视角不同。查“我关注了谁”，适合从following查。查“谁关注我”，适合从follower查。如果只用一张表，也能查，但在分页和索引设计上会更吃力。这一篇主要整理了用户维度计数系统。关注/取关先写

上一篇我们整理了关注/取关写入主表的过程。following 主表outbox 事件表但是 outbox 表只是事件落库，还没有真正通知到其他模块。这一篇继续看事件是如何从 MySQL outbox 表流转到 Kafka 的。Canal 订阅 MySQL binlog↓捕获 outbox 表变更↓解析 payload 字段↓组装 Kafka 消息↓发送到 canal-outbox 主题↓消费者读取

虽然简单，但高并发下会造成写热点。↓产生 CounterEvent↓Kafka 异步写入 counter-events↓消费者把增量写入 Redis Hash 聚合桶↓定时任务每 1 秒把聚合增量折叠到 SDS这一篇就专门整理这条链路。Kafka + Redis 聚合桶可以削峰，把多次增量合并后再刷写。如果状态真的变化，就产生。事件进入 Kafka 后，消费者先写 Redis Hash 聚合桶，后

第 1 篇：分片位图 + Lua 原子判重第 2 篇：Kafka 异步写 + Redis 聚合桶 + SDS 计数快照计数重建和灾难回放。SDS Key 被误删SDS 长度异常聚合刷写中断Redis 数据不完整需要从历史事件恢复计数如果只是普通的 RedisINCR，一旦计数丢失，就很难恢复。1. 读取时发现 SDS 缺失或异常，基于分片位图 BITCOUNT 按需重建2. 灾难场景下启用 Kaf

今天开始整理项目中的 Feed 流系统。Feed 流是内容社区中访问频率非常高的接口。L1：本地 Caffeine 缓存L2：Redis 页面骨架缓存L3：Redis 内容片段缓存这样做的好处是：页面顺序和单条内容片段可以拆开缓存，同一篇内容出现在不同页面或不同场景时，片段可以复用。Caffeine 是进程内缓存，访问速度非常快，适合作为 Feed 热门页的第一层缓存。这一篇主要整理了项目首页 F

如果一篇文章标题就是“Redis 计数系统设计”，它应该比正文里偶然出现 Redis 的文章更靠前。在平台中，用户发布的是一篇篇知文，内容包括标题、摘要、标签、Markdown 正文、图片等。也就是说，搜索结果直接复用 Feed 卡片结构，让前端可以用同一套展示组件。因为在内容搜索场景中，标题命中通常比正文命中更能说明这篇文章和关键词相关。这样用户在搜索结果中看到的不是固定摘要，而是和搜索词相关的

这一篇主要从工程设计角度总结项目。强一致数据走 MySQL 事务，派生数据走 Redis / Kafka / ES 最终一致，并通过重建、回放、短 TTL 和幂等策略保证可恢复。JWT 双令牌：高性能访问 + 可撤销续期OSS 渐进式发布：降低后端大文件传输压力Redis SDS：紧凑计数快照Kafka 聚合：削弱热点写压力Outbox：解决业务表和消息发送的双写一致性Feed 三级缓存：提升高频

Controller 层Service 层Mapper 层刚开始学习 Spring Boot + MyBatis 的时候，很多人会觉得这个结构有点麻烦。明明一个查询功能，Controller 里面直接查数据库不就行了吗？为什么还要经过 Service，再经过 Mapper？其实三层架构不是为了把代码写复杂，而是为了让每一层只负责自己的事情。