【Kafka】2.纯原创，一张图洞悉Kafka集群

写在前面

本文为Kafka系列文章第二篇，全文可见：

• 【Kafka】1.特性与零拷贝
• 【Kafka】2.纯原创，一张图洞悉Kafka集群
• 【Kafka】3.纯原创，消息的发送/存储/消费流程综述
• 【Kafka】4.高可用及Failover流程
  直接上图！由于原图较大，请点击放大后观看。

kafka集群

图中标出小红点的地方会在接下来的文章中进行介绍：

【1】 Server与Broker关系：

• Server即物理意义上的服务器，Broker为Kafka进程；一般来说一台Server上部署一个Broker
• 理论上一台Server可以起多个Broker，但是这样方式的隐患是一台Server宕机对集群造成很大损失（同时多个Broker不可用）

【2】Broker与关系

• 一个Broker中可以部署多个实例
• 分配方式：将broker和编号，采用取余的方式决定放在哪个broker上

【3】主从复制逻辑

• 读取和写入都只和leader进行通信，follower仅用于故障转移
• 一个可以有多个follower。follower和consumer类似，定期从leader拉取数据进行同步

【4】 Controller

• 集群中的Broker节点中需要选出一个Controller负责故障转移操作：它同时也要负责普通Broker的工作
• 通过竞争性地在ZK上创建/controller节点来决定哪个broker成为controller（先到先得 ）

【5】 Partition 分区

• 分区的目的为提高并发度，由多个consumer消费不同的Partition
• Partition属于Topic，与ConsumerGroup/Consumer无关
• 同一个Topic不同Partition之间消息是不重复的，Partition内部消息保证有序

【6】 Metadata 元数据缓存

• Controller在Zookeeper注册并监听集群信息变更，如有变更则通知集群中的Broker从ZK拉取最新集群信息并更新
• 客户端（producer/consumer）从任一Broker拉取并缓存集群Metadata，用于知晓自己own的在哪台broker上
• 如果集群Metadata变更，客户端请求原先的Broker会返回重定向错误，此时客户端会更新自身的Metadata缓存

【7】 Producer发送消息

• Producer根据消息确认Partition（可指定/根据key哈希取余/轮询）
• 通过Metadata确认Partition所在的Broker，发送消息
• Broker内会对Partition的消息进行聚合写入优化，定时/数据量满16KB时再写入文件中（通过MMAP写入，参考Kafka特性与零拷贝）

【8】ConsumerGroup

消费分组，每个分组内的offset是独立的。一般每个Group对应一个不同的应用。

【9】Consumer 消费者

• 主动拉取消息：速率可控，无消息时忙等待
• 和 ConsumerGroup的关系：同一个ConsumerGroup中的Consumer可以消费1个或者多个partition的消息；
• 注意Consumer数量不能多于Partition数量，多出来的Consumer无法消费到数据

【10】Zookeeper

ZK对于Kafka集群是必须的，用于存储和维护集群中的topic, paritition, brokers, consumer, consumerGroup等信息

参考

1. Kafka集群Metadata管理
2. Zookeeper在Kafka中的作用