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 小时前
Postman 被曝自动往 Claude Code 和 Codex 装插件
前端·后端·程序员
AI你一生一世2 小时前
不止于时序存储:DolphinDB 如何成为 AI 时代的工业智能底座
java·人工智能·struts·时序数据库·工业智能·dolphindb·ai基础设施
云-缩影2 小时前
拆解 AI 图像生成应用的后端架构:ECS、OSS 和大模型 API 怎么配合
java·spring boot·后端
瑞克-桑切斯3 小时前
7、MySQL 慢查询排查与优化实战指南
java·服务器·数据库
七牛云行业应用4 小时前
DeepSeek Super-agent 与 Grok Bot:开源 Agent 架构和聊天助手有何区别
人工智能·ai·架构·ai编程
考虑考虑4 小时前
Posrgresql恢复.backup文件
数据库·后端·postgresql
天远Date Lab4 小时前
零信任架构实战:基于天远租凭分期报告构建自动化汽车以租代购免押风控网关
网络·人工智能·架构·自动化
无奈何杨4 小时前
风控决策系统决策流,策略模式,权重、顺序、投票、最坏
后端
Patrick_Wilson5 小时前
Go 为什么需要 defer?从函数怎么收尾说起
后端·go·编程语言
苏三说技术5 小时前
DeepSeek Harness入驻B站,评论区被干成了大型插件集市!
后端