深入理解Kafka：消息队列、架构、顺序消费与故障处理-优快云博客

什么是消息队列？

消息队列Message Queue，简称MQ。
是一种应用间的通信方式，主要由三个部分组成。

生产者：Producer
消息的产生者与调用端
主要负责消息所承载的业务信息的实例化是一个队列的发起方
代理：Broker
主要的处理单元
负责消息的存储、投递、及各种队列附加功能的实现
是消息队列最核心的组成部分
消费者：Consumer
一个消息队列的终端也是消息的调用端,具体是根据消息承载的信息，处理各种业务逻辑。

消息队列的应用场景较多，常用的可以分为三种：
在这里插入图片描述
应用解耦
应用解耦可以看作是把相关但耦合度不高的系统联系起来。比如订单系统与 WMS、EHR 系统，有关联但不哪么紧密，每个系统之间只需要把约定的消息发送到 MQ，另外的系统去消费即可。
解决了各个系统可以采用不同的架构、语言来实现，从而大大增加了系统的灵活性。
在这里插入图片描述
流量削峰
流量削峰一般应用在大流量入口且短时间内业务需求处理不完的服务中心，为了权衡高可用，把大量的并行任务发送到 MQ 中，依据MQ 的存储及分发功能，平稳的处理后续的业务，起到一个大流量缓冲的作用。

目前市面上常见的消息队列中间件主要有
ActiveMQ、RabbitMQ、Kafka、RocketMQ 这几种，

在架构技术选型的时候一般根据业务的需求选择合适的中间件：
比如中小型公司，低吞吐量的一般用 ActiveMQ、RabbitMQ 较为合适，大数据高吞吐量的大型公司一般选用 Kafka 和RocketMQ。

Kafka 基础架构

Producer：
消息生产者，就是向 Kafka broker 发消息的客户端。
Consumer：
消息消费者，向 Kafka broker 取消息的客户端。
Consumer Group（CG）：
消费者组，由多个 Consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
Broker：
一台 Kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。
Topic：
可以理解为一个队列，生产者和消费者面向的都是一个 topic。
Partiton：
为了实现拓展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，一个 topic 可以分为多个 Partition，每个 partition 都是一个有序的队列。
Replication：
副本，为保证集群中某个节点发生故障时，该节点上的 partition 数据不丢失，且 Kafka 仍然可以继续工作，Kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。
leader：
每个分区多个副本的 ”主“，生产者发送数据的对象，以及消费者消费数据时的对象都是 leader。
follower：
每个分区多个副本的 “从”，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 leader。

2. kafka 的零拷贝原理?

在实际应用中，如果我们需要把磁盘中的某个文件内容发送到远程服务器上，那么它必须要经过几个拷贝的过程，如图（贴图）。
在这里插入图片描述
从磁盘中读取目标文件内容拷贝到内核缓冲区
CPU 控制器再把内核缓冲区的数据赋值到用户空间的缓冲区中
接着在应用程序中，调用 write()方法，把用户空间缓冲区中的数据拷贝到内核下的Socket Buffer 中。
最后，把在内核模式下的 SocketBuffer 中的数据赋值到网卡缓冲区（NIC Buffer)
网卡缓冲区再把数据传输到目标服务器上。
在这个过程中我们可以发现，数据从磁盘到最终发送出去，要经历 4 次拷贝，而在这四次拷贝过程中，有两次拷贝是浪费的，分别是：

从内核空间赋值到用户空间
从用户空间再次复制到内核空间
除此之外，由于用户空间和内核空间的切换会带来 CPU 的上线文切换，对于 CPU 性能也会造成性能影响。
而零拷贝，就是把这两次多于的拷贝省略掉，应用程序可以直接把磁盘中的数据从内核中直接传输给Socket，而不需要再经过应用程序所在的用户空间，如下图所示

在这里插入图片描述
零拷贝通过DMA（Direct Memory Access）技术把文件内容复制到内核空间中的Read Buffer，
接着把包含数据位置和长度信息的文件描述符加载到Socket Buffer 中，DMA 引擎直接可以把数据从内核空间中传递给网卡设备。
在这个流程中，数据只经历了两次拷贝就发送到了网卡中，并且减少了 2 次cpu 的上下文切换，对于效率有非常大的提高。

所以，所谓零拷贝，并不是完全没有数据赋值，只是相对于用户空间来说，不再需要进行数据拷贝。对于前面说的整个流程来说，零拷贝只是减少了不必要的拷贝次数而已。

在程序中如何实现零拷贝呢？

在Linux 中，零拷贝技术依赖于底层的sendfile()方法实现
在Java 中，FileChannal.transferTo() 方法的底层实现就是 sendfile() 方法。
除此之外，还有一个 mmap 的文件映射机制;
它的原理是：将磁盘文件映射到内存, 用户通过修改内存就能修改磁盘文件。使用这种方式可以获取很大的 I/O 提升，省去了用户空间到内核空间复制的开销。

3. Kafka 如何保证消息不丢失？

kafka 是一个用来实现异步消息通信的中间件，它的整个架构由Producer、 Consumer、Broker 组成。

在这里插入图片描述
3.1 Producer 端
首先是Producer 端，需要确保消息能够到达 Broker 并实现消息存储，在这个层面，有可能出现网络问题，导致消息发送失败，所以，针对Producer 端，可以通过 2 种方式来避免消息丢失

Producer 默认是异步发送消息，这种情况下要确保消息发送成功，有两个方法
a.把异步发送改成同步发送，这样producer 就能实时知道消息发送的结果。
b.添加异步回调函数来监听消息发送的结果，如果发送失败，可以在回调中重试。
Producer 本身提供了一个重试参数retries，如果因为网络问题或者 Broker 故障导致发送失败，Producer 会自动重试。
3.2 Broker 端
然后是Broker 端，Broker 需要确保Producer 发送过来的消息不会丢失，也就是只需要把消息持久化到磁盘就可以了。
（如图）但是，Kafka 为了提升性能，采用了异步批量刷盘的实现机制，也就是说按照一定的消息量和时间间隔来刷盘，而最终刷新到磁盘的这个动作，是由操作系统来调度的，所以如果在刷盘之前系统崩溃，就会导致数据丢失。

在这里插入图片描述
Kafka 并没有提供同步刷盘的实现，所以针对这个问题，需要通过Partition的副本机制和acks 机制来一起解决。

“我简单说一下 Partition 副本机制，它是针对每个数据分区的高可用策略，每个 partition 副本集包含唯一的一个 Leader 和多个 Follower，Leader 专门处理事务类的请求，Follower 负责同步Leader 的数据”。
在这样的一种机制的基础上，kafka 提供了一个acks 的参数，Producer 可以设置acks参数再结合Broker 的副本机制来个共同保障数据的可靠性。
acks 有几个值的选择。
acks=0，表示producer 不需要等Broker 的响应，就认为消息发送成功，这种情况会存在消息丢失。
acks=1，表示Broker 中的Leader Partition 收到消息以后，不等待其他 Follower Partition 同步完，就给Producer 返回确认，这种情况下Leader Partition 挂了，会存在数据丢失。
acks=-1，表示Broker 中的Leader Parititon 收到消息后，并且等待 ISR 列表中的follower 同步完成，再给 Producer 返回确认，这个配置可以保证数据的可靠性。
3.3 Consumer
最后，就是Consumer 必须要能消费到这个消息，实际上，我认为，只要producer和broker 的消息可靠的到了保障，那么消费端是不太可能出现消息无法消费的问题，除非是Consumer 没有消费完这个消息就直接提交了，但是即便是这个情况，也可以通过调整offset 的值来重新消费。

4. Kafka 怎么避免重复消费?

首先，（如图）Kafka Broker 上存储的消息，都有一个Offset 标记。然后kafka 的消费者是通过 offSet 标记来维护当前已经消费的数据，
每消费一批数据，Kafka Broker 就会更新OffSet 的值，避免重复消费。
在这里插入图片描述
默认情况下，消息消费完以后，会自动提交 Offset 的值，避免重复消费。
Kafka 消费端的自动提交逻辑有一个默认的 5 秒间隔，也就是说在 5 秒之后的下一次向 Broker 拉取消息的时候提交。
所以在Consumer 消费的过程中，应用程序被强制 kill 掉或者宕机，可能会导致 Offset没提交，从而产生重复提交的问题。
除此之外，还有另外一种情况也会出现重复消费。

（如图）在Kafka 里面有一个Partition Balance 机制，就是把多个Partition 均衡的分配给多个消费者。
在这里插入图片描述
Consumer 端会从分配的Partition 里面去消费消息，如果 Consumer 在默认的 5 分钟内没办法处理完这一批消息。
就会触发Kafka 的Rebalance 机制，从而导致Offset 自动提交失败。
而在重新Rebalance 之后，Consumer 还是会从之前没提交的 Offset 位置开始消费，也会导致消息重复消费的问题。

基于这样的背景下，我认为解决重复消费消息问题的方法有几个:

提高消费端的处理性能避免触发Balance，比如可以用异步的方式来处理消息，缩短单个消息消费的市场。或者还可以调整消息处理的超时时间。还可以减少一次性从Broker 上拉取数据的条数。
可以针对消息生成md5 然后保存到 mysql 或者redis 里面，在处理消息之前先去 mysql 或者redis 里面判断是否已经消费过。这个方案其实就是利用幂等性的思想。

5. 什么是 ISR，为什么需要引入 ISR?

首先，发送到 Kafka Broker 上的消息，最终是以 Partition 的物理形态来存储到磁盘上的。
（如图）而Kafka 为了保证Parititon 的可靠性，提供了 Paritition 的副本机制，然后在这些Partition 副本集里面。存在Leader Partition 和Flollower Partition。
生产者发送过来的消息，会先存到 Leader Partition 里面，然后再把消息复制到 Follower Partition，
这样设计的好处就是一旦Leader Partition 所在的节点挂了，可以重新从剩余的 Partition 副本里面选举出新的 Leader。
然后消费者可以继续从新的 Leader Partition 里面获取未消费的数据。

在这里插入图片描述
在Partition 多副本设计的方案里面，有两个很关键的需求。

副本数据的同步
新Leader 的选举
这两个需求都需要涉及到网络通信，Kafka 为了避免网络通信延迟带来的性能问题，以及尽可能的保证新选举出来的Leader Partition 里面的数据是最新的，所以设计了 ISR 这样一个方案。

ISR 全称是 in-sync replica，它是一个集合列表，里面保存的是和 Leader Parition 节点数据最接近的 Follower Partition
如果某个Follower Partition 里面的数据落后 Leader 太多，就会被剔除 ISR 列表。
简单来说，ISR 列表里面的节点，同步的数据一定是最新的，所以后续的Leader 选举，只需要从ISR 列表里面筛选就行了。
所以，我认为引入ISR 这个方案的原因有两个:

尽可能的保证数据同步的效率，因为同步效率不高的节点都会被踢出 ISR 列表。
避免数据的丢失，因为 ISR 里面的节点数据是和 Leader 副本最接近的。以上就是我对这个问题的理解

6. Kafka 如何保证消息消费的顺序性？

首先，在 kafka 的架构里面，用到了 Partition 分区机制来实现消息的物理存储（如图），在同一个topic 下面，可以维护多个partition 来实现消息的分片。

在这里插入图片描述
生产者在发送消息的时候，会根据消息的 key 进行取模（如图），来决定把当前消息存储到哪个partition 里面。
并且消息是按照先后顺序有序存储到 partition 里面的。

在这种情况下，（如图），假设有一个topic 存在三个partition，而消息正好被路由到三个独立的partition 里面。
然后消费端有三个消费者通过 balance 机制分别指派了对应消费分区。因为消费者是完全独立的网络节点，
所有可能会出现，消息的消费顺序不是按照发送顺序来实现的，从而导致乱序的问题。

在这里插入图片描述
针对这个问题，一般的解决办法就是自定义消息分区路由的算法，然后把指定的key都发送到同一个 Partition 里面。（如图）
接着指定一个消费者专门来消费某个分区的数据，这样就能保证消息的顺序消费了。

在这里插入图片描述
另外，有些设计方案里面，在消费端会采用异步线程的方式来消费数据来提高消息的处理效率，那这种情况下，因为每个线程的消息处理效率是不同的，所以即便是采用单个分区的存储和消费也可能会出现无序问题，针对这个问题的解决办法就是在消费者这边使用一个阻塞队列，把获取到的消息先保存到阻塞队列里面，然后异步线程从阻塞队列里面去获取消息来消费。

在Java中，可以使用Kafka的消费者API来实现消息的顺序消费。以下是几种可以考虑的方法：

单个分区消费：创建一个单独的消费者实例来消费一个分区的消息。这样可以确保在单个分区内的消息按顺序消费。但是需要注意，如果有多个分区，不同分区的消息仍可能以并发方式进行消费。

指定分区消费：通过指定消费者订阅的特定分区，可以确保只消费指定分区的消息。这样，可以通过将相关消息发送到同一个分区来保证消息的顺序消费。

按键分区：Kafka允许根据消息的键（key）来决定将消息发送到哪个分区。如果消息的键是相同的，Kafka会将它们发送到同一个分区。因此，可以根据消息的键来保证消息的顺序消费。

无论选择哪种方法，都应该注意以下几点：

设置消费者的 max.poll.records 参数，确保每次拉取的消息数量合适，以避免因一次拉取的消息过多而导致处理速度过慢。
在消费者处理消息时，确保消息处理的逻辑是线程安全的。
监听消费者的 onPartitionsRevoked 事件，以便在重新分配分区时进行必要的清理和准备工作。
使用 auto.offset.reset 参数设置消费者的offset重置策略，以决定当消费者启动时从哪个offset开始消费。

7. Kafka 消息队列怎么保证 exactlyOnce，怎么实现顺序消费?

当我们向某个Topic 发送消息的时候，在 Kafka 的Broker 上，会通过Partition 分区的机制来实现消息的物理存储。
一个Topic 可以有多个Partition，相当于把一个 Topic 里面的N 个消息数据进行分片存储。
消费端去消费消息的时候，会从指定的Partition 中去获取。
在同一个消费组中，一个消费者可以消费多个Partition 中的数据。但是消费者的数量只能小于或者等于Partition 分区数量。
在这里插入图片描述
理解了Kafka 的工作机制以后，再来理解一下exactlyOnce 的意思，在MQ 的消息投递的语义有三种：

At Most Once: 消息投递至多一次，可能会丢但不会出现重复。
At Least Once: 消息投递至少一次，可能会出现重复但不会丢。
Exactly Once: 消息投递正好一次，不会出现重复也不会丢。
准确来说，目前市面上的MQ 产品，基本上都没有提供Exactly Once 语义的实现。我们只能通过一些其他手段来达到 Exactly Once 的效果。也就是确保生产者只发送一次，消费端只接受一次

生产者可以采用事物消息的方式，事务可以支持多分区的数据完整性，原子性。并且支持跨会话的exactly once 处理语义，即使 producer 宕机重启，依旧能保证数据只处理一次
开启事务首先需要开启幂等性，即设置 enable.idempotence 为true。然后对producer消息发送做事务控制。
如果出现导致生产者重试的错误，同样的消息，仍由同样的生产者发送多次，这个消息只被写到 Kafka broker 的日志中一次;
虽然生产者能保证在 Kafka broker 上只记录唯一一条消息，但是由于网络延迟的存在，有可能会导致 Broker 在投递消息给消费者的时候，触发重试导致投递多次。
所以消费端，可以采用幂等性的机制来避免重试带来的重复消费问题。
其次，关于实现顺序消费问题。
在Kafka 里面，每个Partition 分区的消息本身就是按照顺序存储的。
所以只需要针对 Topic 设置一个Partition，这样就保证了所有消息都写入到这一个 Partition 中。
而消费者这边只需要消费这个分区，就可以实现消息的顺序消费处理。