设计一个支持百万级订单每秒处理的股票交易撮合系统，请描述其核心架构，包括订单路由、撮合引擎、结果分发等模块，并说明如何保证低延迟和高可用。

1) 【一句话结论】
采用分布式架构结合订单路由哈希分片、撮合引擎并行计算、异步消息分发，通过多级缓存与冗余部署，实现百万级TPS、微秒级延迟及高可用。

2) 【原理/概念讲解】
老师来解释核心模块：

• 订单路由：像快递分拣中心，根据订单属性（如股票代码、价格）哈希分片到不同撮合节点，避免单点压力（比如用一致性哈希+虚拟节点，每个节点负责特定股票代码范围）。
• 撮合引擎：是系统的“大脑”，执行“时间优先、价格优先”规则，本地多线程并行处理分片订单，计算成交、撤单等状态（类比超市收银台快速结算，多收银员同时处理不同商品）。
• 结果分发：通过消息队列（如Kafka）异步推送撮合结果，减少客户端直接调用延迟（类比外卖骑手及时送达订单状态，避免客户等待）。
  低延迟通过Redis缓存热点股票订单（减少数据库访问），撮合引擎本地计算（降低网络延迟）；高可用通过多节点部署、主从复制（故障自动切换，如ZooKeeper管理集群状态）。

3) 【对比与适用场景】

模块/架构	定义	特性	使用场景	注意点
订单路由	根据订单属性哈希分片到撮合节点	负载均衡，避免热点	高并发订单分发	分片策略影响扩展性
撮合引擎	并行执行交易规则计算匹配结果	本地计算，低延迟	实时撮合	并发控制需防死锁
结果分发	异步消息队列推送撮合结果	高吞吐，低耦合	实时通知	延迟控制与消息可靠性
集中式撮合	单节点处理所有订单	单点故障，延迟高	小规模系统	扩展性差
分布式撮合	多节点并行处理	高可用，可扩展	百万级TPS	数据一致性挑战

4) 【示例】

• 订单结构（JSON示例）：

  { "orderId": "1001", "userId": "u1", "stockCode": "000001", "price": "10.5", "quantity": 100, "orderType": "buy" }  
  

• 撮合引擎伪代码：

  def match_orders(order_list):  
      # 按时间+价格排序  
      order_list.sort(key=lambda o: (o['time'], o['price']))  
      matched = []  
      for order in order_list:  
          if order['orderType'] == 'buy':  
              for sell in sell_orders:  
                  if sell['price'] <= order['price']:  
                      fill_qty = min(order['quantity'], sell['quantity'])  
                      matched.append({  
                          "orderId": order['orderId'],  
                          "matchedOrderId": sell['orderId'],  
                          "price": sell['price'],  
                          "quantity": fill_qty  
                      })  
                      order['quantity'] -= fill_qty  
                      sell['quantity'] -= fill_qty  
          else:  
              # 卖单逻辑类似  
          # 移除已成交订单  
      return matched  
  

5) 【面试口播版答案】
“面试官您好，针对百万级订单每秒处理的股票交易撮合系统，我的核心设计是分布式架构，通过订单路由哈希分片、撮合引擎并行计算、结果分发消息队列，结合多级缓存和冗余部署保证低延迟和高可用。具体来说，订单路由根据股票代码哈希分片到不同节点，避免热点；撮合引擎本地多线程处理时间+价格优先规则，减少延迟；结果通过Kafka异步推送，降低客户端等待。低延迟通过Redis缓存热点订单，减少数据库访问；高可用通过多节点部署和主从复制，故障自动切换。这样能支撑百万级TPS，延迟控制在微秒级。”

6) 【追问清单】

• 问题1：订单路由的具体分片策略如何实现？
  回答要点：用一致性哈希+虚拟节点，每个节点负责特定股票代码范围，避免热点。
• 问题2：如何保证撮合引擎的数据一致性？
  回答要点：通过本地事务日志，故障恢复时重放未完成的撮合。
• 问题3：高可用方案中，节点故障时如何处理未完成的订单？
  回答要点：通过ZooKeeper选举新主节点，未完成的订单由新主节点继续处理。
• 问题4：结果分发如何保证消息不丢失？
  回答要点：消息队列持久化存储+幂等处理，确保至少一次投递。
• 问题5：扩展性方面如何支持未来千万级TPS？
  回答要点：水平扩展节点，增加分片数量，或引入流处理框架优化计算。

7) 【常见坑/雷区】

• 忽略单点故障（如集中式撮合引擎，导致系统不可用）。
• 延迟优化不足（直接访问数据库，未用缓存，延迟过高）。
• 数据一致性处理不当（撮合结果未同步，导致重复成交）。
• 订单路由分片策略不合理（轮询导致热点，影响性能）。
• 结果分发同步调用（客户端等待，延迟增加）。