CN114328638A - 一种基于数据库轮询的业务消息推送系统 - Google Patents

Abstract

本发明公开了一种基于数据库轮询的业务消息推送系统，使得多平台之间解耦，保障各平台在运行时间交错的情况下稳定独立工作并保证各平台数据的最终一致性。其技术方案为：系统包括请求轮询模块、请求处理模块和健康检查模块。系统使得三大平台之间具有平台间解耦，生产者、消费者稳定独立工作，并且集成消息消费异常告警，历史消息查询，业务严格顺序消费，以及消费能力横向扩展的特点。

Description

一种基于数据库轮询的业务消息推送系统

技术领域

本发明涉及应用于金融软件领域的数据处理技术，具体涉及一种基于数据库轮询的业务消息推送系统。

背景技术

随着数字化推进，金融软件系统会分成三大平台全面铺开建设，分别为对外申请类的参与人平台、对内业务审批的协作平台以及对内执行业务操作的操作平台。

这三个平台在运行时间上有各自独立的要求：参与人平台需要支持7×24小时，协作平台的运行时间为7×24小时(排除运维时间，停机更新时间另行通知)，操作平台的运行时间为工作日5×8小时。

这三个平台需要满足以下的需求。

这三个平台基于微服务架构建设，在业务上解耦，互相隔离。

在这三个平台之间的通信传输过程中，业务消息对实时性要求不高，需保证最终一致性。

在协作平台、操作平台停机运维期间，需要保证参与人平台仍然能够正常运转，期间堆积的消息能够在协作平台、操作平台恢复运行后持续消化。

参与人平台、操作平台存在测试情况，此时需要按需掐断这两个平台发往协作平台的消息流量。

市场上现有消息中间件技术产品，如rabbitMQ、Kafka、rocketMQ等，无法全部满足上述需求。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明的目的在于解决上述问题，提供了一种基于数据库轮询的业务消息推送系统，使得多个平台之间解耦，保障各平台能够在运行时间交错的情况下稳定独立工作并保证各平台数据的最终一致性。同时，集成了消息消费异常告警，历史消息查询，业务严格顺序消费，以及消费能力横向扩展的效果。

本发明的技术方案为：本发明揭示了一种基于数据库轮询的业务消息推送系统，系统应用于多个外部平台的场景，系统包括请求轮询模块、请求处理模块，其中：

请求轮询模块配置为从与系统对应的外部平台的请求存量数据库中获取该外部平台发出的请求消息并推送到其他的外部平台；

请求处理模块配置为解析请求轮询模块获取到的请求，根据请求类型和请求动作完成对应的逻辑，最后拼装成http post请求发送给对应服务。

根据本发明的基于数据库轮询的业务消息推送系统的一实施例，外部平台是参与人平台，对应参与人平台的业务消息推送系统的请求轮询模块接收的是参与人平台所有服务发出的请求消息，并推送到协作平台或操作平台。

根据本发明的基于数据库轮询的业务消息推送系统的一实施例，外部平台是协作平台，对应协作平台的业务消息推送系统的请求轮询模块接收的是协作平台所有服务发出的请求消息，并推送到参与人平台和操作平台。

根据本发明的基于数据库轮询的业务消息推送系统的一实施例，外部平台是操作平台，对应操作平台的业务消息推送系统的请求轮询模块接收的是操作平台所有服务发出的请求消息，并推送到参与人平台和协作平台。

根据本发明的基于数据库轮询的业务消息推送系统的一实施例，平台间交互数据以消息的形式保存在各平台的请求存量数据库中，其中消息设置分组机制，每个消息组通过开关控制是否允许其正常发送。

根据本发明的基于数据库轮询的业务消息推送系统的一实施例，请求轮询模块的配置进一步包括：

业务消息推送系统在每一次轮询时，首先加载请求组配置，获取当前请求组的活跃情况，获取当前区域下活跃请求组下所有的请求码，其中在请求组中，某些类型的请求属于同一个请求组，请求组通过配置来决定该组是否活跃，只有属于活跃请求组中的请求才能被业务消息推送系统处理，任一平台的业务消息推送系统获取对应平台的所有请求组下请求类型的请求；

业务消息推送系统加载活跃请求组中的待处理请求，其中请求包括：请求码、请求协议、请求目标服务、请求待处理的目标方法和请求体。

根据本发明的基于数据库轮询的业务消息推送系统的一实施例，请求轮询模块基于业务哈希桶，采用并行模式处理请求。

根据本发明的基于数据库轮询的业务消息推送系统的一实施例，在业务哈希桶的实现中，将同一个业务实例ID的消息散列到同一个业务哈希桶中消费，实现同一业务实例ID的请求严格顺序执行，不同的业务实例ID之间的执行是并行的。

根据本发明的基于数据库轮询的业务消息推送系统的一实施例，在业务哈希桶的实现中，根据当前时间戳随机将请求散列到业务哈希桶中处理，通过调整业务哈希桶的大小和个数横向扩展消息消费能力。

根据本发明的基于数据库轮询的业务消息推送系统的一实施例，请求处理模块中配置的处理请求逻辑包括：

针对每一个请求，根据不同请求码，使用设定的服务发现方式找到服务地址，其中服务发现方式包括zookeeper、容器网关、配置文件；

系统使用约定的协议类型执行请求发送，其中协议类型包括标准的HTTP POST协议和自定义框架标准协议。

根据本发明的基于数据库轮询的业务消息推送系统的一实施例，请求处理模块中的请求具有两个可选配置：处理时段、过期时间，

对于配置了处理时段的请求，当请求不在处理时段内则直接跳过，直到当前时间在允许的处理时间范围内才会执行处理逻辑，如果没有配置处理时段，默认随时都允许执行请求处理逻辑；

对于配置了过期时间的请求，如果轮询到该请求的时间滞后于过期时间，则将请求状态置为已过期，如果没有配置过期时间或者当前时间小于等于过期时间，则进行正常处理。

根据本发明的基于数据库轮询的业务消息推送系统的一实施例，系统还包括：

健康检查模块，配置为定时进行系统状态健康监控，当发现请求存量数据库中的请求长时间未执行，或执行状态异常时进行报警处理。

本发明对比现有技术有如下的有益效果：本发明的系统对应有三个实例：参与人平台业务消息推送系统、协作平台业务消息推送系统和操作平台业务消息推送系统。业务消息推送系统包括：请求轮询模块、请求处理模块和健康检查模块。本发明的基于数据库轮询的业务消息推送系统，使得三大平台之间具有平台间解耦，生产者、消费者稳定独立工作，集成消息消费异常告警，历史消息查询，业务严格顺序消费，以及消费能力横向扩展的特点。

具体而言，解耦是在平台服务时间不一致的情况下保证系统运行正常的实现方式：

1、平台间交互数据以消息的形式保存在各平台的消息存量数据库中，消息在本发明中以http请求形式存在，整个请求体和请求定义共同组成了业务消息；

2、消息有分组机制，每个消息组通过开关控制是否允许正常发送。假设其中一个平台未在活跃状态，通过运维手段将发往该平台的消息切断，在该平台正常服务的时候再开启开关，堆积的消息能够按顺序处理。

历史消息查询和异常消息处理管理是本发明的延伸产品，提供了查询界面和不同场景下处理操作推荐手段，根据管理页能够实现监控、恢复消息处理的能力。

业务严格顺序消费的实现包括：

消息有业务实例ID的字段，具有相同的业务ID的消息会被程序散列到同一个哈希桶中消费。同一个哈希桶中的消息按时间顺序先进先出，所以能够保证同一个业务内，堆积的消息消费严格顺序。一旦某个堆积的消息消费失败，同业务实例ID的后续消息不能继续执行，直到失败的消息被正常处理(尝试重发或通过管理页人工介入操作)。

消费能力的横向扩展的实现包括：

1、通过简单的起多个消息服务实例即可时间横向扩展；

2、通过调整消息服务的配置可以增加并发消费的能力，但并发能力越强系统消耗的内存越大，需要合理调试参数。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了本发明的基于数据库轮询的业务消息推送系统的应用场景的示例图。

图2示出了本实施例的业务消息推送系统中的请求轮询模块的处理细节的示意图。

图3示出了本实施例的业务消息推送系统中的请求处理模块的处理逻辑的示意图。

图4示出了本发明的基于数据库轮询的业务消息推送系统的一实施例的原理图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

图1示出了本发明的基于数据库轮询的业务消息推送系统的一个应用场景的示例。图1中为了体现本发明的业务消息推送系统和三大平台(参与人平台、协作平台和操作平台)的关联关系，业务消息推送系统的研发目的就是为了解耦这三大平台，为平台正常工作服务。

请参见图1，本实施例的业务消息推送系统应用于参与人平台、协作平台和操作平台的交互，图1中的实现虚线都是消息数据发送，其中实线表示同步调用，虚线表示异步调用。业务消息推送系统用于轮询对应平台的请求表，从请求表中获取请求实例并解析，按照解析出的请求码的定义发送http post请求，完成指定异步发送逻辑。其中，请求码的定义规定一个类型的请求在执行时对应的接口服务名(service)、方法名(function)、接口协议类型(targetProtocolType)、请求响应时间(responseTimeout)，请求的过期处理服务(expireService)、方法(expireFunction)、过期处理协议类型(expireProtocolType)、过期处理请求响应时间(expireResponseTimeout)。

对应应用场景中的参与人平台、协作平台和操作平台，本发明的业务消息推送系统也对应有三个实例：参与人平台业务消息推送系统、协作平台业务消息推送系统和操作平台业务消息推送系统。

参与人平台包括：参与人门户服务、其他参与人业务服务，涉及到消息发送的数据内容分别存放在参与人申请数据库和参与人业务数据库，参与人平台的消息存放在参与人平台消息存量数据库中。各参与人服务都会通过本发明的业务消息推送系统完成平台间消息交互。

协作平台包括工作流服务和协作平台业务服务，对应数据存储在流程数据库和协作业务数据库，协作平台的消息存放在协作平台消息存量数据库中。工作流平台承接了参与人平台提交的申请类业务，由参与人平台门户服务发起审批流程消息，经本发明的业务消息推送系统处理流转到工作流服务起协作审批流程。

操作平台包括：操作平台门户服务和核心业务服务，对应数据存储在门户数据库和业务核心数据库，操作平台的消息存放在操作平台消息存量数据库中。核心指令执行后同步到协作业务服务等操作或者参与人触发的核心数据变更都经消息触发，由本发明的业务消息推送系统完成处理。

图4示出了本发明的基于数据库轮询的业务消息推送系统的一实施例的原理。本实施例的业务消息推送系统包括：请求轮询模块、请求处理模块和健康检查模块。

请求轮询模块配置为通过单个或多个线程(线程的数目按需配置)从外部平台的请求存量数据库中获取平台发出的请求消息并推送到其他的外部平台。各外部平台都能发请求消息，例如：参与人平台业务消息推送系统的请求轮询模块接收的是参与人平台所有服务发出的请求消息，按要求推送到协作平台或操作平台；协作平台业务消息推送系统的请求轮询模块接收的是协作平台所有服务发出的请求消息，按要求推送到参与人平台和操作平台；操作平台业务消息推送系统的请求轮询模块接收的是操作平台所有服务发出的请求消息，按要求推送到参与人平台和协作平台。

平台间交互数据以消息的形式保存在各平台的请求存量数据库中。消息设置分组机制，每个消息组通过开关控制是否允许正常发送。假设其中一个平台未在活跃状态，通过运维手段将发往该平台的消息切断，在该平台正常服务的时候再开启开关，堆积的消息能够按顺序处理。

请求处理模块配置为解析请求轮询模块获取到的请求，根据请求类型和请求动作完成对应的逻辑，最后拼装成http post请求发送给对应服务。

健康检查模块配置为定时进行系统状态健康监控，当发现请求存量数据库中的请求长时间未执行，或执行状态异常时进行报警处理，报警处理包括按需对接短信、微信、邮件模块进行短信、微信或者邮件的报警。

历史消息查询和异常消息处理管理是本发明的健康检查模块的延伸产品，提供了查询界面和不同场景下处理操作推荐手段，根据管理页能够实现监控、恢复消息处理的能力。

同时，业务消息推送系统提供应用发送消息的sdk(软件开发工具包)，应用本身在使用时需要根据业务需求保证事务一致性。

图2示出了请求轮询模块的处理过程。

业务消息推送系统在每一次轮询时，首先会加载请求组配置，获取当前请求组的活跃情况，获取本区域下活跃请求组下所有的请求码。在请求组中，某些类型的请求属于同一个请求组，请求组通过配置决定该组是否活跃，只有属于活跃请求组中的请求才能被业务消息推送系统处理(每个消息组通过开关控制是否允许正常发送。假设其中一个平台未在活跃状态，通过运维手段将发往该平台的消息切断，在该平台正常服务的时候再开启开关，堆积的消息能够按顺序处理)，不同平台的业务消息推送系统获取对应平台的所有请求组下请求类型的请求。接着系统加载活跃的请求组中的待处理请求，请求包括了以下几部分内容：请求码、请求协议、请求目标服务、请求待处理的目标方法和请求体(消息内容，需要业务逻辑解析处理)。

在本发明中，消息是逻辑概念，请求是模型，消息在本发明中以http请求形式存在，整个请求体和请求定义共同组成了业务消息。

每一次轮询有获取请求的条数上限，默认为100条，可以通过配置动态调整一次轮询可获取的请求条数。轮询获取请求使用递归逻辑，取完未处理的请求或取满上限为止。

请求的一个重要属性是业务实例ID。如果一个业务的多个请求在执行上要求严格顺序，应当使用同一个业务实例ID，优先处理请求ID数字小的请求，如果这一串请求中某一个请求处理失败(即业务过程中已经报错失败)，后续同业务实例ID的请求业务消息推送系统执行时跳过，不予处理。

请求轮询模块基于业务哈希桶(hash bucket)实现，业务哈希桶的概念对应kafkapartition的概念，在请求的处理上使用并行模式处理。为了保证一系列具有业务相关性的事件在处理上是有序的，本实施例采取哈希hash算法，将同一个业务实例ID的消息散列到同一个业务哈希桶中消费，实现同一业务实例ID的请求严格顺序执行，不同的业务实例ID之间的执行是并行的，不保证顺序执行，因此能保证同一个业务内，堆积的消息消费严格顺序。一旦某个堆积的消息消费失败，同业务ID的后续消息不能继续执行，直到失败的消息被正常处理(尝试重发或通过管理页人工介入操作)。机器人支持配置业务哈希桶的大小来调整机器人的处理性能。当业务哈希桶的大小设置为1时，同分组的所有请求严格顺序执行。

如果没有设置业务实例ID，根据当前时间戳随机将请求散列到业务哈希桶中处理。通过调整业务哈希桶的大小和个数是可以便利地横向扩展消息消费能力。消费能力的横向扩展的实现包括：1、通过简单的起多个消息服务实例(消息服务实例是本发明中设计的系统部署实例，通过扩容可以增强处理能力)即可时间横向扩展；2、通过调整消息服务(消息服务是服务节点，是一个物理概念，用于系统多节点部署的场景中)的配置可以增加并发消费的能力，但并发能力越强系统消耗的内存越大，需要合理调试参数。

请求处理模块的处理请求逻辑的具体过程详述如下。

针对每一个请求，根据不同请求码，使用设定的服务发现方式找到服务地址，例如本实施例提供三种服务发现方式：zookeeper、容器网关、配置文件，通过继承基础服务发现模块扩展支持其他服务发现模式。系统使用约定的协议类型执行请求发送，例如本实施例提供两种协议：标准的HTTP POST协议和自定义框架标准协议，通过继承基础请求发送模块扩展支持其他系统交互协议。

请求处理状态如图3所示，一个请求实例有两个可选配置：1、处理时段，其格式为0-24(小时)1-7(周几)；2、过期日期、时间(expireDate，expireTime)。

对于配置了处理时段的请求，当请求不在处理时段内则直接跳过，直到当前时间在允许的处理时间范围内才会执行处理逻辑。如果没有配置处理时段，默认随时都允许执行请求处理逻辑；

对于配置了过期时间的请求，如果轮询到该请求的时间滞后于过期时间，则将请求状态置为已过期。如果没有配置过期时间或者当前时间小于等于过期时间，则进行正常处理。

正常处理请求逻辑的状态流转过程如下：

1、等待获取：

此时请求状态为未处理，如果此时发生系统异常则中断本次轮询线程，下一次轮询从当前请求点重新开始执行。

2、已获取：

获取请求后将请求状态置为处理中，此时系统异常或崩溃，下次循环重启后，会从该请求的下一个请求处执行。

3、执行：

若请求执行中系统异常崩溃，此时状态停留在处理中，报警人工介入。

4、状态更新：

如果执行动作收到正常反馈，则状态更新为已处理；

如果执行动作超时，根据配置执行超时处理逻辑；

在请求处理环节中，采取保守的错误处理方式，发生错误后不进行重试而是记录错误状态，只有当程序重启时才会尝试进行启动检查核对请求状态。

当执行请求过程中发生技术异常时(请求超时等)，记录异常日志，跳过该事件继续处理下一个请求。此时状态为异常，需要人工介入判断，将处理中改为未处理或者已处理。

当执行请求过程中收到了请求执行的反馈，即任务请求已经被接收方处理，将请求状态置为已处理。正常处理和处理时发生业务处理异常都算作已处理。

如果请求反馈中包含了业务错误信息，在机器人的请求表中记录错误信息便于统计稽核。

健康检查模块配置为借助splunk日志收集工具、短信服务、邮箱服务等，提供了对应告警功能。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

Claims (12)

1.一种基于数据库轮询的业务消息推送系统，其特征在于，系统应用于多个外部平台的场景，系统包括请求轮询模块、请求处理模块，其中：

请求轮询模块配置为从与系统对应的外部平台的请求存量数据库中获取该外部平台发出的请求消息并推送到其他的外部平台；

请求处理模块配置为解析请求轮询模块获取到的请求，根据请求类型和请求动作完成对应的逻辑，最后拼装成http post请求发送给对应服务。

2.根据权利要求1所述的基于数据库轮询的业务消息推送系统，其特征在于，外部平台是参与人平台，对应参与人平台的业务消息推送系统的请求轮询模块接收的是参与人平台所有服务发出的请求消息，并推送到协作平台或操作平台。

3.根据权利要求1所述的基于数据库轮询的业务消息推送系统，其特征在于，外部平台是协作平台，对应协作平台的业务消息推送系统的请求轮询模块接收的是协作平台所有服务发出的请求消息，并推送到参与人平台和操作平台。

4.根据权利要求1所述的基于数据库轮询的业务消息推送系统，其特征在于，外部平台是操作平台，对应操作平台的业务消息推送系统的请求轮询模块接收的是操作平台所有服务发出的请求消息，并推送到参与人平台和协作平台。

5.根据权利要求1所述的基于数据库轮询的业务消息推送系统，其特征在于，平台间交互数据以消息的形式保存在各平台的请求存量数据库中，其中消息设置分组机制，每个消息组通过开关控制是否允许其正常发送。

6.根据权利要求5所述的基于数据库轮询的业务消息推送系统，其特征在于，请求轮询模块的配置进一步包括：

业务消息推送系统在每一次轮询时，首先加载请求组配置，获取当前请求组的活跃情况，获取当前区域下活跃请求组下所有的请求码，其中在请求组中，某些类型的请求属于同一个请求组，请求组通过配置来决定该组是否活跃，只有属于活跃请求组中的请求才能被业务消息推送系统处理，任一平台的业务消息推送系统获取对应平台的所有请求组下请求类型的请求；

业务消息推送系统加载活跃请求组中的待处理请求，其中请求包括：请求码、请求协议、请求目标服务、请求待处理的目标方法和请求体。

7.根据权利要求6所述的基于数据库轮询的业务消息推送系统，其特征在于，请求轮询模块基于业务哈希桶，采用并行模式处理请求。

8.根据权利要求7所述的基于数据库轮询的业务消息推送系统，其特征在于，在业务哈希桶的实现中，将同一个业务实例ID的消息散列到同一个业务哈希桶中消费，实现同一业务实例ID的请求严格顺序执行，不同的业务实例ID之间的执行是并行的。

9.根据权利要求7所述的基于数据库轮询的业务消息推送系统，其特征在于，在业务哈希桶的实现中，根据当前时间戳随机将请求散列到业务哈希桶中处理，通过调整业务哈希桶的大小和个数横向扩展消息消费能力。

10.根据权利要求6所述的基于数据库轮询的业务消息推送系统，其特征在于，请求处理模块中配置的处理请求逻辑包括：

针对每一个请求，根据不同请求码，使用设定的服务发现方式找到服务地址，其中服务发现方式包括zookeeper、容器网关、配置文件；

系统使用约定的协议类型执行请求发送，其中协议类型包括标准的HTTP POST协议和自定义框架标准协议。

11.根据权利要求10所述的基于数据库轮询的业务消息推送系统，其特征在于，请求处理模块中的请求具有两个可选配置：处理时段、过期时间，

对于配置了处理时段的请求，当请求不在处理时段内则直接跳过，直到当前时间在允许的处理时间范围内才会执行处理逻辑，如果没有配置处理时段，默认随时都允许执行请求处理逻辑；

对于配置了过期时间的请求，如果轮询到该请求的时间滞后于过期时间，则将请求状态置为已过期，如果没有配置过期时间或者当前时间小于等于过期时间，则进行正常处理。

12.根据权利要求1至11中任一项所述的基于数据库轮询的业务消息推送系统，其特征在于，系统还包括：

健康检查模块，配置为定时进行系统状态健康监控，当发现请求存量数据库中的请求长时间未执行，或执行状态异常时进行报警处理。

Images