目录
Broker
描述
1. 定义：
- Broker是Kafka集群中的一个服务器节点，负责存储消息数据并处理客户端（如Producer和Consumer）的请求。
2. 标识：
- 每个Broker都有一个唯一的标识符，称为broker.id，用于在集群中区分不同的Broker。
3. 功能：
- 存储消息：Broker将Producer发送的消息存储到磁盘上。
- 转发消息：Broker将存储的消息转发给订阅该消息的Consumer。
- 管理分区：Broker负责管理Kafka中的分区（Partition），包括分区的创建、删除、复制等。
zookeeper存储情况
下图为zookeeper节点中的存储
- 具体主题节点： 每个主题在ZooKeeper中都有一个节点，节点名称为主题ID，如 [0,1,2]。 在该节点下，存储了与主题相关的各种信息，例如 ids, topics, seqid等。
- 事务状态和分区信息： 图片中展示了事务状态（__transaction_state）和分区信息（partitions）。 partitions节点下存储了每个分区的详细信息，包括每个分区的leader和ISR（In-Sync Replicas）列表。
每个分区的信息以epoch和leader为标识，存储其状态以及ISR列表。- 消费者偏移量： 消费者的偏移量信息存储在 __consumer_offsets 路径下。 每个消费者的状态信息以epoch和消费者ID为标识，存储其状态以及分区信息。
Broker组成
1. 网络层：
- Broker通过网络层与客户端进行通信，接收Producer发送的消息，并将消息发送给Consumer。
2. 存储层：
- Broker将消息存储到磁盘上，采用分段（Segment）存储的方式，每个Segment包含一个.log文件和一个.index文件。
- .log文件用于存储消息数据，.index文件用于存储消息的偏移量索引，便于快速查找消息。
3. 控制器（Controller）：
- 每个Kafka集群都有一个Controller，负责集群的元数据管理、Leader选举、分区重分配等任务。
- Controller通常运行在集群中的某个Broker上，当该Broker发生故障时，会触发新的Controller选举。
4. 复制管理器：
- Broker负责管理分区的副本（Replica），包括Leader和Follower的选举、消息复制等。
- 当Leader发生故障时，复制管理器会从ISR（In-Sync Replicas）中选择新的Leader。
Broker工作流程
1. 启动与注册
启动Broker： 当启动一个Kafka Broker时，它会首先进行初始化操作，加载配置文件，创建必要的线程和组件。
向ZooKeeper注册： Broker启动后，会向ZooKeeper注册自己的信息。ZooKeeper是Kafka集群的元数据存储中心，负责维护集群的状态信息。Broker会在ZooKeeper的/brokers/ids路径下创建一个节点，节点名称是Broker的唯一标识符（broker.id），并存储该Broker的地址和端口等信息。
注册Controller： Kafka集群中的每个Broker都有一个内置的Controller组件。Controller负责集群的元数据管理、Leader选举、分区重分配等重要任务。在Broker启动后，会尝试在ZooKeeper的/controller路径下注册自己为Controller。第一个成功注册的Broker将成为集群的Controller，负责监听其他Broker的状态变化。
2. 监听与响应
监听ZooKeeper变化： Broker会持续监听ZooKeeper中与自己相关的节点的变化。例如，它会监听/brokers/ids路径下其他Broker的状态变化，以便在集群中其他Broker发生故障时，能够及时调整自己的状态。
处理客户端请求： Broker接收来自Producer（生产者）和Consumer（消费者）的请求。Producer向Broker发送消息，Broker将消息存储到磁盘中；Consumer从Broker订阅消息，Broker将消息发送给Consumer。Broker处理这些请求时，会根据消息的主题（Topic）和分区（Partition）进行路由。
3. 消息的存储与处理
存储消息： 当Broker接收到Producer发送的消息时，会首先将消息写入到操作系统的页面缓存中，然后异步地刷新到磁盘上。Kafka采用分段（Segment）存储的方式，每个Segment包含一个.log文件（存储消息数据）和一个.index文件（存储消息的偏移量索引）。这种方式既提高了写入性能，又便于消息的快速查找和删除。
消息复制： 为了提高消息的可靠性，Kafka支持消息的复制。每个Partition可以有多个副本（Replica），其中一个副本是Leader，负责处理读写请求；其他副本是Follower，从Leader同步消息数据。当Leader发生故障时，可以从Follower中选举出新的Leader，继续处理消息。
Leader选举： 当Leader发生故障时，Broker会触发Leader选举过程。Controller负责监控所有Broker和Partition的状态，当检测到Leader故障时，会在ZooKeeper中更新Leader信息，并通知所有Broker更新本地的Leader缓存。新的Leader会从ISR（In-Sync
Replicas，与Leader保持同步的副本集合）中选择，以确保消息的可靠性和一致性。
4. 处理Consumer请求
消费偏移量管理： Broker还负责管理Consumer的消费偏移量。Consumer在消费消息时，会定期向Broker提交自己的消费偏移量，Broker会将偏移量存储到ZooKeeper或Kafka内部的特定Topic中。这样，即使Consumer发生故障重启，也能从上次消费的位置继续消费消息。
响应Consumer请求： 当Consumer向Broker发送消息获取请求时，Broker会根据Consumer提供的主题、分区和偏移量信息，从相应的Segment中读取消息数据，并返回给Consumer。Broker会确保Consumer读取到的是已经成功复制到ISR中的消息，以保证消息的一致性。
5. 集群协作与维护
负载均衡： Kafka集群支持动态的负载均衡。当新增或删除Broker时，Controller会触发分区重分配过程，将现有的分区重新分配到集群中的Broker上，以均衡负载。
监控与报警： Broker会定期向ZooKeeper报告自己的状态信息，如磁盘使用情况、网络延迟等。Controller会监控这些信息，并在检测到异常情况时触发报警或采取相应的措施。
故障恢复： 当Broker发生故障时，Controller会触发故障恢复流程。它会在ZooKeeper中更新Broker的状态信息，通知其他Broker停止向故障的Broker发送请求，并从ISR中选择新的Leader继续处理消息。同时，Controller会尝试重启故障的Broker，并在其恢复后重新加入集群。
副本
1. Kafka 副本作用：避免单点故障，提高数据可靠性。 partition是有序消息日志，那么一定不能只保存这一份日志，否则一旦保存partition的Kafka服务器挂掉了，其上保存的消息也就都丢失了。分布式系统必然要实现高可靠性，而目前实现的主要途径还是依靠冗余机制一一简单地说，就是备份多份日志。这些备份日志在Kafka中被称为副本(replica),它们存在的唯一目的就是防止数据丢失，这一点一定要记住！
2. Kafka 默认副本 1 个，生产环境一般配置为 2 个，保证数据可靠性；太多副本会增加磁盘存储空间，增加网络上数据传输，降低效率。
3. Kafka 中副本分为：Leader 和 Follower。Kafka 生产者只会把数据发往 Leader，然后 Follower 找 Leader 进行同步数据。Leader 发生故障之后，就会从 ISR 中选举新的 Leader。
4. Kafka 分区中的所有副本统称为 AR（Assigned Repllicas），AR = ISR + OSR。
- ISR(in-sync replica)，表示和 Leader 保持同步的 Follower 集合。
- OSR，表示 Follower 与 Leader 副本同步时，延迟过多的副本。
- 如果 Follower 长时间未向 Leader 发送通信请求或同步数据，则该 Follower 将被踢出 ISR，放到OSR。该时间阈值由replica.lag.time.max.ms参数设定，默认 30s。
- 当OSR中Follower重新"追上"了Leader的进度时，OSR->ISR。