kafka 技术介绍

Posted 2023-03-12 PENGFEI在路上~

1 介绍

Kafka起初是由Linkedln公司釆用Scala语言开发的一个多分区、多副本且基于ZooKeeper协调的分布式消息系统，现已被捐献给Apache基金会。Kafka 2.8.0之后的版本移除了Zookeeper的依赖。Kafka目前定位为一个分布式流式处理平台，具有高吞吐、可持久化、可水平扩展、支持流数据处理等多种特性。有很多开源分布式处理系统，如：Cloudera、Storm、Spark、Flink等都支持与Kafka集成。

Kafka之所以受到越来越多的青睐，与它所“扮演”的三大角色是分不开的：

1. 消息系统：Kafka和传统的消息系统（也称作消息中间件）都具备系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能。同时，Kafka还提供了大多数消息系统难以实现的消息顺序性保障及回溯消费的功能。
2. 存储系统：Kafka把消息持久化到磁盘，相比于其他基于内存存储的系统而言，有效地降低了数据丢失的风险。也正是得益于Kafka的消息持久化功能和多副本机制，我们可以把Kafka作为长期的数据存储系统来使用，只需要把对应的数据保留策略设置为“永久”或启用主题的日志压缩功能即可。
3. 流式处理平台：Kafka不仅为每个流行的流式处理框架提供了可靠的数据来源，还提供了一个完整的流式处理类库，比如窗口、连接、变换和聚合等各类操作。

2 基本架构

一个典型的Kafka体系架构包括若干Producer、若干Broker、若干Consumer，以及一个ZooKeeper集群。

如上图所示，其中ZooKeeper是Kafka用来负责集群元数据的管理、控制器的选举等操作的。Producer将消息发送到Broker， Broker负责将收到的消息存储到磁盘中，而Consumer采用拉（pull）模式负责从Broker订阅并消费消息。

3 架构组成

3.1 Producer

生产者，也就是发送消息的一方。生产者负责创建消息，然后将其投递到Kafka 中。

3.2 Consumer

消费者，也就是接收消息的一方。消费者连接到Kafka上并接收消息，进而进行相应的业务逻辑处理。

3.3 Broker

服务代理节点。对于Kafka而言，Broker可以简单地看作一个独立的Kafka服务节点或Kafka服务实例。大多数情况下也可以将Broker看作一台Kafka服务器，前提是这台服务器上只部署了一个Kafka实例。一个或多个Broker组成了一个Kafka集群。一般而言，我们更习惯使用首字母小写的broker来表示服务代理节点。

3.4 Topic

主题。Kafka中的消息以主题为单位进行归类，生产者负责将消息发送到特定的主题(发送到Kafka集群中的每一条消息都要指定一个主题)，而消费者负责订阅主题并进行消费。

3.5 Partition

分区。主题是一个逻辑上的概念，它还可以细分为多个分区，一个分区只属于一个主题，很多时候也会把分区称为主题分区(Topic-Partition)。同一主题下的不同分区包含的消息是不同的，分区在存储层面可以看作一个可追加的日志(Log)文件，消息在被追加到分区日志文件的时候都会分配一个特定的偏移量(offset)。offset是消息在分区中的唯一标识，Kafka通过它来保证消息在分区内的顺序性，不过offset并不跨越分区，也就是说，Kafka保证的是分区有序而不是主题有序。

如下图所示，主题中有4个分区，消息被顺序追加到每个分区日志文件的尾部。Kafka 中的分区可以分布在不同的服务器（broker）上，也就是说，一个主题可以横跨多个broker，以此来提供比单个broker更强大的性能。

每一条消息被发送到broker之前，会根据分区规则选择存储到哪个具体的分区。如果分区规则设定得合理，所有的消息都可以均匀地分配到不同的分区中。如果一个主题只对应一个文件，那么这个文件所在的机器I/O将会成为这个主题的性能瓶颈，而分区解决了这个问题。在创建主题的时候可以通过指定的参数来设置分区的个数，当然也可以在主题创建完成之后去修改分区的数量，通过增加分区的数量可以实现水平扩展。

3.6 Replica

3.6.1 定义

副本。本质就是一个只能追加写消息的提交日志。同一分区的不同副本中保存的是相同的消息（在同一时刻，副本之间并非完全一样），这些副本分散保存在不同的 Broker 上，从而能够保证Leader节点宕机后依旧能够保证Kafka高可用。

3.6.2 多副本机制

3.6.2.1 描述

Kafka为分区引入的多副本（Replica）机制，通过增加副本数量可以提升容灾能力。副本之间是“一主多从”的关系，其中Leader副本负责处理读写请求，Follower副本只负责与Leader副本的消息同步。副本处于不同的broker中，当Leader副本出现故障时，从Follower副本中重新选举新的leader副本对外提供服务。Kafka通过多副本机制实现了故障的自动转移，当Kafka集群中某个broker失效时仍然能保证服务可用。

如下图所示，Kafka集群中有4个broker，某个主题中有3个分区，且副本因子（即副本个数）也为3，如此每个分区便有1个leader副本和2个follower副本。生产者和消费者只与leader 副本进行交互，而follower副本只负责消息的同步，很多时候follower副本中的消息相对leader副本而言会有一定的滞后。

kafka消费端也具备一定的容灾能力。consumer使用拉(pull)模式从服务端拉取消息，并且保存消费的具体位置，当消费者宕机后恢复上线时可以根据之前保存的消费位置重新拉取需要的消息进行消费，这样就不会造成消息丢失。

3.6.2.2 关键概念

3.6.2.2.1 AR、ISR、OSR

AR (Assigned Replicas)：分区中的所有副本统称为AR。

ISR (In-Sync Replicas)：所有与Leader副本保持一定程度同步的副本(包括leader副本在内)组成ISR (In-Sync Replicas)，ISR集合是AR集合中的一个子集。消息会先发送到Leader副本，然后Follower副本才能从Leader副本中拉取消息进行同步，同步期间内Follower副本相对于Leader副本而言会有一定程度的滞后。前面所说的“一定程度的同步”是指可忍受的滞后范围，这个范围可以通过参数进行配置。

OSR (Out-of-Sync Replicas)：与Leader副本同步滞后过多的副本(不包括Leader副本)组成OSR (Out-of-Sync Replicas)，由此可见，AR=ISR+OSR。在正常情况下，所有的Follower副本都应该与Leader副本保持一定程度的同步，即AR=ISR，OSR集合为空。

Leader副本负责维护和跟踪ISR集合中所有Follower副本的滞后状态，当Follower副本落后太多或失效时，Leader副本会把它从ISR集合中剔除。如果OSR集合中有Follower副本“追上”了leader副本，那么leader副本会把它从OSR集合转移至ISR集合。默认情况下，当Leader副本发生故障时，只有在ISR集合中的副本才有资格被选举为新的Leader，而在OSR集合中的副本则没有任何机会(不过这个原则也可以通过修改相应的参数配置来改变)。

3.6.2.2.2 HW、LEO

LEO（Log End Offset）：它标识当前日志文件中下一条待写入消息的offset，上图中offset为9的位置即为当前日志文件的LEO，LEO的大小相当于当前日志分区中最后一条消息的offset值加1。

HW（High Watermark）：分区ISR集合中的每个副本都会维护自身的LEO，而ISR集合中最小的LEO 即为分区的HW，对消费者而言只能消费HW之前的消息。

如下图所示，它代表一个日志文件，这个日志文件中有9条消息，第一条消息的offset(logStartOffset)为0，最后一条消息的offset为8，offset为9的消息用虚线框表示，代表下一条待写入的消息。日志文件的HW为6，表示消费者只能拉取到offset在0至5之间的消息，而offset为6的消息对消费者而言是不可见的。

注意要点：很多资料中误将上图中的offset为5的位置看作HW，而把offset为8的位置看作LEO，这显然是不对的。

3.6.2.2.3 ISR与HW、LEO关系

ISR与HW和LEO也有紧密的关系。HW是High Watermark的缩写，俗称高水位，它标识了一个特定的消息偏移量(offset)，消费者只能拉取到这个offset之前的消息。

由于文字不好描述，举例说明

1. 如下图所示，假设某个分区的ISR集合中有3个副本，即一个leader 副本和2个follower副本，此时分区的LEO和HW都为3。

1. 消息3和消息4从生产者发出之后会被先存入leader副本，如下图所示

1. 在消息写入leader副本之后，follower副本会发送拉取请求来拉取消息3和消息4以进行消息同步。在同步过程中，不同的follower副本的同步效率也不尽相同。如下图所示，在某一时刻follower1完全跟上了leader副本而follower2只同步了消息3，如此leader副本的LEO为5，follower1的LEO为5，follower2的LEO为4，那么当前分区的HW取最小值4，此时消费者可以消费到offset为0至3之间的消息。

1. 当所有的副本都成功写入了消息3和消息4，整个分区的HW和LEO都变为5，因此消费者可以消费到offset为4的消息了。

由此可见，kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。

同步复制：所有能工作的follower副本都复制完，这条消息才会被确认为已成功提交，这种复制方式极大地影响了性能。

异步复制：follower副本异步地从leader副本中复制数据，数据只要被leader副本写入就被认为已经成功提交。在这种情况下，如果follower副本都还没有复制完而落后于leader副本，突然leader副本宕机，则会造成数据丢失。

事实上，而在Kafka使用的这种ISR的方式则有效地权衡了数据可靠性和性能之间的关系。

4 基本特性

1. 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒
2. 可扩展性：kafka集群支持动态扩展
3. 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
4. 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
5. 高并发：支持数千个客户端同时读写

5 消息模式

5.1 点对点模式

如图所示，点对点模式通常是基于拉取或者轮询的消息传送模型，这个模型的特点是发送到队列的消息被一个且只有一个消费者进行处理。生产者将消息放入消息队列后，由消费者主动的去拉取消息进行消费。

点对点模型的的优点是消费者拉取消息的频率可以由自己控制。但是消息队列是否有消息需要消费，在消费者端无法感知，所以在消费者端需要额外的线程去监控。

5.2 发布订阅模式

如图所示，发布订阅模式是一个基于消息送的消息传送模型，该模型可以有多种不同的订阅者。生产者将消息放入消息队列后，队列会将消息推送给订阅过该类消息的消费者（类似微信公众号）。

由于是消费者被动接收推送，所以无需感知消息队列是否有待消费的消息，但是consumer1、consumer2、consumer3由于机器性能不一样，所以处理消息的能力也会不一样，但消息队列却无法感知消费者消费的速度，因此推送的速度成了发布订阅模模式的一个问题。假设三个消费者处理速度分别是 8M/s、5M/s、2M/s，如果队列推送的速度为5M/s，则consumer3无法承受。如果队列推送的速度为 2M/s，则consumer1、consumer2会出现资源的极大浪费。

5.3 Kafka 选择

作为一个消息系统，kafka遵循了传统的方式，选择由producer向broker push消息并由consumer从broker pull 消息。

push模式和pull模式各有优劣。

push模式很难适应消费速率不同的消费者，因为消息发送速率是由 broker决定的。push 模式的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而 pull 模式则可以根据consumer 的消费能力以适当的速率消费消息。

对kafka而言，pull模式更合适。pull模式可简化broker的设计，consumer可自主控制消费消息的速率，同时 consumer可以自己控制消费方式——既可批量消费也可逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义。

6 工作流程

6.1 消息发送

6.1.1 发送过程

1. 先从集群获取分区的leader副本。
2. producer将消息发送给leader。
3. leader将消息写入本地文件。
4. follower从leader拉取消息。
5. follower将消息写入本地后向leader发送ack确认。
6. leader收到所有副本的ack后向producer发送ack确认。

6.1.2 消息push

消息写入leader 后，follower是主动pull leader同步的。producer采用push模式将数据发布到 broker，将每条消息追加到分区中，顺序写入磁盘，保证同一分区内的数据是有序的。（如果往不存在的 topic 写数据，kafka 会自动创建 topic，分区和副本的数量根据默认配置都是 1）如图：

6.1.3 消息路由

首先明确一点，producer发送的消息会写入到不同的分区，kafka为什么这么设计？

1. 方便扩展：因为一个 topic可以有多个partition，所以我们可以通过扩展机器去轻松的应对日益增长的数据量。
2. 提高并发：以partition为读写单位，可以多个消费者同时消费数据，提高了消息的处理效率。

消息是怎么写入到对应分区里面的？

1. 在写入的时候可以指定需要写入的partition，如果有指定，则写入对应的 partition。
2. 如果没有指定partition，但是设置了数据的key，则会根据key的hash值出一个partition。
3. 如果既没指定partition，又没有设置key，则会轮询选出一个partition。
4. 同时也支持自定义分区写入策略：实现Partitioner接口。

6.1.4 Ack机制

kafka通过ack应答机制保证消息可靠性。在producer向队列写入数据的时候可以设置参数来确定是否确认kafka接收到数据，可以通过 request.required.acks参数来设置数据可靠性的级别，这个参数可设置的值为 0、1、all 。

1. 0 代表 producer 往集群发送数据不需要等到集群的返回，不确保消息发送成功。安全性最低但是效率最高。
2. 1代表 producer 往集群发送数据只要leader应答就可以发送下一条，只确保leader发送成功。
3. all代表producer往集群发送数据需要所有的follower都完成从leader的同步才会发送下一条，确保 leader发送成功和所有的副本都完成备份。安全性最高，但是效率最低。

6.2 消息写入

6.2.1 写入方式

kafka将数据保存在磁盘，可能在我们的一般的认知里，写入磁盘是比较耗时的操作，不适合这种高并发的组件。kafka为了优化写入速度采用了两个技术，磁盘顺序写入和MMFile。

6.2.1.1 磁盘顺序写入

因为硬盘是机械结构，每次读写都会寻址->写入，其中寻址是一个“机械动作”，它是最耗时的。所以硬盘最“讨厌”随机I/O，最喜欢顺序I/O。为了提高读写硬盘的速度，Kafka就是使用顺序I/O。在顺序读写的情况下，磁盘的顺序读写速度和内存几乎持平。

随机和顺序读写对比如下图：

详细对比链接：磁盘和内存的随机和顺序读写详细对比

6.2.1.2 Memory Mapped Files

即使是顺序写入硬盘，硬盘的访问速度还是不可能追上内存。所以kafka的数据并不是实时的写入硬盘 ，它充分利用了现代操作系统分页存储来利用内存提高I/O效率。

Memory Mapped Files(简称mmap)也被称为内存映射文件，在64位操作系统中一般可以表示20G的数据文件。它的工作原理是直接利用操作系统的page实现文件到物理内存的直接映射。完成映射后，用户对内存的所有操作会被操作系统自动的刷新到磁盘上（操作系统在适当的时候），极大地降低了IO使用率。

mmap其实是Linux中的一个函数就是用来实现内存映射的，通过mmap进程像读写硬盘一样读写内存（虚拟机内存），并且不需要关心内存的大小有虚拟内存为我们兜底。

使用这种方式可以获取很大的I/O提升，省去了用户空间到内核空间复制的开销（调用文件的read会把数据先放到内核空间的内存中，然后再复制到用户空间的内存中）。也有一个很明显的缺陷——不可靠， 写到mmap中的数据并没有被真正的写到硬盘，操作系统会在程序主动调用flush的时候才把数据真正的写到硬盘。kafka提供了一个参数——producer.type来控制是不是主动flush，如果Kafka写入到mmap之后就立即flush然后再返回producer叫同步 (sync)，写入mmap之后立即返回producer不调用flush叫异步 (async)。

6.2.2 消息存储

6.2.2.1 partition 结构

每个topic都可以分为一个或多个partition，partition在服务器上的表现形式就是一个一个的文件夹。partition命名规则为：

<topic_name>-<partition_id>

比如创建一个名为 firstTopic 的 topic，其中有 3 个 partition，那么在kafka的数据目录中就有 3 个文件：

firstTopic-0
firstTopic-1
firstTopic-2

每个partition的文件夹下面会有多组segment文件，每组segment文件又包含.index 文件、.log 文件、.timeindex 文件（早期版本中没有）三个文件， log 文件就实际是存储 message 的地方，而 index 和 timeindex文件为索引文件，用于检索消息。文件的命名是以该segment最小offset 来命名的，如000.index存储 offset为0~1234566 的消息，kafka就是利用分段+索引的方式来解决查找效率的问题。

6.2.2.2 message 结构

上面说到log文件就实际是存储message的地方，我们在producer往kafka写入的也是一条一条的 message，那存储在 log中的message是什么样子的呢？

• CRC32：4个字节，消息的校验码。
• magic：1字节，魔数标识，与消息格式有关，取值为0或1。当magic为0时，消息的offset使用绝对offset且消息格式中没有timestamp部分；当magic为1时，消息的offset使用相对offset且消息格式中存在timestamp部分。所以，magic值不同，消息的长度是不同的。
• attributes：1字节，消息的属性。其中第0~ 2位的组合表示消息使用的压缩类型，0表示无压缩，1表示gzip压缩，2表示snappy压缩，3表示lz4压缩。第3位表示时间戳类型，0表示创建时间，1表示追加时间。
• timestamp： 时间戳，其含义由attributes的第3位确定。
• key length：消息key的长度。
• key：消息的key。
• value length：消息的value长度。
• value：消息的内容

6.2.2.3 message 消息查找

在index文件中，左边第一列是offset，右边对应是物理地址，都是递增排序，log文件每条消息物理地址也是递增。

如下图，要查找一个offset为368801的消息：

1. 根据offset使用二分查找定位具体的索引文件（索引文件前缀有offset），对应的segment为segment2。
2. 在具体的索引文件使用二分查找，用offset找到相应的物理地址。
3. 到索引对应的log文件使用顺序扫描找到具体消息。

这套机制是建立在offset为有序的基础上，利用segment+有序offset+稀疏索引+二分查找+顺序查找等多种手段来高效的查找数据。

6.2.2.4 消息删除策略

每一个Partition其实都是一个文件 ，收到消息后Kafka会把数据插入到文件末尾（虚框部分）。如下图：

这种方法有一个缺陷——没有办法删除数据 ，所以Kafka是不会删除数据的，它会把所有的数据都保留下来。

因此如果不删除硬盘肯定会被撑满，所以kakfa提供了两种策略来删除数据。一是基于时间，二是基于partition文件大小。

• 基于时间，默认配置是 168 小时（7天）；
• 基于大小，默认配置是 1073741824。

需要注意的是，kafka 读取特定消息的时间复杂度是 O(1)，所以这里删除过期的文件并不会提高 kafka 的性能。

6.3 消息读取

6.3.1 零拷贝

kafka在磁盘上是顺序写入的，这样读取时效率更高。然而还有其他方式提高读写性能。例如消费者获取消息时，服务器先从硬盘读取数据到内存，然后把内存中的数据原封不动的通过 socket 发送给消费者。步骤如下：

1. 操作系统将数据从磁盘读入到内核空间的页缓存
2. 应用程序将数据从内核空间读入到用户空间缓存中
3. 应用程序将数据写回到内核空间到 socket 缓存中
4. 操作系统将数据从 socket 缓冲区复制到网卡缓冲区，以便将数据经网络发出Copy to clipboardErrorCopied

这个过程涉及到 4 次上下文切换以及 2 次数据复制，但过程中数据没有变化。

“零拷贝”可以去掉这些没必要的数据复制操作，同时也会减少上下文切换次数。Linux 中通过 sendfile 系统调用来完成。Java 提供了访问这个系统调用的方法：

FileChannel.transferTo

这样操作系统内核将数据从原来的内核缓冲区中拷贝到与 socket 相关的内核缓冲区中(高版本的linux可以直接跳过它, 直接发给网卡), 从操作系统角度这已经是zero-copy因为数据没有在内核空间与用户空间进行copy。

 6.3.2 消息消费

消息存储在log文件后，消费者就可以进行消费了。消费者主动的去kafka集群pull消息，与 producer相同的是，消费者在拉取消息的时候也是找leader去拉取。

多个消费者可以组成一个消费者组（consumer group），每个消费者组都有一个组 id，同一个消费组者的消费者可以消费同一 topic下不同分区的数据，但是不会组内多个消费者消费同一分区的数据。如下图：

上图所示，是消费者组内的消费者小于partition 数量的情况，所以会出现某个消费者消费多个 partition 数据的情况，消费的速度也就不及只处理一个 partition 的消费者的处理速度。

如果是消费者组的消费者多于 partition 的数量，那会不会出现多个消费者消费同一个 partition 的数据呢？上面已经提到过不会出现这种情况。多出来的消费者不消费任何partition的数据。所以在实际的应用中，建议消费者组的 consumer 的数量与 partition 的数量一致。

至此，消费者就能拿到需要处理的数据进行处理了。那每个消费者又是怎么记录自己消费的位置呢？

每个消费者（consumer）对每个topic都有一个offset用来表示读取到了第几条数据 。如下图：

在早期的版本中，消费者将消费到的 offset 维护 zookeeper 中，consumer 每间隔一段时间上报一次，这里容易导致重复消费，且性能不好。现在版本中消费者消费到的offset 已经直接维护在kafka 集群的consumer_offsets这个 topic 中了。

7 VS其他

7.1 功能分析

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，比 RocketMQ、Kafka 低一个数量级	同ActiveMQ	10万级，支撑高吞吐	10万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响	/	/	topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic	topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
时效性	ms 级	微秒级，这是 RabbitMQ 的一大特点，延迟最低	ms 级	延迟在 ms 级以内
可用性	高，基于主从架构实现高可用	同 ActiveMQ	非常高，分布式架构	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据	基本不丢	经过参数优化配置，可以做到 0 丢失	同 RocketMQ
功能支持	MQ 领域的功能极其完备	基于 erlang 开发，并发能力很强，性能极好，延时很低	MQ 功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用
社区活跃度	低	高	中	高

7.2 选型建议

• kafka：追求高吞吐量，初始目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务。如果是大数据领域实时计算、日志采集等场景，用kafka是业内标准的，社区活跃度很高，几乎是全世界这个领域的事实性规范。
• rocketmq：天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。并且roketmq在稳定性上可能更值得信赖，这些业务场景在阿里双11已经经历了多次考验，如果业务有上述并发场景，建议可以选择roketmq。
• rabbitmq：erlang语言本身并发优势，性能较好，社区活跃度也比较高，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，不利于做二次开发和维护，不过rabbitmq社区十分活跃，有比较稳定的支持。因此中小型公司，数据量不是很大，技术实力较为一般，技术挑战不是特别高，用rabbitmq是不错的选择。
• activemq：官方社区现在对activemq 5.x维护越来越少，没经过大规模吞吐量场景的验证，社区也不是很活跃，不建议使用。

8 参考文档

1. 深入理解Kafka：核心设计与实践原理