带你吃透Kafka的可靠性设计( 二 ) _Kafka

3.副本设计副本（ Replica ）是分布式系统中常见的概念之一，指的是分布式系统对数据和服务提供的一种冗余方式。
我们知道 Kafka 通过多副本机制，增强了容灾备份的能力，并且实现了故障转移。这无疑是大大提高了 Kafka 的可用性，下面笔者会带着大家一起看 Kafka 的副本机制是如何设计的。
在此之前，先简单复习几个相关的概念：

副本是相对分区而言的，即副本是指某个分区的副本
在多副本情况下，其中一个副本为 leader，其它均为 follower 。只有 leader 对外提供服务，follower 仅同步leader 数据
分区中所有的副本集合称为 AR，ISR 是与 leader 保持同步状态的副本集合，leader 也是 ISR 中的一员
LEO 是每个分区下一条消息要写入的位置
HW 是 ISR 中最小的 LEO，消费者只能拉取 HW 之前的消息

3.1 失效副本正常情况下，分区中所有副本都应该属于 ISR，但是网络具有不可靠性。因此，难免在某一个时刻会有一些成员会被踢出 ISR，这些副本要么处于同步失效状态，要么功能失效，这些副本统称为失效副本。
功能失效指的是无法工作，比如某个 broker 宕机了，那么在它上面的分区就会失效。
同步失效又是怎么判断是否同步失效的呢？是通过参数 replica.lag.time.max.ms 来判断的，默认是 10000 毫秒。当某个 follower 同步滞后 leader 的时间超过 10 秒，则判定为同步失效。
具体实现原理如下：

文章插图
当 follower 将 leader LEO 之前的消息全部同步完成，那么会认为该 follower 已经追上 leader ，并更新 lastCaughtUpTimeMs 。Kafka 的副本管理器有一个副本过期检测的定时任务，如果发现当前时间 - lastCaughtUpTimeMs > 10秒，则判定同步失效。
除了时间设置以外，还有另一个参数 replica.lag.max.message（默认4000，这个是 broker 级别的参数），也是用来判定失效副本的。
一般情况下，这两个参数都是使用默认值就可以，因为如果没有调优经验，自己乱配置，容易导致 ISR 变动过于频繁。同时，需要监控失效副本的数量，因为它是衡量 Kafka 是否健康的一个很重要的指标。
PS：新加入的副本因子/宕机恢复后重新加入的副本在追赶上 leader 之前，也会一直处于失效状态。3.1.1 失效副本的作用失效副本为 Kafka 带来了什么收益呢？为什么需要设计这么一个状态呢？
大家不妨试想下：假设允许 ISR 中有一个副本同步一直跟不上 leader 。当 leader 发生宕机时，这个 follower 被选举成了新的 leader，那么这时就会发生消息丢失。
一般会造成副本失效基本是以下两个原因：

follower 副本进程卡顿，在一段时间内无法发起同步请求，比如说频繁发生 FULL GC
follower 同步过慢，在一段时间内无法追上 leader，比如 I/O有问题（笔者实际工作中遇到过一次，公司搭建自己的物理机房，用了二手服务器，有一台服务器I/O老化导致读写数据慢，导致了副本失效，消息堆积等问题）

3.2 LEO 与 HW这一小节会更进一步去讲解它们之间的关系，让大家可以更清楚 Kafka 的副本同步机制。
假设现在有 3 个 broker，某个 topic 有 1 个分区，3 个副本。现在有一个 producer 发送了一条消息，这 3 个副本会发生些什么操作。