分布式场景下Kafka消息顺序性的思考

在业务中使用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时间之后再发送.

你可能感兴趣的:(分布式场景下Kafka消息顺序性的思考)