- *消息重复。 相同的消息重复发送会造成消费者消费两次同样的消息,这同样会造成系统间数据的不一致。比如,订单支付成功后会通过消息队列给支付系统发送需要扣款的金额,如果消息发送两次一样的扣款消息,而订单只支付了一次,就会给用户带来余额多扣款的问题。
总结来说,这两个问题直接影响到业务系统间的数据一致性。
那到底该如何避免这两个问题的发生呢?
Kafka 针对这两个问题有系统的解决方案,需要服务端、客户端做相应的配置以及采取一些补偿方案。
先介绍下 三种消息语义及场景
介绍一下”消息语义”的概念,这是理论基础,会有利于你更好地抓住下面解决方案的要点。
消息语义有三种,分别是:消息最多传递一次、消息最少传递一次、消息有且仅有一次传递 ,这三种语义分别对应:消息不重复、消息不丢失、消息既不丢失也不重复。
这里的”消息传递一次”是指生产者生产消息成功,Broker 接收和保存消息成功,消费者消费消息成功。对一个消息来说,这三个要同时满足才算是”消息传递一次”。上面所说的那三种消息语义可梳理为如下。
-
*最多一次(At most once):对应消息不重复。消息最多传递一次,消息有可能会丢,但不会重复。一般运用于高并发量、高吞吐,但是对于消息的丢失不是很敏感的场景。
-
*最少一次(At least once):对应消息不丢失。消息最少传递一次,消息不会丢,但有可能重复。一般用于并发量一般,对于消息重复传递不敏感的场景。
-
*有且仅有一次(Exactly once):每条消息只会被传递一次,消息不会丢失,也不会重复。 用于对消息可靠性要求高,且对吞吐量要求不高的场景。
Kafka 如何做到消息不丢失?
我们先来讨论一下 Kafka 是如何做到消息不丢失的,也就是:生产者不少生产消息,服务端不丢失消息,消费者也不能少消费消息。
那具体要怎么来实现呢?下面我们就来详细讲解下。
生产端:不少生产消息
以下是为了保证消息不丢失,生产端需要配置的参数和相关使用方法。
acks=0,表示生产者不等待任何服务器节点的响应,只要发送消息就认为成功。
acks=1,表示生产者收到 leader 分区的响应就认为发送成功。
acks=-1,表示只有当 ISR(ISR 的含义后面我会详细介绍)中的副本全部收到消息时,生产者才会认为消息生产成功了。这种配置是最安全的,因为如果 leader 副本挂了,当 follower 副本被选为 leader 副本时,消息也不会丢失。但是系统吞吐量会降低,因为生产者要等待所有副本都收到消息后才能再次发送消息。
只要上面这四个要点配置对了,就可以保证生产端的生产者不少生产消息了。
服务端:不丢失消息
为了保证不丢失消息,消费者就不能少消费消息,该如何去实现呢?消费端需要做好如下的配置。
第一个,设置 enable.auto.commit=false。enable.auto.commit 这个参数表示是否自动提交,如果是自动提交会导致什么问题出现呢?
消费者消费消息是有两个步骤的,首先拉取消息,然后再处理消息。向服务端提交消息偏移量可以手动提交也可以自动提交。
如果把参数 enable.auto.commit 设置为 true 就表示消息偏移量是由消费端自动提交,由异步线程去完成的,业务线程无法控制。如果刚拉取了消息之后,业务处理还没进行完,这时提交了消息偏移量但是消费者却挂了,这就造成还没进行完业务处理的消息的位移被提交了,下次再消费就消费不到这些消息,造成消息的丢失。因此,一定要设置 enable.auto.commit=false,也就是手动提交消息偏移量。
第二个,要有手动提交偏移量的正确步骤。enable.auto.commit=false 并不能完全满足消费端消息不丢的条件,还要有正确的手动提交偏移量的过程。具体如何操作呢?
业务逻辑先对消息进行处理,再提交 offset,这样是能够保证不少消费消息的。但是你可以想象这样一个场景:如果消费者在处理完消息后、提交 offset 前出现宕机,待消费者再上线时,还会处理未提交的那部分消息,但是这部分已经被消费者处理过了,也就是说这样做虽然避免了丢消息,但是会有重复消费的情况出现。(这种情况比较少,一般特殊情况特殊处理就好)
具体代码需要这么写:
List
Kafka 如何做到消息不重复?
生产端不重复生产消息,服务端不重复存储消息,消费端也不能重复消费消息。
相较上面”消息不丢失”的场景,”消息不重复”的服务端无须做特别的配置,因为服务端不会重复存储消息,如果有重复消息也应该是由生产端重复发送造成的。也就是说,下面我们只需要分析生产端和消费端就行。
生产端:不重复生产消息
生产端发送消息后,服务端已经收到消息了,但是假如遇到网络问题,无法获得响应,生产端就无法判断该消息是否成功提交到了 Kafka,而我们一般会配置重试次数,但这样会引发生产端重新发送同一条消息,从而造成消息重复的发送。
对于这个问题,Kafka 0.11.0 的版本之前并没有什么解决方案,不过从 0.11.0 的版本开始,Kafka 给每个生产端生成一个 唯一的 ID ,并且在每条消息中生成一个 sequence num,sequence num 是递增且唯一的,这样就能对消息去重,达到一个生产端不重复发送一条消息的目的。
但是这个方法是有局限性的,只对在一个生产端内生产的消息有效,如果一个消息分别在两个生产端发送就不行了,还是会造成消息的重复发送。好在这种可能性比较小,因为消息的重试一般会在一个生产端内进行。当然,对应一个消息分别在两个生产端发送的请求我们也有方案,只是要多做一些补偿的工作,比如,我们可以为每一个消息分 配一个全局 ID,并把全局 ID 存放在远程缓存或关系型数据库里 ,这样在发送前可以判断一下是否已经发送过了。
消费端:不能重复消费消息
为了保证消息不重复,消费端就不能重复消费消息,该如何去实现呢?消费端需要做好如下配置。
第一步,设置 enable.auto.commit=false。跟前面一样,这里同样要避免自动提交偏移量。你可以想象这样一种情况,消费端拉取消息和处理消息都完成了,但是自动提交偏移量还没提交消费端却挂了,这时候 Kafka 消费组开始重新平衡并把分区分给另一个消费者,由于偏移量没提交新的消费者会重复拉取消息,这就最终造成重复消费消息。
第二步,单纯配成手动提交同样不能避免重复消费,还需要消费端使用正确的消费”姿势”。
消费者拉取消息后,先提交 offset 后再处理消息,这样就不会出现重复消费消息的可能。但是你可以想象这样一个场景:在提交 offset 之后、业务逻辑处理消息之前出现了宕机,待消费者重新上线时,就无法读到刚刚已经提交而未处理的这部分消息,还是会有少消费消息的情况。这种情况也是少数,可以根据业务做补偿
具体代码如下:
java;gutter:true;
List messages = consumer.poll();
consumer.commitOffset(); processMsg(messages);
总结一下:
Kafka 中消息不丢失、不重复很重要,就我个人经验来讲,业务人员除了担忧消息队列服务端宕机外,对消息的丢失和消息的重复会非常敏感,因为这直接影响到了业务本身。
总体来讲,要保证消息不丢失和不重复,你要从生产端、服务端和消费端三个部分全盘考虑才可行,只是单独考虑某一端是远远不够的。同时,我也希望你搞懂消息语义的含义,因为所有的消息队列都会有相应的涉及。
Original: https://www.cnblogs.com/daohangtaiqian/p/15398724.html
Author: 道行太浅
Title: Kafka 是如何做到消息不丢或不重复的
原创文章受到原创版权保护。转载请注明出处:https://www.johngo689.com/594430/
转载文章受原作者版权保护。转载请注明原作者出处!