Kafka 到底有多高可靠？（RNG NB）

作者：敖丙

2022 年 5 月 30 日
本文字数：4058 字
阅读完需：约 13 分钟

在聊 Kafka 高可靠之前，先在评论区来波 RNG NB 好不好！

什么叫可靠性？

大家都知道，系统架构有三高：「高性能、高并发和高可用」，三者的重要性不言而喻。

对于任意系统，想要同时满足三高都是一件非常困难的事情，大型业务系统或者传统中间件都会搭建复杂的架构来保证。

除以上三种模式之外，还有一个指标方向也很重要，那就是高可靠，甚至你可能会将它和「高可用」混淆起来。

事实上两者并不一样，高可用会更偏向于整体服务的可用性，防止系统宕机等等。而高可靠是指数据的可靠性保证嘛，你可以理解”高可靠“相比于系统三高会是一个更细一点的概念。

那么什么是数据的高可靠呢，总结一下就是系统要提供可靠的数据支撑，不能发生丢失、重复等错误现象。

所以每个开源中间件在发布版本时都会通过文档声明自己是超可靠的，就像 520 那天每一位暖男说的那样。

咱今天的主角 kafka 就是这么一个例子。

一些重要概念

因为有一段时间没讲消息队列了嘛，为了帮助你更好理解文章，我们来先复习一下 kafka 的基础概念：

record：消息，消息队列基础通信单位
topic：主题，目的就是将消息进行分类，不同业务类型的消息通常会被分发到不同的主题
partition：分区，每个主题可以创建多个分区，每个分区都由一系列有序和不可变的消息组成
replica：副本，每个分区都有一个至多个副本存在，它的主要作用是存储保存数据，以日志(Log)对象的形式体现。副本又分为 leader 副本和 follower 副本
offset：偏移量，每一个消息在日志文件中的位置都对应一个按序递增的偏移量，你可以理解为类似数组的存储形式
producer：生产者，生产消息的那一方
consumer：消费者，通常不同的业务都会有一到多个消费者组成消费者集群
broker：代理，一个 Kafka 集群由一个或多个 Kafka 实例构成，每一个 Kafka 实例就称为代理

如上图所示，一共存在主题 1 和主题 2，主题 1 有两个分区，主题 2 只有一个分区，并且每个分区都存在一个 leader 副本和两个 follower 副本，它们分布在每个不同的代理节点上。

partition 里只有 leader 副本负责与生产者、消费者之间数据的交互，follower 副本会定期从 leader 副本拉取数据以保证整个集群数据可用性。

如何保证数据高可靠

Kafka 是通过副本机制实现数据的存储的，所以就需要一些机制保证数据在跨集群的副本之间能够可靠地传输。

1.副本同步集合

业务数据封装成消息在系统中流转，由于各个组件都是分布在不同的服务器上的，所以主题和生产者、消费者之间的数据同步可能存在一定的时间延迟，Kafka 通过延迟范围划分了几个不同的集合：

AR(Assigned Replicas)

指的是已经分配数据的分区副本，通常指的是 leader 副本 + follower 副本。

ISR(In Sync Replicas)

指的是和 leader 副本数据保持同步的副本集合。当 follower 副本数据和 leader 副本数据保持同步，那么这些副本就处在 ISR 里面，ISR 集合会根据数据的同步状态动态变化。

OSR(Out Sync Replicas)

一旦 follower 副本的数据同步进度跟不上 leader 了，那么它就会被放进叫做 OSR 的集合里。也就是这个集合包含的是不处于同步状态的分区副本。

OK，那有什么标准判断它是同步还是不同步呢？

通过 replica.lag.time.max.ms 这个参数来设置数据同步时间差，它的默认值是 10s。

一旦从分区副本和主分区副本的消息相差 10s 以上，那么就认为消息处于 OSR 不同步的状态。若 follower 处于 OSR 集合里，那么在选取新的 leader 的时候就不会选举它作为新 leader。

2.ACK 应答机制

我们刚刚说了 kafka 是通过 ack 来发送数据同步信号的，那信号发送频率又有几种设定呢？

ack = 0

生产者发送一次消息就不再发送。不管是否发送成功，若发出去的消息处于通信的路上就丢失，或者还未做磁盘持久化操作，那么消息就可能丢失。

它的好处就是性能很高，你想呀你发送消息都不需要等待对方回复就持续发送下一批，那么消息等待的时间就节省出来了。同一时间范围内能比别人处理更多数据，缺点就是它的可靠性真的很低，数据真的是说丢就丢。

ack = 1

leader 接收到消息并且写入到本地磁盘后就认为消息处理成功。这种方式可靠性会比上一种好一些，当 leader 接收到消息并且写入到本地磁盘后就认为消息处理成功，不论 follower 是否同步完这条消息就会返回给 producer。

但是假如此刻 partition leader 所在的 broker 宕机了，如果那么数据也可能会丢失，所以 follower 副本的数据同步就很重要。

Kafka 默认就采用这种方式。

ack = -1

producer 只有收到分区内所有副本的响应 ACK 才会认为消息已经 push 成功。

这种方式虽然对于数据的可靠保障做得很好，但是就是性能很差，影响吞吐量，所以一般也不会采取。

那么它就绝对可靠吗？也不一定。最重要的还是取决于副本数据是否同步完成。若 producer 收到响应消息前 leader 副本挂掉，那么 producer 会因未收到消息重复发送消息，那就可能造成数据重复。怎么解决呢？只要保证业务幂等就行。

我们可以通过 request.required.acks 这个参数控制消息的发送频率。

3.消息语义

消息集群整体是一个复杂的系统，所以过程中可能会因为各种原因导致消息传递出错，Kafka 对于这些可能遇到的场景定义了对应的的消息语义。

at most once

它代表消息可能被消费者消费 0 次或者 1 次。若场景如下：

消息从 partition 分发给消费者集群
消费者把自己收到的消息告诉集群，集群收到之后 offset 就会往后移动
消费者将数据入库做持久化

你一定想到了。在第三步消费者将消息入库时若因任何原因消费者 A 挂了，那么在将消费者切换到集群的消费者 B 后，数据还没入库呢。此时 partition 是浑然不知的呀，那么这就会造成一个问题：数据丢失。

at least once

它代表 partition 分发的消息至少被消费一次。其通信过程如下：

消息从 partition 分发给消费者集群
消费者将数据入库做持久化
消费者把自己收到的消息告诉集群，集群收到之后 offset 就会往后移动

假设 consumer group 在数据入库之后，在将数据返回给 partition 的过程中消费者 A 挂了，那么 partition 会因为接收不到响应 ACK 而重新发送数据，此时消费者 B 可能再次将原先的消息入库，这就造成了数据重复了。

在没有做任何幂等性保护的情况下，像重复转账，重付叠加积分这种业务，那么结果可能是致命的。

exactly once

代表消息正好能被消费一次，不丢失，不重复。

在 at least once 的情况基础上，假设 consumerA 在返回 ack 给 partition 的过程中宕机了。那么 consumerB 不会跟着 partition 的 offset 走，它会先去数据库里面查看最新消息对应的偏移位，再根据这个偏移位返回 Kafka 集群从对应的偏移位置出发，这就可以避免消息重复和消息丢失。