深入理解kafka核心设计与实践原理_读书笔记第8章可靠性探究_深入理解kafka核心设计与实践原理第8章-优快云博客

第8章可靠性探究

8.1 副本剖析

Kafka 0.8 版本开始为分区引入了多副本机制，通过增加副本数量来提升数据容灾能力。同时， Kafka 通过多副本机制实现故障自动转移，在 Kafka 集群中某 broker 节点失效的情况下，仍然保证服务可用。

8.1.1 失效副本

正常情况下，分区的所有副本都处于 ISR 集合中，但是难免会有异常情况发生，从而某些副本被剥离出 ISR 集合中。在 ISR 集合之外，也就是处于同步失效或功能失效（比如副本处于非存活状态）的副本统称为失效副本。
怎么判定某个分区是否有副本处于同步失效的状态昵？ Kafka 0.9.x 版本开通过唯一broker 端参数replica.lag.time.max.ms 来确定，当 ISR 集合中的 follower副本滞后 leader 本的时间超过参数指定的值时，则判定为同步失败。需要将此 follower 副本剔除出 ISR 集合具体可以参考图

8.1.2 ISR伸缩

Kafka 在启动的时候，会开启两个与 ISR有关的定时任务，名称分别为”isr-expiration"和"isr-change-propagation"。"isr-expiration"任务会周期性地检测每个分区是否需要缩减其 ISR集合。

8.1.3 LEO与HW

分析消息中各个副本 LEO与HW的变化情况

8.2 日志同步机制

日志同步机制的一个基本原则就是：如果告知客户端已成功提交了某条消息，那么即使leader宕机，也要保证新选举出来的 leader 中能够包含这条消息。这里就有一个需要权衡（ tradeoff)的地方，如果leader 在消息被提交前需要等待更多 follower 确认，那么在它宕机之后就可以有更多的follower 替代它，不过这也会造成性能的下降。

8.3 可靠性分析

怎样可以确保 Kafka 完全可靠？[面试重点]
- 1、副本数。越多的副本数越能够保证数据的可靠性，一般设置为3个，对数据更高要求可以设置更多。
- 2、acks = -1 配合 min.insync.replicas。 acks = -1:leader 副本在成功写入本地日志之后还要等待 ISR 中的 follower 副本全部同步完成才能够告知生产者已经成功提交。
```
   ack = -1 存在退化为ack=1的情形

  试想一下这样的情形，leader 副本的消息流入速度很快，而follower 副本的同步速度很慢，
  在某个临界点时所有的 follower 副本都被剔除出了 ISR 集合，那ISR 只有一个 leader 副本，
  最终 acks ＝-1 演变为 acks =1 情形，如此也就加大了消息丢失的风险。 

  Kafka 考虑到了这种情况，并为此提供了 min .insync.replicas 参数（默认值1）来
  作为辅助（配合 acks =-1 来使用），**这个参数指定了 ISR 集合中最小的副本数**

  在正常的配置下，需要满足副本数＞ min.sync.replicas 参数的值。

  一个典型的配置方为：副本数配置为 3, min.insync.replicas 参数值配置为2
```
- 3、同步/异步发送消息。消息发送的3种模式，即发后即忘、同步和异步。
- 4、enable.auto.commit 设置为false。enable.auto.commit 参数的默认值为 true ，即开启自动位移提交的功能虽然这种方式非常简便，但它会带来重复消费和消息丢失的问题，对于高可靠性要求的应用来说显然不可取，所以需要将将次参数设置为 false 来执行手动位移提交。
- 5、回溯消费 对于消费端， Kafka 还提供了个可以兜底的功能，即回溯消费，通过这个功能可以让我们能够有机会对漏掉的消息相应地进行回补，进而可以进步提高可靠性。