消息顺序性：顺序要么是局部的，要么贵得用不起

顺序为什么要紧。 有些消息序列是因果链：先建订单、再扣款、再发货。消费者先收到"发货"再收到"扣款"，那不是性能问题，是正确性事故。所以顺序不是消息系统的锦上添花，是它契约的一部分。

全局有序为什么贵。 总序意味着所有参与者对全部消息的先后持一致看法。建立它，要么让消息过同一个定序点，要么过一轮共识——吞吐被那个点或那轮协商卡死，机器加多少都没用。而且机器之间的"先后"不能靠墙上的时钟定：各机时钟偏差是毫秒级，恰好就是顺序决策所在的尺度。

业界的妥协：顺序只在因果组内承诺。 Kafka 把话说得最直白——只保证单个 partition 内的顺序。同一订单、同一账户、同一用户的全部事件带同一个 key，经分片规则（consistent-hashing 一家）永远进同一个 partition，在那里按发送顺序落盘、按序消费。组与组之间不承诺，因为没有因果要保护。顺序保证的边界，是由业务里因果的边界划的，不是技术划的。

这个形状是复用的。 TCP 几十年前做了同一笔交易：序号保证一条连接内有序，两条连接之间从不排总序。TCP 里的连接，就是 Kafka 里的 partition——顺序称王的小王国。

剩下的三个洞和补法。 (1) 生产者重试会乱序：失败重发的那条落在其后继之后——用生产者序号（幂等生产者）补，broker 据此恢复发送顺序。(2) 并行消费会乱序：多个消费者并行抽一个 partition，完成顺序必然散——partition 内只能串行消费，否则保证作废；这也是 partition 数量决定消费并行度上限的原因。(3) 时间戳排不了序：物理时钟有偏差，严肃系统用逻辑序号定序，或者把定序权收归单点（partition 的 leader）。