在业务中使用kafka发送消息异步消费的场景，并且需要实现在消费时实现顺序消费， 利用kafka在partition内消息有序的特点，实现消息消费时的有序性。

1、在发送消息时，通过指定partition hash
2、consumer 消费消息时，需要使用亲缘性线程池进行消费，才能实现消息的基本有序。否则即使通过发送时指定partition，在消费端由于线程池的异步消费，消息之间的处理都是并发进行的，消息就会被打乱。

上面的方式基本可以实现消息的消费顺序性，除了在极端场景下，比如：

1、进程A 在T0时刻发送一个消息A
2、进程B在T1时刻发送了一个消息B。

  由于T1>T0，并且进程A和进程B发送消息都是同一个hash partition，消息理论上在partition内消息A是在消息B前被消费的。但假如进程A和进程B出于不同的机房等原因，导致在发送消息时进程A的消息由于网络原因，要比进程B更晚发送成功，那么就会导致消息B是在消息A之前。

多集群模式下

由于kafka的有序性，只是在单集群的单partition内是有效的，所以当多集群模式下，各个集群之间的消息就不满足了有序的条件。虽然由于每个集群都是使用相同的配置，都映射同一个consumer进程消费，如下：

image

但是由于cluster-1-partition-5和cluster-2-partition-5两个partition之间的是不同的partition，所以没有办法做到绝对有序。

同时由于conusmer-1会出现跨机房消费的多个集群的情况，所以原本在单集群模式下，由于网络耗时而导致的消息先后顺序，在多集群情况下就会增大。目前跨集群消费延迟在2-10ms之间，所以在实际业务处理中遇到了消息A比消息B早发送，在消息B先到达的场景。

io瓶颈

由于需要在consume端实现顺序消费，需要使用亲缘性线程池以确保同一个sku在同一个线程中消费消息。这种方式当某个sku的消息量特别大时，那么就会阻塞了io线程，导致其他消息也出现大量延迟。目前默认io线程拉取消息按broker来的，应该是等同于broker数量。虽然可以增加io线程数来减缓这个情况，但依然会存在这个场景。

总结

  在分布式场景下要实现消息消费强顺序性需要付出很大的成本，并且需要做到绝对顺序十分困难。如果可以容忍这个消费的无序性，那么往往就不需要用到顺序消费了。 以上分析为实际应用中遇到的坑，仅供参考，欢迎拍砖。
ps：
  业务进程在发送kafka消息后，会有一个linger时间，等待linger时间之后再发送.