基本概念
消费者:负责定于Topic,并从Topic拉取消息
消费组:每个消费者都有对应的消费组。消息发布到Topic中,只会被投递给订阅它的每个消费组中的一个消费者
基于消费者-消费组的模型,可以是的Kafka在消费消息方面具有很好的伸缩性。
消息投递模式
点对点:每条消息只会被一个消费者使用
发布订阅:一对多广播
- 可以采用集合或者正则表达式订阅主题
- 集合方式,以最后一次的为准
- 正则,以最新为准,一般多用于系统之间数据复制
- 除订阅主题外,可以订阅指定分区
消息消费
消费模式:一般有俩种,推和拉。Kafka基于拉。
拉的内部还包含消费位移,消费者协调器,组协调器,消费者的选举,分区分配的分发,再均衡的逻辑,心跳等内容。
消息结构:与ConsumerRecord相对应,内部多了偏移量,时间戳
位移提交
offset
- 对于分区而言,表示消息在分区中对应的位置
- 对于消费者而言,代表消费到分区中某个消息所在的位置
- 每次调用poll方法时,返回的是未被消费的消息集,因此偏移量需要持久化。除此之外新添加消费者,再均衡也需要偏移量。
- 旧版客户端的偏移量存储到ZooKeeper,新版存储到Kafka内部的主题**_cunsumer_offsets**中
- 消费完消息之后执行消费位移的提交,提交有自动和手动。提交不合理会造成消息重复消费。
再均衡
- 分区的所属权从一个消费者转移到另外的一个消费者
- 为消费组具备高可用,伸缩性提供保障
- 发送期间,消费组不可用。原有的消息状态不会同步,尚未提交的会造成重复消费。
多线程
- KafkaCustomer非线程安全。内部定义了acquire方法,用来检测当前是否只有一个线程操作。公用方法都会调用这个方法,除了wakeup方法。
- acquire类似轻量级锁,不会阻塞等待。通过线程操作计数的方法来检测线程。
- 实现多线程方式
- 依靠一个Customer实例一个线程的方式去消费消息
- 多线程消费同个分区,代码逻辑复杂。
- 对于消息处理增加多线程,但消息的顺序性需要考虑。可以减少TCP连接
- 创建一个滑动窗口。窗口包含消息,内部细分网格。消费者消费网格,完成之后提交,窗口滑动。网格长时间不提交,进行重试处理或其他处理。