SequenceGenerator高并发有序顺序号生成中间件 - 架构设计文档

高并发有序顺序号生成中间件 - 架构设计文档

设计思想参考上一篇文章:高并发强一致性顺序号生成系统 -- SequenceGenerator

github:SequenceGenerator

1. 核心设计理念

本组件采用了 "Redis 主生成 + DB 异步备份 + DB 乐观锁降级" 的高可用架构设计。

  • 极致性能 :正常情况下,所有的 ID 生成请求全部由 Redis 的 Lua 脚本(或 INCR)在内存中原子完成,无锁、无阻塞。
  • 数据防丢:生成序列号后,通过线程池(或 Kafka)异步将最新值同步到 DB 中(Upsert 记录最大值)。
  • 平滑降级:当 Redis 宕机时,系统瞬间切换为 DB 乐观锁自增模式,继续提供服务。由于 DB 一直在异步备份,所以降级时不会出现序列号回退。
  • 安全恢复:当探测到 Redis 恢复后,系统冻结所有请求,从 DB 中读取当前的最大序列号来初始化 Redis,确保恢复后也是严格递增的。

2. 核心状态机 (FSM) 设计

整个系统围绕三种状态进行运转:
启动初始化
Redis 连接超时/执行异常
达到 N 次请求探活发现 Redis 恢复
DB 最大值同步到 Redis 完成
恢复期间发生异常
NORMAL
FAILOVER
RECOVERING

3. 调用流程交互图

3.1 正常模式 (NORMAL) 序列号生成流转

MySQL (备份) 异步线程池 / Kafka Redis (主) 状态机 (StateMachineManager) 客户端线程 MySQL (备份) 异步线程池 / Kafka Redis (主) 状态机 (StateMachineManager) 客户端线程 异步执行,不阻塞主线程 请求 nextId() INCR 获取最新序号 (V) 返回序号 V 提交异步写 DB 任务 (seqKey, date, V) 组装前缀返回完整 ID UPSERT ... GREATEST(curr_value, V) 写入成功

3.2 降级模式 (FAILOVER) 序列号生成流转

MySQL (降级提供服务) Redis (宕机) 状态机 (StateMachineManager) 客户端线程 MySQL (降级提供服务) Redis (宕机) 状态机 (StateMachineManager) 客户端线程 捕获异常,将状态切为 FAILOVER 请求 nextId() 尝试 INCR Timeout Exception 查询当前最大记录 返回 current_value (如 100) CAS 乐观锁 UPDATE sys_sequence SET curr_value=101 WHERE version=v 受到影响行数 = 1 (成功) 返回序号 101

3.3 恢复模式 (RECOVERING) 序列号生成流转

Redis (已恢复) MySQL 分布式锁 状态机 客户端线程 (触碰间隔 N) Redis (已恢复) MySQL 分布式锁 状态机 客户端线程 (触碰间隔 N) 状态切换为 RECOVERING (阻塞后续请求) 状态切回 NORMAL,释放锁 请求 nextId(),触发 failoverCounter % N == 0 尝试获取恢复锁 (tryLock) 获取成功 探活 (PING) PONG (存活) 读取 DB 中最大序号 (如 500) 返回 500 SET 强制重置 Redis 的值为 500 (对其 DB 进度) OK INCR 生成最新序号 (501) 501 返回序号 501

4. DB 同步策略 (DbSyncStrategy)

系统提供两种异步持久化 DB 的策略,可以通过 [application.yml](file:///Users/jixu/Project/Java/SequenceGenerator/src/main/resources/application.yml) 的 sync-mode 参数灵活切换:

4.1 线程池模式 (THREAD_POOL)

  • 适用场景:单体应用、大多数微服务、对外部依赖要求少的场景。
  • 机制 :通过内置的有界队列线程池直接执行 sys_sequence 表的 Upsert 操作。
  • 防丢机制 :线程池队列打满后,通过 CallerRunsPolicy 降级为同步执行,牺牲一点性能但绝对不丢数据。

4.2 消息队列模式 (KAFKA)

  • 适用场景:超高并发写、系统本身已重度依赖 Kafka 并希望复用它来做削峰。
  • 机制 :Redis 拿到号后作为生产者将消息发入指定 Topic,由统一的 @KafkaListener 消费者进行写库。
  • 乱序容忍 :DB 端采用 ON DUPLICATE KEY UPDATE curr_value = GREATEST(curr_value, newValue) 语法,无惧消息的乱序消费,只记录最大值。
相关推荐
码农刚子1 小时前
字符串拼接用“+”还是 StringBuilder?别再凭感觉写了
后端·代码规范
lzp07912 小时前
SpringBoot3.3.0集成Knife4j4.5.0实战
java
weixin_449290012 小时前
智能盒子-Agent-Skill-执行逻辑架构
网络·架构
茶杯梦轩2 小时前
面试常问:DNS,CDN,Cookie,Session和Token详解及实战避坑指南
后端·网络协议·面试
Memory_荒年2 小时前
TiDB 单机部署与监控完整指南
运维·数据库·后端
殷紫川2 小时前
吃透分库分表:分片策略、跨库事务与平滑扩容全解
mysql·架构
犯困的饭团2 小时前
3_【自动化引擎Ansible Runner】深入功能模块 - 不止于 Playbook
后端
写Cpp的小黑黑2 小时前
WHEP 拉流技术详解(基于一个 html/js demo)
后端
GetcharZp2 小时前
告别 Selenium!这款 Go 语言神器,让网页自动化与爬虫快到飞起!
后端