图解kafka的高可用机制

对于一个复杂的分布式系统，如果没有丰富的经验和牛逼的架构能力，很难把系统做得简单易维护，我们都知道，一个软件的生命周期中，后期维护占了70%，所以系统的可维护性是极其重要的， kafka 能成为大数据领域的事实标准，很大原因是因为运维起来很方便简单，今天我们来看下 kafka 是怎么来简化运维操作的。

kafka 使用多副本来保证消息不丢失，多副本就涉及到kafka的复制机制，在一个超大规模的集群中，时不时地这个点磁盘坏了，那个点cpu负载高了，出现各种各样的问题，多个副本之间的复制，如果想完全自动化容错，就要做一些考量和取舍了。我们举个例子说明下运维中面对的复杂性，我们都知道 kafka 有个 ISR集合，我先说明下这个概念：

kafka不是完全同步，也不是完全异步，是一种ISR机制：

1. leader会维护一个与其基本保持同步的Replica列表，该列表称为ISR(in-sync Replica)，每个Partition都会有一个ISR，而且是由leader动态维护

2. 如果一个follower比一个leader落后太多，或者超过一定时间未发起数据复制请求，则leader将其重ISR中移除

3. 当ISR中所有Replica都向Leader发送ACK时，leader才commit，这时候producer才能认为一个请求中的消息都commit了。

在这种机制下，如果一个 producer 一个请求发送的消息条数太多，导致flower瞬间落后leader太多怎么办？如果 follower不停的移入移出 ISR 会不会影响性能？如果对这种情况加了报警，就有可能造成告警轰炸，如果我们不加报警，如果是broker 挂掉或者 broker 因为IO性能或者GC问题夯住的情况导致落后leader太多，这种真正需要报警情况怎么办呢？今天我们来看下 kafka 是怎么在设计上让我们完全避免这种运维中头疼的问题的。

kafka的复制机制

kafka 每个分区都是由顺序追加的不可变的消息序列组成，每条消息都一个唯一的offset 来标记位置。

kafka中的副本机制是以分区粒度进行复制的，我们在kafka中创建 topic的时候，都可以设置一个复制因子，这个复制因子决定着分区副本的个数，如果leader 挂掉了，kafka 会把分区主节点failover到其他副本节点，这样就能保证这个分区的消息是可用的。leader节点负责接收producer 打过来的消息，其他副本节点（follower）从主节点上拷贝消息。

kakfa 日志复制算法提供的保证是当一条消息在 producer 端认为已经 committed的之后，如果leader 节点挂掉了，其他节点被选举成为了 leader 节点后，这条消息同样是可以被消费到的。

这样的话，leader 选举的时候，只能从 ISR集合中选举，集合中的每个点都必须是和leader消息同步的，也就是没有延迟，分区的leader 维护ISR 集合列表，如果某个点落后太多，就从 ISR集合中踢出去。 producer 发送一条消息到leader节点后， 只有当ISR中所有Replica都向Leader发送ACK确认这条消息时，leader才commit，这时候producer才能认为这条消息commit了，正是因为如此，kafka客户端的写性能取决于ISR集合中的最慢的一个broker的接收消息的性能，如果一个点性能太差，就必须尽快的识别出来，然后从ISR集合中踢出去，以免造成性能问题。kafka 复制机制详情参考 https://kafka.apache.org/documentation.html#replication

一个副本怎么才算是跟得上leader的副本

一个副本不能 “caught up” leader 节点，就有可能被从 ISR集合中踢出去，我们举个例子来说明，什么才是真正的 “caught up” —— 跟leader节点消息同步。

现在 producer 发送一条消息，offset 为3， 这时候 broker 3 发生了 GC， 入下图：

什么时候一个副本才会从ISR集合中踢出去

一个副本被踢出 ISR集合的几种原因：

一个节点在什么情况下真正处于落后状态

然后，因为 follower 是正常的，所以下一次 fetch 请求就会又追上 leader， 这时候就会再次加入 ISR 集合，如果经常性的抖动，就会不断的移入移出ISR集合，会造成令人头疼的 告警轰炸。

这里的核心问题是，在海量的 topic 情况下，或者经常性的流量抖动情况下，我们不能对 topic 的producer 每次打过来的消息数目做任何假设，所以就不太好定出来一个 合适的值

一个配置全部搞定

其实只有两种情况是异常的，一种就是卡住，另外一种是follower 性能慢，如果我们只根据 follower 落后 leader 多少来判断是否应该把 follower 提出ISR集合，就必须要对流量进行预测估计，怎么才能避免这种不靠谱的估计呢，kafka 给出的方案是这样的，对replica.lag.time.max.ms这个配置的含义做了增强，和之前一样，如果 follower 卡住超过这个时间不发送fetch请求， 会被踢出ISR集合，新的增强逻辑是，在 follower 落后 leader 超过eplica.lag.max.messages条消息的时候，不会立马踢出ISR 集合，而是持续落后超过replica.lag.time.max.ms时间，才会被踢出，这样就能避免流量抖动造成的运维问题，因为follower 在下一次fetch的时候就会跟上leader， 这样就也不用对 topic 的写入速度做任何的估计喽。

大家都在看

▼

structured streaming 系列:

spark streaming 系列:

spark 机器学习系列

关注【spark技术分享】

一起撸spark源码，一起玩spark最佳实践