消息处理方法、装置、存储介质及计算机设备与流程

1.本发明涉及信息处理技术领域，尤其涉及一种消息处理方法、装置、存储介质及计算机设备。


背景技术：

2.目前，业务系统在处理一些业务流程时，主要是依赖第三方服务进行流程周转，若第三方服务不稳定，则业务系统中的业务流程也无法及时进行响应。
3.针对上述问题，现有技术中主要是采用针对不同的业务流程开发定制化的流程引擎组件，当流程节点异常时，需要自定义重试方案，且不同的业务流程，可能需要多套重试方案，进而导致开发成本较高，流程引擎的普适性较低。


技术实现要素：

4.本发明的目的旨在至少能解决上述的技术缺陷之一，特别是现有技术中针对不同的业务流程开发定制化的流程引擎组件，导致开发成本较高，流程引擎组件的普适性较低的技术缺陷。
5.本发明提供了一种消息处理方法，所述方法基于发布订阅式的消息系统实现，包括：
6.当监听到所述消息系统中缓存有目标消息时，根据所述目标消息的主题类型将所述目标消息分配至订阅所述主题类型的消费者；
7.获取所述消费者消费所述目标消息后返回的消费状态；
8.若所述消费状态为消费异常，则按照所述消息系统中的异常处理策略对所述目标消息进行处理。
9.可选地，所述按照所述消息系统中的异常处理策略对所述目标消息进行处理，包括：
10.确定本次消费异常的异常类型；
11.若所述异常类型满足重新消费条件，则重新发布所述目标消息；
12.若所述异常类型满足延迟消费条件，则将所述目标消息送入到延迟队列中。
13.可选地，若所述异常类型满足重新消费条件，则重新发布所述目标消息之后，所述方法还包括：
14.对重新发布所述目标消息的发布次数进行统计；
15.若所述发布次数超过预设次数阈值，则将所述目标消息送入死信队列中，其中，所述死信队列用于对所述目标消息进行入库保存。
16.可选地，若所述异常类型满足延迟消费条件，则将所述目标消息送入到延迟队列中之后，所述方法还包括：
17.判断所述延迟队列中的目标消息是否满足预设消费条件；
18.若不满足，则继续等待；
19.若满足，则从所述延迟队列中取出所述目标消息后，将所述目标消息重新分配至所述消费者。
20.可选地，所述方法还包括：
21.确定所述目标消息的消费者是否属于链式结构消息中的消费者；
22.若属于，则在所述目标消息的消费状态为消费成功时，根据所述目标消息的消费者在所述链式结构消息中的节点位置，确定所述链式结构消息中的的下一消费者。
23.可选地，所述方法还包括：
24.监听所述消息系统中是否缓存有与所述下一消费者订阅的主题类型对应的消息；
25.若有，则将所述消息分配至所述下一消费者。
26.可选地，所述方法还包括：
27.当检测到所述链式结构消息的消费逻辑变更时，对所述链式结构消息进行变更。
28.本发明还提供了一种消息处理装置，所述装置基于发布订阅式的消息系统实现，包括：
29.消息分配模块，用于当监听到消息系统中缓存有目标消息时，根据所述目标消息的主题类型将所述目标消息分配至订阅所述主题类型的消费者；
30.状态获取模块，用于获取所述消费者消费所述目标消息后返回的消费状态；
31.异常处理模块，用于若所述消费状态为消费异常，则按照所述消息系统中的异常处理策略对所述目标消息进行处理。
32.本发明还提供了一种存储介质，所述存储介质中存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如上述实施例中任一项所述消息处理方法的步骤。
33.本发明还提供了一种计算机设备，所述计算机设备中存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如上述实施例中任一项所述消息处理方法的步骤。
34.从以上技术方案可以看出，本发明实施例具有以下优点：
35.本发明提供的消息处理方法、装置、存储介质及计算机设备，当流程引擎组件监听到消息系统中缓存有目标消息时，可以依据该目标消息的主题类型来将该目标消息分配至订阅该主题类型的消费者，以便该消费者来消费该目标消息；由于本技术中的流程引擎组件是基于发布订阅式的消息系统实现的，因此在分配消息时，只需要根据该消息的主题类型即可确定对应的消费者，无需针对不同的消费者单独开发独立的流程引擎，并且，本技术中流程控制与业务逻辑解耦后，可以利用消息系统中的消息处理机制来制定相应的异常处理策略，并在消费者返回消费异常时，按照该异常处理策略来对目标消息进行统一处理，无需针对不同的消费者进行单独处理，从而在一定程度上减少了开发成本，且流程引擎组件的普适性较高。
36.另外，由于本技术中将流程控制与业务逻辑进行解耦，不同的业务逻辑无需依赖相应的流程控制，而是依赖于消息的消费状态，从而使得对原有的流程控制进行更新时，只需要修改流程逻辑，无需修改底层流程引擎代码，从而进一步提高开发效率，减少开发成本。
附图说明
37.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。
38.图1为本发明实施例提供的一种消息处理方法的流程示意图；
39.图2为本发明实施例提供的eventmq组件的流程驱动示意图；
40.图3为本发明实施例提供的一种消息处理装置的结构示意图；
41.图4为本发明实施例提供的一种计算机设备的内部结构示意图。
具体实施方式
42.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
43.目前，业务系统在处理一些业务流程时，主要是依赖第三方服务进行流程周转，若第三方服务不稳定，则业务系统中的业务流程也无法及时进行响应。
44.针对上述问题，现有技术中主要是采用针对不同的业务流程开发定制化的流程引擎组件，当流程节点异常时，需要自定义重试方案，且不同的业务流程，可能需要多套重试方案，进而导致开发成本较高，流程引擎的普适性较低。
45.基于此，本技术提供了如下技术方案，具体参加下文：
46.在一个实施例中，如图1所示，图1为本发明实施例提供的一种消息处理方法的流程示意图；本发明提供了一种消息处理方法，所述方法基于发布订阅式的消息系统实现，具体包括如下：
47.s110：当监听到消息系统中缓存有目标消息时，根据目标消息的主题类型将目标消息分配至订阅主题类型的消费者。
48.本步骤中，当流程引擎组件监听到消息系统中缓存有目标消息时，可以依据该目标消息的主题类型来将该目标消息分配至订阅该主题类型的消费者，以便该消费者来消费该目标消息。
49.其中，本技术中的流程引擎组件可以是基于vms实现的eventmq组件，vms(vip message system)是在成熟的开源框架(如kafka)基础上自主研发的消息系统，旨在为业务系统提供高可靠，高可用，高性能且易于扩展的消息服务。本技术通过消息事件驱动，实现流程引擎，自由选择同步、异步方式处理业务流程。
50.由于消息系统为生产者和消费者之间的中间件，当生产者创建消息后，可以将其发布到消息系统中约定的主题类型中，此时，流程引擎组件通过消息监控器监听到消息系统中缓存有目标消息时，可以根据该目标消息的主题类型，将该目标消息分配至订阅该主题类型的消费者。
51.可以理解的是，这里的目标消息指的是与业务系统中的业务流程相关的消息，如取现业务系统中的授信、放款、借款、提额等与外部资方交互的业务流程相关的消息。
52.s120：获取消费者消费目标消息后返回的消费状态。
53.本步骤中，通过s110将目标消息分配至订阅与目标消息的主题类型一致的消费者后，接着可以获取消费者消费目标消息后返回的消费状态，以便流程引擎组件根据消费者返回的消费状态来执行后续流程操作。
54.s130：若消费状态为消费异常，则按照消息系统中的异常处理策略对目标消息进行处理。
55.本步骤中，通过s120获取消费者消费目标消息后返回的消费状态后，可以对该消费状态进行判断，若该消费状态显示消费异常，此时，可以按照消费系统中的异常处理策略对目标消息进行处理。
56.可以理解的是，若消费者返回的消费状态显示消费异常，一般指的是比较明确的异常，该异常可能是由部分准备工作未完成导致的，可以通过消息重试机制来进行重试。而由于第三方服务不稳，响应超市，调用方不知异常详细原因等导致的异常，这类异常即使短时间内重试，也不会有响应，因此，针对该类型的异常则可以选择延迟消费消息。
57.上述实施例中，当流程引擎组件监听到消息系统中缓存有目标消息时，可以依据该目标消息的主题类型来将该目标消息分配至订阅该主题类型的消费者，以便该消费者来消费该目标消息；由于本技术中的流程引擎组件是基于发布订阅式的消息系统实现的，因此在分配消息时，只需要根据该消息的主题类型即可确定对应的消费者，无需针对不同的消费者单独开发独立的流程引擎，并且，本技术中流程控制与业务逻辑解耦后，可以利用消息系统中的消息处理机制来制定相应的异常处理策略，并在消费者返回消费异常时，按照该异常处理策略来对目标消息进行统一处理，无需针对不同的消费者进行单独处理，从而在一定程度上减少了开发成本，且流程引擎组件的普适性较高。
58.另外，由于本技术中将流程控制与业务逻辑进行解耦，不同的业务逻辑无需依赖相应的流程控制，而是依赖于消息的消费状态，从而使得对原有的流程控制进行更新时，只需要修改流程逻辑，无需修改底层流程引擎代码，从而进一步提高开发效率，减少开发成本。
59.在一个实施例中，s130中按照所述消息系统中的异常处理策略对所述目标消息进行处理，可以包括：
60.s131：确定本次消费异常的异常类型。
61.s132：若所述异常类型满足重新消费条件，则重新发布所述目标消息。
62.s133：若所述异常类型满足延迟消费条件，则将所述目标消息送入到延迟队列中。
63.本实施例中，当消费者返回消费目标消息的消费状态为消费异常时，可以先确定本次消费异常的异常类型，接着根据该异常类型来确定具体的异常处理策略。
64.具体地，当本次消费异常的异常类型满足重新消费条件时，则可以重新发布目标消息，而当本次消费异常的异常类型满足延迟消费条件时，则可以将该目标消息送入延迟队列中。
65.可以理解的是，对于比较明确的异常，该异常可能是由部分准备工作未完成导致的，可以通过消息重试机制来重新发布消息。而由于第三方服务不稳，响应超市，调用方不知异常详细原因等导致的异常，这类异常即使短时间内重试，也不会有响应，因此，针对该类型的异常则可以选择延迟消费消息。
66.进一步地，一般消息队列可以分为普通队列和延迟队列。本技术中的消息重试机制是通过重新发布消息来实现的，选择重新发布消息时，消费者可以监控消息队列中的普通队列，有消息便会执行。
67.在一个实施例中，s132中若所述异常类型满足重新消费条件，则重新发布所述目标消息之后，所述方法还可以包括：
68.s1321：对重新发布所述目标消息的发布次数进行统计。
69.s1322：若所述发布次数超过预设次数阈值，则将所述目标消息送入死信队列中，其中，所述死信队列用于对所述目标消息进行入库保存。
70.本实施例中，若消费者返回的消费状态为消费异常，且消费异常的异常类型满足重新消费条件时，可以选择重新发布目标消息，并对重新发布目标消息时的发布次数进行统计，若发布次数超过预设次数阈值，则可以将该目标消息送入死信队列中。
71.需要说明的是，本技术中的eventmq组件是利用消息来实现的，消息在消费过程中，无法避免失败或异常，此时消息需要重试，而死信队列则是为了避免消息因失败或异常导致的无限重试。
72.死信一般可以通过以下手段来实现：
73.(1)丢弃消息，如果消息不是很重要，可以选择丢弃；
74.(2)记录死信入库，做后续的业务分析或处理；
75.(3)由负责监听死信的应用程序进行处理；
76.(4)通过告警手段，做后续的业务分析或处理。
77.本技术中，eventmq组件可以使用死信入库的处理方式，将发布次数超过预设次数阈值的目标消息进行入库保存，以便做后续的业务分析或处理。
78.在一个实施例中，s133中若所述异常类型满足延迟消费条件，则将所述目标消息送入到延迟队列中之后，所述方法还可以包括：
79.s1331：判断所述延迟队列中的目标消息是否满足预设消费条件；
80.s1332：若不满足，则继续等待。
81.s1333：若满足，则从所述延迟队列中取出所述目标消息后，将所述目标消息重新分配至所述消费者。
82.本实施例中，若消费者返回的消费状态为消费异常，且消费异常的异常类型满足延迟消费条件，则可以将该目标消息送入到延迟队列中，并判断延迟队列中的目标消息是否满足预设消费条件，如果不满足，则继续等待，如果满足，则可以从延迟队列中将该目标消息取出并重新分配给该消费者。
83.具体地，对于延迟队列中的消息，可以查看是否满足预设消费条件(如时间等)，如果不满足，消息者暂停消费消息，重置offset，继续等待，如果满足，则将该消息取出后重新分配至对应的消费者。
84.在一个实施例中，所述方法还可以包括：
85.s141：确定所述目标消息的消费者是否属于链式结构消息中的消费者。
86.s142：若属于，则在所述目标消息的消费状态为消费成功时，根据所述目标消息的消费者在所述链式结构消息中的节点位置，确定所述链式结构消息中的的下一消费者。
87.本实施例中，当引入eventmq组件来对消息进行处理时，新增业务无需重新定义流
程引擎，只需要新增消费者逻辑，定义好消息结构体即可。
88.例如，本技术可以根据业务流程的消费逻辑来生成链式结构消息，并通过链式结构消息来实现业务的流转。当获取到消息系统中的目标消息后，可以先确定该目标消息是否为链式结构消息中的消费者，若是，则在该目标消息被成功消费后，根据该目标消息的消费者在链式结构消息中的节点位置，来确定链式结构消息中的下一消费者。
89.举例来说，业务流程中的授信服务可以分为多个子服务，如授信数据初始化和校验，上传ocr，上传人脸，签章并上传授信协议，提交征信申请，资方征信结果通知，风控申请，提交授信申请，资方授信结果通知，中台开户等。
90.其中，每个子服务都是一个独立的消费服务，在执行授信服务时，首先执行“授信数据初始化和校验消费服务”，处理完该消费服务后，继续执行“上传ocr消费”服务。该过程中，有些是同步的直接调用，有些是通过消息异步调用处理的。但只要知道第一个消费服务，整个链式结构消息就确认了，最后一个消费者，next服务为空。
91.本技术通过在现有的业务系统的基础上引入eventmq组件，使得流程执行只依赖于消息的数据内容，并且，对于流程逻辑的修改，无需修改底层流程引擎代码，流程新增环节，只需调整多个消费者间的next指向配置，即可实现简单快捷的业务流程周转。
92.在一个实施例中，所述方法还可以包括：
93.s143：监听所述消息系统中是否缓存有与所述下一消费者订阅的主题类型对应的消息。
94.s144：若有，则将所述消息分配至所述下一消费者。
95.本实施例中，当确定下一消费者后，可以监听消费系统中是否缓存有与所述下一消费者订阅的主题类型对应的消息，如果有，则可以将该消息分配给下一消费者。
96.示意性地，如图2所示，图2为本发明实施例提供的eventmq组件的流程驱动示意图；图2中，eventmq组件监听vms中的消息，当监听到目标消息时，根据该目标消息的主题类型将该目标消息分配至对应的消费者，并接收该消费者返回的消费状态，若消费状态为消费异常，且满足延迟消费时，可以将目标消息送入延迟队列中进行延迟消费，若消费状态正常，则表示消费者成功消费消息，此时可以判断当前目标消息的消费者是否为链式结构消息中的消费者，若是，则在该目标消息被成功消费后，根据该目标消息的消费者在链式结构消息中的节点位置，来确定链式结构消息中的下一消费者，并通过消息监控器来监听消息，当监听到与下一消费者订阅的主题类型对应的消息时，可以将该消息分配至下一消费者，以便下一消费者对该消息进行消费。
97.在一个实施例中，所述方法还可以包括：
98.当检测到所述链式结构消息的消费逻辑变更时，对所述链式结构消息进行变更。
99.本实施例中，当引入eventmq组件对业务流程进行把控后，新增业务无需重新定义流程引擎，只需要新增消费者逻辑，定义好消息结构体即可。因此，当eventmq组件检测到当前的链式结构消息的消费逻辑需要变更时，可以按照开发人员上传的与当前链式结构消息的业务流程对应的消息逻辑，对当前的链式结构消息进行变更。如提额流程，开发人员只需要完成提额相关的消息消费逻辑的编写，eventmq组件即可根据该消息消费逻辑实现业务流程的流转，无需修改底层流程引擎代码，极大程度上节省了开发成本和开发效率。
100.下面对本技术实施例提供的消息处理装置进行描述，下文描述的消息处理装置与
上文描述的消息处理方法可相互对应参照。
101.在一个实施例中，如图3所示，图3为本发明实施例提供的一种消息处理装置的结构示意图；本发明还提供了一种消息处理装置，所述装置基于发布订阅式的消息系统实现，包括消息分配模块210、状态获取模块220、异常处理模块230，具体包括如下：
102.消息分配模块210，用于当监听到消息系统中缓存有目标消息时，根据所述目标消息的主题类型将所述目标消息分配至订阅所述主题类型的消费者。
103.状态获取模块220，用于获取所述消费者消费所述目标消息后返回的消费状态。
104.异常处理模块230，用于若所述消费状态为消费异常，则按照所述消息系统中的异常处理策略对所述目标消息进行处理。
105.上述实施例中，当流程引擎组件监听到消息系统中缓存有目标消息时，可以依据该目标消息的主题类型来将该目标消息分配至订阅该主题类型的消费者，以便该消费者来消费该目标消息；由于本技术中的流程引擎组件是基于发布订阅式的消息系统实现的，因此在分配消息时，只需要根据该消息的主题类型即可确定对应的消费者，无需针对不同的消费者单独开发独立的流程引擎，并且，本技术中流程控制与业务逻辑解耦后，可以利用消息系统中的消息处理机制来制定相应的异常处理策略，并在消费者返回消费异常时，按照该异常处理策略来对目标消息进行统一处理，无需针对不同的消费者进行单独处理，从而在一定程度上减少了开发成本，且流程引擎组件的普适性较高。
106.另外，由于本技术中将流程控制与业务逻辑进行解耦，不同的业务逻辑无需依赖相应的流程控制，而是依赖于消息的消费状态，从而使得对原有的流程控制进行更新时，只需要修改流程逻辑，无需修改底层流程引擎代码，从而进一步提高开发效率，减少开发成本。
107.在一个实施例中，所述异常处理模块230可以包括：
108.异常类型确定模块，用于确定本次消费异常的异常类型。
109.重新发布模块，用于若所述异常类型满足重新消费条件，则重新发布所述目标消息。
110.延迟消费模块，用于若所述异常类型满足延迟消费条件，则将所述目标消息送入到延迟队列中。
111.在一个实施例中，所述装置还可以包括：
112.次数统计模块，用于对重新发布所述目标消息的发布次数进行统计。
113.消息入库模块，用于若所述发布次数超过预设次数阈值，则将所述目标消息送入死信队列中，其中，所述死信队列用于对所述目标消息进行入库保存。
114.在一个实施例中，所述装置还可以包括：
115.条件判断模块，用于判断所述延迟队列中的目标消息是否满足预设消费条件。
116.等待模块，用于若不满足，则继续等待。
117.取出模块，用于若满足，则从所述延迟队列中取出所述目标消息后，将所述目标消息重新分配至所述消费者。
118.在一个实施例中，所述装置还可以包括：
119.结构确定模块，用于确定所述目标消息的消费者是否属于链式结构消息中的消费者。
120.消费者确定模块，用于若属于，则在所述目标消息的消费状态为消费成功时，根据所述目标消息的消费者在所述链式结构消息中的节点位置，确定所述链式结构消息中的的下一消费者。
121.在一个实施例中，所述装置还可以包括：
122.消息监听模块，用于监听所述消息系统中是否缓存有与所述下一消费者订阅的主题类型对应的消息。
123.服务分配模块，用于若有，则将所述消息分配至所述下一消费者。
124.在一个实施例中，所述装置还可以包括：
125.逻辑变更模块，用于当检测到所述链式结构消息的消费逻辑变更时，对所述链式结构消息进行变更。
126.在一个实施例中，本发明还提供了一种存储介质，所述存储介质中存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如上述实施例中任一项所述消息处理方法的步骤。
127.在一个实施例中，本发明还提供了一种计算机设备，所述计算机设备中存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如上述实施例中任一项所述消息处理方法的步骤。
128.示意性地，如图4所示，图4为本发明实施例提供的一种计算机设备的内部结构示意图，该计算机设备300可以被提供为一服务器。参照图4，计算机设备300包括处理组件302，其进一步包括一个或多个处理器，以及由存储器301所代表的存储器资源，用于存储可由处理组件302的执行的指令，例如应用程序。存储器301中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件302被配置为执行指令，以执行上述任意实施例的消息处理方法。
129.计算机设备300还可以包括一个电源组件303被配置为执行计算机设备300的电源管理，一个有线或无线网络接口304被配置为将计算机设备300连接到网络，和一个输入输出(i/o)接口305。计算机设备300可以操作基于存储在存储器301的操作系统，例如windows server tm、mac os xtm、unix tm、linux tm、free bsdtm或类似。
130.本领域技术人员可以理解，图4中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
131.最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
132.本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间可以根据需要进行组合，且相同相似部分互相参见即可。
133.对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本技术。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本技术的精神或范围的情况下，在其它实施例中实现。因此，本技术将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

技术特征：
1.一种消息处理方法，其特征在于，所述方法基于发布订阅式的消息系统实现，包括：当监听到所述消息系统中缓存有目标消息时，根据所述目标消息的主题类型将所述目标消息分配至订阅所述主题类型的消费者；获取所述消费者消费所述目标消息后返回的消费状态；若所述消费状态为消费异常，则按照所述消息系统中的异常处理策略对所述目标消息进行处理。2.根据权利要求1所述的消息处理方法，其特征在于，所述按照所述消息系统中的异常处理策略对所述目标消息进行处理，包括：确定本次消费异常的异常类型；若所述异常类型满足重新消费条件，则重新发布所述目标消息；若所述异常类型满足延迟消费条件，则将所述目标消息送入到延迟队列中。3.根据权利要求2所述的消息处理方法，其特征在于，若所述异常类型满足重新消费条件，则重新发布所述目标消息之后，所述方法还包括：对重新发布所述目标消息的发布次数进行统计；若所述发布次数超过预设次数阈值，则将所述目标消息送入死信队列中，其中，所述死信队列用于对所述目标消息进行入库保存。4.根据权利要求2所述的消息处理方法，其特征在于，若所述异常类型满足延迟消费条件，则将所述目标消息送入到延迟队列中之后，所述方法还包括：判断所述延迟队列中的目标消息是否满足预设消费条件；若不满足，则继续等待；若满足，则从所述延迟队列中取出所述目标消息后，将所述目标消息重新分配至所述消费者。5.根据权利要求1所述的消息处理方法，其特征在于，所述方法还包括：确定所述目标消息的消费者是否属于链式结构消息中的消费者；若属于，则在所述目标消息的消费状态为消费成功时，根据所述目标消息的消费者在所述链式结构消息中的节点位置，确定所述链式结构消息中的的下一消费者。6.根据权利要求5所述的消息处理方法，其特征在于，所述方法还包括：监听所述消息系统中是否缓存有与所述下一消费者订阅的主题类型对应的消息；若有，则将所述消息分配至所述下一消费者。7.根据权利要求5所述的消息处理方法，其特征在于，所述方法还包括：当检测到所述链式结构消息的消费逻辑变更时，对所述链式结构消息进行变更。8.一种消息处理装置，其特征在于，所述装置基于发布订阅式的消息系统实现，包括：消息分配模块，用于当监听到消息系统中缓存有目标消息时，根据所述目标消息的主题类型将所述目标消息分配至订阅所述主题类型的消费者；状态获取模块，用于获取所述消费者消费所述目标消息后返回的消费状态；异常处理模块，用于若所述消费状态为消费异常，则按照所述消息系统中的异常处理策略对所述目标消息进行处理。9.一种存储介质，其特征在于：所述存储介质中存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如权利要求1至7中任一项
所述消息处理方法的步骤。10.一种计算机设备，其特征在于：所述计算机设备中存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如权利要求1至7中任一项所述消息处理方法的步骤。

技术总结
本发明提供的消息处理方法、装置、存储介质及计算机设备，当流程引擎组件监听到消息系统中缓存有目标消息时，可以依据该目标消息的主题类型来将该目标消息分配至订阅该主题类型的消费者，以便该消费者来消费该目标消息；由于本申请中的流程引擎组件是基于发布订阅式的消息系统实现的，因此在分配消息时，只需要根据该消息的主题类型即可确定对应的消费者，无需针对不同的消费者单独开发独立的流程引擎，并且，在消费者返回消费异常时，可以按照消费系统中的异常处理策略来对目标消息进行统一处理，无需针对不同的消费者进行单独处理，从而在一定程度上减少了开发成本，且流程引擎组件的普适性较高。引擎组件的普适性较高。引擎组件的普适性较高。


技术研发人员：刘华
受保护的技术使用者：上海品顺信息科技有限公司
技术研发日：2021.12.08
技术公布日：2022/3/8