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

文章插图
A 会将自己的 leader epoch 信息给 leader（A的 leader epoch 这里简化成 LE_A）。这里会出现两种情况：
– 变更了 leader
B 会返回 LE_A+1 的 StartOffset 给 A
– 没有变更 leader
B 会返回 A 的 LEO 给 A
因此，我们可以把 OffsetsForLeaderEpochRequest 看作是一个查询 follower 当前 leader_epoch 的 LEO 。

OffsetsForLeaderEpochResponse

文章插图
这个例子中，B 会返回2给 A，而此时的 A 的 LEO 刚好是 2，所以不用进行截断日志。如下图：

文章插图
如果此时B挂了，A成了 leader ，并有 m3 写入，就会得到下图：

文章插图
可以看见 m2 并没有丢失，并且也更新了 leader_epoch 矢量为 (1,2) 。3.3.3.2 解决数据不一致问题

文章插图
上图是3.3.2的例子。副本A是 leader ， B 是 follower 。
A 的 HW=2，LEO=2，LE=（0 ， 0）
B 的 HW=1，LEO=1，LE=（0 ， 0）
此时，A 和 B 同时宕机，并且 B 先恢复成为了 leader 。此时， epoch 变成了 1 。另外，新消息 m3 成功写入，就会得到下图：

文章插图
接着，A 也恢复了，这时 A 不会急着截断日志，而是给 leader 发送 OffsetsForLeaderEpochRequest，B 会返回 LEO = 1 给 A 。因此， A 会截断日志，删除 m2 。之后，再给 B 发送 fetch request，得到 B 的响应并更新后，将得到下图：

文章插图
这样数据不一致问题就解决了。
这里大家可能会有疑问，m2不是丢失了吗？是的，这种设计因为更新具有一定的间隙，并且没有事务管理，所以会有丢失消息的风险。
从 CAP 定理来看，这里的设计属于 AP 。为什么这么说呢？大家不妨想一下，如果为了不丢失数据，这里加了事务控制的设计，那么对于分区而言它的吞吐量是会下降的，甚至是不可用的，因为响应速度是由短板的副本所决定的。对于定位是高吞吐量的 Kafka 而言，这显然是不可接受的。3.4 小结Kafka 通过多副本机制增强了容灾备份的能力，并且基于多副本机制实现了故障转移，避免了单点问题，但同时也引进了新的问题——数据丢失和数据不一致。从 0.11.0.0 版本开始，Kafka 增加了 leader epoch，它对这两个问题进行了优化。虽然无法完全避免消息丢失，但是从实际的使用角度而言，这个问题其实并不大。有实际工作经验的同学应该都知道，我们发送消息难以避免需要重推，哪怕消息中间件做到了百分百不丢失，其实我们在使用时仍然会做防止消息丢失的设计。相对而言，数据一致性就更重要了，否则很容易让订阅消息的下游系统出现脏数据。4 leader 选举机制在 Kafka 集群中会有一个或者多个 broker ，其中有一个 broker 会被选举为控制器，它负责管理整个集群中所有分区和副本的状态。分区的 leader 出现故障时，由控制器负责为其选举新的 leader；当某个分区的 ISR 发生变化时，由控制器负责通知所有 broker 更新其元数据信息；当某个 topic 的分区数量发生变化时，还是由控制器负责分区的重新分配。因此，只要控制器正常工作，分区的 leader 就是唯一的，不会有脑裂问题。
那么， Kafka 是如何保证控制器只有一个的呢？如果控制器发生异常了怎么办？控制器的选举和异常恢复又是怎样的？4.1 控制器控制器是 broker 维度的角色，它负责管理整个集群中所有分区和副本的状态。
Kafka 中的控制器选举工作依赖于 ZooKeeper，成功竞选为控制器的 broker 会在 ZooKeeper 中创建 /controller 临时节点，节点会存储以下信息：{ "version ": 1, "brokerid": 0, "timestamp": "1529210278988"}

其中 version 目前是固定值不用管，brokerid 是成为控制器的 broker 的 id，timestamp 是 broker.id=0 的 broker 成为控制器的时间戳。