kafka架构详解

大佬1 | 大佬2
以下博文由上面两个大神的博文整理

---

kafka整体架构

角色：

broker

装有 kafka服务的机器（kafka代理），一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。

produce

向Kafka发布(写)消息的客户端应用程序

consumer

订阅(读和处理)kafka消息的客户端应用程序
生产者和消费者是完全解耦的，并且彼此是不可知的，这使得其变得非常容易扩展和灵活

Consumer Group

消费者组（CG），消费者组内每个消费者负责消费不同分区的数据，提高消费能力。一个分区只能由组内一个消费者订阅,消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

topic

produce发送消息时指定的主题，像数据库中的表，其可以有多个分区，每个分区有多个segment，每个sement有一个偏移量文件和一个数据文件。

Partition

为了实现扩展性，提高并发能力，一个非常大的 topic 可以分布到多个 broker （即服务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个 有序的队列。

Replica

副本，为实现备份的功能，保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失，且 Kafka 仍然能够继续工作，Kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。

Leader

每个分区多个副本的“主”副本，生产者发送数据的对象，以及消费者消费数据的对象，都是 leader。

Follower

每个分区多个副本的“从”副本，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 还会成为新的 leader。

offset

消费者消费的位置信息，监控数据消费到什么位置，当消费者挂掉再重新恢复的时候，可以从消费位置继续消费。

Zookeeper

Kafka 集群能够正常工作，需要依赖于 zookeeper，zookeeper 帮助 Kafka 存储和管理集群信息。

kafkaControl选举

control

control为利用zookeeper选举机制从brokers中选举出来的broker

职责

1. 监听broker变化，通过监听Zookeeper中的 /brokers/ids/ 节点方式来实现
2. 监听topic变化，通过监听Zookeeper中的 /brokers/topics 节点方式来实现，实时监听topic变化
3. 管理topic、partition、broker相关的信息
4. 更新数据的元数据信息，同步到其他的broker节点
   
   

选举过程
broker控制器选举的原理是借助于zookeeper的临时节点实现： kafka集群启动时，每个broker都会尝试争当控制器，都会往zookeeper的controller节点注册自己，但是由于zookeerper的特性，如果节点已经创建过，再创建就会失败，所以只会有一个broker创建成功，那么创建成功的broker就会成为控制器;此外其他broker都会监听这个controller节点。
由于controller是临时节点，当控制器broker挂机之后，就会断开与zookeeper的会话连接，临时节点也会消失，其它节点监听到controller节点消失后，就会重新争取controller节点。

kafkaPartitionLead选举

lead

lead是从topic的partition中选举出来的，负责和produce建立联系

职责

Partition副本选择机制
当controller感知到副本leader所在的broker宕机之后，会在当前副本所在的副本列表中选出第一个副本所在的broker作为副本leader，并且要保证这个broker一定要在副本的ISR(存活的副本broker)集合中，如果第一个不存在，则继续尝试第二个第三个，直到满足；

kafka消息发送过程及数据一致性保证

Kafka集群将 Record 流存储在称为 topic 的类别中，每个记录由一个键、一个值和一个时间戳组成。

数据写入

produce写入
生产者使用push模式将消息发布到broker中，每条消息都被追加到partition中，属于顺序写磁盘
broker根据以下规则将消息发布到指定分区中

1. produce指定分区号，直接发往该分区
2. 没指定分区
   2.1 没指定分区，有key: key hash值对分区数取模，选择分区
   2.2 没指定分区，没key：第一次生成一个随机数，对分区数取模，选择分区，第二次及以后， 每次递增1，取模，选择分区（轮询）

broker数据存储

Kafka 中消息是以 topic 进行分类的，生产者生产消息，消费者消费消息，面向的都是同一个 topic。topic 是逻辑上的概念，而 partition 是物理上的概念，每个 partition 对应于一个 log 文件，该 log 文件中存储的就是 Producer 生产的数据。Producer 生产的数据会不断追加到该 log 文件末端，且每条数据都有自己的 offset。消费者组中的每个消费者，都会实时记录自己消费到了哪个 offset，以便出错恢复时，从上次的位置继续消费。

partition分片
由于生产者生产的消息会不断追加到 log 文件末尾，为防止 log 文件过大导致数据定位效率低下，Kafka 采取了分片和索引机制，将每个 partition 分为多个 segment，每个 segment 对应两个文件：“.index” 索引文件和 “.log” 数据文件。这些文件位于同一文件下，该文件夹的命名规则为：topic 名-分区号。例如，first 这个 topic 有三分分区，则其对应的文件夹为 first-0，first-1，first-2。

consumer数据消费

consumer从topic中拉取数据，吃的自助餐，吃多少取多少，拒绝浪费（防止吃撑）
分区分配策略
range: 默认
按主题分，同一消费者组如果消费不同主题，可能造成消息分配不对等问题，当消费者组内订阅的主题越多，分区分配可能越不均衡。
RoundRobin
轮询,consumer大于分区数时，按分区名hash进行排序，多于分区数的消费者会按顺序从前往后一个加一个分区，负载均衡，但需要对采集过来的数据进行排序时不同主题的数据可能会混乱

数据一致性保证

配置acks为all或-1, 设置数据发送模式为sync (保证数据不丢)
开启幂等性 (保证数据不重复)