一种实现消息队列自动重推的处理方法与流程

1.本发明涉及分布式架构系统领域，特别涉及金融系统、商城系统、通讯系统等对于一些数据准确度要求较高的系统。


背景技术：

2.随着互联网行业的飞速发展，互联网软件系统需要支持更高的并发、更高的数据准确性，支持高并发、高可用的分布式架构在这种环境下应运而生，加强了系统的可用性、扩展性，还提高了软件开发团队的协作流程。
3.在分布式架构的环境下，涉及跨应用进行消息推送，一般使用kafka等消息中间件来进行消息推送。在使用消息中间件时，常出现不可预知的消息丢失的情况，导致消息接收方应用未能及时处理数据，通常只能用人工干预的方式才能将补推消息数据。本方案可以解决现有场景存在的缺陷，提高系统的健壮性，减少人工干预所带来的成本。


技术实现要素：

4.本发明要解决的技术问题是克服现有技术的缺陷，提供一种实现消息队列自动重推的处理方法。
5.本发明提供了如下的技术方案：
6.本发明提供一种实现消息队列自动重推的处理方法，包括以下步骤：
7.s1、消息发送方将消息id存入数据库或缓存中间件，并发送消息：
8.1).构建消息唯一标识(id)，一般可为数据库主键等；
9.2).根据重试次数计算得出自动重推的时间戳，将消息id与自动重推的时间戳一并存入到数据库或缓存中间件中，自动重推的时间戳为当前系统时间加上延迟时间，并记录重试次数；
10.3).将包含消息id的消息数据发送到kafka等消息队列中；
11.s2、消息接收方接收消息并处理完毕后，根据消息id使用删除数据库或缓存中间件中的id数据；
12.s3、消息发送方启用定时任务每分钟读取数据库或缓存中间件中未删除的消息id，读取成功时附带删除数据库或缓存中间件中的读取的数据；
13.s4、根据缓存中读到的消息id在数据库中查询对应的消息原数据，并将原数据组装成消息，然后重新执行步骤s1；
14.其中，重试的时间间隔如图1所示，重试次数总数为5次，时间间隔以递增的方式进行重试，根据重试次数间隔时间分别为：60秒、60秒、180秒、600秒、900秒，整体在半小时之内完成推送，如果最后一次推送依然失败，则将消息id存入死信表t_error_msg中。
15.与现有技术相比，本发明的有益效果如下：
16.1.发明完善的解决了“使用消息队列时偶现消息丢失”的情况。
17.2.相较于原先的消息队列推送方案，该发明能有效把控发送数据的收发状况，功
能健壮性高。
18.3.当消息反复推送失败时会存入死信表以供人工稽查，解决了出现故障导致消息丢失时难以找回数据的问题。
附图说明
19.附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：
20.图1是本发明的结构图；
21.图2是本发明的交互时序图；
22.图3是本发明的数据架构图；
23.图4是本发明的流程图。
具体实施方式
24.以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。其中附图中相同的标号全部指的是相同的部件。
25.实施例1
26.如图1-4，本案例使用redis作为缓存中间件实现消息队列自动重推的处理方法，包括以下流程步骤：
27.s1、消息发送方将消息id存入redis，并发送消息。
28.s2、消息接收方接收消息并处理完毕后，删除redis中的消息id。
29.s3、消息发送方启用定时任务读取redis中未删除的消息id。
30.s4、根据缓存中读到的消息id在数据库中查询对应的消息原数据，并将原数据组装成消息，然后重新执行步骤s1。
31.具体示例说明如下：
32.1、假设消息发送方当前需要发送的数据如下：
33.idordernotradetypetradedatetradestatus100001200001现金2021-11-23成功
34.消息发送方先将待发送的消息唯一标识使用zadd的方式保存到redis中，其中：redis的key设置为order，假设当前系统时间为2021-11-23 12:00:00，对应的时间戳为1637640000000，由于是第一次推送，设置超时时间为60秒，可得出score的值为1637640060000，最终可得到redis对应的命令为：zadd order 1637640060000 100001。
35.2、消息发送方将以id为100001的订单数据打包为消息数据:
[0036][0037]
并将消息发送到消息队列中间件(kafka等组件)。
[0038]
3、消息接收方从消息队列中间件消费订单消息数据并处理完后，根据"id":"100001"可得知消息的唯一标识为100001，则在redis中执行zrem order 100001命令删除消息唯一标识，表示数据已接收并处理完毕。
[0039]
4、假设消息接收方在超时时间内(此处为5分钟)没有将消息唯一标识从redis中删除，则触发消息发送方的自动重推功能，具体流程如下：
[0040]
(1)消息发送方使用自动任务组件每分钟执行一次redis命令，假设当前时间为2021-11-23 12:01:00，对应的时间戳为：1637640060000，则执行命令：zrangebyscore order 01637640060000
[0041]
(2)获取到消息唯一标识(订单id)后，使用zrem order 100001命令删除消息唯一标识，防止重复处理补推流程。
[0042]
(3)消息发送方根据订单id在数据库中查询到订单原数据，将原数据通过上文1步骤的方式重新进行推送处理。
[0043]
实施例2
[0044]
与实施例1使用缓存中间件不同的是，本案例使用mysql作为数据库实现消息队列自动重推的处理方法，并展示了反复推送消息失败的情况，包括以下流程步骤：
[0045]
具体示例说明如下：
[0046]
保存消息id的数据库表(t_msg)结构设计如下：
[0047]
字段名数据类型是否非空msg_idint是timeouttimestamp是retry_countint是
[0048]
1、假设消息发送方当前需要发送的数据如下：
[0049][0050][0051]
消息发送方先将待发送的消息唯一标识保存到t_msg表中，其中：假设当前系统时间为2021-11-23 12:00:00，如果是第一次推送，设置超时时间为60秒，可得出timeout的值为2021-11-23 12:01:00，最终可得到mysql的insert命令为：insert into`t_msg`(`msg_id`，`timeout`，`retry_count`)values(100002，'2021-11-2312:01:00'，1)。
[0052]
2、消息发送方将以id为100002的订单数据打包为消息数据:
[0053][0054]
并将消息发送到消息队列中间件(kafka等组件)。
[0055]
3、假设消息接收方没有收到对应的消息，在超时时间内(此处为1分钟)没有将消息唯一标识从t_msg表中删除，触发了消息发送方的自动重推功能，具体流程如下：
[0056]
(1)消息发送方使用自动任务组件每分钟执行一次sql命令，假设当前时间为2021-11-23 12:01:00，则执行sql语句：select*from`t_msg`where timeout《＝'2021-11-23 12:01:00'
[0057]
(2)获取到消息唯一标识(订单id)后，使用delete from`t_msg`where`msg_id`＝100002；语句删除消息唯一标识，防止重复处理补推流程。
[0058]
(3)消息发送方根据订单id在数据库中查询到订单原数据，将原数据通过上文步骤1的方式重新进行推送处理。
[0059]
4、当重复了5次步骤1之后，距离第一次推送数据已经过去了30分钟，此时仍无法推送成功，即可认为该消息为死信，需要入库死信表t_error_msg，对应的sql语句为：insert into`t_error_msg`(`msg_id`，`insert_time`，`error_reason`)values(100002，'2021-11-23 12:30:00'，
‘
消息反复推送失败’)。
[0060]
最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。