Kafka 为分区引入了多副本（Replica）机制，通过增加副本数量可以提升容灾能力。同一分区的不同副本中保存的是相同的消息，每个分区都有一个 leader 副本和多个 follower 副本，其中leader副本负责处理读写请求，follower副本只负责与leader副本的消息同步。副本处于不同的broker中，当leader副本出现故障时，Kafka 会自动从 follower 副本中选举一个新的 leader 副本对外提供服务。这个过程称为副本重分配。在副本重分配期间，Kafka 仍然可以正常工作，但可能会出现一些延迟。Kafka通过多副本机制实现了故障的自动转移，当Kafka集群中某个broker失效时仍然能保证服务可用。

如图，Kafka集群中有4个broker，某个主题中有3个分区，且副本因子（即副本个数）也为3，如此每个分区便有1个leader副本和2个follower副本。生产者和消费者只与leader副本进行交互，而follower副本只负责消息的同步，很多时候follower副本中的消息相对leader副本而言会有一定的滞后。

Kafka 的副本机制可以提供以下好处：

① 数据可靠性：即使某个副本失效，数据仍然可以从其他副本中恢复。

② 高可用性：即使某个副本失效，Kafka 仍然可以正常工作。

③ 提高读取性能：由于可以从任意一个副本中读取消息，因此可以提高读取性能。

Kafka 消费端也具备一定的容灾能力。Consumer 使用拉（Pull）模式从服务端拉取消息，并且保存消费的具体位置，当消费者宕机后恢复上线时可以根据之前保存的消费位置重新拉取需要的消息进行消费，这样就不会造成消息丢失。

Kafka是一种分布式流处理平台，其中ISR、AR和OSR是Kafka中的三个重要概念。

① ISR（In-Sync Replicas）：指的是与Leader副本保持同步的副本集合。当Producer发送消息到Kafka集群时，只有ISR中的副本才会被写入消息，确保数据的可靠性和一致性。如果ISR中的某个副本无法与Leader保持同步，则该副本将被从ISR中移除，直到与Leader重新同步。

② OSR（Out-of-Sync Replicas）：指的是与Leader副本失去同步的副本集合。当ISR中的某个副本无法与Leader保持同步时，该副本将被移动到OSR中，直到与Leader重新同步。

③ AR（Assigned Replicas）：指的是被分配到某个Partition的副本集合。AR包括ISR和OSR。

总之，ISR是Kafka中保证数据可靠性和一致性的重要机制，而AR和OSR则是与Partition相关的副本集合。

分区中的所有副本统称为AR 。所有与leader副本保持一定程度同步的副本（包括leader副本在内）组成ISR，ISR集合是AR集合中的一个子集。消息会先发送到leader副本，然后follower副本才能从leader副本中拉取消息进行同步，同步期间内follower副本相对于leader副本而言会有一定程度的滞后。前面所说的“一定程度的同步”是指可忍受的滞后范围，这个范围可以通过参数进行配置。与leader副本同步滞后过多的副本（不包括leader副本）组成OSR，由此可见，AR=ISR+OSR。在正常情况下，所有的 follower 副本都应该与 leader 副本保持一定程度的同步，即AR=ISR，OSR集合为空。

leader副本负责维护和跟踪ISR集合中所有follower副本的滞后状态，当follower副本落后太多或失效时，leader副本会把它从ISR集合中剔除。如果OSR集合中有follower副本“追上”了leader副本，那么leader副本会把它从OSR集合转移至ISR集合。默认情况下，当leader副本发生故障时，只有在ISR集合中的副本才有资格被选举为新的leader，而在OSR集合中的副本则没有任何机会。

ISR中的伸缩指的是ISR中副本的动态变化。当某个副本落后于leader副本时，它将被从ISR中移除，直到它再次与leader副本保持同步。当某个副本追上了leader副本，它将被重新加入ISR中。这种动态变化可以通过Kafka的副本管理机制自动完成，从而保证ISR中的副本集合始终与leader副本保持同步。

ISR（In-Sync Replicas）是Kafka中用于保证数据可靠性和高可用性的机制。ISR中的副本与Leader副本保持同步，可以保证在Leader副本宕机时，ISR中的副本可以顶替成为新的Leader副本，从而保证数据的可靠性和高可用性。

一般情况下，一个broker会从ISR中踢出去有以下几种情况：

① 副本同步延迟：如果ISR中的副本与Leader副本之间的同步延迟超过了一定的阈值，那么该副本就会被从ISR中踢出去。

② 副本故障：如果ISR中的副本发生故障，比如网络故障、硬件故障等，那么该副本也会被从ISR中踢出去。

③ 副本过期：如果ISR中的副本长时间没有与Leader副本保持同步，那么该副本也会被从ISR中踢出去。

需要注意的是，当一个broker被从ISR中踢出去时，需要及时进行故障排查和修复，以保证数据的可靠性和高可用性。

副本（Replicas）和ISR（In-Sync Replicas）是Apache Kafka中非常重要的概念，它们扮演着以下角色：

① 副本：Kafka中的每个分区都有多个副本，每个副本都是分区数据的完整拷贝。副本的作用是提高数据的可靠性和可用性。当某个副本所在的broker宕机时，其他副本可以继续提供服务，确保数据不会丢失。

② ISR：ISR是指与leader副本保持同步的副本集合。当leader副本发生故障时，ISR中的某个副本会被选举为新的leader副本。只有在ISR中的副本才能被选举为新的leader副本，因为它们保证了数据的一致性。如果某个副本与leader副本失去同步，它将被从ISR中移除，直到与leader副本重新保持同步。

因此，副本和ISR是Kafka实现高可用性和数据一致性的重要手段。

在Kafka中，ISR（in-sync replicas）是指与leader副本保持同步的副本集合。如果一个副本长时间不在ISR中，意味着该副本与leader副本的数据同步出现了问题，可能是由于网络故障、硬件故障或其他原因导致的。这种情况下，该副本可能会落后于其他副本，导致数据不一致。因此，Kafka会将该副本从ISR中移除，以避免数据不一致的情况发生。当该副本恢复正常后，Kafka会将其重新加入ISR中，以确保数据同步。

Kafka中的follower副本通过与leader副本进行数据同步来保持与leader副本的一致性。follower节点与leader节点同步的过程如下：

① follower节点向leader节点发送拉取请求，请求获取最新的数据。

② leader节点接收到拉取请求后，将最新的数据发送给follower节点。

③ follower节点接收到数据后，将其写入本地日志文件，并向leader节点发送确认消息，表示已经成功接收到数据。

④ leader节点接收到确认消息后，将该消息标记为已经被follower节点接收到。

⑤ follower节点定期向leader节点发送心跳消息，以保持与leader节点的连接。

⑥ 如果follower节点在一定时间内没有向leader节点发送心跳消息，或者leader节点在一定时间内没有收到follower节点的确认消息，那么leader节点将认为该follower节点已经失效，将其从副本集合中移除。

Kafka通过副本机制来实现主从同步。每个分区都有多个副本，其中一个副本被指定为领导者（leader），其他副本被指定为追随者（follower）。领导者负责处理所有的读写请求，而追随者只是简单地复制领导者的数据。

当生产者向Kafka发送消息时，它会将消息发送到领导者副本。领导者副本将消息写入本地日志，并将消息复制到所有追随者副本。一旦所有追随者副本都确认已成功复制消息，领导者副本将向生产者发送确认消息。

当消费者从Kafka读取消息时，它会从领导者副本读取数据。如果领导者副本不可用，消费者可以从追随者副本读取数据。Kafka使用ZooKeeper来管理领导者和追随者副本之间的切换，以确保高可用性和数据一致性。

① Controller选举

Controller是Kafka集群中的一个节点，负责管理集群的元数据信息，包括Broker的上下线、Partition的分配等。当当前的Controller节点失效时，需要选举一个新的Controller节点来接管其职责。

Controller选举的策略是通过Zookeeper实现的，每个Kafka Broker都会在Zookeeper上创建一个临时节点，节点的路径为/brokers/ids/[broker-id]，其中broker-id为Broker的唯一标识。当一个Broker想要成为Controller时，它会在Zookeeper上创建一个临时节点/brokers/controller_epoch，节点的值为当前的epoch值，然后尝试获取/brokers/controller节点的锁。如果获取锁成功，则该Broker成为新的Controller节点；否则，它会监听/brokers/controller节点的变化，等待锁的释放。

② Partition Leader选举

每个Partition在Kafka集群中都有一个Leader节点，负责处理该Partition的读写请求。当当前的Leader节点失效时，需要选举一个新的Leader节点来接管其职责。

Partition Leader选举的策略是通过副本之间的协作实现的。每个Partition都有多个副本，其中一个副本为Leader，其他副本为Follower。当Leader节点失效时，Follower节点会发起一次选举，选举出一个新的Leader节点。

具体的选举过程如下：

需要注意的是，为了避免脑裂（split-brain）的情况发生，Kafka要求每个Partition至少有一个副本处于活跃状态，否则该Partition将无法使用。因此，在进行Leader选举时，只有那些处于活跃状态的副本才能参与选举。

Kafka是一个分布式的消息系统，它将消息分成多个分区（Partition）并存储在多个Broker上。每个分区都有一个Leader和多个Follower，Leader负责处理读写请求，Follower则从Leader同步数据。

当一个Broker宕机或者网络故障导致Leader无法正常工作时，Kafka需要进行Partition Leader选举，选出一个新的Leader来处理读写请求。选举的过程如下：

① 每个Broker都会定期向Zookeeper注册自己的Broker信息，并创建一个临时节点。这个节点的路径是/brokers/ids/[broker-id]，节点的值是一个JSON格式的字符串，包含了Broker的IP地址、端口号等信息。

② 当一个Broker宕机或者网络故障导致Leader无法正常工作时，Zookeeper会检测到这个Broker的临时节点被删除，然后通知其他Broker。

③ 其他Broker会检查所有的Partition，如果某个Partition的Leader是宕机的Broker，那么它会尝试成为新的Leader。它会向Zookeeper创建一个临时节点/brokers/topics/[topic]/[partition]/[broker-id]，表示它想要成为这个Partition的Leader。

④ 如果多个Broker都尝试成为Leader，那么Zookeeper会根据节点创建时间的先后顺序来选举Leader。创建时间最早的节点会成为新的Leader。

⑤ 选举完成后，新的Leader会向Zookeeper更新Partition的元数据，其他Broker会从Zookeeper获取最新的元数据，并更新自己的缓存。

需要注意的是，Kafka的Partition Leader选举是异步的，也就是说，选举完成后，可能会有一段时间内某些消息无法被正常处理。因此，Kafka的高可用性需要依赖于多个副本（Replica）的存在，以保证即使某个Broker宕机，也能够保证消息的可靠性和可用性。

Kafka 集群中有一个 broker 的 Controller 会被选举为 Controller Leader，负责管理集群 broker 的上下线，所有 topic 的分区副本分配和 Leader 选举等工作。Controller 的信息同步工作是依赖于 Zookeeper 的。

选举流程：

① kafka每启动一个节点就会在zookeeper中注册一个节点信息，每一个broker节点都有对应的Controller，他们会争先抢占Controller的注册，谁先注册谁会被选举为 Controller Leader。

② 选举出来的 Controller 会监听 brokers 节点变化，决定 Leader 的选举，将节点信息上传到 zookeeper，其他Contorller 就会从 zookeeper 同步相关信息。

③ 假设 Broker1 中 Leader 挂了，Controller 就会监听到节点变化，然后获取到 ISR，选举新的 Leader（在 ISR 中存活为前提，按照 AR 中排在前面的优先），更新 Leader 及 ISR。

利用3台服务器（brokerId=0,1,2）集群来验证以上整个流程 ：

① 创建一个新的 topic，3 个分区，3 个副本：

② 查看 Leader 分布情况：

③ 停止掉 brokerId=0 的 kafka 进程，并查看 Leader 分区情况：

假如 brokerId=0 的 kafka 进程挂掉了，那么Partition为2 的Leader 就会重新选举，选举的规则为：在 ISR 中存活为前提，按照AR中排在前面的优先，即新的Leader将是2。

④ 停止掉 brokerId=2 的 kafka 进程，并查看 Leader 分区情况：

假如 brokerId=2 的 kafka 进程挂掉了，那么 Partition1和 Partition2 的Leader 就会重新选举，选举的规则为：在 ISR 中存活为前提，按照AR中排在前面的优先，即Partition1 和 Partition2 新的Leader都将是1。

⑤ 启动 brokerId=0 的 kafka 进程，并查看 Leader 分区情况：

⑥ 启动 brokerId=2 的 kafka 进程，并查看 Leader 分区情况：

⑦ 停止掉 brokerId=1 的 kafka 进程，并查看 Leader 分区情况：

假如 brokerId=1 的 kafka 进程挂掉了，那么 Partition0、Partition1和 Partition2 的Leader 就会重新选举，选举的规则为：在 ISR 中存活为前提，按照AR中排在前面的优先，即 Partition0 的Leader将为0，Partition1 的Leader将为2, Partition2 的Leader将是0。

可以看出选举是按照AR中的顺序轮询选举的，而不是ISR中的顺序。

HW是High Watermark的缩写，俗称高水位，它标识了一个特定的消息偏移量（offset），消费者只能拉取到这个offset之前的消息。

如图 ，它代表一个日志文件，这个日志文件中有 9 条消息，第一条消息的 offset 为0，最后一条消息的offset为8，offset为9的消息用虚线框表示，代表下一条待写入的消息。日志文件的HW为6，表示消费者只能拉取到offset在0至5之间的消息，而offset为6的消息对消费者而言是不可见的。

LEO是Log End Offset的缩写，它标识当前日志文件中下一条待写入消息的offset，图中offset为9的位置即为当前日志文件的LEO，LEO的大小相当于当前日志分区中最后一条消息的offset值加1。分区ISR集合中的每个副本都会维护自身的LEO，而ISR集合中最小的LEO即为分区的HW，对消费者而言只能消费HW之前的消息。

注意要点：很多资料中误将图中的offset为5的位置看作HW，而把offset为8的位置看作LEO，这显然是不对的。

① 假设某个分区的ISR集合中有3个副本，即一个leader副本和2个follower副本，此时分区的LEO和HW都为3。消息3和消息4从生产者发出之后会被先存入leader副本：

② 在消息写入leader副本之后，follower副本会发送拉取请求来拉取消息3和消息4以进行消息同步：

③ 在同步过程中，不同的 follower 副本的同步效率也不尽相同，在某一时刻follower1完全跟上了leader副本而follower2只同步了消息3，如此leader副本的LEO为5，follower1的LEO为5，follower2的LEO为4，那么当前分区的HW取最小值4，此时消费者可以消费到offset为0至3之间的消息。

④ 所有的副本都成功写入了消息3和消息4，整个分区的HW和LEO都变为5，因此消费者可以消费到offset为4的消息了。

Kafka 的复制机制既不是完全的同步复制，也不是单纯的异步复制。事实上，同步复制要求所有能工作的 follower 副本都复制完，这条消息才会被确认为已成功提交，这种复制方式极大地影响了性能。而在异步复制方式下，follower副本异步地从leader副本中复制数据，数据只要被leader副本写入就被认为已经成功提交。在这种情况下，如果follower副本都还没有复制完而落后于leader副本，突然leader副本宕机，则会造成数据丢失。Kafka使用的这种ISR的方式则有效地权衡了数据可靠性和性能之间的关系。