可乐ea-CSDN博客

原创【知识获取与分享社区项目 | 项目日记第 12 天】分片位图计数重建与 Kafka 灾难回放策略

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

2026-05-25 20:21:26 279

原创【知识获取与分享社区项目 | 项目日记第 11 天】Kafka 异步写与写聚合：从点赞事件到 Redis SDS 计数快照

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

2026-05-24 15:16:40 586 1

原创【知识获取与分享社区项目 | 项目日记第 10 天】分片位图实现点赞幂等与判重

如果计数缓存丢失，能不能从事实数据恢复？知光项目里没有直接用 MySQL 计数列，也没有简单使用 RedisINCRRedis 分片位图 + Lua 原子切换 + Kafka 异步聚合 + Redis SDS 汇总计数。是否签到是否已读每个用户只占一个 bit，内存非常紧凑。项目中没有直接用 RedisINCR后续的 Kafka 异步聚合和 SDS 计数快照，都是建立在这个“位图事实层”之上的。

2026-05-23 16:38:20 568

原创【知识获取与分享社区项目 | 项目日记第 9 天】一主多从模型：follower 伪从、列表缓存与用户计数异步维护

第 1 篇：关注/取关如何写 following 主表和 outbox 表第 2 篇：Canal 如何订阅 outbox binlog 并投递 Kafka这一篇继续看事件真正被消费之后，系统如何更新多个“伪从”。following 主表：权威事实follower 表：粉丝视角伪从Redis ZSet：关注/粉丝列表缓存伪从Redis SDS：用户计数伪从Caffeine：大 V 用户 Top 列表本地缓存这些数据源不要求和 following 主表强一致，而是通过事件异步追平。

2026-05-22 17:27:41 504

原创【知识获取与分享社区项目 | 项目日记第 8 天】Outbox 事件驱动：Canal 订阅 Binlog 并投递 Kafka

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

2026-05-21 15:09:44 578

原创【知识获取与分享社区项目 | 项目日记第 7 天】关注取关实现：following 主表 + Outbox 同事务

今天开始整理项目中的用户关系系统。关注用户取消关注查询是否关注、是否被关注、是否互关查询关注列表和粉丝列表维护关注数、粉丝数异步更新缓存和粉丝表这部分没有简单地在一个接口里同时更新所有数据，而是采用了“一主多从 + 事件驱动”的模型。following 表：主事实表follower 表：粉丝视角的伪从表用户计数 SDS：计数伪从Redis ZSet：列表缓存伪从关注动作发生时，只要求following主表和outbox事件表在同一个 MySQL 事务中成功。

2026-05-20 16:13:46 580

原创【知识获取与分享社区项目 | 项目日记第 6 天】用户维度关注粉丝计数：Outbox 事件 + Redis SDS + 采样一致性校验

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

2026-05-19 20:00:00 706

原创【知识获取与分享社区项目 | 项目日记第 5 天】笔记维度点赞收藏：Redis 位图 + Lua 原子更新 + SDS 紧凑计数

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

2026-05-18 16:03:13 715

原创【知识获取与分享社区项目 | 项目日记第 4 天】元数据完善、DeepSeek 摘要生成与正式发布实现

上一篇我们已经完成了发布系统的前半段：创建草稿、OSS 预签名直传和内容确认。今天我们来继续整理后半段：更新标题、标签、图片列表、可见性、摘要，并接入 DeepSeek AI 实现一键生成文章摘要，最后将草稿正式发布。上传确认完成 -> 更新元数据 -> AI 生成摘要 -> 保存摘要 -> 发布草稿"content" : "这里是 Markdown 正文内容..." }"description" : "生成的不超过50字的中文描述" }这个接口只负责生成摘要，不直接保存数据库。

2026-05-17 17:01:05 523

原创【知识获取与分享社区项目 | 项目日记第 3 天】渐进式发布流程与 OSS 预签名直传实现

今天我们来整理项目中发布系统的前半段：创建草稿、申请 OSS 预签名 URL、前端直传文件、上传成功后回传确认。这个流程和普通的“新增文章”不太一样。创建草稿 -> 申请预签名 URL -> 前端直传 OSS -> 后端确认上传结果这样后端不需要中转大文件，只负责鉴权、签名和保存对象元数据，更适合 Markdown 正文、图片、视频这类内容发布场景。因为后续 OSS 对象路径需要依赖postId先生成草稿 ID，就可以让正文、图片、视频都归属到同一个内容目录下。

2026-05-16 20:28:56 522

原创【知识获取与分享社区项目 | 项目日记第 2 天】JWT 双令牌与 Redis 白名单撤销机制

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

2026-05-15 18:30:04 852 1

原创【知识获取与分享社区项目 | 项目日记第 1 天】登录注册与验证码认证实现

为了督促自己每天坚持写以及记录项目知识点，所以用这种项目日记的方式鞭策自己。今天专门整理认证系统的入口部分：验证码发送、注册、登录、用户落库和登录审计。本篇重点是把“用户如何完成身份校验并进入系统”讲清楚，为下一篇的 Token 签发、刷新、撤销做铺垫。第一天主要梳理了认证系统的前半段：验证码、注册、登录、用户创建和登录审计。这部分解决的是“用户如何证明自己是谁”。至于登录成功后如何保持会话、如何刷新 Token、如何退出登录后即时失效，就放到明天继续整理。

2026-05-14 22:04:01 445 2