Kafka为什么有Topic还用Partition
Topic和Partition是Kafka中国比较重要的概念
- Topic：主题，是Kafka中承载消息的逻辑容器。可以理解为一个消息队列。生产者将消息发送到特定的Topic，消费者从Topic中读取消息。Topic可以被认为是逻辑上的消息流。在实际使用中多用来区分具体的业务。
- Partition：分区，是Topic的物理分区。一个Topic可以被分成多个Partition，每个Partition是一个有序且是持久化的存储日志文件。每个Partition都存储了一部分消息，并且有一个唯一的标识符（简称为Partition ID）。
从上面简单的解释不难看出，这两个看上去其实都是消息的载体。那么为什么还要分为两层呢，有了Topic为什么还需要Partition呢？
在软件领域中，任何问题都可以加一个中间层来解决，而Topic和Partition就是类似的思想，在Topic的基础上，再细粒度的划分出了一层，主要有以下几个好处：
- 提高吞吐量：通过将一个Topic分成多个Partition，可以实现消息的并行处理。每个Partition可以由不同的消费者进行独立消费，这样就可以提高整个系统的吞吐量。
- 负载均衡：Partition的数量通常比消费者组的数量多，这样可以使每个消费者组中的消费者均匀地消费消息。当有新的消费者加入或离开消费者组时，可以通过重新分配Partition的方式进行负载均衡。
- 更好的扩展性：通过增加Partition的数量，可以实现Kafka集群的扩展。更多的Partition可以提高更高的并发处理能力和更大的存储容量。
综上所述，Topic是消息的逻辑分类，而Partition是物理上的消息分区。通过Topic分成多个Partition，可以实现提高吞吐量、负载均衡、以及由更好的扩展性。
什么是Kafka的重平衡机制？
Kafka的重平衡机制是指再消费者组中新增或删除消费者时，Kafka会重新分配Topic Partition给各个消费者，以保证每个消费者消费的分区数量尽可能均衡。
重平衡机制的目的时实现消费者的负载均衡和高可用性，以确保每个消费者都能够按照预期的方式消费到消息。
触发重平衡的3个条件：
- 消费者组成员数量发生变化。
- 订阅主题数量发生变化。
- 订阅主题的分区数发生变化。
当Kafka集群要出发重平衡机制时，大致步骤如下：
- 暂停消费：在重平衡开始之前，Kafka会暂停所有消费者的拉取操作，以确保不会出现重平衡期间的消息丢失或重复消费
- 计算分区分配方案：Kafka集群会根据当前消费者组的消费者数量和Topic Partition数量，计算出每个消费者应该分配的分区列表，以实现分区的负载均衡
- 通知消费者：一旦分区分配方案确定，Kafka集群会将分配方案发送给每个消费者，告诉它们需要消费的分区列表，并请求它们重新加入消费者组
- 重新分配分区：在消费者重新加消费者组后，Kafka集群会将分区分配方案应用到实际的分区分配中，重新分配主题分区给消费者
- 恢复消费：最后，Kakfa会恢复所有消费者的拉取动作，允许它们消费分配给自己的分区
Kafka的重平衡机制能够有效地实现消费者的负载均衡和高可用性，提高消息的处理能力和可靠性。但是，由于平衡会带来一定的性能开销和不确定性，因此在设计应用时需要考虑到重平衡的影响，并采取一定的措施来降低重平衡的频率和影响。
在重平衡过程中，所有Consumer实例都会停止消费，等待重平衡完成。但是目前并没有什么好的办法来解决重平衡带来的STW，只能尽量避免它的发生。
消费者的五种状态
Kafka的Consumer实例的五种状态，分别是：
| 状态 | 描述 |
|---|---|
| Empty | 组内没有任何成员，但是消费者可能存在已经提交的位移数据，而且这些位移尚未过期 |
| Dead | 同样是组内没有任何成员，但是组的元数据信息已经被协调者端移除，协调者保存着当前向他注册过的所有组信息 |
| PreparingRebalance | 消费者组准备开启重平衡，此时所有成员都需要重新加入消费者组 |
| CompletingRebalance | 消费者组所有成员已经加入，各个成员中等待分配方案 |
| Stable | 消费者组的稳定状态，该状态表明重平衡已经完成，组内成员能够正常消费数据 |
状态的流转过程：
Kafka几种选举过程
在Kafka中常见的几种选举过程如下：
Partition Leader选举
Kafka中的每个Partition都有一个Leader，负责处理该Partition的读写请求。在正常情况下，Leader和ISR集合中的所有副本保持同步，Leader接收到的消息也会被ISR集合中的副本所接收。当Leader副本宕机或者无法正常工作时，需要选举新的Leader副本来接管分区的工作。
Leader选举的过程如下：
- 每个参与选举的副本会尝试向Zookeeper上写入一个临时节点，表示它们正在参与Leader选举。
- 所有写入成功的副本会在Zookeeper上创建一个序列号节点，并将自己的节点序列号写入该节点。
- 节点序列号最小的副本会选为新的Leader，并将自己的节点名称写入Zookeeper上的的
/broker/.../leader节点中
Controller 选举
Kafka集群中只能有一个Controller节点，用于管理分区的副本分配、leader选举等任务。当一个Broker变成Controller后，会在Zookeeper的/controller节点中记录下来。然后其它的Broker会实时监听这个节点，主要就是避免这个Controller宕机的话，就需要重新选举。
Controller选举的过程如下：
- 所有可用的Broker向Zookeeper注册自己的ID，并监听Zookeeper中/Controller节点的变化
- 当Controller节点出现故障时，Zookeeper会删除/controller节点，这是所有的Broker都会监听到该事件，并开始争夺Controller的位置
- 为了避免出现多个Broker同时竞选Controller的情况，Kafka设计了一种基于Zookeeper的Master-Slave机制，其中一个Broker成为Master，其它Broker成为Slave，Master负责选举Controller，并将选举结果写入Zookeeper中，而Slave则监听/controller节点的变化，一旦发现Master发生故障则开始争夺Master的位置
- 当一个Broker发现Controller失效时，它会向Zookeeper写入自己的ID，并尝试竞选Controller的位置。如果创建临时节点成功，则Broker成为新的Controller，并将选举结果写入Zookeeper中
- 其它的Broker会监听到Zookeeper中/controller节点的变化，一旦发现选举结果发生变化，则更新自己的元素据信息，然后与新的Controller建立连接，进行后续操作
Kafka中，为什么节点序列号最小的副本会被选为新的Leader
在Kafka中，节点序列号最小的副本被选为新的Leader是因为Kafka使用了Zookeeper作为协调服务。在Kafka集群中，Zookeeper负责维护集群的元数据（例如Topic和Partition信息）以及Brokers（Kafka服务器）的状态
当一个Broker（副本）成为Leader候选人时，它会向Zookeeper注册自己并申请成为该分区的Leader。在这个过程中，每个候选人都会创建一个临时带有递增序列号的Zookeeper节点，被称为选举竞争者（election contender）
当都选人注册完成后，它们会查询Zookeeper并比较自己的序列号与其他候选人的序列号。Kafka采用基于递增序列号的最小值来选择新的Leader。因此，具有最小序列号的候选人将成为新的Leader，并负责处理该分区的所有读写请求
通过这种方式，Kafka实现了简单而有效的Leader选举机制，确保了高可用性和数据一致性。选择序列号最小的副本作为Leader可以避免分区不一致的情况，并且能够迅速的恢复正常操作，因为Zookeeper节点序列号是唯一且递增的
如有问题，欢迎加微信交流：w714771310，备注- 技术交流 。或关注微信公众号【码上遇见你】。
好了，本章节到此告一段落。希望对你有所帮助，祝学习顺利。