system-design-notesSequencer排序器与确定性执行图解交易所的核心心脏【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notessystem-design-notes 是一套系统设计的面试笔记项目本文带你深入其中第 28 章「Stock Exchange交易所」拆解Sequencer 排序器与确定性执行——交易所系统的核心心脏它如何为每秒数万笔订单公平排号用单写者 mmap 事件存储把延迟压到微秒级并在故障后快速恢复。本文要点预览Sequencer 为每笔订单/成交打上全局唯一序列号公平性可验证单写者 环形缓冲 mmap 事件存储 微秒级低延迟确定性执行顺序由序列号决定而不是墙钟时间领导者选举 热备副本 → 99.99% 可用性为什么公平是交易所系统设计的核心难题先看量级一天约 10 亿笔订单交易时段 6.5 小时平均 QPS 约 4.3 万开市高峰可达21.5 万 QPS。当数万用户同时抢购同一本订单簿时谁先谁后直接决定谁能以更优价格成交——顺序一旦模糊就会引发争议甚至监管风险。Sequencer 排序器要解决的正是这个排号问题。在交易主链路Critical Path中订单的旅程是券商 → 客户端网关 → 订单经理 →Sequencer→ 撮合引擎。市场数据流与报表流不在关键路径上延迟要求相对宽松但交易流必须极致优化。Sequencer排序器交易所的心脏长什么样Sequencer 是让撮合引擎确定性运行的关键组件它分为两半Inbound Sequencer入站为进入撮合引擎的每笔订单盖上序列号Outbound Sequencer出站为撮合产生的每笔成交fill盖上序列号为什么必须打号三个理由⚖️及时性与公平性——先到先得有了可验证的客观依据快速恢复与重放——故障后按序列号重放事件流即可重建状态✅恰好一次exactly-once保证——凭序列号可识别并去重重复事件一个有意思的取舍Kafka 本质上就是入站 出站的消息队列概念上完全可以当 Sequencer 用但为了追求更低延迟笔记中选择自己实现这正是心脏必须长在体内、不能外包的原因。深入剖析单写者 环形缓冲 mmap 事件存储事件溯源Event Sourcing视角下Sequencer 的定位发生了微妙的变化——它不再自己充当事件存储而是单写者single writer先排序再转发。整个流程分三步网关Gateway与撮合引擎各自把事件写进环形缓冲ring buffer——预分配空间、无锁避免内存分配开销Sequencer 从环形缓冲中拉取数据统一盖上序列号写入Event Store基于 mmap 的共享内存总线各组件只需订阅事件存储就能拿到自己需要处理的事件订单经理甚至以库的形式在每个组件中持有一份副本省掉一次跨进程调用。低延迟实践单服务器 mmap 总线现代交易所有一个反直觉的做法不像大多数软件那样分布式部署而是把所有核心组件跑在一台巨型服务器上。如果按最初的分布式设计瓶颈在于服务间网络延迟和 Sequencer 的磁盘读写端到端只能做到几十毫秒而目标是几十微秒。把关键路径搬上同一台机器、进程间通过 mmap 总线通信后再配上一个小技巧——把 mmap 文件建在/dev/shm共享内存里就彻底告别了磁盘访问。应用循环告别上下文切换与锁竞争另一个关键优化是应用循环Application Loop用一个 while 循环持续执行使命关键任务并把进程绑定到固定 CPU 上避免操作系统线程调度的上下文切换。它的附带好处是天然没有锁竞争——单线程单循环多线程抢同一资源的场景直接消失了。确定性执行如何成立序列号决定顺序这是 Sequencer 最精妙的地方事件实际发生的时刻不重要重要的是它在序列中的位置。上图中6 个事件在时间轴上分布疏密不均进入 Sequencer 之后它们被重新排成严格有序的队列。撮合算法在处理时还会校验若收到的序列号不是预期的nextSequence直接返回OUT_OF_ORDER错误拒收。这就是功能确定性——同样的事件序列在任何节点、任何时刻重放都会得到完全一致的撮合结果。笔记中同时提醒要关注延迟确定性通过监控 99 / 99.99 分位延迟追踪毛刺典型元凶是 Java 的垃圾回收GC停顿。构建 99.99% 可用性领导者选举与热备副本99.99% 的可用性意味着每天最多停机 8.64 秒。围绕单台机器跑核心的架构高可用方案分两层进程级部署备用的撮合引擎实例待命自动检测故障并快速切换。有状态组件在非领导状态下可以接收入站事件、但不发布出站事件心跳探测主副本是否失能服务器级整台服务器作为热/温备机事件存储通过可靠 UDP跨机复制比 TCP 更快即使热备也倒下怎么办笔记给出了跨城市多数据中心复制的思路并用 Raft 类领导者选举term 任期机制决定由谁接管。对交易所而言数据丢失不可接受必须高频备份。学习指南Stock Exchange 全章与相关笔记本章全文28. Stock Exchange/README.md按理解问题 → 高层设计 → 深度剖析 → 总结四步展开覆盖撮合算法、行情多播、Colocation 托管等主题。延伸阅读同一项目内事件溯源完整细节27. Digital Wallet/README.md消息队列背景知识Sequencer 与 Kafka 的取舍19. Distributed Message Queue/README.md全局唯一 ID 与序列号生成07. Unique-Id Generator/Readme.md一致性哈希在分片中的应用05. Consistent Hashing/Readme.md一句话总结Sequencer 排序器用全局序列号这一个简单机制同时买到了公平性、可重放性和故障恢复能力再叠加单写者、mmap 总线与应用循环就构成了交易所那颗稳定跳动的心脏。【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 system-design-notes：Sequencer排序器与确定性执行，图解交易所的“核心心脏“
system-design-notesSequencer排序器与确定性执行图解交易所的核心心脏【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notessystem-design-notes 是一套系统设计的面试笔记项目本文带你深入其中第 28 章「Stock Exchange交易所」拆解Sequencer 排序器与确定性执行——交易所系统的核心心脏它如何为每秒数万笔订单公平排号用单写者 mmap 事件存储把延迟压到微秒级并在故障后快速恢复。本文要点预览Sequencer 为每笔订单/成交打上全局唯一序列号公平性可验证单写者 环形缓冲 mmap 事件存储 微秒级低延迟确定性执行顺序由序列号决定而不是墙钟时间领导者选举 热备副本 → 99.99% 可用性为什么公平是交易所系统设计的核心难题先看量级一天约 10 亿笔订单交易时段 6.5 小时平均 QPS 约 4.3 万开市高峰可达21.5 万 QPS。当数万用户同时抢购同一本订单簿时谁先谁后直接决定谁能以更优价格成交——顺序一旦模糊就会引发争议甚至监管风险。Sequencer 排序器要解决的正是这个排号问题。在交易主链路Critical Path中订单的旅程是券商 → 客户端网关 → 订单经理 →Sequencer→ 撮合引擎。市场数据流与报表流不在关键路径上延迟要求相对宽松但交易流必须极致优化。Sequencer排序器交易所的心脏长什么样Sequencer 是让撮合引擎确定性运行的关键组件它分为两半Inbound Sequencer入站为进入撮合引擎的每笔订单盖上序列号Outbound Sequencer出站为撮合产生的每笔成交fill盖上序列号为什么必须打号三个理由⚖️及时性与公平性——先到先得有了可验证的客观依据快速恢复与重放——故障后按序列号重放事件流即可重建状态✅恰好一次exactly-once保证——凭序列号可识别并去重重复事件一个有意思的取舍Kafka 本质上就是入站 出站的消息队列概念上完全可以当 Sequencer 用但为了追求更低延迟笔记中选择自己实现这正是心脏必须长在体内、不能外包的原因。深入剖析单写者 环形缓冲 mmap 事件存储事件溯源Event Sourcing视角下Sequencer 的定位发生了微妙的变化——它不再自己充当事件存储而是单写者single writer先排序再转发。整个流程分三步网关Gateway与撮合引擎各自把事件写进环形缓冲ring buffer——预分配空间、无锁避免内存分配开销Sequencer 从环形缓冲中拉取数据统一盖上序列号写入Event Store基于 mmap 的共享内存总线各组件只需订阅事件存储就能拿到自己需要处理的事件订单经理甚至以库的形式在每个组件中持有一份副本省掉一次跨进程调用。低延迟实践单服务器 mmap 总线现代交易所有一个反直觉的做法不像大多数软件那样分布式部署而是把所有核心组件跑在一台巨型服务器上。如果按最初的分布式设计瓶颈在于服务间网络延迟和 Sequencer 的磁盘读写端到端只能做到几十毫秒而目标是几十微秒。把关键路径搬上同一台机器、进程间通过 mmap 总线通信后再配上一个小技巧——把 mmap 文件建在/dev/shm共享内存里就彻底告别了磁盘访问。应用循环告别上下文切换与锁竞争另一个关键优化是应用循环Application Loop用一个 while 循环持续执行使命关键任务并把进程绑定到固定 CPU 上避免操作系统线程调度的上下文切换。它的附带好处是天然没有锁竞争——单线程单循环多线程抢同一资源的场景直接消失了。确定性执行如何成立序列号决定顺序这是 Sequencer 最精妙的地方事件实际发生的时刻不重要重要的是它在序列中的位置。上图中6 个事件在时间轴上分布疏密不均进入 Sequencer 之后它们被重新排成严格有序的队列。撮合算法在处理时还会校验若收到的序列号不是预期的nextSequence直接返回OUT_OF_ORDER错误拒收。这就是功能确定性——同样的事件序列在任何节点、任何时刻重放都会得到完全一致的撮合结果。笔记中同时提醒要关注延迟确定性通过监控 99 / 99.99 分位延迟追踪毛刺典型元凶是 Java 的垃圾回收GC停顿。构建 99.99% 可用性领导者选举与热备副本99.99% 的可用性意味着每天最多停机 8.64 秒。围绕单台机器跑核心的架构高可用方案分两层进程级部署备用的撮合引擎实例待命自动检测故障并快速切换。有状态组件在非领导状态下可以接收入站事件、但不发布出站事件心跳探测主副本是否失能服务器级整台服务器作为热/温备机事件存储通过可靠 UDP跨机复制比 TCP 更快即使热备也倒下怎么办笔记给出了跨城市多数据中心复制的思路并用 Raft 类领导者选举term 任期机制决定由谁接管。对交易所而言数据丢失不可接受必须高频备份。学习指南Stock Exchange 全章与相关笔记本章全文28. Stock Exchange/README.md按理解问题 → 高层设计 → 深度剖析 → 总结四步展开覆盖撮合算法、行情多播、Colocation 托管等主题。延伸阅读同一项目内事件溯源完整细节27. Digital Wallet/README.md消息队列背景知识Sequencer 与 Kafka 的取舍19. Distributed Message Queue/README.md全局唯一 ID 与序列号生成07. Unique-Id Generator/Readme.md一致性哈希在分片中的应用05. Consistent Hashing/Readme.md一句话总结Sequencer 排序器用全局序列号这一个简单机制同时买到了公平性、可重放性和故障恢复能力再叠加单写者、mmap 总线与应用循环就构成了交易所那颗稳定跳动的心脏。【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考