一种消息处理系统和消息处理方法与流程

1.本发明涉及异步消息处理的技术，主要应用于消费金融领域，具体涉及一种消息处理系统和消息处理方法。


背景技术：

2.在为用户提供基于分布式消息的发布/订阅场景的产品时，需要采用某种消息队列中间件产品(市面上比较流行的有activemq、rocketmq、rabbitmq、kafka等)作为基础架构的一部分，来支持业务的需要。
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.监听所述消息代理中的异常预发送状态消息，所述异常预发送状态消息是指处于预发送状态的持续时长超过预设的第一时间阈值的消息，将所述异常预发送状态消息删除；和/或，
39.监控所述消息代理中的异常发送中状态消息，所述异常发送中状态消息是指处于发送中状态的持续时长超过预设的第二时间阈值的消息，触发所述消息代理对所述异常发送中状态消息进行重新发送。
40.第五方面，还提供了一种计算机可读存储介质，计算机可读存储介质内存储有计算机程序，该计算机程序被处理器执行时实现上述任意一种消息处理方法的各步骤。
41.第六方面，还提供一种计算机设备，其包括：
42.一个或多个处理器；
43.存储装置，用于存储一个或多个程序；
44.当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上所述的任意一种消息处理方法的各步骤。
45.上述技术方案具有如下有益效果：本发明实施例能够解决在异步消息通信场景下如何快速发布、接收消息，以及如何确保消息的一致性的问题。
附图说明
46.为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
47.图1a是本发明实施例的消息处理系统的整体功能框图；
48.图1b是本发明实施例的消息处理系统的一种具体功能框图；
49.图2是本发明实施例的消息的全生命周期中对所述消息的状态进行监控示意图；
50.图3是本发明实施例的可伸缩性设计的部署示意图；
51.图4是本发明实施例的一种消息处理方法的流程图；
52.图5是本发明实施例的另一种消息处理方法的流程图；
53.图6是本发明实施例的一种消息状态监控系统的功能框图；
54.图7是本发明实施例的一种计算机可读存储介质的功能框图；
55.图8是本发明实施例的一种计算机设备的功能框图。
具体实施方式
56.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
57.本发明实施例属于异步消息处理的技术，主要应用于消费金融领域，用于解决在
异步消息通信场景下如何快速发布、接收消息，以及如何确保消息的一致性的问题。
58.发明人在研究中发现，现有技术存在如下问题：
59.(1)维护工作量大。有些项目方由于历史原因实际维护了多套消息队列中间件产品，这样导致运维成本增加(配置不同产品的监控、告警、指标采集等)。
60.(2)技术复杂性高。主要体现需要投入大量精力在对消息积压、丢失、补偿、重试、幂等、限流、路由、顺序性、清理、归档、版本升级、技术选型等问题的考量和设计。从架构上还要考虑消费的吞吐量、流量伸缩、高可靠、技术选型、版本升级等问题。
61.(3)增加业务开发人员的开发负担。业务开发人员要充分关注和解决以上提到的消息队列的技术复杂性，特别对大数据量和高并发场景，要求更高，限制交付进度，分散开发精力，损害产品质量等。
62.为了解决上述问题，本发明实施例提供一种能够确保业务架构无感知于具体消息中间件影响的通用框架，从而使得产品开发更专注于业务领域，大幅度提升产品交付的速度和质量。
63.一、解决方案简介
64.作为独立的中间件，通过封装具体消息队列中间件技术，屏蔽了技术差异，并为业务开发提供通用的协议接口和规范，形成业务代码和技术代码分开演化和管理，具体如下：
65.(1)弱化mq中间件的强依赖。
66.(2)采用最终一致性架构思想解决消息在微服务间的一致性问题。
67.(3)实现消息有序消费功能。
68.(4)深入定制，实现满足核算平台特点的企业解决方案。
69.二、术语定义
70.rm，是reliable message的简称，表示可靠的消息处理系统。
71.broker，消息代理，是业务系统借由rm技术完成对异步消息处理的需要，rm是业务系统的代理。对rm来说，由broker完成对mq技术栈的封装，broker是rm的消息代理。
72.数据分区，指将数据根据散列算法进行分类，达到数据始终稳定地归属与某个分区之内。
73.实例克隆，即副本的概念，rm系统利用实例克隆的技术为消息处理提供高可用。
74.分片因子，在本实施例的核算系统中，通过借据号或客户号，来定义参与分片的算法参数。在rm系统中，由生产端通过指定分片因子，然后rm系统对分片因子进行计算，从而获取feign的索引号，找到调用指定broker的代理。feign是spring-cloud开源架构中的术语，它的作用是提供对http通信协议的封装和负载均衡处理。
75.三、技术手段
76.本发明实施例通过3个方面实现技术封装：
77.(1)封装消息队列交互接口，达到屏蔽通讯差异的目的。
78.(2)实现微服务分布式部署策略，达到屏蔽消息队列分布式部署差异的目的。
79.(3)实现一套通用的消息分发一致性，屏蔽不同消息队列技术栈，保障消息不丢失、不重复消费等特性。
80.四、技术原理
81.以技术手段提到的3个方面来解释：
82.(1)为业务调用方定义通用的交互接口，而将技术差异封装到架构内部。
83.(2)基于spring-cloud技术栈，为独立部署的rm提供服务注册发现、中心配置管理、路由分发、负载均衡、熔断限流等技术支撑。
84.(3)通过分布式部署特点，设计一组分布式事务持久化序列，并通过补偿、重试等技术实现消息分发的最终一致性。
85.五、约束说明
86.(1)rm系统仅为业务系统提供差异技术栈的对接，平滑接口协议的定义和规范，以确保业务代码对接的统一性，并不会重写mq技术本身的能力或降低mq技术本身的收益。
87.(2)rm作为微服务架构，可以独立部署和版本演化，采用mysql作为底层数据存储的基础技术。
88.(3)rm支持的指标采集技术是依托于spring-boot的actuator模块，以及符合该接口规范的监控中间件，例如prometheus等。actuator是spring-cloud开源架构中的术语，它的作用是提供对监控指标的定义和埋点。
89.(4)rm系统已经提供了对接不同消息队列的外部接口，目前rm系统支持activemq、rocketmq等mq技术栈。但是由于rm框架提供了二次开发的扩展规范，所以对接一个新的技术栈的开发成本很低，一般在2天内即可完成二次开发，并轻松拥有rm的所有技术输出成果。
90.六、适用场景
91.其适用于如下场景：
92.(1)关注平台级的通用性，对消息队列的使用完全封装到rm框架里，业务代码对rm的变化是无感知的(这种变化包括使用什么技术的消息队列、使用哪种通信协议、透明地增加计算节点、以及围绕消息的管控功能等)。
93.(2)关注消息的最终一致性。这种管控能力主要体现在如何解决消息丢失问题、如何进行消息补偿、清理、追溯、透传等问题，这是rm非常重要的运维特性，它解决了消息管理所面临的分布式系统难点问题，例如数据丢失、不一致、重复消费等问题。
94.所谓补偿，即指的是当消息状态不一致时重新发起消息推送，直到消息最终一致。
95.本实施例的补偿的算法包括：由监控系统负责检查发送状态，当发送消息失败时会重试并记录重试次数，如果超过重试次数阀值，则标记消息为死亡，转为人工处理。
96.状态不一致包括多种可能性，典型场景如下：
97.场景一：对于生产端，预发送消息成功，但是业务操作失败怎么办。
98.解决方案：由消息状态监控系统负责监听长期处于预发送状态的消息，超过一定时间后删除。
99.场景二：对于生产端，预发送消息成功，业务操作成功，但是发送消息失败怎么办。
100.解决方案：由消息状态监控系统负责定期查询生产端的业务执行结果，如果发现已成功了，则由消息代理broker发起对预消息的发送，确保将其发给消息队列。
101.场景三：对于消息代理来说，已接收到生产端成功的请求，但发送消息队列失败怎么办。
102.解决方案：由消息状态监控系统负责监控长期处于发送中状态的消息，然后重新发送。
103.场景四：对于消息代理来说，已成功发送消息队列，但消息状态一直处于发送中或待发送的状态怎么办。
104.解决方案：由消息状态监控系统负责监控长期处于发送中或待发送状态的消息，当检测到重发次数超限时，将该笔消息转为死亡并发送通知给客户。
105.场景五：对于消费端来说，已监听到消息，但是本地业务处理失败怎么办。
106.解决方案：由消息状态监控系统负责监控长期处于发送中或待发送状态的消息，然后重新发送消息。
107.场景六：对于消费端来说，已成功处理了本地消息，但发布通知失败怎么办。
108.解决方案：由消息状态监控系统负责监控长期处于发送中状态的消息，然后重新发送，而消费端因为已经成功处理过了，所以必须确保幂等机制(即幂等机制由消费端承担设计)。
109.(3)关注rm的可伸缩性，这主要体现在实例克隆、数据分区、监控、告警、容器化运行等，这是rm非常重要的运维特性，解决这类问题能够让开发人员从中解放出来，真正把精力投入到业务设计和开发上来。
110.七、关键设计说明
111.7.1、通用接口规范设计
112.rm系统承接了所有消息队列技术的功能，设计目标是为业务系统提供最简单的接口协议，主要包括以下内容：
113.消息接收需要实现的接口；
114.消息启动所需的配置(例如线程、监听的队列名，有序性相关的配置等)。
115.对于业务系统与rm系统承担的职责如下：
116.对于生产端服务，例如订单服务，通过spring-cloud技术栈的feign接口向rm的代理服务发送http请求，也即，生产端对rm是无感知的，这进一步体现了业务代码不需要关心mq技术栈的设计目标。
117.rm代理服务broker承接了消息发送的职责，将消息发送行为与业务生产端隔离。
118.对于消费端服务，例如会计引擎服务，只需要定义一个实现imsgrecievecallbackhandler接口的自定义类，用于接收消息并处理自己的报文即可。另外，消费端启动后，通过rm的内部配置。
119.rm系统的主要组成如下：
120.(1)生产端组件，主要包括producer-starter和mq-producer，其中mq-producer是封装了每一个mq技术栈，例如封装了activemq，则该组件为active-producer；封装了rocketmq，则为rocket-producer。每一个producer都被设计为封装并隐藏对应mq的技术规范。其中，producer-starter是组件包的命名，其组件功能是为生产消息端提供包的引用，该包实现了所有相关的功能实现。
121.(2)消费端组件，主要包括consumer-starter和mq-consumer，其中mq-consumer是封装了每一个mq技术栈，例如封装了activemq，则该组件为active-consumer；封装了rocketmq，则为rocket-consumer。每一个消费端consumer都被设计为封装并隐藏对应mq的技术规范。其中，consumer-starter是组件包的命名，其组件功能是为消费消息端提供包的引用，该包实现了所有相关的功能实现。
122.(3)内核组件，主要包括内核功能(core)、自动装配功能(autoconfig)、客户端接口(client)、实例工厂(factory)等，负责接口规范定义、实例工厂、动态配置、消息发送、报文格式、消息通知、消息结果监听等操作。
123.(4)消息代理组件broker，负责定义生产端发来的请求，并将请求报文转换为消息报文持久化，然后分发给消息队列。
124.7.2、消息一致性设计
125.如图1a所示，消息处理系统包括：
126.消息生产端，用于向消息代理发送处于预发送状态的消息，执行本地业务操作并将业务操作结果持久化到第一数据库，向消息代理发送业务操作结果。在一个举例中，本地业务操作包括但不限于放款的业务操作。
127.消息代理，消息代理包括：接收模块，用于接收处于预发送状态的消息；第二数据库，用于存储处于预发送状态的消息；处理模块，其包括：预发送消息处理子模块，用于当消息生产端发送的与业务操作结果相关联的确认信息指示业务操作成功时，则将处于预发送状态的消息的状态修改为发送中状态，并且控制发送模块向消息队列发送消息；如果确认信息指示业务操作失败时，则删除处于预发送状态的消息；发送模块，用于在处理模块的控制下向消息队列发送消息。
128.消息队列，用于对消息代理发送的消息进行缓存。
129.消息消费端，用于接收消息并处理本地业务。
130.消息状态监控系统，用于在消息的全生命周期中对消息的状态进行监控，并且当消息的状态异常时，触发消息代理对状态异常的消息进行处理。
131.具体地，预发送消息处理子模块，用于判断确认信息是否成功，如果确认信息是成功的，则控制发送模块向消息队列发送消息；如果确认信息是失败的，则删除处于预发送状态的消息。预发送状态的消息，指的是在向消息队列发送消息前，消息生产端先向消息代理(broker)发送该消息，等待消息生产端发送确认信息(业务操作成功/业务操作失败/未接到任何响应)后再决定如何操作。如果确认信息是成功，消息代理发送该消息到消息队列；如果确认信息是失败，消息代理不发该消息到消息队列；如果长期未收到结果，消息监控(monitor)轮询消息生产端状态，发现业务操作成功，则消息代理发送消息到消息队列；如果发现业务操作失败，消息代理删除预发送消息。
132.如图1b所示，在一些实施例中，所述消息代理中的处理模块还包括：消息状态监测及处理子模块，用于执行如下任意一种或多种操作：
133.定时清理消息或者定时备份消息；删除已死亡的消息；发起对已死亡消息的重新发送；查询已超时的消息，对所述已超时的消息进行重新发送；这里可由消息监控系统负责向消息生产端提供的接口进行查询，并返回查询结果；查询已超时并且超过预设发送次数的消息，触发人工处理。这里可由消息监控系统负责向消息生产端提供的接口进行查询，并返回查询结果。
134.在一些实施例中，消息消费端，具体用于监听消息队列中的消息，消息由消息代理负责投递；当所述消息队列中消息被成功地投递到消息消费端后，接收消息并根据接收到的消息来处理本地业务；在处理完本地业务后，将处理结果存入消息消费端的业务数据库，并向消息代理发布通知，通知指示消息已被成功消费。
135.在一些实施例中，消息状态监控系统，用于执行如下中的任意一项或多项；
136.监控处于异常发送状态的消息，触发所述消息代理对处于异常发送状态的消息进行处理。
137.监控已死亡的消息，触发消息代理对已死亡的消息进行删除或者重新发送；作为一个举例，当由于消息格式错误导致无法处理消息的，就可以删除该消息。本步骤还可以包括：监控已死亡的消息，向用户或客户输出提示或通知信息，接收用户或客户输入的(第一)处理指令，根据该处理指令触发消息代理对已死亡的消息进行删除或者重新发送。
138.监控未得到确认的消息，触发所述消息代理对所述未得到确认的消息进行重新发送，记录发送次数；如果所述发送次数超过预设的重试次数(重发次数)，则将所述未得到确认的消息转为死亡状态，进一步触发人工处理。
139.监控待清理或者待备份的消息，触发消息代理对待清理的消息进行删除或者对待备份的消息进行备份。在一个示例中，对于没有意义的请求，例如报文格式本身具有问题或缺陷的，可以删除该待清理的消息；当具有预设的日志审计要求或者默认要求进行日志审计时，可以对待备份的消息进行备份。在另一个示例中，该步骤可以包括：当监控到待清理或者待备份的消息时，向用户输出询问信息，例如询问弹窗或者具有交互式选项的界面，然后基于该询问信息接收用户输入的(第二)处理指令，并且根据该处理指令触发消息代理相应地对待清理的消息进行删除或者对待备份的消息进行备份。
140.具体地，一条消息对应消息代理broker中维护的数据表，主要字段包括：
141.messageid，消息id；
142.status，消息状态，预发送(preset)/发送中(sending)/已消费(consumed)；
143.deaded，死亡标志，true表示已死亡。
144.在一些实施例中，消息状态监控系统，具体用于：监听消息代理中的异常预发送状态消息，异常预发送状态消息是指处于预发送状态的持续时长超过预设的第一时间阈值的消息，将异常预发送状态消息删除；和/或，监控消息代理中的异常发送中状态消息，异常发送中状态消息是指处于发送中状态的持续时长超过预设的第二时间阈值的消息，触发消息代理对异常发送中状态消息进行重新发送。具体地，预发送是生产端在处理本地业务前先发送消息给代理的一种行为；待发送指的是消息代理准备将满足预定条件的消息发送到消息队列的行为。上述预定条件包括以下几种：(1)消息处于预发送状态；(2)消息处于正在发送状态(发送中状态)、超时并且未达到重发送次数上限。
145.在一些实施例中，消息状态监控系统，还用于：监测异常发送中状态消息的重新发送次数，当重新发送次数超出预设的重发次数阈值时，将异常发送中状态消息标记为已死亡的消息，并且发出指示进行人工处理的通知。具体地，删除已死亡的消息的操作由人工处理决定，消息代理响应于人工处理操作指令，删除已死亡的消息。
146.在一些实施例中，消息状态监控系统，还用于：定期查询消息生产端的业务操作结果，如果业务操作结果为已成功，则触发消息代理发起对预发送消息的发送，确保将预发送状态的消息的发送给消息队列。例如，对于放款业务，业务操作成功是指：接收贷款申请人的放款请求，创建了放款数据和还款计划等，就表示业务操作成功了。
147.在一些实施例中，消息状态监控系统，还用于：当消息生产端和消息消费端的数据是一致的，触发消息代理更新消息的状态为已消费。
148.在一些实施例中，消息消费端包括：
149.收发模块，用于监听消息队列中的消息，当消息到达后，接收消息；
150.幂等检查模块，用于对接收的消息进行幂等检查；
151.业务操作模块，用于对通过幂等检查的消息进行业务操作，并且将业务操作的处理结果存储至第三数据库；
152.第三数据库，用于存储业务操作的处理结果；
153.通知模块，用于向消息代理发布通知，通知指示消息已被成功消费。
154.在一些实施例中，消息生产端，还用于：指定分片因子，例如包括借据号或客户号；根据分片因子和消息代理的数量，获得feign的索引号；根据feign的索引号确定调用与该索引号相匹配的消息代理。具体地，可利用分片因子对消息代理的数量进行取模运算获得数字值，或者，先将分片因子进行哈希处理后再对消息代理的数量进行取模运算获得数字值，基于该数字值确定feign的索引号，根据feign的索引号确定调用与索引号相匹配的消息代理，例如名称编号中包含该索引号的消息代理。
155.以下结合图1b对消息处理系统主要包括的以下五部分进行更加详细的说明：
156.(1)消息生产端
157.由业务系统的上游系统承担消息生产端的角色，负责处理本地业务并发送消息。具体地，消息生产端，负责执行本地业务和发送消息的操作。其基本流程是：首先发送预消息，然后执行本地业务操作，并将消息和业务数据关联后存盘。
158.在一些实施例中，消息生产端执行以下步骤：
159.首先，向消息代理(broker)发送预消息，消息代理会将该笔请求(上述预消息)持久化到数据库。该笔请求就是那笔“预消息”。预消息是一条消息记录，状态是“预发送”状态。发送预消息时，因为生产端的业务还没有处理，所以数据在生产端和消费端之间是一致的。
160.然后，执行本地业务操作并将预消息持久化到数据库。所述的本地业务操作，指的是改变业务状态的操作，并同时将该业务操作与前面发送的预消息通过标识符管理起来，一起存储到数据库。例如，在执行业务操作前，先发送预消息，消息id＝a；成功发送了预消息后，开始执行业务操作。当业务操作成功并落库时(一般一笔业务都会有一个唯一的业务交易流水号)，同时将消息id也落库。这样，数据库就有两种类型的数据：业务流水号作为唯一标识的数据记录；以及，业务流水号+消息id作为唯一标识的关联记录。
161.最后，向消息代理发送业务操作执行结果(成功/失败)。
162.(2)消息代理(broker)
163.消息代理负责管理消息的全生命周期。其基本处理流程是：消息代理收到预发送信息后，存到本地磁盘，将消息状态置为“预发送”。然后当收到生产端的确认信息后，消息代理执行如下操作：操作1：将消息状态变更为“发送中”；操作2：发送该消息到消息队列。
164.在一些实施例中，消息代理负责接收消息生产端的消息，并持久化到本地数据库；并且通过跟踪消息的全生命周期状态，以便确定如何处理消息，其包括如下处理：
165.接收并存储预发送消息；
166.接收并处理消息；如果是成功的，则向消息队列发送消息；如果是失败的，删除消息。具体地，消息被预发送后是“预发送状态”，生产端成功地执行了业务处理后，并成功地
发送了确认信息，表示消息成功地转为“确认状态”，即代表生产端已经完成了消息和业务处理的一致性操作，即表示成功地发送了消息。
167.对于消息代理来说，它接收生产端发来的预消息。如果再一次收到生产端发来的确认信息(即生产端执行完自己的业务处理后发送确认信息)，即表示成功；如果一直没有收到生产端的确认信息，监控系统检测到这一状况，发起对生产端的询问。如果生产端业务处理结果是业务已经成功处理，则监控系统告知消息代理，消息是已经“确认”的，即表示成功；如果生产端业务处理的结果是失败的，即表示失败。
168.管理其他消息，其具体包括如下中的任意一种或多种：定时清理/备份消息；定时删除已死亡的消息；发起对已死亡消息的重新发送；查询已超时的消息，重新投递；查询已超时并超过投递次数的消息，转人工处理等。
169.具体地，清理，表示删除；备份，表示将数据迁移到其他存储介质。当到达终态的消息，才需要清理或备份，终态包括：
170.1、已消费。这是成功的处理状态，表示一种正常的生产和消费过程。
171.2、已死亡。即消息代理一直发送消息，并达到发送次数上限，最终交给人工处理后的状态。
172.总之，已经成功处理的消息应该定期备份；对于无法解决的消息，最终被标记为系统丢弃的，应该清理。
173.上述发起对已死亡消息的重新发送，具体包括：已死亡，表示消息代理尝试发送消息，直到超过发送次数上限，就标记为死亡，转为人工处理。例如消息队列中间件宕机，就会发生这种情况。当故障排出后，将已死亡改为未死亡，同时发送次数归零，则监控系统又识别并重新发送消息，直到成功，或者直到死亡，即又发送失败并超过发送次数上限。
174.(3)消息队列(实时消息服务或消息中间件)
175.消息队列是将消息通过先入先出的队列，以异步的方式从生产端发送给消费端的一种数据结构。消息队列指的是具体技术栈的消息队列，例如activemq，它可能是单点部署，也可能是集群部署，由客户方目前的技术方案决定。通常每个客户的it系统建设，采用的是一套自己的技术选型方案，对于rm系统来说，该技术选型并不是强制依赖的。即消息队列可以采用任何一款技术，其适配方案是：
176.rm的activemq-producer和activemq-consumer适配activemq消息队列架构；
177.rm的rocketmq-producer和rocketmq-consumer适配rocketmq消息队列架构；
178.rm的rabbitmq-producer和rabbitmq-consumer适配rocketmq消息队列架构。
179.rm架构负责解决技术差异，这与业务系统(生产端和消费端)无关。
180.(4)消息消费端
181.消息消费端负责消息接收并执行本地业务操作。其基本处理流程主要包括如下步骤：消息队列的消息到达后，消费端执行本地业务，并将消息与业务关联后存盘，然后将通知发给消息代理。
182.在一些实施例中，消息消费端由业务系统的下游系统承担消费端的角色，用于接收上游系统发送的消息并处理本地业务，其执行以下3个步骤：
183.首先，监听消息队列中的消息，该消息由消息代理broker负责投递；
184.当消息到达后，消息消费端接收该消息并处理本地业务；
185.处理完本地业务后，将处理结果存盘(存到业务数据库)，并向消息代理发布通知消息，这个通知消息指示确认信息已被成功消费，从而使得消息代理能够管理消息状态。
186.(5)消息状态监控系统
187.消息状态监控系统主要用于在各种异常状态下的操作，它是保障消息最终一致性的关键服务，其主要功能包括如下中的至少一项；监控消息发送状态；监控死亡的消息；监控未得到确认的消息；通过监控跟踪状态，发出指令来触发消息代理执行消息清理或备份等。
188.在一些实施例中，消息监控系统，主要解决操作处理的异常场景的管理，主要包括以下几个典型场景：
189.场景一：对于消息生产端来说，预发送消息成功，但是业务操作失败。
190.本技术发明人经研究发现，由于业务操作一直没有成功，此时消息生产端和消息消费端的数据是一致的，只需要删除消息代理中的预发送消息即可。因此，本实施例采用的技术手段是：由消息状态监控系统负责监听长期处于预发送状态的消息，超过一定时间后将其删除。
191.场景二：对于消息生产端来说，预发送消息成功，业务操作成功，但是发送消息失败。
192.本技术发明人经研究发现，由于消息生产端的业务操作已经成功，而消息代理没有成功地将消息发送给消息消费端，导致数据不一致，所以必须确保消息代理成功地将消息发出去。因此，本实施例采用的技术手段是：由消息状态监控系统负责定期查询消息生产端的业务执行结果，如果发现已成功了，则由消息代理发起对预发送消息的发送，确保将其发给消息队列。其中，消息具有唯一状态标识，前面提到的预消息、待确认信息、正在发送的消息、已消费消息等，都是该笔消息在不同阶段的状态。
193.场景三：对于消息代理来说，已接收到消息生产端业务操作成功的请求，但发送消息队列失败。
194.本技术发明人经研究发现，由于消息生产端的业务操作已经成功，而消息代理没有成功地将消息发送给消费端，导致数据不一致，所以必须确保消息代理成功地将消息发出去。因此，本实施例采用的技术手段是：由消息状态监控系统负责监控长期处于发送中状态的消息，然后重新发送。
195.场景四：对于消息代理来说，已成功发送至消息队列，但消息状态一直处于发送中的状态。
196.本技术发明人经研究发现，该现象表示消息代理重试发送多次都失败了，此时消息生产端和消息消费端最终数据不一致了，这可能是系统问题或网络问题导致的，必须尽快转人工处理。因此，本实施例采用的技术手段是：由消息状态监控系统负责监控长期处于发送中状态的消息，当检测到重发次数超限时，将该笔消息转为死亡并发送通知给客户(进行人工处理)。
197.场景五：对于消息消费端来说，已监听到消息，但是本地业务处理失败。
198.本技术发明人经研究发现，该现象表示消息生产端和消息消费端已经明确数据不一致了，需要消息生产端重新发起消息。因此，本实施例采用的技术手段是：由消息状态监控系统负责监控长期处于发送中状态的消息，然后重新发送该消息。
199.场景六：对于消息消费端来说，已成功处理了本地消息，但发布通知失败。
200.本技术发明人经研究发现，该现象表示消息生产端和消息消费端的数据是一致的，需要消息代理正确地更新消息的状态为已消费。因此，本实施例采用的技术手段是：由消息状态监控系统负责监控长期处于发送中状态的消息，然后重新发送，而消息消费端因为已经成功处理过了，所以必须确保幂等机制(即幂等机制由消息消费端承担设计)。
201.此处的重新发送指的是消费端已经成功了，但是发送通知给消息代理时网络中断或消费端宕机等，导致消息代理无法获取消息是否成功的信息。
202.以这个场景为例，当消费端成功获取到消息并执行本地业务后，要通知给消息代理，此时，消费端宕机了。对于消息代理来说，它是无法知道为什么消息消费端没有将通知发过来。本发明实施例的处理的方式是，消息代理重新推送。对于消费端来说，要解决的是幂等操作。确保在相同的交易流水号的请求下，数据状态一致保持一致。
203.如图2所示，所谓的消息一致性，是生产端的业务与消费端的业务处理的最终状态是一致的。
204.该状态图的“已被消费”的状态，就是表示消息最终一致了。确保消息最终一致的全流程，就是这种状态图所要表达的设计意图。
205.s1、首先生产端发起一比交易，要求执行本地业务，此时生产端先发送一笔预消息给消息代理，告知代理服务未来将有一笔业务需要处理。
206.s2、消息代理将该笔消息存盘落库，等待消息确认。
207.s3、当生产端完成业务处理后，发送确认信息，告知消息代理可以发送消息到消息队列了。
208.s4、消息代理收到消息确认后，将该消息发送到消息队列，并将消息状态置为“发送中”。
209.s5、如果消息状态一直处于“发送中”，并达到时间上限，则由监控系统监听并发起重新发送的操作，同时记录发送次数加1。
210.s6、如果消息状态一直处于“发送中”，并达到发送次数上限，则由监控系统监听并触发执行消息死亡(由另一字段deaded标识)。
211.s7、当消息消费者成功收到消息后执行本地业务，并发通知给消息代理。消息代理收到消息，就将消息状态置为“已被消费”。
212.可伸缩性设计：
213.可伸缩性设计的目的是解决大数据高并发场景下，通过横向扩展解决处理的并发性和单位时间的数量的问题。
214.可伸缩性设计设计思路如下：
215.为了提升处理消息的机器数量，将消息处理的机器进行分区，每个分区处理一部分数据，一般按message_id进行散列算法，这样处理的消息可以均衡的分散在不同的区上。分区数量越多，处理消息的机器越多，并行处理的能力越强。对于消息生产端来说，发送消的目标地址需要通过散列算法获取到目标机器的编号；同理，消息代理发送消息到消息队列、消费端将消费的结果推送给消息代理，都是通过相同的算法获取目标地址的。例如，消息代理部署3台，编号分别是0、1、2，消息生产端根据借据号(loanno)将消息发送到消息代理，具体发送到哪个代理，采用如下公式：机器编号＝loanno取模3。
216.由于单分区一旦宕机，将导致所有分流到该分区的消息都无法得到处理，所以必须设计在分区内克隆实例，以确保当某个实例失效后会由另一个实例继续消费，实例数量越多，可用性越高，一般至少设置2个实例。每个实例建议部署在独立的机器上，最好跨机房部署。
217.如果某一分区的所有实例全部宕机，则rm能够动态识别并将消息分流到其他正常的分区上。这一过程完全动态进行，无需人工干预。上述动态识别和分流处理，是通过服务注册中心统一管理，该服务注册中心是spring-cloud微服务架构的统一解决方案，rm调用服务注册中心的相关功能实现上述动态识别和分流处理。
218.图3是本发明实施例的可伸缩性设计的部署示意图。如图3所示，消息代理的部署模式包括：
219.如图3的(a)部分所示，消息代理的部署模式一，在该模式中具有相同的serverid，进行实例克隆，具体包括：消息代理包括处于单个分区中的多台机器，多台机器具有共同的服务器标识，每台机器上运行克隆实例，当一台机器上的克隆实例失效后，切换至由本分区内的另一台机器上的克隆实例继续消费；或者，
220.如图3的(b)部分所示，消息代理的部署模式二，在该模式中具有不相同的serverid，做流量分区，具体包括：消息代理包括多个分区，每个分区中具有一台机器，每台机器的服务器标识均不相同，当任意一个分区中的机器宕机时，将待处理消息分流到其他正常的分区内的机器上；或者，
221.如图3的(c)部分所示，消息代理的部署模式三，在该模式中具有不相同的serverid，某一serverid存在多份部署：消息代理包括多个分区，在至少一个分区中仅配置一台机器，在至少一个分区中配置多台机器，并且在配置多台机器的分区中，多台机器具有共同的服务器标识且运行相应的克隆实例，当任意一个分区中的机器宕机时，将待处理消息分流到其他正常的分区内的克隆实例未失效的机器上。
222.本发明实施例的上述技术方案具有如下有益技术效果：
223.1、提升平台级的通用性，主要体现在以下几点：
224.仅需要一次性学习rm的接口规范，不同mq的技术特性由rm封装；
225.业务人员无需关心技术栈配置和部署等运维要求；
226.业务人员可以快速接入客户研发团队对mq的需求，通常接入一款新的mq仅需1～2天时间，大大降低开发成本。
227.2、解决消息的一致性，主要体现在以下几点：
228.业务开发人员无需关注消息丢失问题，由rm系统自动完成消息的本地保存和全局监控；
229.业务开发人员无需开发消息补偿代码，由rm系统自动完成消息状态的跟踪和重新发送；
230.由于分布式系统网络等原因导致的消息补偿失败，由rm系统自动推送到人工平台，通过告警系统通知人工干预。告警系统是一个通用的解决方案，一般微服务系统都会标配，类似于prometheus、zabbix等系统平台。如果不安装告警系统也是可以的，通过输入日志，或编写一些代码监控状态也可以实现告警。
231.3、实现rm的可伸缩性，主要体现在以下几点：
232.在高流量场景下，通过增加rm分区数量，可以快速解决数据处理的压力，增加分区对业务上下游系统无感知；
233.在高可靠场景下，通过增加单分区的机器实例数量，可以保障分区的高可用性。
234.4、实现其他一些有价值的特性，主要体现在以下几点：
235.自动完成消息的备份、清洗等操作，业务人员无需干预；
236.对消息高可靠要求没有那么高的场景下，可以通过透传消息解决，业务人员无需做额外开发；
237.业务人员可以方便地追溯消息的来源、路由和原始报文等信息；
238.发挥消息接收节点的资源利用率，业务开发人员无需做任何额外开发，仅通过配置来调整性能。
239.图4是本发明实施例的一种消息处理方法的流程图。如图4所示，该方法包括如下步骤：
240.s110、消息生产端向消息代理发送处于预发送状态的消息，执行本地业务操作并将业务操作结果持久化到第一数据库，向消息代理发送业务操作结果；
241.s120、消息代理接收处于预发送状态的消息，存储处于预发送状态的消息到第二数据库，当消息生产端发送的与业务操作结果相关联的确认信息指示业务操作成功时，则将消息的状态修改为发送中状态，并且向消息队列发送消息，如果确认信息指示业务操作失败时，则删除处于预发送状态的消息；
242.s130、消息队列对消息代理发送的消息进行缓存；
243.s140、消息消费端接收消息并处理本地业务；
244.s150、消息状态监控系统在消息的全生命周期中对消息的状态进行监控，并且当消息的状态异常时，触发消息代理对状态异常的消息进行处理。
245.在一些实施例中，所述方法还包括如下中的任意一项或多项：
246.消息代理定时清理消息或者定时备份消息；
247.消息代理删除已死亡的消息；
248.消息代理发起对已死亡消息的重新发送；
249.消息代理查询已超时的消息，对已超时的消息进行重新投递；
250.消息代理查询已超时并且超过预设投递次数的消息，触发人工处理。
251.在一些实施例中，步骤s150中消息状态监控系统在消息的全生命周期中对消息的状态进行监控，并且当消息的状态异常时，触发消息代理对状态异常的消息进行处理，具体包括执行如下中的任意一项或多项：
252.消息状态监控系统监控处于异常发送状态的消息，触发所述消息代理对处于异常发送状态的消息进行处理；
253.消息状态监控系统监控已死亡的消息，触发消息代理对已死亡的消息进行删除或者重新发送；
254.消息状态监控系统监控未得到确认的消息，触发消息代理对未得到确认的消息进行处理；
255.消息状态监控系统监控待清理或者待备份的消息，触发消息代理对待清理的消息进行清理或者对待备份的消息进行备份。
256.在一些实施例中，所述的监控处于异常发送状态的消息，触发所述消息代理对处于异常发送状态的消息进行处理，具体包括：
257.所述消息状态监控系统监听所述消息代理中的异常预发送状态消息，所述异常预发送状态消息是指处于预发送状态的持续时长超过预设的第一时间阈值的消息，将所述异常预发送状态消息删除；和/或，
258.所述消息状态监控系统监控所述消息代理中的异常发送中状态消息，所述异常发送中状态消息是指处于发送中状态的持续时长超过预设的第二时间阈值的消息，触发所述消息代理对所述异常发送中状态消息进行重新发送。
259.具体地，消息状态监控系统监测所述异常发送中状态消息的重新发送次数，当所述重新发送次数超出预设的重发次数阈值时，将所述异常发送中状态消息标记为已死亡的消息，并且发出指示进行人工处理的通知。
260.在一些实施例中，消息状态监控系统定期查询消息生产端的业务操作结果，如果业务操作结果为已成功，则触发消息代理发起对预发送消息的发送，确保将预发送消息的发送给消息队列。
261.在一些实施例中，当消息生产端和消息消费端的数据是一致的，消息状态监控系统触发消息代理更新消息的状态为已消费。
262.图5是本发明实施例的另一种消息处理方法的流程图。如图5所示，该方法包括如下步骤：
263.s210、在消息的全生命周期中对所述消息的状态进行监控；
264.具体地，消息的全生命周期指消息从生成到死亡的全过程，消息的状态包括但不限于：预发送(preset)、发送中(sending)、已消费(consumed)、死亡状态(deaded)。
265.s220、当监控到所述消息的状态异常时，触发消息代理对状态异常的消息进行处理。
266.可选地，步骤s220具体可以包括如下中的任意一项或多项：
267.当监控到处于异常发送状态的消息，触发所述消息代理对处于异常发送状态的消息进行处理；
268.当监控到已死亡的消息，触发所述消息代理对所述已死亡的消息进行删除或者重新发送；
269.当监控到未得到确认的消息，触发所述消息代理对所述未得到确认的消息进行重新发送，记录发送次数，如果所述发送次数超过预设的重试次数，则将所述未得到确认的消息转为死亡状态；
270.当监控到待清理或者待备份的消息，触发所述消息代理对待清理的消息进行清理或者对待备份的消息进行备份。
271.可选地，所述的当监控到处于异常发送状态的消息，触发所述消息代理对处于异常发送状态的消息进行处理，具体包括：
272.监听所述消息代理中的异常预发送状态消息，所述异常预发送状态消息是指处于预发送状态的持续时长超过预设的第一时间阈值的消息，将所述异常预发送状态消息删除；和/或，
273.监控所述消息代理中的异常发送中状态消息，所述异常发送中状态消息是指处于
发送中状态的持续时长超过预设的第二时间阈值的消息，触发所述消息代理对所述异常发送中状态消息进行重新发送。
274.图6是本发明实施例提供的一种消息状态监控系统的功能框图。如图6所示，其包括：
275.消息状态监控模块310，用于在消息的全生命周期中对所述消息的状态进行监控；
276.消息异常处理模块320，用于当监控到所述消息的状态异常时，触发消息代理对状态异常的消息进行处理。
277.在一些实施例中，消息异常处理模块320，具体用于执行如下中的任意一项或多项：
278.当监控到处于异常发送状态的消息，触发所述消息代理对处于异常发送状态的消息进行处理；
279.当监控到已死亡的消息，触发所述消息代理对所述已死亡的消息进行删除或者重新发送；
280.当监控到未得到确认的消息，触发所述消息代理对所述未得到确认的消息进行重新发送，记录发送次数，如果所述发送次数超过预设的重试次数，则将所述未得到确认的消息转为死亡状态；
281.当监控到待清理或者待备份的消息，触发所述消息代理对待清理的消息进行清理或者对待备份的消息进行备份。
282.在一些实施例中，消息异常处理模块320，具体可以用于：
283.监听所述消息代理中的异常预发送状态消息，所述异常预发送状态消息是指处于预发送状态的持续时长超过预设的第一时间阈值的消息，将所述异常预发送状态消息删除；和/或，
284.监控所述消息代理中的异常发送中状态消息，所述异常发送中状态消息是指处于发送中状态的持续时长超过预设的第二时间阈值的消息，触发所述消息代理对所述异常发送中状态消息进行重新发送。
285.图7是本发明实施例的一种计算机可读存储介质的功能框图。如图7所示，该计算机可读存储介质400内存储有计算机程序410，该计算机程序410被处理器执行时实现上述任意一种消息处理方法的各步骤。
286.图8是本发明实施例的一种计算机设备的功能框图。如图8所示，其包括：
287.一个或多个处理器501；
288.一个或多个通信接口502；
289.通信总线304；
290.存储器503，用于存储一个或多个程序；
291.其中，处理器301，通信接口302，存储器303通过通信总线304完成相互间的通信；
292.当所述一个或多个程序被所述一个或多个处理器501执行时，使得所述一个或多个处理器501实现如上所述的任意一种消息处理方法的各步骤。
293.处理器501可以是通用处理器，包括中央处理器(central processing unit，cpu)、网络处理器(network processor，np)等；还可以是数字信号处理器(digital signal processing，dsp)、专用集成电路(application specific integrated circuit，asic)、现
场可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
294.存储器503可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器503可包括硬盘驱动器(hard disk drive，hdd)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(universal serial bus，usb)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器503可包括可移除或不可移除(或固定)的介质。
295.通信总线504包括硬件、软件或两者，用于将上述部件彼此耦接在一起。举例来说，总线可包括加速图形端口(agp)或其他图形总线、增强工业标准架构(eisa)总线、前端总线(fsb)、超传输(ht)互连、工业标准架构(isa)总线、无限带宽互连、低引脚数(lpc)总线、存储器总线、微信道架构(mca)总线、外围组件互连(pci)总线、pci-express(pci-x)总线、串行高级技术附件(sata)总线、视频电子标准协会局部(vlb)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线可包括一个或多个总线。尽管本发明实施例描述和示出了特定的总线，但本发明考虑任何合适的总线或互连。
296.所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本技术的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
297.上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
298.虽然本技术提供了如实施例或流程图的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。
299.本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
300.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指
令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
301.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
302.本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。