CN114880137A - 消息处理方法及装置、电子设备及存储介质 - Google Patents

消息处理方法及装置、电子设备及存储介质 Download PDF

Info

Publication number
CN114880137A
CN114880137A CN202210420327.9A CN202210420327A CN114880137A CN 114880137 A CN114880137 A CN 114880137A CN 202210420327 A CN202210420327 A CN 202210420327A CN 114880137 A CN114880137 A CN 114880137A
Authority
CN
China
Prior art keywords
callback
delivery
message
compensation
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210420327.9A
Other languages
English (en)
Inventor
李云龙
常军
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Shareit Information Technology Co Ltd
Original Assignee
Beijing Shareit Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Shareit Information Technology Co Ltd filed Critical Beijing Shareit Information Technology Co Ltd
Priority to CN202210420327.9A priority Critical patent/CN114880137A/zh
Publication of CN114880137A publication Critical patent/CN114880137A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本公开实施例提供一种消息处理方法、装置、电子设备及计算机可读存储介质，所述消息处理方法包括：通知服务接收并存储业务方发送的事务型消息，进行事务型消息的投递，并根据事务型消息的投递状况维护消息投递记录，当事务型消息投递成功之后进行事务型消息的回调，并根据回调状况维护事务型消息的回调记录。如此，事务型消息存储在数据库服务器，解决因消息丢失造成数据不一致问题，保证数据安全。同时将事务型消息接收、通知处理、补偿、回调内聚到本系统里，真正实现高内聚低耦合，极大节约和降低服务器成本。

Description

消息处理方法及装置、电子设备及存储介质
技术领域
本公开涉及计算机应用技术领域，特别涉及一种消息处理方法、装置、电子设备及计算机可读存储介质。
背景技术
微服务提倡将单一应用程序划分成一组小的服务，服务之间互相协调配合，而只要涉及到微服务就存在数据一致性的问题，目前业内有采用消息队列(Message Queue，MQ)消息发布订阅机制发布消息，并基于补偿策略保证数据最终一致性的弱一致性策略，也有使用分布式事务框架的强一致性策略。而由于强一致性策略是同步处理，存在线程阻塞、时延大、耦合性强等问题，不适合吞吐量比较高的高并发业务。因此业内更多采用弱一致性策略。
服务内常规事件，消息发送出去即可，关心该事件的业务方订阅此消息即可。如果是事务型事件，则至少需要保证最终一致性，不同MQ中间件对事务和重试策略等支持不够友好和不够灵活，甚至有的MQ中间件完全不支持。就算支持事务型消息比较友好的分布式消息队列，最终一致也需要事件发布方有兜底补偿策略(比如定时轮询等)才能完全保证。
在异常情况或极端情况下，如消息重试次数用尽或者消息失效；消息存储空间达到阈值或过期的自动清除等各种原因，消息事件订阅方无法按照预定设想完成对应的消息处理，导致系统数据错乱。
通常情况下是通过增加额外的轮询补偿机制来解决上述问题。如果一个服务内存在多个类似业务，则会有很多雷同的重试补偿机制。造成系统资源不可复用，可维护性越来越低。
发明内容
本公开实施例提供一种消息处理方法、装置、电子设备及计算机可读存储介质。
第一方面，本申请提供了一种消息处理方法，由包含通知服务的第一设备执行，该方法可以包括：
通知服务接收并存储业务方发送的事务型消息；
进行事务型消息的投递，并根据事务型消息的投递状况维护消息投递记录；
当事务型消息投递成功之后进行事务型消息的回调，并根据回调状况维护事务型消息的回调记录。
在一些可能的实施方式中，事务型消息携带的参数至少包括：事务型消息涉及的业务码以及业务方的业务方标识；
根据事务型消息的投递状况维护消息投递记录，包括：
根据投递状况，生成同时与业务码和业务方标识对应的投递记录，其中，投递记录至少包括：指示是否已投递的投递状态标识位；
根据回调状况维护事务型消息的回调记录，包括：
根据回调状况，生成同时与业务码和业务方标识对应的回调记录，其中，回调记录至少包括：指示已回调的回调状态标识位。
在一些可能的实施方式中，投递记录还指示以下至少之一：
已投递次数；
已投递时刻；
重复投递次数；
下一次重复投递时刻；
和/或，
回调记录还指示以下至少之一：
已回调次数；
已回调时刻；
重复回调次数。
在一些可能的实施方式中，事务型消息携带的参数还包括以下之一：
投递地址；
回调地址；
补偿策略信息，用于投递失败时确定再次投递的投递补偿参数，和/或，用于回调失败时确定再次回调的回调补偿参数。
在一些可能的实施方式中，根据事务型消息的投递状况维护消息投递记录包括：
在尚未进行事务型消息的首次投递时，将投递状态标识位置为指示待投递；
或者，
根据消息投递的关联业务方的投递响应的接收状况，确定事务型消息是否投递成功；
在事务型消息投递失败时，将投递状态标识位置为指示待补偿；
在事务型消息投递成功时，将投递状态标识位置为指示已投递。
在一些可能的实施方式中，进行事务型消息的投递，包括：
在事务型消息投递失败时，基于投递补偿策略确定补偿投递参数；其中，补偿投递参数包括：最大补偿投递次数和/或下一次补偿投递时刻；
根据补偿投递参数，重新投递事务型消息。
在一些可能的实施方式中，方法还包括：
当事务型消息投递的次数大于补偿策略的最大补偿次数后，输出投递异常报警信息。
在一些可能的实施方式中，当事务型消息投递成功之后进行事务型消息的回调，并根据回调状况维护事务型消息的回调记录，包括：
当事务型消息投递成功时，将回调状态标识位置为指示待投递；
或者，
根据消息回调的业务方的回调响应，确定事务型消息是否回调成功；
在事务型消息回调失败时，将回调状态标识位置为指示待补偿；
在事务型消息回调成功时，将回调状态标识位置为指示已回调。
在一些可能的实施方式中，进行事务型消息的回调，还包括：
当事务型消息回调失败后，基于回调补偿策略确定回调补偿参数，其中，补偿回调参数包括：最大补偿回调次数和/或下一次补偿回调时刻；
根据补偿回调参数，重新回调事务性消息。
在一些可能的实施方式中，方法还包括：
事务型消息的回调次数大于补偿策略的最大补偿回调次数时，输出回调异常报警信息。
在一些可能的实施方式中，投递补偿策略与回调补偿策略为预定义的补偿策略中任一种补偿策略，补偿策略包括以下至少之一：
第一补偿策略，在第一预设时长内限定补偿次数M；M为正整数；
第二补偿策略，在第二预设时长内每间隔第三预设时长进行Y次补偿；Y为根据X和在第二预设时长内间隔的第三预设时长的个数Z确定的；其中，第三预设时长小于第二预设时长；X为间隔首个第三个预设时长之后补偿次数；
第三补偿策略，在第四预设时长内每隔第五预设时长进行一次补偿。
在一些可能的实施方式中，方法还包括：
监控通知服务的消息投递以及回调的状况信息；
根据状况信息，生成通知服务进行消息投递和/或回调的统计数据；其中，统计数据，用于确定通知服务的运行状况。
在一些可能的实施方式中，方法还包括：
根据第一设备的消息投递负载状况，扩大或缩小分配给通知服务的资源。
在一些可能的实施方式中，根据消息投递负载状况，自动扩大或缩小分配给通知服务的资源，包括：
当消息投递负载率大于第一阈值时，扩大分配给通知服务的资源；
或者，
当消息投递负载低于第二阈值时，缩小分配给通知服务的资源；
其中，第二阈值低于第一阈值。
第二方面，本申请提供一种消息处理装置，可以应用于包含通知服务的第一设备，包括用于实施第一方面的任意一种方法的若干个功能单元。消息处理装置可以包括：
通知服务模块，用于接收并存储业务方发送的事务型消息；
投递模块，用于进行事务型消息的投递，并根据事务型消息的投递状况维护消息投递记录；
回调模块，用于当事务型消息投递成功之后进行事务型消息的回调，并根据回调状况维护事务型消息的回调记录。
在一些可能的实施方式中，事务型消息携带的参数至少包括：事务型消息涉及的业务码以及业务方的业务方标识；
投递模块，具体用于根据投递状况，生成同时与业务码和业务方标识对应的投递记录，其中，投递记录至少包括：指示是否已投递的投递状态标识位；
回调模块，具体用于根据回调状况，生成同时与业务码和业务方标识对应的回调记录，其中，回调记录至少包括：指示已回调的回调状态标识位。
在一些可能的实施方式中，投递记录还指示一下至少之一：
已投递次数；
已投递时刻；
重复投递次数；
下一次重复投递时刻；
和/或，
回调记录还指示以下至少之一：
已回调次数；
已回调时刻；
重复回调次数。
在一些可能的实施方式中，事务型消息携带的参数还包括以下之一：
投递地址；
回调地址；
补偿策略信息，用于投递失败时确定再次投递的投递补偿参数，和/或，用于回调失败时确定再次回调的回调补偿参数。
在一些可能的实施方式中，投递模块，具体用于：
在尚未进行事务型消息的首次投递时，将投递状态标识位置为指示待投递；
或者，
根据消息投递的关联业务方的投递响应的接收状况，确定事务型消息是否投递成功；
在事务型消息投递失败时，将投递状态标识位置为指示待补偿；
在事务型消息投递成功时，将投递状态标识位置为指示已投递。
在一些可能的实施方式中，投递模块，具体用于：
在事务型消息投递失败时，基于投递补偿策略确定补偿投递参数；其中，补偿投递参数包括：最大补偿投递次数和/或下一次补偿投递时刻；
根据补偿投递参数，重新投递事务型消息。
在一些可能的实施方式中，装置还包括：
异常报警模块，用于当事务型消息投递的次数大于补偿策略的最大补偿次数后，输出投递异常报警信息。
在一些可能的实施方式中，回调模块，具体用于：
当事务型消息投递成功时，将回调状态标识位置为指示待投递；
或者，
根据消息回调的业务方的回调响应，确定事务型消息是否回调成功；
在事务型消息回调失败时，将回调状态标识位置为指示待补偿；
在事务型消息回调成功时，将回调状态标识位置为指示已回调。
在一些可能的实施方式中，回调模块，具体用于：
当事务型消息回调失败后，基于回调补偿策略确定回调补偿参数，其中，补偿回调参数包括：最大补偿回调次数和/或下一次补偿回调时刻；
根据补偿回调参数，重新回调事务性消息。
在一些可能的实施方式中，异常报警模块，还用于事务型消息的回调次数大于补偿策略的最大补偿回调次数时，输出回调异常报警信息。
在一些可能的实施方式中，投递补偿策略与回调补偿策略为预定义的补偿策略中任一种补偿策略，补偿策略包括以下至少之一：
第一补偿策略，在第一预设时长内限定补偿次数M；M为正整数；
第二补偿策略，在第二预设时长内每间隔第三预设时长进行Y次补偿；Y为根据X和在第二预设时长内间隔的第三预设时长的个数Z确定的；其中，第三预设时长小于第二预设时长；X为间隔首个第三预设时长之后补偿次数；
第三补偿策略，在第四预设时长内每隔第五预设时长进行一次补偿。
在一些可能的实施方式中，装置还包括：
监控模块，用于监控通知服务的消息投递以及回调的状况信息；
数据统计模块，用于根据状况信息，生成通知服务进行消息投递和/或回调的统计数据；其中，统计数据，用于确定通知服务的运行状况。
在一些可能的实施方式中，装置还包括：资源分配模块，用于据第一设备的消息投递负载状况，扩大或缩小分配给通知服务的资源。
在一些可能的实施方式中，资源分配模块，具体用于：
当消息投递负载率大于第一阈值时，扩大分配给通知服务的资源；
或者，
当消息投递负载低于第二阈值时，缩小分配给通知服务的资源；
其中，第二阈值低于第一阈值。
第三方面，本申请还提供一种电子设备，包括：
用于存储处理器可执行指令的存储器；
处理器；其中，处理器被配置为：用于执行可执行指令时，实现如第一方面及其可能的实施方式的方法。
第四方面，本申请提供了一种计算机可读存储介质，计算机可读存储介质存储有可执行程序，其中，可执行程序被处理器执行时实现如第一方面及其可能的实施方式的方法。
本申请实施例提供的技术方案与现有技术相比存在的有益效果是：
在本申请中，通知服务接收并存储业务方发送的事务型消息，进行事务型消息的投递，并根据事务型消息的投递状况维护消息投递记录，当事务型消息投递成功之后进行事务型消息的回调，并根据回调状况维护事务型消息的回调记录。如此，业务方的事务型事件消息全部落地存储于数据库服务器，实现可回溯的同时，解决因消息丢失造成数据不一致问题，保证数据安全。各业务的补偿业务抽象到通知服务中统一调度统一处理，解耦并简化各个业务逻辑，同时将事务型消息接收、通知处理、补偿、回调内聚到通知服务，真正实现高内聚低耦合，极大节约和降低服务器成本。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。
图1是本申请实施例中的一种消息处理方法的实施例流程示意图。
图2是本申请实施例的系统架构示意图。
图3是本申请实施例提供的消息处理方法流程示意图。
图4是本申请实施例中自动扩大或缩小分配给通知服务资源的实现效果图。
图5是本申请实施例中的一种消息处理装置的结构示意图。
图6是本申请实施例中的一种电子设备结构示意图。
具体实施方式
以下描述中，参考形成本申请一部分并以说明之方式示出本申请实施例的具体方面或可使用本申请实施例的具体方面的附图。应理解，本申请实施例可在其它方面中使用，并可包括附图中未描绘的结构或逻辑变化。因此，以下详细描述不应以限制性的意义来理解，且本申请的范围由所附权利要求书界定。例如，应理解，结合所描述方法的揭示内容可以同样适用于用于执行所述方法的对应设备或装置，且反之亦然。例如，如果描述一个或多个具体方法步骤，则对应的设备可以包含如功能单元等一个或多个单元，来执行所描述的一个或多个方法步骤(例如，一个单元执行一个或多个步骤，或多个单元，其中每个都执行多个步骤中的一个或多个)，即使附图中未明确描述或说明这种一个或多个单元。另一方面，例如，如果基于如功能单元等一个或多个单元描述具体装置，则对应的方法可以包含一个步骤来执行一个或多个单元的功能性(例如，一个步骤执行一个或多个单元的功能性，或多个步骤，其中每个执行多个单元中一个或多个单元的功能性)，即使附图中未明确描述或说明这种一个或多个步骤。进一步，应理解的是，除非另外明确提出，本文中所描述的各示例性实施例和/或方面的特征可以相互组合。
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
图1为本申请实施例提供的一种消息处理方法的实施例流程示意图，该方法由包含通知服务的第一设备执行。第一设备可以是进行消息处理的计算机设备，可以是服务器，服务器可以用独立的服务器或多个物理服务器组成的服务器集群来实现。第一设备所处的网络包括但不限于互联网、广域网、城域网、局域网、虚拟专用网络(Virtual PrivateNetwo rk，VPN)等。
参见图1所示，本申请实施例提供的一种消息处理方法可以包括：
S101，通知服务接收并存储业务方发送的事务型消息；
S102，进行事务型消息的投递，并根据事务型消息的投递状况维护消息投递记录；
S103，当事务型消息投递成功之后进行事务型消息的回调，并根据回调状况维护事务型消息的回调记录。
事务(transaction)是一个程序执行单元，一组业务整体处理的行为叫一个事务，通常根据该业务的业务处理逻辑进行处理，在处理过程中通过生成事务消息与服务器进行通信。一个事务有四个基本特性，也就是ACID，即原子性(atomicity，或称不可分割性)、一致性(consistency)、隔离性(isolation，又称独立性)、持久性(durability)。
基于事务产生的消息，即为前述事务型消息。
业务方，又可称事务发起者节点，在分布式事务中，可以将分布式事务视为一个全局事务，每个全局事务至少包括一项应用服务，每个应用服务可以交给一个节点服务器来进行，其中，发起全局事务的节点服务器称为事务发起者。
在一个实施例中，业务方的数量可以是多个，通知服务可以同时接收多个业务方发送的事务型消息，并将接收到的所有事务型消息存储在数据库服务器中。上述第一设备可以通过提供单独的业务接口，各业务方通过调用该业务接口实现事务型消息的发送。设备在接收到事务型消息后，可暂时不做业务逻辑处理，而是将事务型消息直接写入数据库服务器中。
本申请实施例中，通知服务同时接收到多个业务方发送的事务型消息后暂停业务逻辑处理，直接将事务型消息写入数据库服务器中，能够做到对事务型消息进行快速接收并写入，针对各业务方而言，只需要将要处理的事务型消息发送出去即可，而不用一直等待事务型消息处理完成之后返回结果，提高了接收事务型消息的效率。
在一个实施例中，通知服务接收到事务型消息后，在未进行任何业务逻辑处理之前可直接向对应业务方发送确认接收消息。
可以理解的，通知服务快速接收各业务方发送的事务型消息，但若是存在网络故障等情况下，通知服务可能存在未接收到消息的情况，造成消息的丢失。因此，通知服务接收到消息后，向发送该消息的业务方返回确认接收消息，可以告知发送消息的业务方哪些消息已被接收，业务方则可基于是否收到确认消息判断是否需要对该事务型消息重新发送，避免因网络故障等原因造成的消息丢失。
在一个实施例中，事务型消息携带的参数至少包括：事务型消息涉及的业务码以及业务方的业务方标识。
业务码，是业务方注册的身份标识，业务方发送事务型消息之前，可以先进行业务码注册，为后续的交互提供基本的身份认证。各业务方只需注册一个业务码，即可方便维护和管理各业务方。业务方标识，是业务方自身标识，业务码和业务方标识单独或者两者组合起来，都可构成对应业务方的唯一标识。
在本申请实施例中，通知服务在接收到事务型消息后，会将事务型消息传输给目的接收方，从而实现事务型消息的投递。为了确保投递成功，在完成一次投递之后，会及时根据事务型消息的投递状况维护消息投递记录。
在一个实施例中，根据事务型消息的投递状况维护消息投递记录，可以是根据投递状况，生成同时与业务码和业务方标识对应的投递记录。投递记录至少包括指示是否已投递的投递状态标识位。
示例性的，在接收并存储事务型消息后，也就是在尚未进行事务型消息的首次投递时，将事务型消息的投递状态标识位置为待投递。
应理解的，对事务型消息的投递必然存在两种结果信息，消息投递失败或消息投递成功。因此，将事务型消息投递后还需要确定事务型消息是否投递成功。
在一个实施例中，通知服务根据消息投递的关联业务方的投递响应的接受状况，确定事务型消息是否投递成功。
示例性的，在事务型消息投递至关联业务方后，关联业务方返回应答消息，若通知服务接收到关联业务方发送的应答消息，则证明事务型消息投递成功，此时，将投递状态标识位置为已投递。若通知服务没有接收到应答消息，则说明事务型消息投递失败，将投递状态标识位置为待补偿。
在一个实施例中，可以通过判断在预设时长内是否接收到关联业务方发送的应答消息，确定事务型消息投递是否投递成功。
预设时长可以是根据事先设定的最大等待时长确定的，也可以是基于历史投递记录所用时长确定，例如，预设时长可以是历史消息投递记录中投递消息后接收到应答消息的最大时长。
对事务型消息进行投递时，若事务型消息投递失败，为保证该事务型消息的最终一致性，可以重新对该事务型消息进行投递。基于此，上述方法还可以包括：
在事务型消息投递失败时，基于投递补偿策略确定补偿投递参数；
根据补偿投递参数，重新投递事务型消息。
在一个实施例中，投递补偿参数可以是最大补偿次数。那么，根据补偿投递参数，重新投递事务型消息可以是：每当通知服务确定事务型消息投递失败，立即发起对该事务型消息的重新投递，直到达到最大补偿次数后不再重新发起补偿。
在另一个实施例中，根据最大补偿次数重新投递事务型消息还可以是，在事务型消息投递失败时，通知服务检测当前所处网络状态，若当前网络状态处于拥堵状态，暂不进行事务型消息的重新投递，待当前网络状态未存在拥堵时发起对事务型消息的重新投递，直到达到最大补偿次数后不再重新发起补偿。
在一个实施例中，投递参数可以是下一次补偿投递时刻。那么根据补偿投递参数，重新投递事务型消息可以是：通知服务首先确定可以进行投递补偿的最大时长，在确定事务型消息投递失败时，通知服务在最大时长内，确定重新发起下一次投递事务型消息的时刻。例如，可以是以固定频率重试投递，即通知服务每次发起补偿间隔相同的时间，直到到达投递补偿的最大时长。或者也可以是在最大时长内，补偿次数随时间递增或递减，例如在每次补偿后，间隔乘一个固定指数的时间间隔后进行下一次补偿。
在另一个实施例中，投递补偿参数还可以是同时包括最大补偿次数和下一次补偿投递时刻。那么根据补偿投递参数，重新投递事务型消息可以是：通知服务首先确定可以进行投递补偿的最大时长，在最大时长内发起最大补偿次数的补偿。例如，可以是在最大时长内间隔相同时间发起最大补偿次数补偿，或者也可以是在最大时长内，补偿次数随时间递增或者递减，例如每次补偿后，间隔乘一个固定指数的时间间隔后进行下一下补偿，直到达到最大补偿次数。
本申请实施例中，在事务型消息投递失败时，通知服务基于补偿策略确定补偿参数，根据补偿参数，重新对事务型消息进行投递，保证了事务型消息投递过程中的可靠触达。同时，在实际进行投递补偿过程中，如果只要确定投递事务型消息失败，就一直进行重新投递，那么，若是存在部分事务型消息一直投递失败的情况，会导致事务型消息一直处在投递、重新投递的过程中，事务型消息对应的所要执行的事务会一直无法得到处理，同时，不断的重新投递还会一直占用计算资源。因此，在本申请实施例中，设置最大补偿次数和/或最大补偿时间，进一步避免了发生事务型消息无休止重新投递的情况。
在一个可选的实施例中，投递补偿策略可以是各业务方预置的默认补偿策略，默认补偿策略可以直接内置于事务型消息携带的参数中。
在另一个可选的实施例中，通知服务可以内置多个可选的补偿策略。投递补偿策略可以是基于事务型消息携带的对应业务方的补偿策略标识，从通知服务中内置的补偿策略中确定的投递补偿策略。或者也可以是通知服务基于分配策略分别给接收到的每个事务型消息分配投递补偿策略。例如，分配策略可以是随机分配，通知服务基于随机分配原则，分别为各事务型消息从内置的多个补偿策略中随机分配一补偿策略作为投递补偿策略。
基于此，在一个实施例中，事务型消息携带的参数还可以包括以下之一：
投递地址；即事务型消息投递的关联业务方的目标地址，可以是关联业务方对应的IP地址，也可以是MAC地址等具有构成关联业务方的唯一标识的信息。
补偿策略信息；用于投递失败时确定进行再次投递的补偿投递参数。
其中，上述补偿策略可以包括以下至少之一：
第一补偿策略，在第一预设时长内限定补偿次数M；所述M为正整数。
可以理解的，第一补偿策略为固定重试次数补偿，只需要在最大补偿时间内重试预设次数。可以是以固定时间间隔补偿，或者也可以是基于当前网络状态确定是否发起补偿，知道最大补偿次数。例如，第一预设时间为4个小时，M等于10。那么此时第一补偿策略为在四个小时内进行10次补偿。
第二补偿策略，在第二预设时长内每间隔第三预设时长进行Y次补偿；Y为根据X和在第二预设时长内间隔的第三预设时长的个数Z确定的；其中，第三预设时长小于第二预设时长；X为间隔首个第三个预设时长之后补偿次数.
可以理解的，第二补偿策略可以基于时间顺序调整补偿次数。例如，第二预设时长为24个小时，第三预设时长为1个小时，Y＝XZ，X＝4。那么此时第二补偿策略为24个小时内，第一个小时补偿四次，之后每次补偿4的Z+1指数次。
第三补偿策略，在第四预设时长内每隔第五预设时长进行一次补偿。
可以理解的，第三补偿策略为固定频率重试补偿，在最大补偿时间内以固定时间间隔进行补偿。例如，第四预设时长为24个小时，第五预设时长为10分钟，那么此时第三补偿策略为在24个小时内，每10分钟进行一次补偿。
在基于上述补偿策略进行投递补偿时，每进行一次补偿，都需要确定进行投递记录的更新维护，因此，在一个实施例中，上述投递记录还指示以下至少之一：
已投递次数；
已投递时刻；
重复投递次数；
下一次重复投递时刻。
在一个可选的实施例中，上述方法还可以包括：
当事务型消息投递的次数大于补偿策略的最大补偿次数后，输出投递异常报警信息。
示例性的，以补偿策略为上述第三补偿策略为例，在补偿策略的时限内，最后一次进行补偿后，若通知服务仍未收到关联业务方发送的应答消息，则输出投递异常报警信息。
在另一个实施例中，上述方法还可以是：投递事务型消息的时间大于补偿策略的最大补偿时间后，输出投递异常报警信息。
在一个可选的实施例中，输出的投递异常报警信息可以是以弹窗文字消息的形式显示在设备的显示界面上。
在另一个可选的实施例中，输出的投递异常报警信息也可以是以播放报警提示音的形式输出。
在另一个可选的实施例中，输出的投递异常报警信息还可以是以文字和声音两种方式同时进行输出报警信息。
在一个实施例中，通知服务输出报警信息后，上述方法还包括：基于管理人员的操作，在设备的显示界面上显示异常异常发生的位置以及相关记录信息。用于方便管理人员解决及时定位异常发生的原因，有助于异常的快速解决。
本申请实施例中，通知服务在事务型消息投递成功之后，会将关联业务方的应答结果传输回对应业务方，从而试下事务型消息的回调，为了确保回调成功，在完成一次回调之后，会及时并根据回调状况维护事务型消息的回调记录。
在一个实施例中，根据事务型消息的回调状况维护消息回调记录，可以是根据回调状况，生成同时与业务码和业务方标识对应的回调记录。回调记录至少包括指示是否已回调的回调状态标识位。
示例性的，在事务型消息投递成功之后且在完成回调之前，将事务型消息的回调状态标识位置为待回调。
应理解的，对事务型消息的回调必然存在两种结果信息，消息回调失败或消息回调成功。因此，回调事务型消息后还需要确定事务型消息是否回调成功。：
根据消息回调的业务方的回调响应的接收状况，确定事务型消息是否回调成功。
示例性的，在事务型消息回调至业务方后，业务方返回应答消息，若通知服务接收到业务方发送的应答消息，则证明事务型消息回调成功，此时，将回调状态标识位置为已回调。若通知服务没有接收到应答消息，说明事务型消息回调失败，将回调状态标识位置为待补偿。
在一个实施例中，可以通过判断在预设时长内是否接收到业务方发送的应答消息，确定事务型消息是否回调成功。
预设时长可以是根据事先设定的最大等待时长确定的，也可以是基于历史回调记录所用时长确定，例如，预设时长可以是历史消息回调记录中回调消息后接收到应答消息的最大时长。
对事务型消息进行回调时，若事务型消息回调失败，为保证该事务型消息的最终一致性，可以重新进行该事务型消息的回调。基于此，在一个实施例中，上述方法还可以包括：
在事务型消息回调失败时，基于回调补偿策略确定补偿回调参数；
根据补偿回调参数，重新回调事务型消息。
在一个实施例中，回调补偿参数可以是最大补偿次数。那么，根据补偿回调参数，重新回调事务型消息可以是：每当通知服务确定事务型消息回调失败，立即发起对该事务型消息的重新回调，直到达到最大补偿次数后不再重新发起补偿。
在另一个实施例中，根据最大补偿次数重新回调事务型消息还可以是，在事务型消息回调失败时，通知服务检测当前所处网络状态，若当前网络状态处于拥堵状态，暂不进行事务型消息的重新回调，待当前网络状态未存在拥堵时发起对事务型消息的重新回调，直到达到最大补偿次数后不再重新发起补偿。
在一个实施例中，回调参数可以是下一次补偿回调时刻。那么根据补偿回调参数，重新回调事务型消息可以是：通知服务首先确定可以进行回调补偿的最大时长，在确定事务型消息回调失败时，通知服务在最大时长内，确定重新发起下一次回调事务型消息的时刻。例如，可以是以固定频率重试回调，即通知服务每次发起补偿间隔相同的时间，直到到达回调补偿的最大时长。或者也可以是在最大时长内，补偿次数随时间递增或递减，例如在每次补偿后，间隔乘一个固定指数的时间间隔后进行下一次补偿。
在另一个实施例中，回调补偿参数还可以是同时包括最大补偿次数和下一次补偿回调时刻。那么根据补偿回调参数，重新回调事务型消息可以是：通知服务首先确定可以进行回调补偿的最大时长，在最大时长内发起最大补偿次数的补偿。例如，可以是在最大时长内间隔相同时间发起最大补偿次数补偿，或者也可以是在最大时长内，补偿次数随时间递增或者递减，例如每次补偿后，间隔乘一个固定指数的时间间隔后进行下一下补偿，直到达到最大补偿次数。
本申请实施例中，在事务型消息回调失败时，通知服务基于补偿策略确定补偿参数，根据补偿参数，重新对事务型消息进行回调，保证了事务型消息回调过程中的可靠触达。同时，在实际进行回调补偿过程中，如果只要确定回调事务型消息失败，就一直进行重新回调，那么，若是存在部分事务型消息一直回调失败的情况，会导致事务型消息一直处在回调、重新回调的过程中，事务型消息对应的所要执行的事务会一直无法得到处理，同时，不断的重新回调还会一直占用计算资源。因此，在本申请实施例中，设置最大补偿次数和/或最大补偿时间，进一步避免了发生事务型消息无休止重新回调的情况。
在一个可选的实施例中，回调补偿策略可以是各业务方预置的默认补偿策略，默认补偿策略可以直接内置于事务型消息携带的参数中。
在另一个可选的实施例中，通知服务可以内置多个可选的补偿策略。回调补偿策略可以是基于事务型消息携带的对应业务方的补偿策略标识，从通知服务中内置的补偿策略中确定的回调补偿策略。或者也可以是通知服务基于分配策略分别给接收到的每个事务型消息分配回调补偿策略。例如，分配策略可以是随机分配，通知服务基于随机分配原则，分别为各事务型消息从内置的多个补偿策略中随机分配一补偿策略作为回调补偿策略。
在一个实施例中，事务型消息携带的参数还可以包括以下之一：
回调地址；用于事务型消息回调的业务方目标地址，可以是业务方对应的IP地址或者MAC地址等业务方具有的唯一标识的信息。
补偿策略信息，用于回调失败时的再次回调参数。
其中，上述补偿策略可以包括以下至少之一：
第一补偿策略，在第一预设时长内限定补偿次数M；所述M为正整数；
可以理解的，第一补偿策略为固定重试次数补偿，只需要在最大补偿时间内重试预设次数。可以是以固定时间间隔补偿，或者也可以是基于当前网络状态确定是否发起补偿，知道最大补偿次数。例如，第一预设时间为4个小时，M等于10。那么此时第一补偿策略为在四个小时内进行10次补偿。
第二补偿策略，在第二预设时长内每间隔第三预设时长进行Y次补偿；所述Y为根据所述X和在所述第二预设时长内间隔的第三预设时长的个数Z确定的；其中，所述第三预设时长小于所述第二预设时长；所述X为间隔首个所述第三个预设时长之后补偿次数；
可以理解的，第二补偿策略可以基于时间顺序调整补偿次数。例如，第二预设时长为24个小时，第三预设时长为1个小时，Y＝XZ，X＝4。那么此时第二补偿策略为24个小时内，第一个小时补偿四次，之后每次补偿4的Z+1指数次。
第三补偿策略，在第四预设时长内每隔第五预设时长进行一次补偿。
可以理解的，第三补偿策略为固定频率重试补偿，在最大补偿时间内以固定时间间隔进行补偿。例如，第四预设时长为24个小时，第五预设时长为10分钟，那么此时第三补偿策略为在24个小时内，每10分钟进行一次补偿。
在一个可选的实施例中，上述方法还可以包括：
当事务型消息回调的次数大于补偿策略的最大补偿次数后，输出回调异常报警信息。
示例性的，以补偿策略为上述第三补偿策略为例，在补偿策略的时限内，最后一次进行补偿后，若通知服务仍未收到业务方发送的应答消息，则输出回调异常报警信息。
在另一个实施例中，上述方法还可以是：回调事务型消息的时间大于补偿策略的最大补偿时间后，输出投递异常报警信息。
在一个可选的实施例中，输出回调异常报警信息可以是以弹窗文字消息的形式显示在设备的显示上。
在另一个可选的实施例中，输出回调异常报警信息也可以是以播放报警提示音的形式输出。
在另一个可选的实施例中，输出回调异常报警信息还可以是以文字和声音两种方式同时进行输出的报警信息。
在一个实施例中，通知服务输出报警信息后，上述方法还包括：基于管理人员的操作，在设备的显示界面上显示异常异常发生的位置以及相关记录信息。用于方便管理人员解决及时定位异常发生的原因，有助于异常的快速解决。
本申请实施例中，业务方只需注册一个业务码，同时方便维护和管理各个业务方，业务方的事务型事件消息全部落地存储于数据库服务器，实现可回溯。同时，事务型消息存储在数据库服务器，解决因消息丢失造成数据不一致问题，保证数据安全，各业务的补偿业务抽象到本系统里统一调度统一处理，解耦并简化各个业务逻辑，同时将事务型消息接收、通知处理、补偿、回调内聚到本系统里，真正实现高内聚低耦合，极大节约和降低服务器成本。
在一个实施例中，上述方法还可以包括：
监控通知服务的消息投递以及回调的状况信息；
根据状况信息，生成通知服务进行消息投递和/或回调的统计数据；其中，统计数据，用于确定通知服务的运行状况。
在一个实施例中，通过实时监控各个业务方和关联业务方的关键指标，以及系统整体的各个组件的关键指标确定消息投递以及回调的状况信息。
示例性的，关键指标包括但不限于中央处理器(central processing unit，CPU)、内存、网卡、线程、java虚拟机(Java Virtual Machine，JVM)信息、每秒查询率(Querie s-per-second，QPS)、应答码、耗时、系统异常、应答异常等关键指标的信息。
在一个实施例中，上述方法还可以包括：根据统计数据确定通知服务的运行状况，若通知服务的运行状况信息超出预设阈值，则输出告警信息用于告知系统管理人员。
示例性的，获取到上述统计数据后，可以基于统计的各个组件的关键指标数据分析系统的整体运行状况，当系统整体的运行状况信息超出预设阈值时输出告警信息。或者也可以是分别针对各个组件设置预设阈值，当各个组件的指标信息存在超出各自预设阈值时，输出针对不同组件的告警信息。
本申请实施例通过实时监控各个业务方和关联业务方的关键指标，以及系统的各个组件和和关键指标，确定通知服务中投递状况信息和回调状况信息，进而确定通知服务的运行状况，如存在问题第一时间可以发出告警通知，保证本系统高可靠。
在一个实施例中，上述方法还可以包括：
根据第一设备的消息投递负载状况，自动扩大或缩小分配给通知服务的资源。
具体的，根据上述统计的CPU、内存、网卡、线程、JVM信息、QPS等信息分析消息投递负载状况，当消息投递负载率大于第一阈值时，扩大分配给通知服务的资源；当消息投递负载低于第二阈值时，缩小分配给通知服务的资源；其中，第二阈值低于第一阈值。
示例性的，以CPU和内存使用率超过或低于预设阈值的策略进行自动扩缩容为例。当并发比较高，CPU超过预设阈值例如70％，或内存使用率超过预设阈值例如80％触发自动扩容，以保证本系统高效高速运行，随着压力的减轻CPU和内存指标降低，系统会开始缩容，逐步缩回到常规节点数例如10个节点。这样既保证系统高可用，又灵活实现最低成本系统高效运行。
下面结合一个优选的实施例，对上述实施例涉及到的内容进行说明。
图2为本申请实施例的系统架构示意图，参见图2所示，通知服务将消息的接受、投递、回调内聚至一个系统中，发送消息的业务方可以是多个，通知服务同时快速接收多个业务方发送的事务型消息，通过消息接收、消息投递、补偿、消息回调，就可轻松实现事务型消息的最终一致，并且整个过程业务方无感知。
以第一设备为执行本申请实施例所述方法的事务型消息通知系统为例，图3为本申请实施例提供的消息处理方法流程示意图，参见图3所示：
系统内可内置多种补偿策略，补偿策略可以包括一下至少之一：
第一补偿策略，在第一预设时长内限定补偿次数M；M为正整数。
示例性的，第一预设时间为4个小时，M等于10。那么此时第一补偿策略为在四个小时内进行10次补偿。
第二补偿策略，在第二预设时长内每间隔第三预设时长进行Y次补偿；Y为根据X和在第二预设时长内间隔的第三预设时长的个数Z确定的；其中，第三预设时长小于第二预设时长；X为间隔首个第三个预设时长之后补偿次数。
示例性的，第二预设时长为24个小时，第三预设时长为1个小时，Y＝XZ，X＝4。那么此时第二补偿策略为24个小时内，第一个小时补偿四次，之后每次补偿4的Z+1指数次。
第三补偿策略，在第四预设时长内每隔第五预设时长进行一次补偿。
示例性的，第四预设时长为24个小时，第五预设时长为10分钟，那么此时第三补偿策略为在24个小时内，每10分钟进行一次补偿。
业务方接入前，通过注册一个业务码作为身份标识，为后续的系统交互提供基本身份认证。
业务方发送的事务型消息可以携带如下表1所示参数，投递状态默认为待投递，设备快速写入事务型消息，此时不做任何业务逻辑处理，快速返回确认消息，以提高吞吐量和并发。
Figure BDA0003606554040000171
表1
设备基于各业务方携带参数对应的投递补偿策略和投递状态标识位进行事务型消息的投递，将状态标识位为待投递的事务型消息投递至投递目标地址也就是关联业务方，并同步等待关联业务方接收到事务型消息后发送的应答消息。系统基于是否收到应答消息和补偿策略确定是否重新投递，直到投递成功将投递状态标识为置为指示已投递或者超出补偿策略最大补偿时间或最大补偿次数后输出告警信息。事务型消息投递过程中维护消息投递记录，包括：每次投递的投递状态标识位的更新、已投递次数、已投递时刻、重复投递次数、下一次重复投递时刻等信息。
其中，系统向关联业务方投递事务型消息可以携带如表2所示参数。
Figure BDA0003606554040000181
表2
根据上述步骤完成消息投递之后，将投递状态标识位置为已投递的消息的回调状态标识位置为待回调。系统基于各业务方携带参数对应的回调补偿策略和回调状态标识位进行事务型消息的回调，将状态标识位为待回调的事务型消息回调至回调目标地址也就是发送该事务型消息的业务方，并同步等待业务方接收到消息后发送的应答消息。系统基于是否收到应答消息和补偿策略确定是否重新回调，直到回调成功将回调状态标识位置为指示已回调或者超出补偿策略最大补偿时间或最大补偿次数后输出告警信息。回调过程中维护消息回调记录，包括：每次回调的回调状态标识位的更新、已回调次数、已回调时刻、重复回调次数、下一次重复回调时刻等信息。
其中，系统向业务方回调消息可以携带如表3所示参数。
Figure BDA0003606554040000182
Figure BDA0003606554040000191
表3
同时，系统实时监控各个业务方和关联业务方的关键指标，以及系统整体的各个组件和关键指标确定消息投递以及回调的状况信息，包括CPU、内存、网卡、线程、JVM信息，QPS、应答码、耗时、系统异常、应答异常等关键指标的信息。
示例性的，通过监控系统例如Prometheus收集CPU、内存、网卡、线程、JVM信息、QPS、RPS等信息，通过日志采集工具例如Filebeat收集应答码、耗时、系统异常、应答异常等的指标日志信息。
系统根据采集到的上述组件的关键指标信息，分析确定系统的整体运行状态信息，当超出预设阈值时，发出告警提示音和/或告警文字提示。
另外，系统根据消息投递负载状况，自动扩大或缩小分配给通知服务的资源。如图4所示，图4为本申请实施例中自动扩大或缩小分配给通知服务资源的实现效果图。
示例性的，系统根据获取到的CPU、内存、网卡、线程、JVM信息、QPS等指标信息分析消息投递负载状况，例如以CPU和内存使用率超过或低于预设阈值的策略进行自动扩缩容为例。当并发比较高，CPU超过预设阈值例如70％，或内存使用率超过预设阈值例如80％触发自动扩容，以保证本系统高效高速运行，随着压力的减轻CPU和内存指标降低，系统会开始缩容，逐步缩回到常规节点数例如10个节点。
本申请实施例中，通知服务接收并存储业务方发送的事务型消息，进行事务型消息的投递，并根据事务型消息的投递状况维护消息投递记录，当事务型消息投递成功之后进行事务型消息的回调，并根据回调状况维护事务型消息的回调记录。如此，业务方不再依赖传统消息队列和补偿策略，只需注册一个业务码，同时方便维护和管理各个业务方，业务方的事务型事件消息全部落地存储于数据库服务器，实现可回溯。同时，事务型消息存储在数据库服务器，解决因消息丢失造成数据不一致问题，保证数据安全，各业务的补偿业务抽象到本系统里统一调度统一处理，解耦并简化各个业务逻辑，同时将事务型消息接收、通知处理、补偿、回调内聚到本系统里，真正实现高内聚低耦合，极大节约和降低服务器成本。另外，本申请对各个组件和关键指标增加监控，可以根据高峰期和低峰期压力情况灵活实现自动伸缩，合理有效利用资源。
基于相同的发明构思，本申请实施例提供一种消息处理装置，可以应用于包含通知服务的第一设备，该消息处理装置包括用于实施上述消息处理方法的若干个功能单元。
图5为本申请实施例中的一种消息处理装置的结构示意图，参见图5所示，该消息处理装置500可以包括：
通知服务模块501，用于接收并存储业务方发送的事务型消息；
投递模块502，用于进行事务型消息的投递，并根据事务型消息的投递状况维护消息投递记录；
回调模块503，用于当事务型消息投递成功之后进行事务型消息的回调，并根据回调状况维护事务型消息的回调记录。
在一些可能的实施方式中，事务型消息携带的参数至少包括：事务型消息涉及的业务码以及业务方的业务方标识；
投递模块502，具体用于根据投递状况，生成同时与业务码和业务方标识对应的投递记录，其中，投递记录至少包括：指示是否已投递的投递状态标识位；
回调模块503，具体用于根据回调状况，生成同时与业务码和业务方标识对应的回调记录，其中，回调记录至少包括：指示已回调的回调状态标识位。
在一些可能的实施方式中，投递记录还指示一下至少之一：
已投递次数；
已投递时刻；
重复投递次数；
下一次重复投递时刻；
和/或，
回调记录还指示以下至少之一：
已回调次数；
已回调时刻；
重复回调次数。
在一些可能的实施方式中，事务型消息携带的参数还包括以下之一：
投递地址；
回调地址；
补偿策略信息，用于投递失败时的再次投递参数，和/或，用于回调失败时的再次回调参数。
在一些可能的实施方式中，投递模块502，具体用于：
在尚未进行事务型消息的首次投递时，将投递状态标识位置为指示待投递；
或者，
根据消息投递的关联业务方的投递响应的接收状况，确定事务型消息是否投递成功；
在事务型消息投递失败时，将投递状态标识位置为指示待补偿；
在事务型消息投递成功时，将投递状态标识位置为指示已投递。
在一些可能的实施方式中，投递模块502，具体用于：
在事务型消息投递失败时，基于投递补偿策略确定补偿投递参数；其中，补偿投递参数包括：最大补偿投递次数和/或下一次补偿投递时刻；
根据补偿投递参数，重新投递事务型消息。
在一些可能的实施方式中，装置还包括：
异常报警模块，用于当事务型消息投递的次数大于补偿策略的最大补偿次数后，输出投递异常报警信息。
在一些可能的实施方式中，回调模块503，具体用于：
当事务型消息投递成功时，将回调状态标识位置为指示待投递；
或者，
根据消息回调的业务方的回调响应，确定事务型消息是否回调成功；
在事务型消息回调失败时，将回调状态标识位置为指示待补偿；
在事务型消息回调成功时，将回调状态标识位置为指示已回调。
在一些可能的实施方式中，回调模块503，具体用于：
当事务型消息回调失败后，基于回调补偿策略确定回调补偿参数，其中，补偿回调参数包括：最大补偿回调次数和/或下一次补偿回调时刻；
根据补偿回调参数，重新回调事务性消息。
在一些可能的实施方式中，异常报警模块，还用于事务型消息的回调次数大于补偿策略的最大补偿回调次数时，输出回调异常报警信息。
在一些可能的实施方式中，投递补偿策略与回调补偿策略为预定义的补偿策略中任一种补偿策略，补偿策略包括以下至少之一：
第一补偿策略，在第一预设时长内限定补偿次数M；M为正整数；
第二补偿策略，在第二预设时长内每间隔第三预设时长进行Y次补偿；Y为根据X和在第二预设时长内间隔的第三预设时长的个数Z确定的；其中，第三预设时长小于第二预设时长；X为间隔首个第三预设时长之后补偿次数；
第三补偿策略，在第四预设时长内每隔第五预设时长进行一次补偿。
在一些可能的实施方式中，装置还包括：
监控模块，用于监控通知服务的消息投递以及回调的状况信息；
数据统计模块，用于根据状况信息，生成通知服务进行消息投递和/或回调的统计数据；其中，统计数据，用于确定通知服务的运行状况。
在一些可能的实施方式中，装置还包括：资源分配模块，用于据第一设备的消息投递负载状况，扩大或缩小分配给通知服务的资源。
在一些可能的实施方式中，资源分配模块，具体用于：
当消息投递负载率大于第一阈值时，扩大分配给通知服务的资源；
或者，
当消息投递负载低于第二阈值时，缩小分配给通知服务的资源；
其中，第二阈值低于第一阈值。
需要说明的是，通知服务模块501、投递模块502以及回调模块503的具体实现过程可参考图1至图4实施例的详细描述，为了说明书的简洁，这里不再赘述。
基于相同的发明构思，本申请实施例提供一种电子设备，该电子设备可以与上述一个或者多个实施例中所述的消息处理方法一致。图6为本申请实施例中的一种电子设备结构示意图，参见图6所示，电子设备600，可以采用通用的计算机硬件，包括处理器601、存储器602。
在一些可能的实施方式中，至少一个处理器可以构成具有对一个或多个输入执行逻辑运算的电路的任何物理设备。例如，至少一个处理器可以包括一个或多个集成电路(IC)，包括专用集成电路(ASIC)、微芯片、微控制器、微处理器、中央处理单元(CPU)的全部或部分、图形处理单元(GPU)、数字信号处理器(DSP)、现场可编程门阵列(FPGA)或者适于执行指令或执行逻辑运算的其它电路。由至少一个处理器执行的指令可以例如被预加载到与控制器集成的或嵌入在控制器中的存储器中，或者可以存储在分离的存储器中。存储器可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘、光盘、磁介质、闪存，其它永久、固定或易失性存储器，或者能够存储指令的任何其它机制。在一些实施例中，至少一个处理器可以包括多于一个处理器。每个处理器可以具有相似的结构，或者处理器可以具有彼此电连接或断开的不同构造。例如，处理器可以是分离的电路或集成在单个电路中。当使用多于一个处理器时，处理器可以被配置为独立地或协作地操作。处理器可以以电、磁、光学、声学、机械或通过允许它们交互的其它手段来耦合。
基于相同的发明构思，本申请提供一种计算机存储介质，计算机存储介质存储有计算机可执行指令，计算机可执行指令被处理器执行后，能够实现如上述一个或者多个实施例所述的消息处理方法。
本领域技术人员可以理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
以上所述，仅为本申请示例性的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims (30)

1.一种消息处理方法，其特征在于，由包含通知服务的第一设备执行，所述方法包括：
所述通知服务接收并存储业务方发送的事务型消息；
进行所述事务型消息的投递，并根据所述事务型消息的投递状况维护消息投递记录；
当所述事务型消息投递成功之后进行所述事务型消息的回调，并根据回调状况维护所述事务型消息的回调记录。
2.根据权利要求1所述的方法，其特征在于，所述事务型消息携带的参数至少包括：所述事务型消息涉及的业务码以及所述业务方的业务方标识；
所述根据所述事务型消息的投递状况维护消息投递记录，包括：
根据所述投递状况，生成同时与所述业务码和所述业务方标识对应的投递记录，其中，所述投递记录至少包括：指示是否已投递的投递状态标识位；
所述根据回调状况维护所述事务型消息的回调记录，包括：
根据回调状况，生成同时与所述业务码和所述业务方标识对应的回调记录，其中，所述回调记录至少包括：指示已回调的回调状态标识位。
3.根据要求2所述的方法，其特征在于，所述投递记录还指示以下至少之一：
已投递次数；
已投递时刻；
重复投递次数；
下一次重复投递时刻；
和/或，
所述回调记录还指示以下至少之一：
已回调次数；
已回调时刻；
重复回调次数。
4.根据权利要求1至3任一项所述的方法，其特征在于，所述事务型消息携带的参数还包括以下之一：
投递地址；
回调地址；
补偿策略信息，用于投递失败时确定再次投递的投递补偿参数，和/或，用于回调失败时确定再次回调的回调补偿参数。
5.根据权利要求2所述的方法，其特征在于，所述根据所述事务型消息的投递状况维护消息投递记录包括：
在尚未进行所述事务型消息的首次投递时，将所述投递状态标识位置为指示待投递；
或者，
根据消息投递的关联业务方的投递响应的接收状况，确定所述事务型消息是否投递成功；
在所述事务型消息投递失败时，将所述投递状态标识位置为指示待补偿；
在所述事务型消息投递成功时，将所述投递状态标识位置为指示已投递。
6.根据权利要求5所述的方法，其特征在于，所述进行所述事务型消息的投递，包括：
在所述事务型消息投递失败时，基于投递补偿策略确定补偿投递参数；其中，所述补偿投递参数包括：最大补偿投递次数和/或下一次补偿投递时刻；
根据所述补偿投递参数，重新投递所述事务型消息。
7.根据权利要求6所述的方法，其特征在于，所述方法还包括：
当所述事务型消息投递的次数大于所述补偿策略的最大补偿次数后，输出投递异常报警信息。
8.根据权利要求2所述的方法，其特征在于，所述当所述事务型消息投递成功之后进行所述事务型消息的回调，并根据回调状况维护所述事务型消息的回调记录，包括：
当所述事务型消息投递成功时，将所述回调状态标识位置为指示待回调；
或者，
根据消息回调的所述业务方的回调响应，确定所述事务型消息是否回调成功；
在所述事务型消息回调失败时，将所述回调状态标识位置为指示待补偿；
在所述事务型消息回调成功时，将所述回调状态标识位置为指示已回调。
9.根据权利要求8所述的方法，其特征在于，所述进行所述事务型消息的回调，还包括：
当所述事务型消息回调失败后，基于回调补偿策略确定回调补偿参数，其中，所述补偿回调参数包括：最大补偿回调次数和/或下一次补偿回调时刻；
根据所述补偿回调参数，重新回调所述事务性消息。
10.根据权利要求9所述的方法，其特征在于，所述方法还包括：
所述事务型消息的回调次数大于所述补偿策略的最大补偿回调次数时，输出回调异常报警信息。
11.根据权利要求5或8所述的方法，其特征在于，所述投递补偿策略与所述回调补偿策略为预定义的补偿策略中任一种补偿策略，所述补偿策略包括以下至少之一：
第一补偿策略，在第一预设时长内限定补偿次数M；所述M为正整数；
第二补偿策略，在第二预设时长内每间隔第三预设时长进行Y次补偿；所述Y为根据所述X和在所述第二预设时长内间隔的第三预设时长的个数Z确定的；其中，所述第三预设时长小于所述第二预设时长；所述X为间隔首个所述第三个预设时长之后补偿次数；
第三补偿策略，在第四预设时长内每隔第五预设时长进行一次补偿。
12.根据权利要求1所述的方法，其特征在于，所述方法还包括：
监控所述通知服务的消息投递以及回调的状况信息；
根据所述状况信息，生成所述通知服务进行消息投递和/或回调的统计数据；其中，所述统计数据，用于确定所述通知服务的运行状况。
13.根据权利要求1所述的方法，其特征在于，所述方法还包括：
根据所述第一设备的消息投递负载状况，自动扩大或缩小分配给所述通知服务的资源。
14.根据权利要求13所述的方法，其特征在于，所述根据消息投递负载状况，自动扩大或缩小分配给所述通知服务的资源，包括：
当消息投递负载率大于第一阈值时，扩大分配给所述通知服务的资源；
或者，
当消息投递负载低于第二阈值时，缩小分配给所述通知服务的资源；
其中，所述第二阈值低于所述第一阈值。
15.一种消息处理装置，其特征在于，应用于包含通知服务的第一设备，所述装置包括：
通知服务模块，用于接收并存储业务方发送的事务型消息；
投递模块，用于进行所述事务型消息的投递，并根据所述事务型消息的投递状况维护消息投递记录；
回调模块，用于当所述事务型消息投递成功之后进行所述事务型消息的回调，并根据回调状况维护所述事务型消息的回调记录。
16.根据权利要求15所述的装置，其特征在于，所述事务型消息携带的参数至少包括：所述事务型消息涉及的业务码以及所述业务方的业务方标识；
所述投递模块，具体用于根据所述投递状况，生成同时与所述业务码和所述业务方标识对应的投递记录，其中，所述投递记录至少包括：指示是否已投递的投递状态标识位；
所述回调模块，具体用于根据回调状况，生成同时与所述业务码和所述业务方标识对应的回调记录，其中，所述回调记录至少包括：指示已回调的回调状态标识位。
17.根据权利要求16所述的装置，其特征在于，所述投递记录还指示一下至少之一：
已投递次数；
已投递时刻；
重复投递次数；
下一次重复投递时刻；
和/或，
所述回调记录还指示以下至少之一：
已回调次数；
已回调时刻；
重复回调次数。
18.根据权利要求15-17任一项所述的装置，其特征在于，所述事务型消息携带的参数还包括以下之一：
投递地址；
回调地址；
补偿策略信息，用于投递失败时确定再次投递的投递补偿参数，和/或，用于回调失败时确定再次回调的回调补偿参数。
19.根据权利要求16所述的装置，其特征在于：所述投递模块，具体用于：
在尚未进行所述事务型消息的首次投递时，将所述投递状态标识位置为指示待投递；
或者，
根据消息投递的关联业务方的投递响应的接收状况，确定所述事务型消息是否投递成功；
在所述事务型消息投递失败时，将所述投递状态标识位置为指示待补偿；
在所述事务型消息投递成功时，将所述投递状态标识位置为指示已投递。
20.根据权利要求19所述的装置，其特征在于，所述投递模块，具体用于：
在所述事务型消息投递失败时，基于投递补偿策略确定补偿投递参数；其中，所述补偿投递参数包括：最大补偿投递次数和/或下一次补偿投递时刻；
根据所述补偿投递参数，重新投递所述事务型消息。
21.根据权利要求20所述的装置，其特征在于，所述装置还包括：
异常报警模块，用于当所述事务型消息投递的次数大于所述补偿策略的最大补偿次数后，输出投递异常报警信息。
22.根据权利要求16所述的装置，其特征在于，所述回调模块，具体用于：
当所述事务型消息投递成功时，将所述回调状态标识位置为指示待投递；
或者，
根据消息回调的所述业务方的回调响应，确定所述事务型消息是否回调成功；
在所述事务型消息回调失败时，将所述回调状态标识位置为指示待补偿；
在所述事务型消息回调成功时，将所述回调状态标识位置为指示已回调。
23.根据权利要求22所述的装置，其特征在于，所述回调模块，具体用于：
当所述事务型消息回调失败后，基于回调补偿策略确定回调补偿参数，其中，所述补偿回调参数包括：最大补偿回调次数和/或下一次补偿回调时刻；
根据所述补偿回调参数，重新回调所述事务性消息。
24.根据权利要求23所述的装置，其特征在于，所述异常报警模块，还用于所述事务型消息的回调次数大于所述补偿策略的最大补偿回调次数时，输出回调异常报警信息。
25.根据权利要求19或22所述的装置，其特征在于，所述投递补偿策略与所述回调补偿策略为预定义的补偿策略中任一种补偿策略，所述补偿策略包括以下至少之一：
第一补偿策略，在第一预设时长内限定补偿次数M；所述M为正整数；
第二补偿策略，在第二预设时长内每间隔第三预设时长进行Y次补偿；所述Y为根据所述X和在所述第二预设时长内间隔的第三预设时长的个数Z确定的；其中，所述第三预设时长小于所述第二预设时长；所述X为间隔首个所述第三个预设时长之后补偿次数；
第三补偿策略，在第四预设时长内每隔第五预设时长进行一次补偿。
26.根据权利要求15所述的装置，其特征在于，所述装置还包括：
监控模块，用于监控所述通知服务的消息投递以及回调的状况信息；
数据统计模块，用于根据所述状况信息，生成所述通知服务进行消息投递和/或回调的统计数据；其中，所述统计数据，用于确定所述通知服务的运行状况。
27.根据权利要求15所述的装置，其特征在于，所述装置还包括：资源分配模块，用于据所述第一设备的消息投递负载状况，扩大或缩小分配给所述通知服务的资源。
28.根据权利要求27所述的装置，其特征在于，所述资源分配模块，具体用于：
当消息投递负载率大于第一阈值时，扩大分配给所述通知服务的资源；
或者，
当消息投递负载低于第二阈值时，缩小分配给所述通知服务的资源；
其中，所述第二阈值低于所述第一阈值。
29.一种电子设备，其特征在于，包括：
用于存储处理器可执行指令的存储器；
处理器；其中，所述处理器被配置为：用于执行所述可执行指令时，实现如权利要求1至14任一项所述的方法。
30.一种计算机可读存储介质，其特征在于，所述可读存储介质存储有可执行程序，其中，所述可执行程序被处理器执行时实现如权利要求1至14任一项所述的方法。
CN202210420327.9A 2022-04-20 2022-04-20 消息处理方法及装置、电子设备及存储介质 Pending CN114880137A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210420327.9A CN114880137A (zh) 2022-04-20 2022-04-20 消息处理方法及装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210420327.9A CN114880137A (zh) 2022-04-20 2022-04-20 消息处理方法及装置、电子设备及存储介质

Publications (1)

Publication Number Publication Date
CN114880137A true CN114880137A (zh) 2022-08-09

Family

ID=82672443

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210420327.9A Pending CN114880137A (zh) 2022-04-20 2022-04-20 消息处理方法及装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN114880137A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115801788A (zh) * 2023-02-01 2023-03-14 深圳市思为软件技术有限公司 事件投递的方法、装置、电子设备及存储介质

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115801788A (zh) * 2023-02-01 2023-03-14 深圳市思为软件技术有限公司 事件投递的方法、装置、电子设备及存储介质

Similar Documents

Publication Publication Date Title
US10838777B2 (en) Distributed resource allocation method, allocation node, and access node
CN106777026B (zh) 支持微服务架构事务最终一致性的方法、装置及系统
US7480918B2 (en) Duplicate message elimination during recovery when multiple threads are delivering messages from a message store to a destination queue
US10108630B2 (en) Cluster unique identifier
US9614646B2 (en) Method and system for robust message retransmission
CN108153598B (zh) 基于微服务架构的数据一致性方法以及装置
CN108279986B (zh) 一种分布式事务处理方法及装置
CN109714409A (zh) 一种消息的管理方法和系统
CN110830283A (zh) 故障检测方法、装置、设备和系统
CN102571850A (zh) 事务提交系统、方法及设备
CN111565135A (zh) 监控服务器运行的方法、监控服务器和存储介质
CN109391691A (zh) 一种单节点故障下nas服务的恢复方法及相关装置
CN110825505B (zh) 任务调度方法、装置、计算机设备及存储介质
CN114880137A (zh) 消息处理方法及装置、电子设备及存储介质
CN112181627A (zh) 定时任务调度方法、装置及系统
CN117762652A (zh) 基于消息中间件的分布式事务的处理方法及装置
CN113448699A (zh) 一种分布式定时任务处理系统、方法及相关装置
CN112751743A (zh) 消息发送异常的处理方法、消息发送装置和电子设备
CN113703669B (zh) 一种缓存分区的管理方法、系统、设备及存储介质
EP3346671B1 (en) Service processing method and equipment
CN112860746B (zh) 一种基于缓存削减的方法、设备及系统
CN111324668B (zh) 数据库数据同步处理方法、装置及存储介质
CN112231601A (zh) 链接管理方法、装置、设备及计算机存储介质
CN109361620B (zh) 一种数据发送的方法、装置、设备及存储介质
CN115914152B (zh) 回执信息推送方法、系统及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination