kafka读书笔记（六）可靠性探究之日志同步机制

kafka读书笔记（六）可靠性探究之日志同步机制

文章目录

日志同步机制

副本AR、ISR、OSRLEO与HWISR的缩小ISR的扩展ISR伸缩的条件ISR的伸缩与HW 可靠性分析
上一章我们从客户端角度分析了kafka在消息可靠性方面做了哪些保证，下面我们从副本角度讲讲，kafka是如何保证消息不丢失的。

日志同步机制

在分布式系统中，日志同步机制既要保证数据的一致性，也要保证数据的顺序性。为了达到这些目的，并出于简单方便的考虑，kafka选择了强leader的设计：有且只有一个leader，该leader提供了所有的读写服务并会处理数据的顺序性。
这也就是说通常情况下只有leader在与客户端进行交互，我们不需要考虑副本同步问题。反之，假如leader宕机，那么副本同步策略就会影响到数据的一致性。
而kafka的leader宕机策略很简单：**在集群中维护了一个isr集合，只有处于isr集合内的副本才有成为leader的可能。**接下来本文会详解关于ISR的一切。

副本

为了提高kafka集群的吞吐量，kafka设计以主题分区为粒度的消息生产、消费与存储。在此基础上，kafka引入了多副本机制来提升容灾能力。副本之间是一主多从的关系，leader负责处理所有的读写，follower只负责与leader副本的消息消息同步。当leader出现故障，则控制器选择一个follower替换leader，并以该follwer的日志为准对其它follower日志进行同步，从而实现了故障的自动转移。

AR、ISR、OSR

分区中所有副本称为AR，所有与leader副本保持一定程度的副本（包括leader副本在内）组成ISR，OSR则是滞后的过多副本的集合。
leader副本负责跟踪和维护ISR集合中所有follower副本的滞后状态，follower落后太多或者失效时，leader副本会把它从ISR集合中剔除。

LEO与HW

LEO（last end offset）标识当前日志文件中下一条待写入消息的offset，ISR中的每个副本都会维护自身的LEO，其中最小的LEO即分区的HW，对消费者而言只能消费HW之前的消息。leader所在的节点会记录所有副本的LEO，而follower副本所在的节点只会记录自身的LEO。

ISR的缩小

ISR的缩小过程，就是把副本从ISR转移到OSR的过程。
处于同步失效或者功能失效的副本都可称为失效副本。
同步失效判定：
当follower副本向leader副本拉取消息时，假如此时leader判断所有的消息都被leader拉取完毕，就会更新记录下这次拉取的时间，称为lastCaughtUpTimeUs。
同时，leader副本还会启动一个定时任务，对比配置的超时时间和该参数（lastCaughtUpTimeUs）之间的差，差值过大则将该副本踢出。

ISR的扩展

当follower不断拉取leader副本进行消息同步，最终使得follower的LEO不小于ISR的HW时，follower副本就能加入ISR。

ISR伸缩的条件

当检测到分区的ISR发生变化时，还需要检查以下两个条件：

上一次isr变化发生在五秒之前上一次写入zookpeer的时间是在60秒之前

满足这两个条件才能把isr变化写入目标节点。这么做主要是考虑到zookpeer的性能和watch机制带来的负担。

ISR的伸缩与HW

当ISR发生伸缩，或者ISR集合中任一副本的LEO发生变化时，都会影响ISR整个分区的HW。

可靠性分析

就kafka集群而言，越多的副本数越能保证数据的可靠性，不过副本数过多也会造成网络带宽、磁盘的浪费，并对服务器造成不必要的压力（譬如日志读写带来的IO）。一般来说一个分区有3个副本就够用了（书上说的，俺寻思不出来为啥），有些银行服务会选择5个副本。同时，如果在分配分区副本时引入了机架信息，那么还要面临机架整体宕机的风险。
根据上面的分区leader替换机制可以看出，仅仅依靠副本数来保证数据的可靠是远远不够的，通过对于生产者客户端参数ack的配置，我们可以调整数据的可靠性。一般来说，将ack设置为-1可以获得最大的可靠性，这种情况下，只有ISR中的全部副本都同步到了信息才会回复成功，否则生产者会收到信息失败的回复。

对于生产者而言，消息发送有三种策略：

发后既忘同步异步

（在使用ack=-1的前提下）
使用发后既忘的策略可能会导致消息丢失。同步和异步模式可以通过重试提高可靠性，但是可能会引起消息重复。

除此之外，一些配置也会影响到消息的可靠性。
生产者的ack参数：前文已经说明，不再赘述
生产者的min.insync.replicas参数：指定ISR最小的副本数，小于该数会返回异常
生产者的retries和retry.backoff.ms参数：对于可重试异常（NetworkException）的重试次数，以及重试的时间间隔。
控制器的unclean.leader.election.enable:令其值为true会可能会导致OSR中的副本被选举成leader。

broker端的log.flush.interval.messages和log.flush.interval.ms：用来调整刷盘时机，默认是由 *** 作系统做持久化。同步刷盘可以有效地保证持久化，代价是性能的极大降低。

消费者方面可以通过修改位移提交时机来调整可靠性，也可以利用消费回溯的功能兜底。对于一些消费失败的信息，可以用死信队列来完成后继的处理。