CN111510469B - 一种消息处理方法和装置 - Google Patents

Abstract

本发明公开了一种消息处理方法和装置，该消息处理方法，包括：接收消息投放请求后，将接收到的消息存储至消息存储集群；轮询消息存储集群中已过期消息，按照约定策略进行消息的处理投递；消息投递后接受方未按照约定答复，则延迟指定的时间再次投递消息；多次同时批量获取消息，如果其中一个所述的消息已经被消费标记，则当前消费时间根据返回的内容不进行处理，处理未标记的消息id；对已经被消费标记的消息设定固定过期时间，当超过设定的固定过期时间后，对该消息进行投放处理。本发明针对支付系统或电商系统中存在大量的稍后重试或错误失败重试场景，对于每条消息投放提供可变时的延时通知配置以及对应的下游服务配置。

Description

一种消息处理方法和装置

技术领域

本发明涉及计算机技术领域，特别涉及一种消息处理方法和装置。

背景技术

支付系统存在大量的异步通知场景，如支付完成通知商户发货，支付后查询第三方获得支付结果，此时消息在通知过程中可能因为商户或者下游系统未准备好需要再次通知。

异步消息是消息中间件中的概念，存放在消息队列中，通常用于同步操作异步化与业务逻辑解耦。比如生产者发送特定结构的消息到队列中之后，消费者订阅消息队列，获取消息并消费。例如现在的支付和服务分发业务，普遍存在交易结果通知回调，而且要求要做到最大努力通知，现在的支付和服务分发业务及审计日志业务，都要求尽量做成异步的，不要影响主业务。

然而，本专利申请发明人发现，现有技术至少存在如下问题：

1、常规的异步通知处理可能会因为下游状态不稳定，从而导致下游不能正确收到被通知的消息。

2、遇到高并发场景时，固定间隔的稍后重试对系统造成较大的压力。

3、不同的异步通知场景需要额外设计实施新的定时任务，成本较高。

发明内容

本发明的目的是提供一种消息处理方法和装置，针对支付系统或电商系统中存在大量的稍后重试或错误失败重试场景，对于每条消息投放提供可变时的延时通知配置以及对应的下游服务配置。

为了实现以上目的，本发明是通过以下技术方案实现的：

一种消息处理方法，包括：

接收消息投放请求，将消息按照组织格式存储至消息存储集群；

轮询消息存储集群中已过期消息，按照约定策略进行消息的处理投递。

进一步地，所述的消息以序列化串方式存储，并按照key-value形式存储于消息存储集群中，所述的key为消息id，value为消息体。

进一步地，所述的消息体包括：用户投递的消息内容、消息到期时间戳和消息回调地址。

进一步地，所述的消息体还包括消息重试策略，则本发明实施例的按照约定策略进行消息的处理投递进一步包括：

消息投递后若未收到按照约定的答复，则延迟指定的时间再次投递消息。

进一步地，本发明实施例的方法进一步包括：

对过期消息进行时间序列，所述对过期消息进行时间序列包括：

采用redis zset结构组织消息片，并从redis zset中跟进时间戳范围获取到期的所有消息id，根据消息id获取消息id对应消息体投放，其中存放消息过期时间序列的zset称为过期序列zset。

进一步地，所述redis zset对应存储一个时间片序列，所述的方法进一步包括：

获取当前时间片zset的位置，根据分布存储值并结合过期序列zset找到当前时间到期的所有消息id，再次进行获取当前时间到期的所有消息id。

进一步地，如果其中一个所述的消息体已经被消费标记，则当前消费时间根据返回的内容不进行处理，处理未标记的消息id。

进一步地，所述的处理未标记的消息id后进一步包括：

对已经被消费标记的消息体设定固定过期时间，当该消息被消费占用时间超过设定的固定过期时间后，对该消息体进行投放处理。

进一步地，本发明实施的方法还包括：

当消息投放失败后，删除时间序列zset和过期序列zset的指定值，并根据重试策略设定新的过期时间。

根据本发明又一实施例，提供了一种消息处理装置，包括处理器、存储器以及存储在所述存储器中且被配置为由所述处理器执行的计算机程序，其特征在于，所述的处理器执行所述计算机程序时实现上述的消息处理方法。

本发明与现有技术相比，具有以下优点：

1、针对支付系统或电商系统中存在大量的稍后重试或错误失败重试场景，对于每条消息投放提供可变时的延时通知配置以及对应的下游服务配置，通过设定延迟重试策略支持常见互联网服务的事后处理与消息通知，确保投递至下游系统。

2、该消息处理系统提供一个HTTP接口，服务后台仅需调用HTTP接口投放消息即可完成事后通知，服务事后处理的成本仅一次HTTP调用，采用最常用HTTP接口协议输入与回调，适应通用化互联网后台服务场景。

3、高可用性，能够在系统组件故障后持久消息，通过设置时间分片切割的大小，例如切割为10ms，使得延迟处理过程精确到10ms，可作为业务精确定时器使用。

4、该消息处理系统最大服务能力可支持100万QPS(Query per second,每秒系统的请求查询数)以上。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图进行简单介绍，显而易见的，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一种消息处理方法的实施例1的流程图；

图2为本发明消息组织的结构示意图；

图3为本发明一种消息处理方法的实施例2的流程图；

图4为本发明中redis集群中的消息组织格式图；

图5为本发明一种消息处理系统的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，在本文中，诸如“第一”、“第二”、“第三”等关系术语(如果存在)仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。应该理解这样使用的术语在适当情况下可以互换，以便这里描述的本发明的实施例，例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”、“包含”、“具有”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括……”或“包含……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的要素。此外，在本文中，“大于”、“小于”、“超过”等理解为不包括本数；“以上”、“以下”、“以内”等理解为包括本数。

一种消息处理方法的实施例之一

图1示出了一种消息处理方法的流程图，如图1所示，一种消息处理方法，包括如下步骤：

S101，接收消息投放请求后，将接收的消息存储至消息存储集群；

S102，轮询消息存储集群中已过期消息，按照约定策略进行消息的处理投递。

示例性的，为了实现高效与高可用，上述处理方法基于redis集群(cluster)实施，同时为了保证应用的高可用和容量，采用互联网常见的分布式docker部署方式部署。

具体地，所述的步骤S101通过构建一消息发布模块作为消息发布服务的入口，消息发布模块接受消息投放请求，并将消息按照存储于消息存储redis集群，需要说明的是，该消息发布模块可以采用互联网常见服务系统构建，例如可以采用Springboot框架构建。

进一步地，消息存储集群为基于redis3.0版本构建的redis集群系统，配备部署Redis-sentinel哨兵应用自动切换集群(cluster)主从，用以单实例节点故障时自动切换主从容灾，Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自行切换，主要功能有：不时地监控redis是否按照预期良好地运行；如果发现某个redis节点运行出现状况，能够通知另外一个进程(例如它的客户端)；能够进行自动切换，当一个master节点不可用时，能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master，其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。此外，上述的消息存储redis集群主要存储消息分片信息和消息体信息。

在具体实施例中，所述的步骤S102通过构建一消息消费模块实现，所述的消息消费模块为一组毫秒级循环定时任务服务，可以轮询消息存储集群中已过期消息，按照约定策略进行消息的处理投递。进一步地，上述约定策略为：对于成功投递的消息，需要从消息存储redis中删除，对于投递失败的消息，需要按照重投策略再次投放。

通过上述，对于每条消息投放提供可变时的延时通知配置以及对应的下游服务配置，通过设定延迟重试策略支持常见互联网服务的事后处理与消息通知，确保投递至下游系统。

可选的，参照图2，图2为消息组织的结构示意图，在上述实施例中，所述的消息以序列化串方式存储于redis集群中，并按照关键字-值(key-value)形式存储于消息存储集群中，所述的关键字(key)为消息id，值(value)为消息体。所述的消息体包括用户投递的消息内容、过期绝对时间、消息回调地址和消息重试策略；上述的过期绝对时间为本条消息到期时间戳，消息回调地址包括记录消息投递地址，该记录投递地址支持HTTP、eureka、rpc等协议；消息重试策略具体为：设定具体的延迟重试时间，比如1、2、3、4秒，表明消息投递后若接收方未按约定答复，延迟指定的时间再次投递消息。

进一步地，所述的按照约定策略进行消息的处理投递还包括：

通过重试策略对消息做延迟投递处理，具体则有，消息投递后若未收到按照约定的答复，延迟指定的时间再次投递消息，示例性的，重试投递为，失败1秒后再次投递，如果失败2秒后再次投递，如果失败3秒后再次投递，最后一次投递失败后，则不再继续投递。

为了能够让消息按照时间进行存储，此处采用了redis zset结构组织消息片，利用zset能够按照score进行自动排序的特性。zset score值为消息的绝对过期时间，value为消息体id(关联消息结构体存储的key)，这样可以按照到期时间大小顺序排序。消息消费服务可以从zset中跟进时间戳范围获取到期的所有消息id，根据消息id去获取消息id对应消息结构体投放。所述的存放消息过期时间序列的zset称为过期序列zset。

通过上述解决了消息的延迟投递及时间存储的问题。

redis中zset使用跳表实现，在海量数据的情况下，一个zset的存储数据过多，会导致性能减慢，同时也会导致每次投放，cluster的slave都要进行大数据量的同步，继而造成性能瓶颈。

为了解决此问题，所述的方法进一步包括：采用redis zset对应存储一个时间片序列，并获取当前时间片zset的位置，根据分布存储值并结合过期序列zset找到当前时间到期的所有消息id，再次进行获取当前时间到期的所有消息id。具体地，每个时间片序列的值存储为过期序列zset的key，称为时间片序列zset，特定时间消息消费服务，先获得当前时间片zset是哪个时间片，根据时间片存储的值再次去过期序列zset找到当前时间到期的所有消息id，再次进行获取，解决了cluster的slave都要进行大数据量的同步，继而造成性能瓶颈的问题，并通过调节时间片的大小进而可以调节每个时间片中过期序列zset的大小，示例性的一般采用1分钟一个时间片，这样redis中每个存储的大小都比较均衡，另外还可以将时间片分割成10ms，使得延迟处理过程精确到10ms，从而作为业务精确定时器使用。

一种消息处理方法的实施例之二

图3示出了一种消息处理方法的流程图，如图3所示，一种消息处理方法，包括如下步骤：

步骤S201，接收消息投放请求，将消息按照组织格式存储至消息存储集群；

步骤S202，轮询消息存储集群中已过期消息，按照约定策略进行消息的处理投递。

步骤S201和步骤S202与上述实施例中的S101和S102内容类似，这里不做详细阐述。

所述的消息以序列化串方式存储于redis集群中，并按照key-value形式存储于消息存储集群中，所述的key为消息id，value为消息体。所述的消息体包括用户投递的消息内容、过期绝对时间、消息回调地址和消息重试策略；上述的过期绝对时间为本条消息到期时间戳，消息回调地址包括记录消息投递地址，该记录投递地址支持HTTP、eureka、rpc等协议；消息重试策略具体为：设定具体的延迟重试时间，比如1、2、3、4秒，表明消息投递后若接收方未按约定答复，延迟指定的时间再次投递消息。

通过重试策略对消息做延迟投递处理，具体则有，消息投递后若未收到按照约定的答复，延迟指定的时间再次投递消息，示例性的，重试投递为，失败1秒后再次投递，如果失败2秒后再次投递，如果失败3秒后再次投递，最后一次投递失败后，则不再继续投递。

步骤S203，多次同时批量获取消息，如果其中一个所述的消息已经被消费标记，则当前消费时间根据返回的内容不进行处理，处理未标记的消息id。

在具体实施例中，为了保证性能，每个消息模块获取消息是批量执行的，在毫秒级的处理周期中，多个消息消费模块定时消费消息时，往往会同步获取到同一条消息体，这样会导致多个消费实例多次投递同一条消息。为了解决上述问题，采用单台redis的setnx和multi功能，多个消息体id保证执行的原子性，如果一个消息体已被另外一个消费实例占用，则当前消费时间根据setnx返回内容不进行处理，仅处理未标记的消息id，这样可以做到多个消费实例不会同时处理一个消息。

S204，对已经被消费标记的消息设定固定过期时间，当超过设定的固定过期时间后，对该消息进行投放处理。具体地，为了避免消息体被某个消息消费模块标记后，实例由于某些原因故障，导致消息一直不会被其他实例处理，标记setnx时候，标记key-value设置固定过期时间，当先前被标记的消息被消费占用时间超过设定的固定过期时间后，即超时后，其他实例会继续处理此条消息的投放，确保消息会且仅会一个消费实例被投放一次。已处理成功的消息，消费模块将特定消息体、时间序列zset、过期序列zset均删除，值得注意的是，此删除过程也是批量执行，提升性能。

图4为redis集群中的消息组织格式图，参见图4，时间序列zset中17:16分对应17:16分的过期序列zset，该17:16分的过期序列zset包括17:16:15消息等，对应地，该17:16:15消息包括17:16:15消息id、消息体(消息内容)、消息回调地址、过期绝对时间和消息重试策略。

上述redis setnx(SET if Not eXists)命令在指定的key不存在时，为key设置指定的值，当且仅当key不存在，将key的值设置为value，并且返回1；若是给定的key已经存在，则setnx不做任何动作，返回0：

上述redis multi命令用于标记一个事务块的开始，事务块内的多条命令会按照先后顺序被放进一个队列当中，最后由EXEC命令原子性(atomic)地执行，其总是返回OK。

需要说明的是，上述步骤可以通过构建一一致性控制模块实现，所述的一致性控制模块用于控制多个消息消费模块多次同时批量获取消息，避免消息的重复消费。

进一步地，所述的方法还包括对投递失败的消息处理，具体为：当消息投放失败后，删除时间序列zset和过期序列zset的指定值，并根据重试策略设定新的过期时间。

以上结合附图1～4描述了根据本发明实施例的消息处理方法。进一步地，本发明还可以应用于消息处理装置。

消息处理装置，包括处理器、存储器以及存储在所述存储器中且被配置为由所述处理器执行的计算机程序，所述的处理器执行所述计算机程序时实现上述的消息处理方法。

本发明实施例的消息处理装置中处理器的工作原理与本发明实施例消息处理方法的相同，此处不再赘述。

图5为消息处理系统的结构示意图，如图5所示，一种消息处理系统500包括：

消息发布模块501，其作为消息发布入口服务，消息发布实例接受消息投放请求，并将消息按照组织格式存储至消息存储redis集群，消息发布实例可以采用互联网常见服务系统构建，本文中采用Springboot框架构建。

消息存储redis集群502，其基于redis 3.0版本构建的redis cluster集群系统，配备部署redis sential哨兵应用自动切换cluster主从，用以单实例节点故障时自动切换主从容灾。消息存储redis集群主要存储消息分片信息与消息体信息。

一致性控制redis组503，其多个单独部署的redis块，可以利用单独的redis块的multi、pipiline、setnx等功能，用于控制多个消息消费实例多次同时批量获取消息，避免消息的重复消费。

消息消费模块504，其为一组毫秒级循环定时任务服务，轮询消息存储redis集群中已到期消息，按约定进行消息的处理投递。对于成功投递的消息，从消息存储redis集群中删除，对于投递失败的消息，按照重投策略再次投放。

此外该消息处理系统还配置一HTTP接口，服务后台仅需调用HTTP接口投放消息即可完成事后通知，服务事后处理的成本仅一次HTTP调用，采用最常用HTTP接口协议输入与回调，适应通用化互联网后台服务场景。

通过上述配置，该消息处理系统最大服务能力可支持100万QPS(Query persecond,每秒系统的请求查询数)以上。

本发明的系统实施例能实现图1至图4的方法实施例中各步骤，为避免重复，在此不再赘述。

综上所述，本发明一种消息处理方法和装置，针对支付系统或电商系统中存在大量的稍后重试或错误失败重试场景，对于每条消息投放提供可变时的延时通知配置以及对应的下游服务配置。

本领域内的技术人员应明白，上述各实施例可提供为方法、装置、或计算机程序产品。这些实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。上述各实施例涉及的方法中的全部或部分步骤可以通过程序来指令相关的硬件完成，所述的程序可以存储于计算机设备可读取的存储介质中，用于执行上述各实施例方法所述的全部或部分步骤。

上述各实施例是参照根据实施例所述的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到计算机设备的处理器以产生一个机器，使得通过计算机设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

尽管本发明的内容已经通过上述优选实施例作了详细介绍，但应当认识到上述的描述不应被认为是对本发明的限制。在本领域技术人员阅读了上述内容后，对于本发明的多种修改和替代都将是显而易见的。因此，本发明的保护范围应由所附的权利要求来限定。

Claims (9)

1.一种消息处理方法，其特征在于，包括：

接收消息投放请求后，将接收到的消息存储至消息存储集群；

轮询消息存储集群中已过期消息，按照约定策略进行消息的处理投递，其中，所述轮询消息存储集群中已过期消息包括：采用redis zset对应存储一个时间片序列，并获取当前时间片zset的位置，根据分布存储值并结合过期序列zset找到当前时间到期的所有消息id，再次进行获取当前时间到期的所有消息id。

2.如权利要求1所述的消息处理方法，其特征在于，所述的消息以序列化串方式存储，并按照“关键字-值”形式存储于消息存储集群中，所述的关键字为消息id，值为消息体。

3.如权利要求2所述的消息处理方法，其特征在于，所述的消息体包括：用户投递的消息内容、消息到期时间戳和消息回调地址。

4.如权利要求3所述的消息处理方法，其特征在于，所述的消息体还包括消息重试策略，则所述的按照约定策略进行消息的处理投递进一步包括：

消息投递后若未收到按照约定的答复，则延迟指定的时间再次投递消息。

5.如权利要求1所述的消息处理方法，其特征在于，所述的方法进一步包括：

存储消息过期时间序列，所述存储消息过期时间序列包括：

采用redis zset结构组织消息，并从redis zset中跟进时间戳范围获取到期的所有消息id，根据消息id获取消息id对应消息体投放，其中存放消息过期时间序列的zset为过期序列zset。

6.如权利要求1所述的消息处理方法，其特征在于，还包括：

多次同时批量获取消息，如果其中一个所述的消息已经被消费标记，则当前消费时间根据返回的内容不进行处理，处理未标记的消息id。

7.如权利要求6所述的消息处理方法，其特征在于，所述的处理未标记的消息id后进一步包括：

对已经被消费标记的消息设定固定过期时间，当该消息被消费占用时间超过设定的固定过期时间后，对该消息进行投放处理。

8.如权利要求1所述的消息处理方法，其特征在于，进一步包括：

当消息投放失败后，删除时间序列zset和过期序列zset的指定值，并根据重试策略设定新的过期时间。

9.一种消息处理装置，包括处理器、存储器以及存储在所述存储器中且被配置为由所述处理器执行的计算机程序，其特征在于，所述的处理器执行所述计算机程序时实现如权利要求1-8任一项所述的消息处理方法。

Images