@toc:
- Kafka高吞吐量的实现?
- 消息顺序性如何保证?
- Consumer Group如何防止重复消费?
- Partition多副本选举机制的实现?
➤ Kafka特性解析:
每个 partition 存于不同的 broker 机器上，一个partition可以有副本存在于多个 broker;
每个partition都有一个唯一的leader， 其他的 partition 作为folower, 所有的读写操作都在leader上完成， follower定期从 leader partition 同步数据;
每个partition的leader和follower都与zk建立长连接, 如果 leader partition 挂掉, 从 follower上选举出新的 leader;
- 吞吐量: 因为每条消息都被append到该partition中，是顺序写磁盘，因此效率非常高（经验证，顺序写磁盘效率比随机写内存还要高，这是Kafka高吞吐率的一个很重要的保证）。
- 水平扩展: 每一条消息被发送到broker时，会根据paritition规则选择被存储到哪一个 partition。如果 partition规则设置的合理，所有消息可以均匀分布到不同的partition里，这样就实现了水平扩展。
- 顺序性: 在发送一条消息时，还可以指定这条消息的key，producer根据这个key和partition机制来判断将这条消息发送到哪个parition。业务上, 多条相关的有顺序的消息, 可以指定同一个Key, 就可以保证都发送到同一个partition并有序;
- 删除策略: 对于传统的message queue而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，无论其被消费与否。当然，因为磁盘限制，不可能永久保留所有数据（实际上也没必要），因此Kafka提供两种策略去删除旧数据。一是基于时间(固定时间点清理)，二是基于partition文件大小
- Consumer Group概念:
- 一个Consumer Group 可以订阅多个Topic
- 一个Consumer Group 有唯一的 GroupID, 可以包含多个 Consumer 实例, Topic下某条消息只能给这个Consumer Group其中一个Consumer实例消费( 某 Topic下的一条消息,只能被某个 Consumer Group 消费一次, 但可以被多个 Consumer Group 消费)
- Consumer Group防重复消费:
- Consumer Group 中一个实例只能消费某Topic下面的一个分区 (当然其他 Group也可以消费这个分区), 所以记录下这个Group对于某个Topic的某个Partition的消费offset即可, offset的存储是在Zk的节点下
/consumers/<group.id>/offsets/<topic>/<partitionId>; - offset的提交: 在旧版本kfk中, 每个Consumer Group的 offset数据是提交到 Zookeeper的, 但是zk并不适合大量写入操作, 所以kafka提供了另一种方案: 额外创建一个叫
__consumer_offsets的Topic, 将offset写入这个Topic, 摆脱对Zk的依赖. 由于这个Topic使用了 Compact策略, 该Topic保存的总是最新的offset, 存储格式是顺序的:| GroupId1:Parttion1:offset | GroupId1:Parttion2:offset | ... |
- Consumer Group 中一个实例只能消费某Topic下面的一个分区 (当然其他 Group也可以消费这个分区), 所以记录下这个Group对于某个Topic的某个Partition的消费offset即可, offset的存储是在Zk的节点下
- Rebalance:
- 什么是Rebalance? 例如 Consumer Group A下有 20个消费者, 它订阅了一个有 100个分区的 Topic, 每个消费者分配一部分分区, 当这个 Consumer Group中新增或删除了消费者, 就需要给现有的消费者重新分配分区, 这个过程叫做 Rebalance
- consumer rebalance算法 @link:: [[../_attachments/Kafka- a Distributed Messaging System for Log Processing.pdf]]
➤ Kafka高可用实现:
- HA:partition多副本同步机制:
- 方式1: 同步复制, leader要保证所有follower都写入后, 才把这条消息确认为commit, 影响吞吐
- 方式2: 异步复制, 只需要leader写入完成, 消息就算commit了. 如果leader partition宕机, 可能丢失一部分数据
- kafka的多副本同步机制不同于1和2, Kafka在Zookeeper中动态维护了一个ISR（in-sync replicas）列表, 一条消息只有被 in sync列表里所有follower都同步了, 这条消息才算commit.落后太多的follower从ISR列表剔除
- HA:partition选举机制:
- 只有 in sync 列表里的成员才有被选举为leader的可能。在这种模式下，对于f+1个replica，一个Kafka topic能在保证不丢失已经commit的消息的前提下容忍f个replica的失败。ISR可以看成是吞吐量和冗余度的一个平衡.
- 分区选举机制见: 消息队列-Kafka-选举机制
@ref Kafka消费组(consumer group) - huxihx - 博客园
@ref 各消息队列对比，Kafka深度解析，众人推荐，精彩好文！大数据一切依旧的专栏-CSDN博客