3.4 消息顺序性：什么时候会乱，能保到什么程度

3.4 消息顺序性：什么时候会乱，能保到什么程度

本节摘要：单个队列对单消费者是严格先进先出，但重投递、多消费者并行、多队列分片都会打破全局顺序。本节讲清乱序的四个来源、局部有序与全局有序的代价鸿沟，并给出"按业务键分片保序"的标准方案——顺带回答追查第四现场的疑点：那批"没收到"的订单事件，其实是收到了但乱了顺序。

追查第四现场的结论让所有人意外：那批"丢失"的订单事件，一条都没丢。风控系统的消费日志里它们都在——只是"订单创建"排在"订单取消"之后才到，风控先处理了取消再处理创建，状态机当场报错，事件被当异常丢进了错误目录。丢了顺序，等效于丢了消息。

顺序在哪四道关口上失守

关口一，队列内部。单队列对单消费者天然先进先出，这一段是最安全的。唯一的例外是优先级队列：开了 x-max-priority，队列内部就按优先级出队，先进先出作废——需要顺序的队列别开优先级。

关口二，重投递。消费者处理到一半崩溃，未签收消息重新入队。注意它回到的是队列"当前可用"的位置，如果此时后面已有新消息，重投消息未必排在原位。手动签收加重试的可靠性方案，天然携带乱序风险。

关口三，多消费者并行。一个队列起五个消费者，消息虽然按序投出，但五人处理有快有慢：一号消费者拿到 A 在苦战，二号拿到 B 秒完——B 先处理完。并行度就是乱序度，这是一体两面。

关口四，发布方与拓扑。生产者多实例并发发布，谁先到 Broker 本就不定；一发布多队列的扇出拓扑下，各队列独立推进，下游读到的事件流更没有全局可比性。

把四道关口摆在一起，结论就清楚了：全局有序在分布式消息系统里是一个昂贵承诺——它要求单队列、单消费者、无重投、无优先级，等于放弃并行与可靠重试，吞吐上限就是单线程。绝大多数业务要的不是全局有序，而是同一个业务对象的操作有序：同一订单的事件按序处理，不同订单之间顺序无所谓。

完整演练：按订单号分片保序

背景：订单事件流需要"同一订单严格有序、不同订单并行处理"，目标吞吐单队列无法满足。

操作：经典的分片保序方案——用订单号哈希把事件路由到固定队列，每个队列单消费者串行处理：

import pika, json, hashlib

connection = pika.BlockingConnection(pika.ConnectionParameters(host="localhost"))
channel = connection.channel()

# 声明 N 个分片队列，N 取 8：吞吐扩展 8 倍，可按需调整
SHARDS = 8
for i in range(SHARDS):
    channel.queue_declare(queue=f"order.events.shard.{i}", durable=True)

def publish_order_event(event: dict):
    # 同一订单永远落在同一分片：哈希决定归属，与时间无关
    shard = int(hashlib.md5(event["order_id"].encode()).hexdigest(), 16) % SHARDS
    channel.basic_publish(
        exchange="order.sharding",          # direct 交换机
        routing_key=f"shard.{shard}",
        body=json.dumps(event).encode(),
        properties=pika.BasicProperties(delivery_mode=2))
​

每个分片队列起且仅起一个消费者，prefetch 设一，处理完再签收——分片内部严格串行，分片之间完全并行。

结果：订单 A1024 的创建、支付、发货三个事件命中同一个分片，由同一个消费者按发布序处理；八个分片同时运转，总吞吐约等于单队列的八倍。解读：这个方案的三个前提要刻在心里。其一，分片数要预留余量：分片队列同样受"参数不可变更"约束，扩容意味着新建队列加迁移，取十六或三十二起步是常见做法。其二，消费者数绝不能超过分片数：一个队列两个消费者，并行关口立刻失守。其三，哈希键要稳定：用订单号而不是时间戳或自增序号，保证跨天跨实例的一致归属。

变式一：业务只需"最终状态正确"而不在乎中间事件顺序（比如只关心库存最终数），让消费端带版本号做幂等覆盖，乱序无害，方案可以简化成普通并行消费——先问需求再上方案，分片保序是有成本的。变式二：验证重投乱序——分片消费者处理到一半 kill 掉，重启后该消息重新处理，但同一分片内它仍是下一个被处理的：分片保序方案对崩溃重投同样成立，这正是选单消费者串行的隐性收益。

需求分级：先判级，再选型

把顺序需求分成三档，对号入座即可：

第三档的真实需求比想象中少得多。见到"我们要全局有序"的第一反应应该是追问：哪个环节需要？多数时候答案是"某个下游的状态机需要"，那把它降级为键内有序即可。

分片保序方案里还有一块拼图值得补上：幂等去重的最小实现。分片内部串行不等于不重复——重投递仍会让同一订单的同一事件到达两次，保序方案必须配上去重表才算完整：

def process_with_dedup(event: dict):
    key = f'{event["order_id"]}:{event["event"]}:{event["version"]}'
    # 唯一索引兜底：插入成功即首次处理，冲突即重复投递
    inserted = dedup_db.execute(
        "INSERT IGNORE INTO event_seen(event_key, seen_at) VALUES (?, NOW())",
        (key,))
    if not inserted:
        return            # 已处理过，直接跳过
    handle(event)
​

注意去重表的清理策略：保留窗口按业务回放周期定（常见七天），过期清理，否则表无限膨胀反成新的故障点。

💡 关键直觉：顺序与吞吐是一对直接交易的变量。每增加一路并行，全局顺序就碎一分；把顺序约束收窄到业务键上，是两者兼顾的唯一杠杆。

本节要点回顾

• 四个关口：优先级设置、重投递、多消费者、发布与拓扑并行，都会破序；
• 全局有序的代价：单队列单消费者，吞吐锁死，慎选；
• 分片保序：业务键哈希定分片，分片内串行、分片间并行，是标准解；
• 三个前提：分片数留余量、消费者数不超分片数、哈希键稳定；
• 先判级再选型：幂等覆盖能解决的，不要动用分片。

顺序问题收口。五个现场全部查完，下一节把所有线索汇成全链路可靠性方案——本章的最终报告。