CN117290122A - 一种基于Kafka的多环境有序性生产消费的方法 - Google Patents
一种基于Kafka的多环境有序性生产消费的方法 Download PDFInfo
- Publication number
- CN117290122A CN117290122A CN202310200211.9A CN202310200211A CN117290122A CN 117290122 A CN117290122 A CN 117290122A CN 202310200211 A CN202310200211 A CN 202310200211A CN 117290122 A CN117290122 A CN 117290122A
- Authority
- CN
- China
- Prior art keywords
- message
- consumption
- messages
- kafka
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 54
- 238000004519 manufacturing process Methods 0.000 title claims abstract description 23
- 239000002243 precursor Substances 0.000 claims description 39
- 238000005192 partition Methods 0.000 claims description 26
- 230000008569 process Effects 0.000 claims description 8
- 230000007246 mechanism Effects 0.000 claims description 5
- 230000004048 modification Effects 0.000 claims description 4
- 238000012986 modification Methods 0.000 claims description 4
- 238000004806 packaging method and process Methods 0.000 claims description 3
- 238000012546 transfer Methods 0.000 claims description 3
- 238000012795 verification Methods 0.000 claims description 3
- 230000002618 waking effect Effects 0.000 claims description 3
- 230000005856 abnormality Effects 0.000 abstract description 4
- 238000012545 processing Methods 0.000 abstract description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1438—Restarting or rejuvenating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/524—Deadlock detection or avoidance
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供一种基于Kafka的多环境有序性生产消费的方法,涉及数据处理技术领域。该基于Kafka的多环境有序性生产消费的方法,该方法通过一款技术框架来实现,其特征在于,所述技术框架工作在应用层,不是独立的中间件系统,通过Maven或者Gradle将依赖导入到项目中,开箱即用,所述技术框架通过多个应用程序的消息框架向Kafka中间项传输投递消息和消费消息,并且通过DB端查阅待投递的消息。本发明中,其保证了消息可靠地有序生产,即便出现宕机、网络闪断异常、应用执行报错异常、数据库HA切换,仍能确保消息按序投递,并且不会出现消息丢失,保证了消息的幂等性,无论是生产者超时重试,还是消费者宕机,都不会出现重复消费的问题。
Description
技术领域
本发明涉及数据处理技术领域,具体为一种基于Kafka的多环境有序性生产消费的方法。
背景技术
在软件系统业务逻辑处理的流程中,通常会采用MQ来解耦服务之间的耦合调用,通过异步消息,缩短响应时间,提升系统性能,在异步消费的场景下有诸多问题,会导致消息的生产和消费不能按照业务中事务提交的顺序来执行,消息乱序可能会导致严重的业务影响,可能出现脏数据,写入覆盖等诸多问题。并且随着微服务架构的流行,多副本多环境的架构下,一套系统可能存在多套环境,如:预发布环境,生产环境V1,生产环境V2。在这种多环境的架构下,MQ消息的消息者可能有多个,同一个队列中的消息会被并发消费,在并发消费的场景下仍会消息消费的乱序,有序消费在多环境架构下面临诸多挑战。
由于业务方法执行时是并发执行的,生产者发送消息时,如果不通过技术手段来处理就会因为并发原因、网络延迟、服务卡顿等问题导致乱序投递,生产者向Kafka发送消息,即便是同步发送也会因为并发导致乱序,异步发送不能确保消息可靠投递,需要一种可靠投递的机制。
现有技术方案适用于单一环境下的有序消费,即一个partition只有一个消费者会接收到消息,在多环境的场景下,比如线上业务系统有V1版本的环境和V2版本的环境,两个环境的消费者使用不同的消费者组,均能收到来自同一个partition的消息,在多环境并行消费的场景下,无法保证业务有序性,针对消费失败的场景,Kafka默认的重试策略吞吐量较差,一个消息失败会阻塞后续消息的执行,并且在消息消费的过程中,可能出现重复消费问题,不能绝对保证消息消费的幂等性,一旦重复消费,可能对业务数据造成严重影响。
因此,本领域技术人员提供了一种基于Kafka的多环境有序性生产消费的方法,以解决上述背景技术中提出的问题。
发明内容
(一)解决的技术问题
针对现有技术的不足,本发明提供了一种基于Kafka的多环境有序性生产消费的方法,能够保证消息生产者的可靠性投递,无论生产者宕机、Kafka宕机、网络闪断、DB异常的故障场景,待故障恢复之后,生产者仍然可以继续进行有序投递,如果消费者在消费完消息之后,还未提交偏移量就宕机,那么重启之后,Kafka会重新投递消息,对重复消息进行幂等处理,避免重复消费。
(二)技术方案
为实现以上目的,本发明通过以下技术方案予以实现:
一种基于Kafka的多环境有序性生产消费的方法,该方法通过一款技术框架来实现,其特征在于,所述技术框架工作在应用层,不是独立的中间件系统,通过Maven或者Gradle将依赖导入到项目中,开箱即用,所述技术框架通过多个应用程序的消息框架向Kafka中间项传输投递消息和消费消息,并且通过DB端查阅待投递的消息。
该方法的实现过程包括以下步骤:
步骤一:消息的可靠性投递
S1.应用程序在完成业务操作之后,在同一个事务内将需要发送的消息落库,存储在消息表(msg_info)中,消息表需要存储该消息要发往哪个队列,应该被路由到哪个分区,这里的分区索引是通过业务数据的主键和Kafka队列的分区数进行hash,消息表中的主键使用自增ID,由于消息数据是和业务数据在同一个事务内完成的,因此消息的产生可以满足原子性,由于事务对数据进行修改时,会添加行锁,因此,即便是应用程序并发地访问数据库,但是在数据库层面,操作同一条数据首先需要获取到数据的行锁,行锁是独占锁,所以并发的线程会等待,因此,事务提交的顺序就是消息执行的先后顺序。
S2.获取分区粒度的分布式锁,避免有多个生产者并发地向同一个分区上生产消息,这样会导致生产者乱序投递。
S3.生产者拉取消息表中未投递的数据,按照SeqId排序,并将这些消息要操作的业务ID存储到针对每一个待发送的消息,将当前待发送的消息中,应该操作的ID存储到数据表msg_id_info中,便于后续消息在发送之前生成前驱消息。
S4.保存完消息对应的业务ID之后,需要判断当前待发送的消息是否存在前驱消息;
前驱消息:一个消息要想被消费,需要等待前驱消息消费完成才能开始消费当前消息,消息在发送时,需要判断是否存在前驱消息;
前驱链表:假如一个消息的SeqId为11,这个消息要操作的业务数据ID为3,那么根据SeqId倒序,查看当前事件之前是否存在操作ID为3的消息,如果存在,则将消息内添加前置消息的SeqId;
S5.前驱关系绑定完成之后,将待发送的消息发送至Kafka,需要将生产者ack的确认机制改为-1,即leader和follower均收到消息之后,才认为消息投递成功,发送完成之后将消息在数据库中的状态改为已投递,消息投递和状态修改在一个事务内,如果消息投递失败,就不会修改状态,并且生产者将不会继续投递下一个事件,而会在当前消息上不断重试,如果跳过当前消息继续投递,就会导致之前的消息丢失;
至此,生产者可以完成可靠且有序地将消息投递到Kafka的主题下的某一个分区上。
步骤二:生产者的容错处理与故障转移
如果生产者宕机,或者Kafka宕机,都会导致消息投递失败,针对以上场景,生产者应具备失败重试,故障转移等能力,具体场景和解决方案如下:
场景1:生产者宕机
重试处理:在生产者重启之后,应该拉取所有未投递的消息,进行重试
故障转移:如果集群内有多个生产者,一个生产者宕机,消息会被其他的生产者定时拉起重试,实现故障转移;
场景2:Kafka宕机
如果中间件宕机,生产者不断重试投递当前消息,直至成功为止。
步骤三:消息消费的幂等性
如果队列中有重复消息产生,消费者如果不做幂等性控制,会导致重复消费,可能会对业务产生严重影响,以下场景可能会产生重复消息:
场景1:如果生产者出现网络抖动,实际消息已经投递成功,但生产者没收到kafka的ACK,并判定本次消息发送失败,生产者将会重试投递该消息
场景2:由于Kafka消费者的偏移量通常是批量提交的,即消费完10条消息之后,提交一次偏移量,如果消息消费完成但是还没有提交偏移量,消费者宕机,此时Kafka未收到偏移量,消费者再次重启之后,Kafka会重新投递一次之前的消息,导致重复消费。
步骤四:可靠的有序消费
S1.幂等性校验与消费记录初始化;
S2.根据分区和消息中携带的业务ID,通过hash,找到对应的线程来处理,同一个分区不同的业务ID之间可以并发执行,提高了有序消费的并发度;
S3.判断是否存在前驱消息,如果存在,判断前驱消息是否消费完成,如果前驱消息未消费完成,则将当前的消费记录的状态改为排队中。如果已经消费完成,或者前驱消息不存在,则开始消费当前消息;
S4.获取当前消息要消费的业务数据主键,并判断,当前分区下,是否存在消费失败的消息,如果存在消费失败的消息,需要排队等待之前失败的消息重试成功,才能继续消费,否则就会导致消费乱序,因为队列之前的数据有消费失败的消息,如果直接消费,当之前失败的消息开始重试时,就导致了乱序消费;
S5.跟踪消息的消费情况,如果消息消费成功,则将消费记录的状态改为消费成功,如果消息消费失败,则将当前消息的消费状态改为失败;
S6.消费成功之后,提交消费者的针对当前消费分支和业务ID的偏移量,并唤醒后续排队等待的事件。
所述步骤一中的S3中,若待投递的消息SeqId=10,该消息的业务数据中,需要操作业务ID为3的业务数据,则在msg_id_info中存储的结构为seqId,businessId存储结果为10,3。
所述步骤一中的S4中,将前驱消息“指向”前一个消息的seqId,这里的指向只是在Kafka的消息头中存储了一个preSeq的属性,标识了一个消息的前驱消息的SeqId,假如SeqId为10的消息也要操作ID为3的业务数据,那么该消息的preSeq=10,后续事件的前驱消息绑定方式以此类推,最终在队列中会生成前驱链表。
所述步骤三中场景的解决方案如下:
由于消息的SeqId是唯一的,且消费的业务逻辑是具备唯一性的,在框架中,使用执行器来包装业务逻辑,所述执行器是一个实现了Runnable接口的类,封装了框架逻辑和业务逻辑,通过SeqId和消费者组Id加上方法名称可以保证唯一性,消息在消费之前会先初始化执行器的执行记录,将消费记录插入到数据库中,如果出现唯一索引冲突,说明消息被消费过,无需重复消费。
所述步骤四中的S4中,若消费顺序是1->2->3,如果1失败了,2和3成功了,那么1重试之后,消费顺序就变为了2->3->1,导致消息消费的乱序。
所述步骤四中,若消费者1内,针对业务1有一个消费监听,业务1是一个业务方法,对传入的业务参数进行数据处理,该方法可以并发执行,多个线程执行业务1方法,只需要确保执行的方法中,业务参数不同即可,消费完成之后,提交偏移量,格式如下:业务方法1,业务ID,消息的seqId。偏移量就是S3中判断前置消息是否完成的条件,如果一个消息在执行之前,需要先判断前置消息是否执行完成,就是判断当前业务方法的偏移量是否大于等于前置消息的seqId。
(三)有益效果
本发明提供了一种基于Kafka的多环境有序性生产消费的方法。具备以下有益效果:
1、本发明提供了一种基于Kafka的多环境有序性生产消费的方法,保证了消息可靠地有序生产,即便出现宕机、网络闪断异常、应用执行报错异常、数据库HA切换,仍能确保消息按序投递,并且不会出现消息丢失。
2、本发明提供了一种基于Kafka的多环境有序性生产消费的方法,保证了消息的幂等性,无论是生产者超时重试,还是消费者宕机,都不会出现重复消费的问题。
3、本发明提供了一种基于Kafka的多环境有序性生产消费的方法,在分区有序消费的前提下,再根据业务ID进行路由,使用多线程来消费不同业务ID的数据,提升了消息消费的并发度,一定程度上避免了任务阻塞的问题。
4、本发明提供了一种基于Kafka的多环境有序性生产消费的方法,在多环境,多个消费者的情况下,仍能通过前驱判断和排队唤醒机制保证消息的有序消费。
附图说明
图1为本发明的技术框架内部结构示意图;
图2为本发明的技术框架方案组成示意图;
图3为本发明的事务和消息入库流程示意图;
图4为本发明的前驱链表流程图;
图5为本发明的生产者发送流程示意图;
图6为本发明的生产者容错处理与故障转移技术原理图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
实施例:
如图1-6所示,本发明实施例提供一种基于Kafka的多环境有序性生产消费的方法,该方法通过一款技术框架来实现,其特征在于,所述技术框架工作在应用层,不是独立的中间件系统,通过Maven或者Gradle将依赖导入到项目中,开箱即用,所述技术框架通过多个应用程序的消息框架向Kafka中间项传输投递消息和消费消息,并且通过DB端查阅待投递的消息。
该方法的实现过程包括以下步骤:
步骤一:消息的可靠性投递
S1.应用程序在完成业务操作之后,在同一个事务内将需要发送的消息落库,存储在消息表(msg_info)中,消息表需要存储该消息要发往哪个队列,应该被路由到哪个分区,这里的分区索引是通过业务数据的主键和Kafka队列的分区数进行hash,消息表中的主键使用自增ID,由于消息数据是和业务数据在同一个事务内完成的,因此消息的产生可以满足原子性,由于事务对数据进行修改时,会添加行锁,因此,即便是应用程序并发地访问数据库,但是在数据库层面,操作同一条数据首先需要获取到数据的行锁,行锁是独占锁,所以并发的线程会等待,因此,事务提交的顺序就是消息执行的先后顺序。
消息要发送的顺序就是自增ID的顺序,这个主键就是消息的全局有序的SequenceId(SeqId),事务和消息入库流程如附图3所示。
S2.获取分区粒度的分布式锁,避免有多个生产者并发地向同一个分区上生产消息,这样会导致生产者乱序投递。
S3.生产者拉取消息表中未投递的数据,按照SeqId排序,并将这些消息要操作的业务ID存储到针对每一个待发送的消息,将当前待发送的消息中,应该操作的ID存储到数据表msg_id_info中,便于后续消息在发送之前生成前驱消息;
若待投递的消息SeqId=10,该消息的业务数据中,需要操作业务ID为3的业务数据,则在msg_id_info中存储的结构为seqId,businessId存储结果为10,3。
S4.保存完消息对应的业务ID之后,需要判断当前待发送的消息是否存在前驱消息;
前驱消息:一个消息要想被消费,需要等待前驱消息消费完成才能开始消费当前消息,消息在发送时,需要判断是否存在前驱消息;
前驱链表:假如一个消息的SeqId为11,这个消息要操作的业务数据ID为3,那么根据SeqId倒序,查看当前事件之前是否存在操作ID为3的消息,如果存在,则将消息内添加前置消息的SeqId;
将前驱消息“指向”前一个消息的seqId,这里的指向只是在Kafka的消息头中存储了一个preSeq的属性,标识了一个消息的前驱消息的SeqId,假如SeqId为10的消息也要操作ID为3的业务数据,那么该消息的preSeq=10,后续事件的前驱消息绑定方式以此类推,最终在队列中会生成前驱链表,前驱链表如附图4所示。
S5.前驱关系绑定完成之后,将待发送的消息发送至Kafka,需要将生产者ack的确认机制改为-1,即leader和follower均收到消息之后,才认为消息投递成功,发送完成之后将消息在数据库中的状态改为已投递,消息投递和状态修改在一个事务内,如果消息投递失败,就不会修改状态,并且生产者将不会继续投递下一个事件,而会在当前消息上不断重试,如果跳过当前消息继续投递,就会导致之前的消息丢失,生产者发送流程如附图5所示;
至此,生产者可以完成可靠且有序地将消息投递到Kafka的主题下的某一个分区上。
步骤二:生产者的容错处理与故障转移
如果生产者宕机,或者Kafka宕机,都会导致消息投递失败,针对以上场景,生产者应具备失败重试,故障转移等能力,具体场景和解决方案如下:
场景1:生产者宕机
重试处理:在生产者重启之后,应该拉取所有未投递的消息,进行重试
故障转移:如果集群内有多个生产者,一个生产者宕机,消息会被其他的生产者定时拉起重试,实现故障转移;
场景2:Kafka宕机
如果中间件宕机,生产者不断重试投递当前消息,直至成功为止。
步骤三:消息消费的幂等性
如果队列中有重复消息产生,消费者如果不做幂等性控制,会导致重复消费,可能会对业务产生严重影响,以下场景可能会产生重复消息:
场景1:如果生产者出现网络抖动,实际消息已经投递成功,但生产者没收到kafka的ACK,并判定本次消息发送失败,生产者将会重试投递该消息
场景2:由于Kafka消费者的偏移量通常是批量提交的,即消费完10条消息之后,提交一次偏移量,如果消息消费完成但是还没有提交偏移量,消费者宕机,此时Kafka未收到偏移量,消费者再次重启之后,Kafka会重新投递一次之前的消息,导致重复消费;
解决方案:由于消息的SeqId是唯一的,且消费的业务逻辑是具备唯一性的,在框架中,使用执行器来包装业务逻辑,所述执行器是一个实现了Runnable接口的类,封装了框架逻辑和业务逻辑,通过SeqId和消费者组Id加上方法名称可以保证唯一性,消息在消费之前会先初始化执行器的执行记录,将消费记录插入到数据库中,如果出现唯一索引冲突,说明消息被消费过,无需重复消费。
步骤四:可靠的有序消费
S1.幂等性校验与消费记录初始化;
S2.根据分区和消息中携带的业务ID,通过hash,找到对应的线程来处理,同一个分区不同的业务ID之间可以并发执行,提高了有序消费的并发度;
S3.判断是否存在前驱消息,如果存在,判断前驱消息是否消费完成,如果前驱消息未消费完成,则将当前的消费记录的状态改为排队中。如果已经消费完成,或者前驱消息不存在,则开始消费当前消息;
S4.获取当前消息要消费的业务数据主键,并判断,当前分区下,是否存在消费失败的消息,如果存在消费失败的消息,需要排队等待之前失败的消息重试成功,才能继续消费,否则就会导致消费乱序,因为队列之前的数据有消费失败的消息,如果直接消费,当之前失败的消息开始重试时,就导致了乱序消费;
例:若消费顺序是1->2->3,如果1失败了,2和3成功了,那么1重试之后,消费顺序就变为了2->3->1,导致消息消费的乱序;
S5.跟踪消息的消费情况,如果消息消费成功,则将消费记录的状态改为消费成功,如果消息消费失败,则将当前消息的消费状态改为失败;
S6.消费成功之后,提交消费者的针对当前消费分支和业务ID的偏移量,并唤醒后续排队等待的事件。
在步骤四中,若消费者1内,针对业务1有一个消费监听,业务1是一个业务方法,对传入的业务参数进行数据处理,该方法可以并发执行,多个线程执行业务1方法,只需要确保执行的方法中,业务参数不同即可,消费完成之后,提交偏移量,格式如下:业务方法1,业务ID,消息的seqId。偏移量就是S3中判断前置消息是否完成的条件,如果一个消息在执行之前,需要先判断前置消息是否执行完成,就是判断当前业务方法的偏移量是否大于等于前置消息的seqId。
尽管已经示出和描述了本发明的实施例,对于本领域的普通技术人员而言,可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型,本发明的范围由所附权利要求及其等同物限定。
Claims (7)
1.一种基于Kafka的多环境有序性生产消费的方法,该方法通过一款技术框架来实现,其特征在于,所述技术框架工作在应用层,不是独立的中间件系统,通过Maven或者Gradle将依赖导入到项目中,开箱即用,所述技术框架通过多个应用程序的消息框架向Kafka中间项传输投递消息和消费消息,并且通过DB端查阅待投递的消息。
2.根据权利要求1所述的一种基于Kafka的多环境有序性生产消费的方法,其特征在于,该方法的实现过程包括以下步骤:
步骤一:消息的可靠性投递
S1.应用程序在完成业务操作之后,在同一个事务内将需要发送的消息落库,存储在消息表(msg_info)中,消息表需要存储该消息要发往哪个队列,应该被路由到哪个分区,这里的分区索引是通过业务数据的主键和Kafka队列的分区数进行hash,消息表中的主键使用自增ID,由于消息数据是和业务数据在同一个事务内完成的,因此消息的产生可以满足原子性,由于事务对数据进行修改时,会添加行锁,因此,即便是应用程序并发地访问数据库,但是在数据库层面,操作同一条数据首先需要获取到数据的行锁,行锁是独占锁,所以并发的线程会等待,因此,事务提交的顺序就是消息执行的先后顺序。
S2.获取分区粒度的分布式锁,避免有多个生产者并发地向同一个分区上生产消息,这样会导致生产者乱序投递。
S3.生产者拉取消息表中未投递的数据,按照Seq Id排序,并将这些消息要操作的业务ID存储到针对每一个待发送的消息,将当前待发送的消息中,应该操作的ID存储到数据表msg_id_info中,便于后续消息在发送之前生成前驱消息。
S4.保存完消息对应的业务ID之后,需要判断当前待发送的消息是否存在前驱消息;
前驱消息:一个消息要想被消费,需要等待前驱消息消费完成才能开始消费当前消息,消息在发送时,需要判断是否存在前驱消息;
前驱链表:假如一个消息的Seq Id为11,这个消息要操作的业务数据ID为3,那么根据Seq Id倒序,查看当前事件之前是否存在操作ID为3的消息,如果存在,则将消息内添加前置消息的Seq Id;
S5.前驱关系绑定完成之后,将待发送的消息发送至Kafka,需要将生产者ack的确认机制改为-1,即leader和fol lower均收到消息之后,才认为消息投递成功,发送完成之后将消息在数据库中的状态改为已投递,消息投递和状态修改在一个事务内,如果消息投递失败,就不会修改状态,并且生产者将不会继续投递下一个事件,而会在当前消息上不断重试,如果跳过当前消息继续投递,就会导致之前的消息丢失。
步骤二:生产者的容错处理与故障转移
如果生产者宕机,或者Kafka宕机,都会导致消息投递失败,针对以上场景,生产者应具备失败重试,故障转移等能力,具体场景和解决方案如下:
场景1:生产者宕机
重试处理:在生产者重启之后,应该拉取所有未投递的消息,进行重试故障转移:如果集群内有多个生产者,一个生产者宕机,消息会被其他的生产者定时拉起重试,实现故障转移;
场景2:Kafka宕机
如果中间件宕机,生产者不断重试投递当前消息,直至成功为止。
步骤三:消息消费的幂等性
如果队列中有重复消息产生,消费者如果不做幂等性控制,会导致重复消费,可能会对业务产生严重影响,以下场景可能会产生重复消息:
场景1:如果生产者出现网络抖动,实际消息已经投递成功,但生产者没收到kafka的ACK,并判定本次消息发送失败,生产者将会重试投递该消息
场景2:由于Kafka消费者的偏移量通常是批量提交的,即消费完10条消息之后,提交一次偏移量,如果消息消费完成但是还没有提交偏移量,消费者宕机,此时Kafka未收到偏移量,消费者再次重启之后,Kafka会重新投递一次之前的消息,导致重复消费。
步骤四:可靠的有序消费
S1.幂等性校验与消费记录初始化;
S2.根据分区和消息中携带的业务ID,通过hash,找到对应的线程来处理,同一个分区不同的业务ID之间可以并发执行,提高了有序消费的并发度;
S3.判断是否存在前驱消息,如果存在,判断前驱消息是否消费完成,如果前驱消息未消费完成,则将当前的消费记录的状态改为排队中。如果已经消费完成,或者前驱消息不存在,则开始消费当前消息;
S4.获取当前消息要消费的业务数据主键,并判断,当前分区下,是否存在消费失败的消息,如果存在消费失败的消息,需要排队等待之前失败的消息重试成功,才能继续消费,否则就会导致消费乱序,因为队列之前的数据有消费失败的消息,如果直接消费,当之前失败的消息开始重试时,就导致了乱序消费;
S5.跟踪消息的消费情况,如果消息消费成功,则将消费记录的状态改为消费成功,如果消息消费失败,则将当前消息的消费状态改为失败;
S6.消费成功之后,提交消费者的针对当前消费分支和业务ID的偏移量,并唤醒后续排队等待的事件。
3.根据权利要求2所述的一种基于Kafka的多环境有序性生产消费的方法,其特征在于:所述步骤一中的S3中,若待投递的消息Seq Id=10,该消息的业务数据中,需要操作业务ID为3的业务数据,则在msg_id_info中存储的结构为seq Id,businessId存储结果为10,3。
4.根据权利要求2所述的一种基于Kafka的多环境有序性生产消费的方法,其特征在于:所述步骤一中的S4中,将前驱消息“指向”前一个消息的seq Id,这里的指向只是在Kafka的消息头中存储了一个preSeq的属性,标识了一个消息的前驱消息的Seq Id,假如Seq Id为10的消息也要操作ID为3的业务数据,那么该消息的preSeq=10,后续事件的前驱消息绑定方式以此类推,最终在队列中会生成前驱链表。
5.根据权利要求2所述的一种基于Kafka的多环境有序性生产消费的方法,其特征在于:所述步骤三中场景的解决方案如下:
由于消息的Seq Id是唯一的,且消费的业务逻辑是具备唯一性的,在框架中,使用执行器来包装业务逻辑,所述执行器是一个实现了Runnable接口的类,封装了框架逻辑和业务逻辑,通过Seq Id和消费者组Id加上方法名称可以保证唯一性,消息在消费之前会先初始化执行器的执行记录,将消费记录插入到数据库中,如果出现唯一索引冲突,说明消息被消费过,无需重复消费。
6.根据权利要求2所述的一种基于Kafka的多环境有序性生产消费的方法,其特征在于:所述步骤四中的S4中,若消费顺序是1->2->3,如果1失败了,2和3成功了,那么1重试之后,消费顺序就变为了2->3->1,导致消息消费的乱序。
7.根据权利要求2所述的一种基于Kafka的多环境有序性生产消费的方法,其特征在于:所述步骤四中,若消费者1内,针对业务1有一个消费监听,业务1是一个业务方法,对传入的业务参数进行数据处理,该方法可以并发执行,多个线程执行业务1方法,只需要确保执行的方法中,业务参数不同即可,消费完成之后,提交偏移量,格式如下:业务方法1,业务ID,消息的seq Id。偏移量就是S3中判断前置消息是否完成的条件,如果一个消息在执行之前,需要先判断前置消息是否执行完成,就是判断当前业务方法的偏移量是否大于等于前置消息的seq Id。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310200211.9A CN117290122A (zh) | 2023-02-28 | 2023-02-28 | 一种基于Kafka的多环境有序性生产消费的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310200211.9A CN117290122A (zh) | 2023-02-28 | 2023-02-28 | 一种基于Kafka的多环境有序性生产消费的方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN117290122A true CN117290122A (zh) | 2023-12-26 |
Family
ID=89250581
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310200211.9A Pending CN117290122A (zh) | 2023-02-28 | 2023-02-28 | 一种基于Kafka的多环境有序性生产消费的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN117290122A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117692877A (zh) * | 2024-02-02 | 2024-03-12 | 浩鲸云计算科技股份有限公司 | 面向计费c++应用的分布式消息分发方法及系统 |
CN117742998A (zh) * | 2024-02-18 | 2024-03-22 | 浩鲸云计算科技股份有限公司 | 一种面向计费采集数据转发的高性能队列方法及系统 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111930538A (zh) * | 2020-07-31 | 2020-11-13 | 银盛支付服务股份有限公司 | 一种基于kafka集群的生产与消费的方法 |
CN112579274A (zh) * | 2020-12-16 | 2021-03-30 | 中国建设银行股份有限公司 | 一种多渠道接入消息转发方法和装置 |
CN113094362A (zh) * | 2021-04-30 | 2021-07-09 | 中国银行股份有限公司 | 一种异步消息可靠投递和处理的方法和装置 |
CN115328664A (zh) * | 2022-10-11 | 2022-11-11 | 苏州万店掌网络科技有限公司 | 一种消息消费方法、装置、设备及介质 |
-
2023
- 2023-02-28 CN CN202310200211.9A patent/CN117290122A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111930538A (zh) * | 2020-07-31 | 2020-11-13 | 银盛支付服务股份有限公司 | 一种基于kafka集群的生产与消费的方法 |
CN112579274A (zh) * | 2020-12-16 | 2021-03-30 | 中国建设银行股份有限公司 | 一种多渠道接入消息转发方法和装置 |
CN113094362A (zh) * | 2021-04-30 | 2021-07-09 | 中国银行股份有限公司 | 一种异步消息可靠投递和处理的方法和装置 |
CN115328664A (zh) * | 2022-10-11 | 2022-11-11 | 苏州万店掌网络科技有限公司 | 一种消息消费方法、装置、设备及介质 |
Non-Patent Citations (1)
Title |
---|
小小开发者: "SpringBoot整合Kafka实现消息的发送和接收", Retrieved from the Internet <URL:https://mp.weixin.qq.com/s/6_FNEVgOgl9_Mw3EEFPvTA> * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117692877A (zh) * | 2024-02-02 | 2024-03-12 | 浩鲸云计算科技股份有限公司 | 面向计费c++应用的分布式消息分发方法及系统 |
CN117692877B (zh) * | 2024-02-02 | 2024-05-03 | 浩鲸云计算科技股份有限公司 | 面向计费c++应用的分布式消息分发方法及系统 |
CN117742998A (zh) * | 2024-02-18 | 2024-03-22 | 浩鲸云计算科技股份有限公司 | 一种面向计费采集数据转发的高性能队列方法及系统 |
CN117742998B (zh) * | 2024-02-18 | 2024-05-07 | 浩鲸云计算科技股份有限公司 | 一种面向计费采集数据转发的高性能队列方法及系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN117290122A (zh) | 一种基于Kafka的多环境有序性生产消费的方法 | |
US8868492B2 (en) | Method for maximizing throughput and minimizing transactions response times on the primary system in the presence of a zero data loss standby replica | |
US9325757B2 (en) | Methods and systems for fault-tolerant distributed stream processing | |
EP1402363B1 (en) | Method for ensuring operation during node failures and network partitions in a clustered message passing server | |
US6438707B1 (en) | Fault tolerant computer system | |
US7865763B2 (en) | Data replication method | |
CN110941502B (zh) | 消息处理方法、装置、存储介质及设备 | |
US20070260714A1 (en) | Asynchronous interconnect protocol for a clustered dbms | |
CN103036717A (zh) | 分布式数据的一致性维护系统和方法 | |
KR20010079917A (ko) | 복제 서버용 프로토콜 | |
US7562154B2 (en) | System and method for filtering stale messages resulting from membership changes in a distributed computing environment | |
EP4213038A1 (en) | Data processing method and apparatus based on distributed storage, device, and medium | |
US20130275626A1 (en) | Computer system | |
CN112925614B (zh) | 一种分布式事务处理方法、装置、介质和设备 | |
CN112148436B (zh) | 去中心化的tcc事务管理方法、装置、设备及系统 | |
US9069632B2 (en) | Message processing | |
CN111930538A (zh) | 一种基于kafka集群的生产与消费的方法 | |
WO2024051454A1 (zh) | 处理事务日志的方法及装置 | |
US6185702B1 (en) | Method and system for process state management using checkpoints | |
CN108390919A (zh) | 一种用于高可靠双机热备的消息同步系统及方法 | |
CN105373563B (zh) | 数据库切换方法及装置 | |
US6345282B1 (en) | Multi-processor data synchronization method and apparatus | |
CN114500416A (zh) | 用于最多一次消息投递的投递方法和投递系统 | |
CN113992681A (zh) | 一种保证分布式系统中数据强一致性的方法 | |
US8201017B2 (en) | Method for queuing message and program recording medium thereof |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |