kafka的Consumer均衡算法
在说顺序性这个问题之前,我们要先搞明白的是消费者是怎么消费分区上的数据。
我们这里不详细讨论该算法,这不是本文的重点。
简单的说:
-
kafka的消费组的组员最多增加到和partition数量一致,超过的组员只会占用资源,而不起作用;
-
kafka的partition的个数一定要大于消费组组员的个数,并且partition的个数对于消费组组员取模一定要为0,不然有些消费者会占用资源却不起作用;
我们一般将消费组里组员的个数设置为和partition的数量相同。
消息顺序错乱问题
我们都知道Kafka是分布式多partition的,它会将一个topic中的消息尽可能均匀的分发到每个partition上。那么问题就来了,这样怎么保证同一个topic消息的顺序呢?
由于消费者是并行处理消息的,我们就无法保证消息的顺序性。
如何发送顺序消息
这个其实也很简单。
kafka可以通过partitionKey,将某类消息写入同一个partition,一个partition只能对应一个消费线程,以保证数据有序。
也就是说生产者在写消息的时候,可以指定一个 key,比如说我们指定了某个订单 id 作为 key,那么这个订单相关的数据,一定会被分发到同一个 partition 中去,而且这个 partition 中的数据一定是有顺序的。
Kafka如何保证单partition有序?
producer发消息到队列时,通过加锁保证有序。
那么是否有这样一个问题呢?
先后两条消息发送时,前一条消息发送失败,后一条消息发送成功,然后失败的消息重试后发送成功,造成乱序。
为了解决重试机制引起的消息乱序为实现Producer的幂等性,Kafka引入了Producer ID(即PID)和Sequence Number。
对于每个PID,该Producer发送消息的每个<Topic, Partition>都对应一个单调递增的Sequence Number。
同样,Broker端也会为每个<PID, Topic, Partition>维护一个序号,并且每Commit一条消息时将其对应序号递增。
-
对于接收的每条消息,如果其序号比Broker维护的序号大一,则Broker会接受它,否则将其丢弃
-
如果消息序号比Broker维护的序号差值比一大,说明中间有数据尚未写入,即乱序,此时Broker拒绝该消息
-
如果消息序号小于等于Broker维护的序号,说明该消息已被保存,即为重复消息,Broker直接丢弃该消息
-
发送失败后会重试,这样可以保证每个消息都被发送到broker
消费者从 partition 中取出来数据的时候,也一定是有顺序的。到这里,顺序还是 ok 的,没有错乱。
但是消费者这里还是可能会有多个线程来并发来处理消息,因为如果消费者是单线程消费数据,那么这个吞吐量太低了。而多个线程并发的话,顺序可能就乱掉了。
解决方案
消费者端创建多个内存队列,具有相同 key 的数据都路由到同一个内存 队列;然后每个线程分别消费一个内存队列即可,这样就能保证顺序性。