写点什么

Kafka 到底有多高可靠?(RNG NB)

作者:敖丙
  • 2022 年 5 月 30 日
  • 本文字数:4058 字

    阅读完需:约 13 分钟

Kafka到底有多高可靠?(RNG NB)

在聊 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 集群从对应的偏移位置出发,这就可以避免消息重复和消息丢失。

不知道有多少小伙伴看到这里的,如果觉得目前为止写的还不错的,可以帮忙点个赞让,让我看看有多少好学的宝宝。

4.数据截断机制

我们开头说了真正处理数据的是 leader 副本,follower 副本只负责数据的同步和保存,那如果因为 leader 宕机了二者数据不一致会怎么样呢?

在讲一致性保证过程之前还需了解两个 Kafka 用于表示副本数据同步的概念:

HW(High Watermark):中文翻译为高水位,用来体现副本间数据同步的相对位置,consumer 最多只能消费到 HW 所在的位置,通过 HW 我们可以判断数据对副本是否可见。

LEO(Log End Offset):下一条待写入消息的记录位置。

leader 副本从生产者获取消息,follower 副本实时从 leder 同步数据,此时它们的同步数据是一致的都同步到 2 这个位置,并且下一个写入的消息都是偏移位 4:

假设因为意外 leader 发生宕机,follower 即被选为新 leader,此后从生产者写入最新的偏移位 4 和 5:

过了一段时间原 leader 通过修复恢复服务,它就会发现自己和新 leader 的数据是不一致的:

为了保证数据一致性就必须强行让一方妥协。因为数据是不断在刷新的,所以旧 leader 此时的优先级会小于新 leader,因此它会将自己的数据截断到与新 leader 相同的 HW 和 LEO 位置,确保和新 leader 的数据一定相同,这就是 Kafka 数据截断机制。

5.数据清理机制

同其它中间件一样,Kafka 的主要作用是通信,所以即使是将数据保存在磁盘上它还是会占用一定空间。为了节约存储空间它会通过一些机制对过期数据进行清理。

日志删除

日志删除会直接删除日志分段,kafka 会维护一个定时任务来周期性检查和删除「过期数据」

  • 基于时间的日志删除

它在每一个日志段文件里面都维护一个最大时间戳来确认当前配置的删除时间,只要日志段写入新消息该字段都会被更新。一个日志段被写满了之后就不会再接收新的消息,它会去创建一个新的日志段文件往里面写数据。

每一个日志段文件被写满之后它的最大的时间戳都是保持不变的,Kafka 只要通过当前时间与最大时间戳进行比较就可以判断该日志段文件是否过期。

Kafka 默认配置 log.retention.hours = 168,也就是 7 天的日志保留时间。

  • 基于容量大小的日志删除

这和以上是异曲同工的方式, 只不过这次从时间换成了空间。

Kafka 会通过每个日志段空间的大小计算一个总容量阈值,然后计算出当前的实际空间大小和总容量阈值的差值,如果这个差值大于单个日志段文件的大小那么就会删除掉最旧的那个日志段文件,反之则不做任何处理。

同理,这个阈值也可以通过 log.retention.bytes 参数来设置。

日志压缩

Kafka 的消息是由键值组成的,如果日志段里存在多条相同 key 但是不同 value 的数据,那么它会选择性地清除旧数据,保留最近一条记录。

具体的压缩方式就是创建一个检查点文件,从日志起始位置开始遍历到最大结束位置,然后把每个消息的 key 和 key 对应的 offset 保存在一个固定容量的 SkimpyOffsetMap 中。


这样前面的值就会被后面的覆盖掉,如果日志文件里存在相同的 key 只有最新的那个会被保留。

总结

Kafka 通过 ACK 应答机制保证了不同组件之间的通信效率,通过副本同步机制、数据截断和数据清理机制实现了对于数据的管理策略,保证整个系统运行效率。

作为一款高性能又同时兼顾高可靠性的消息中间件来说,Kafka 能吹的点实在太多。如果本篇文章对你有所帮助,点击一下右下角的大拇指,下一次我们来详细讲解 Kafka 是如何实现副本间数据传递的。

你知道的越多,不知道的越多,各位的点赞评论都对我很重要,如果这篇文章有帮助你多一点点了解 Kafka 的话,可以在评论区来一波“变得更强”。

也希望你的 bug 和下面这张图一样,🤺 退 🤺退 🤺退!我们下次见。



本文 GitHub https://github.com/JavaFamily 已经收录,有大厂面试完整考点,欢迎 Star。

发布于: 2022 年 05 月 30 日阅读数: 37
用户头像

敖丙

关注

还未添加个人签名 2019.03.14 加入

还未添加个人简介

评论 (1 条评论)

发布
用户头像
封面牛逼
1 小时前
回复
没有更多了
Kafka到底有多高可靠?(RNG NB)_kafka_敖丙_InfoQ写作社区