深入理解kafka核心设计与实践原理_读书笔记 第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 还提供了 个可以兜底的功能，即回溯消费，通过这个功能可以让我们能够有机会对漏掉的消息相应地进行回补，进而可以进 步提高可靠性。