请设计一个支持每秒万级订单处理的证券交易撮合系统，需要考虑订单类型（市价、限价）、撮合规则（价格优先、时间优先等），并说明如何保证系统的高可用和低延迟。

上海证券交易所A05难度：困难

答案

1) 【一句话结论】：采用内存优先的订单簿结构+多级队列撮合引擎+分布式主备/多活架构，结合批量处理与异步消息，实现万级订单秒级撮合，并通过多副本、熔断降级保障高可用与低延迟。

2) 【原理/概念讲解】：首先解释订单簿（Order Book）——类似超市货架，限价单按价格分层（如买一、买二...卖一、卖二...），市价单直接匹配最近价。撮合引擎核心是“价格优先、时间优先”：价格优先（高买低卖）+ 时间优先（先到先匹配）。高可用通过多节点主备（如ZooKeeper/etcd选主），低延迟通过内存缓存订单、批量处理（如每100ms撮合一次）+ 异步消息（如Kafka）解耦。类比：订单簿像超市货架，市价单是顾客直接要最便宜的，限价单是顾客指定价格等待，撮合引擎像收银员按规则（价格优先）快速匹配商品（订单）。

3) 【对比与适用场景】：

方案类型	定义	特性	使用场景	注意点
内存优先	订单簿全量存内存（如Redis/本地内存）	延迟极低（微秒级），处理能力高（万级/秒）	高频撮合场景（如A股交易）	需要高可用保障（主备/多活），内存容量限制
分布式存储	订单簿分片存分布式存储（如HBase/MySQL分库）	弹性高，可扩展性强	大规模订单（百万级以上）	延迟较高（毫秒级），需一致性保障（如Paxos）

4) 【示例】：伪代码展示订单结构与撮合逻辑。
订单结构（简化）：

{
  "order_id": "1001",
  "type": "buy", // buy/sell
  "price": 10.5,
  "quantity": 100,
  "timestamp": 1670000000
}

撮合逻辑伪代码（单侧订单簿）：

# 买方订单簿（买一、买二...）
buy_book = {
    "level1": {"price": 10.5, "quantity": 500},
    "level2": {"price": 10.4, "quantity": 300},
    ...
}

# 卖方订单簿（卖一、卖二...）
sell_book = {
    "level1": {"price": 10.6, "quantity": 400},
    "level2": {"price": 10.7, "quantity": 200},
    ...
}

def match_order(order):
    if order["type"] == "buy":
        # 市价单：匹配卖方最近价（卖一）
        if sell_book["level1"]["quantity"] >= order["quantity"]:
            sell_book["level1"]["quantity"] -= order["quantity"]
            return {"matched_price": sell_book["level1"]["price"], "quantity": order["quantity"]}
        else:
            # 时间优先：按timestamp排序匹配剩余量
            for level in sorted(sell_book.keys(), key=lambda x: float(x[4:])): # level1, level2...
                if sell_book[level]["quantity"] > 0:
                    matched_qty = min(order["quantity"], sell_book[level]["quantity"])
                    sell_book[level]["quantity"] -= matched_qty
                    return {"matched_price": float(level[4:]), "quantity": matched_qty}
    else: # sell
        # 市价单：匹配买方最近价（买一）
        if buy_book["level1"]["quantity"] >= order["quantity"]:
            buy_book["level1"]["quantity"] -= order["quantity"]
            return {"matched_price": buy_book["level1"]["price"], "quantity": order["quantity"]}
        else:
            # 时间优先
            for level in sorted(buy_book.keys(), key=lambda x: float(x[4:])):
                if buy_book[level]["quantity"] > 0:
                    matched_qty = min(order["quantity"], buy_book[level]["quantity"])
                    buy_book[level]["quantity"] -= matched_qty
                    return {"matched_price": float(level[4:]), "quantity": matched_qty}

5) 【面试口播版答案】：各位面试官好，我来回答这个问题。首先，核心思路是构建一个内存优先的订单簿+多级队列撮合引擎+分布式主备架构的系统，实现万级订单秒级撮合，同时保障高可用与低延迟。

具体来说，订单处理分两类：市价单直接匹配最近价（如买一/卖一），限价单按价格分层（买一、买二...）存储，撮合时遵循“价格优先（高买低卖）+ 时间优先（先到先匹配）”规则。比如买方市价单会优先匹配卖方当前最低价（卖一），若不足则按时间顺序匹配卖二、卖三等。

高可用方面，采用多节点主备模式（如通过ZooKeeper选主），主节点处理请求，备节点热备，主故障时自动切换，同时结合熔断降级（如订单量超阈值时限价单暂缓撮合）。低延迟通过内存缓存订单簿（如Redis的String/Hash结构）实现微秒级访问，批量处理（如每100ms撮合一次）减少CPU开销，异步消息（如Kafka）解耦撮合与通知流程，提升吞吐量。

总结来说，这个设计通过订单簿结构优化、分布式架构保障、低延迟技术手段，满足万级订单撮合需求，同时兼顾高可用与低延迟。

6) 【追问清单】：

问题1：如何保证订单一致性？
回答要点：通过分布式事务（如两阶段提交）或最终一致性（如消息队列保证顺序）+ 事务日志（如MySQL binlog）回滚，确保撮合结果与订单状态一致。
问题2：系统如何处理超时或异常订单？
回答要点：设置订单超时机制（如30秒未撮合则自动撤单），异常订单通过监控告警（如Prometheus）快速定位，并触发补偿流程（如重试或人工干预）。
问题3：如何保证系统扩展性？
回答要点：订单簿分片存储（如按订单ID哈希分库），撮合引擎水平扩展（多实例部署），结合负载均衡（如Nginx）分发请求，支持百万级订单扩展。
问题4：撮合规则中“时间优先”如何实现？
回答要点：限价单按提交时间排序（如时间戳），撮合时按时间顺序匹配，避免价格优先导致“价格断层”（如10.5元买方与10.6元卖方无法匹配）。
问题5：高可用方案中，主备切换的延迟如何控制？
回答要点：通过心跳检测（如每秒一次）快速检测主节点故障，备节点在检测到故障后1秒内接管，结合数据同步（如Redis主从复制）减少数据丢失。

7) 【常见坑/雷区】：

坑1：忽略订单一致性，导致价格波动。
雷区：只关注撮合速度，忽略订单状态同步（如撮合成功但订单未更新），引发交易纠纷。
坑2：只考虑单机性能，未设计分布式扩展。
雷区：订单量增长后，单机无法支撑万级撮合，导致系统崩溃。
坑3：高可用方案仅做主备，未处理多活。
雷区：主备切换时，备节点需等待数据同步，导致延迟增加，无法满足秒级撮合要求。
坑4：撮合逻辑错误，如时间优先顺序混乱。
雷区：导致价格优先规则失效（如10.5元买方与10.6元卖方无法匹配），影响交易公平性。
坑5：低延迟方案未考虑内存容量限制。
雷区：订单量过大时，内存溢出导致系统崩溃，无法保障高可用。