24｜消息顺序：保证消息有序，一个 topic 只能有一个 partition 吗？

作者回复: 丢回去原本的分区就可以了，啥也不用做。但是消息积压的时候，你这个消息就要过很久才能消费到。

作者回复: 最简单的做法，就是重新哈希之后，目标分区暂停消费一会。举个例子来说，原本消息是哈希到 A 分区的，后面重新哈希到 B 了，那么 B 暂停一会就可以。暂停的时间就是考虑到 A 上的都被消费了的时间。如果有 A 上有消息积压就会有比较多的问题。 如果业务上能够检测出来，那么就在 B 上消费的时候，重新丢回去 B 里面。

作者回复: 老大难的问题了，哈哈哈哈。 说实在的，我也没特别好的的办法。如果你们本身就有那种排序机制，比如说我可以通过状态来判定消息是不是失序了，比如说当状态还是未支付的时候，你收到取消消息，这肯定是乱序了。那么你就可以尝试把取消消息重新发回去原本的消息队列上。 另外一种有漏洞的做法就是借助延迟消息。比如说你 A1 消息在重试，A2 不管知不知道 A1 在重试，直接自己延迟一分钟发送。“一分钟”是假定你的 A1 肯定能在一分钟之内重试完成。 当然，如果 A2 的发送者有办法知道 A1 还没发，那么就可以优化成只有当 A1 没发，A2 才会延迟，当然 A3，A4... 显然也要跟着延迟。 比如说，你可以借助 redis，假设 key1=1 的时候，代表 A1 还没发。key1=2 的时候，A1 已经发了。那么 A2 的发送者看一眼 Redis 就知道了。 不过，我的个人看法是……除非是面试吹牛，不然实践中直接告警拉到。就是在真的发现消息失序的时候，告警，人手工微调一下就可以。可用性高的话，你可能一个月才有一个两个这种失序的问题。

作者回复: 分区挂了倒还好，毕竟生产者都发不出来。要解决 rebalance，有一个不太好的办法，但是勉强能用。就是消费者这边手动指定分区。 这样做的话，就是要做好监控。一旦消费特定分区的消费者崩溃了，要及时启动另外一个消费者来消费同样地分区。

作者回复: 好问题。盲猜你是用了不同的 topic 是不是？就是退单的消息用了一个 topic，但是下单的用了另外一个 topic。 如果你是这种的话，只能用我提到的跨 topic 有序的方案，要有一个协调者进来，这个协调者在收到退单的时候，要先去看看有没有收到下单的消息。 但是一般用不着这样，以为你只需要检测有没有这个订单，或者状态是否符合，不符合你就丢回去原本的 topic 里面。或者你设定一个时间，比如说三十分钟之后再处理这个退单消息，然后预期三十分钟内应该能收到下单消息。

作者回复: 可以。你的思路就是，如果我前置消息不满足，我就临时放一个地方。控制住重试就可以。

作者回复: 1. 你是说那个内存队列？就是载体不同。如果是内存队列，那么宕机就没了。 2. 一样会有数据不均匀的问题，但是更加容易解决，因为你开启队列的时候，自己应用一下一致性哈希之类的算法就可以解决了。 不过其实你可以考虑只用一个队列，线程都从这里面取。就是在最后要协调大家停下来批量提交麻烦一点，倒也还可以接受。

作者回复: 1. 确实，极端情况会出现你说的问题。但是并不影响我这里的方案解决了大部分的数据倾斜问题。而且短时间的 QPS 激增不需要去管它，本身 Kafka 就能削峰。而如果你说长时间持续性的单个用户 QPS 激增，你给它一个白名单，让它自己独享一个 topic，彻底隔离掉； 2. 它只会引起新分区上的消息短暂积压，不会引起失序。当你都积压了一大堆数据，比如说要好几个小时才能消费完的时候，你需要的不是增加分区，而是考虑先用异步消费的方案解决。

作者回复: 有一个简单的做法，你可以尝试，就是这个特定的分区，你会消费，但是你只是读了消息之后啥也不干。等到你确定老分区上的老数据消费之后，你可以重置这个分区的偏移量，这一次消费就是真的执行业务逻辑了。

作者回复: 1.1 不需要调整。你可以认为，你的环是不变的，变的是上面的节点； 1.2 也可以。 2 看你业务有没有这个要求。在有序消息的场景下，就是需要的。最好就是调整后的新分区，暂时停止一段时间消费。