写在前面
本文为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与<topic, partition, leader/follower>关系
- 一个Broker中可以部署多个<topic, partition, leader/follower>实例
- 分配方式：将broker和<topic, partition>编号，采用取余的方式决定放在哪个broker上
【3】主从复制逻辑
- 读取和写入都只和leader进行通信，follower仅用于故障转移
- 一个<topic, partiton>可以有多个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的<topic, partition>在哪台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等信息
