深入实战探索Kafka的Broker的原理及可靠性机制分析

深藏阁楼爱情的钟 2024-03-24 16:42 19阅读 0赞

### 副本机制 ###

**分布式系统中，为了提高可靠性，最常用、最有效的策略是“副本机制”，Kafka也不例外**。

> **Kafka 为每个 Partition 维护了一个 AR（Assigned Replicas）列表，由 ISR（In-Sync Replicas，与 Leader 数据同步的 Replica）和OSR（Outof-Sync Replicas，与 Leader 数据不同步的 Replica）组成。**

> **初始状态下，所有的 Replica 都在 ISR 中，但在 Kafka 工作过程中，由于各种问题（网络、磁盘、内存）可能导致部分 Replica 的同步速度慢于参数 replica.lag.time.max.ms 指定的阈值，一旦出现这种情况，这部分 Replica 会被移出 ISR，降级至OSR中。**

#### 参数 **replica.lag.time.max.ms** ####

数据类型为Long，默认值为 10000，重要性为 High，官方解释如下：

If a follower hasn't sent any fetch requests or hasn't consumed up to the leaders log end offset for at least this time, the leader will remove the follower from ISR.
    复制代码

#### 副本机制如何作用？ ####

Producer指定Topic向Broker发送消息，经过内部处理（如负载均衡等）后写入某Partition 的 Leader，**Leader收到消息数据后并不会立即回应Producer**，**而是等待ISR列表中所有的** Replica同步数据完成，之后才向Producer返回成功消息。

**基于上述分析，不难理解，只要保证ISR中的 Replica 数量大于 2（ISR 包括 Leader），即便出现 Leader 突然故障下线的情况，也能保证消息不丢失（因为 ISR 中的 Replica 与 Leader 保持同步）**。

**当然，凡事过犹不及，ISR 中 Replica 的数量不宜过多，否则会降低 Kafka 的吞吐性能。**

> **补充一点，OSR 内的 Replica 是否同步了 Leader 的数据不影响数据是否提交成功，这些 Replica 会不断从Leader中同步数据**。

至于同步的进度并不重要，不过，运维人员应密切关注Replica从ISR 中降级转入 OSR 的情况，并及时排查故障，使其尽快回到 ISR 中，以维持 ISR 中 Replica 的数量处于合理状态，同时降低集群宕机的风险。

### 截断机制 ###

介绍了 LEO 和 HW 在正常情况下的流转过程，那遇到异常情况又会怎样呢？

**如果出现 Leader 故障下线的情况，就需要从所有的 Follower 中选举新的 Leader，以便继续提供服务**。为了保证一致性，通常只能从 ISR 列表中选取新的 Leader （上面已经介绍，ISR 列表中的 Follower 与原 Leader 保持同步）

> **因此，无论 ISR 中哪个 Follower 被选为新的 Leader，它都知道HW之前的数据，可以保证在切换了Leader后，Consumer可以继续“看到”之前已经由 Producer 提交的数据。**

**如下图所示，如果Leader宕机，Follower1被选为新的Leader，而新Leader（原Follower1 ）并没有完全同**