一种消息传递系统的制作方法

本发明实施例涉及数据通信技术领域，尤其涉及一种消息传递系统。

背景技术：

传统的消息传递只能从应用端将消息发送到接受端，当接受端宕机或出现错误而不再接受消息时，会造成消息的丢失。为了避免这种情况的发生可采用消息中间件(messageorientedmiddleware，mom)，消息中间件可以在不同平台之间通信，常被用来屏蔽掉各种平台及协议之间的特性，实现应用程序之间的协同。

传统的消息中间件大多采用同步调用完成消息的传递，而同步调用需要系统同步处理大量业务逻辑，导致用户请求慢、体验差，而且当系统接收到来自大量用户的请求时会对整个系统带来巨大的压力，甚至可能导致服务宕机或整个系统瘫痪。此外，大型互联网分布式系统存在多个服务，若采用这种传统的消息中间件，每个服务都需要提供生产者和消费者，这就使得整个分布式系统非常复杂繁琐。

技术实现要素：

本发明实施例提供一种消息传递系统，基于发送请求的时序完成发送消息的存储与发送，避免发送过程中消息的丢失，保证消息的完整性和一致性，提高系统的性能。

本发明实施例提供一种消息传递系统，包括：消息平台、数据库和消息中间件；

所述消息平台分别与消息订阅端和消息发送端连接，所述消息平台还分别与所述数据库和所述消息中间件连接，

所述消息发送端用于将发送请求发送给所述消息平台，所述消息平台基于所述发送请求生成发送消息，并根据所述发送请求的时序，将对应的发送消息存储到所述数据库，并将所述发送消息发送给所述消息中间件，所述消息订阅端用于发送订阅请求给所述消息平台。

进一步的，所述发送消息包括事务消息和非事务消息，相应的，

当所述发送消息为事务消息时，所述消息平台用于将所述消息发送端确认后的发送消息发送给所述消息中间件；

当所述发送消息为非事务消息时，所述消息平台用于将所述发送消息直接发送给所述消息中间件。

进一步的，所述消息平台还用于接收所述消息订阅端发送的订阅请求，并对所述订阅请求进行解析。

进一步的，所述消息中间件还用于发送订阅消息给所述消息平台，所述订阅消息为所述消息中间件中存储的与解析结果对应的消息。

进一步的，所述消息平台还用于将所述订阅消息发送给所述消息订阅端。

进一步的，所述消息平台还用于当发送给所述消息中间件的发送消息或发送给所述消息订阅端的订阅消息发送失败时，根据预设的消息重试策略重新发送所述发送消息或所述订阅消息。

进一步的，所述消息平台还用于根据所述发送消息的编号对所述发送消息进行幂等处理。

进一步的，所述消息平台还用于根据所述订阅消息的编号对所述订阅消息进行幂等处理。

本发明实施例提供一种消息传递系统，包括：消息平台、数据库和消息中间件，所述消息平台分别与消息订阅端和消息发送端连接，所述消息平台还分别与所述数据库和所述消息中间件连接，所述消息发送端用于将发送请求发送给所述消息平台，所述消息平台基于所述发送请求生成发送消息，并根据所述发送请求的时序，将对应的发送消息存储到所述数据库，并将所述发送消息发送给所述消息中间件，所述消息订阅端用于发送订阅请求给所述消息平台，与传统的消息传递技术相比，本发明的技术方案基于发送请求的时序完成发送消息的存储与发送，避免了发送过程中消息的丢失，保证了消息的完整性和一致性，提高了系统的性能。

附图说明

图1为本发明实施例提供的一种消息传递系统的结构图；

图2为事务消息执行的时序示意图；

图3为非事务消息执行的时序示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

图1为本发明实施例提供的一种消息传递系统的结构图，本实施例可适用于分布式系统数据传输的情况，具体的，该系统包括：消息平台110、数据库120和消息中间件130；

消息平台110分别与消息订阅端150和消息发送端140连接，消息平台110还分别与数据库120和消息中间件130连接，

消息发送端140用于将发送请求发送给消息平台110，消息平台110基于发送请求生成发送消息，并根据发送请求的时序，将对应的发送消息存储到数据库120，并将发送消息发送给消息中间件130，消息订阅端150用于发送订阅请求给消息平台110。

具体的，消息平台110一方面可以接收消息发送端140发送的发送请求，并将与发送请求对应的发送消息发送给消息中间件120，另一方面还可以接收消息订阅端150发送的订阅请求，将与该订阅请求对应的订阅消息发送给消息订阅端150，即消息平台110既可以作为消息的生产者，又可以作为消息的消费者，其中，消息的生产者是消息平台110接收发送请求后，可以对该发送请求进行包装，生成对应的发送消息。具体的，发送请求可以是包含发送消息的内容以及发送要求的请求，当消息发送端140将包含内容的发送请求发送给消息平台110后，消息平台110根据发送要求对接收的发送消息的内容进行包装以生成与发送要求对应的发送消息。消息的消费者是消息平台110发送订阅消息给消息订阅端150，具体的，消息平台110接收消息订阅端150发送的订阅请求后，获取与该订阅请求相关的订阅消息，并将该订阅消息发送给消息订阅端150。

数据库120可以是db2数据库或sqlserver数据库，实施例对数据库120的类型不作限定，数据库120用于存储消息，其中，消息可以是待发送的发送消息，也可以是接收到还未发送给消息订阅端150的订阅消息。具体的，消息平台110基于发送请求生成对应的发送消息后，将该发送消息存储到数据库120中，这样设置的好处是可以避免消息发送失败时，因不能重新发送该消息而导致系统中的数据不一致的情况，需要说明的是，消息平台110可以根据发送请求的时序将对应的发送消息存储到数据库120，以避免消息的丢失，其中，该存储可以是持久化存储，即发送消息可以永久保存在数据库120中，订阅消息的存储也是类似，此处不再赘述。

消息中间件130与消息平台110连接，可以接收消息平台110发送的发送消息，也可以发送与订阅请求相关的订阅消息给消息平台110，完成消息的管理和传递。具体的，消息中间件130包括异步消息传递和同步消息传递两种方式，其中，同步消息传递需要系统同步处理业务，当业务量较大时，不仅会降低用户的体验，甚至会导致系统宕机或瘫痪，为此，实施例采用消息中间120的异步消息传递方式，以减少用户等待时间，其中，消息中间件130可以是分布式消息中间件。需要说明的是，消息平台110可以按照发送消息对应的时序以设定时间间隔发送给消息中间件130，其中，发送消息对应的时序可以是与发送消息对应的发送请求的时序，也可以是消息平台110生成发送消息的时序，其中，消息平台110按照发送请求的时序生成对应的发送消息。

消息发送端140可以是用于发送消息的终端，例如可以是手机或电脑等智能终端。消息发送端140可以是一个也可以是多个，当消息发送端140是多个时，可以采用相同终端，也可以采用不同终端。具体的，当消息发送端140采用不同终端时，可以采用消息发送端140的id来唯一标识发送给消息平台110的发送请求，避免消息在管理过程中出错，例如，由终端m发送的发送请求可以分别用m1、m2和m3标识。消息订阅端150也可以理解为是消息接收方，用于发送订阅请求给消息平台110以订阅消息，当消息平台110接收该订阅请求时，解析该订阅请求的数据结构，明确其订阅的消息，然后接收消息中间130发送的消息，并将该消息发送给消息订阅端150。具体的，消息平台110可以通过消息通道接收消息中间件130发送的消息，其中，消息通道为根据业务规则和消息类型预先制定的，不同的消息通道传递不同类型的消息，设置消息通道的好处是：便于对消息进行分类发送，也减少了接收指定消息的时间。

下面简单描述一下消息传递的过程：

消息发送端140发送具体的发送请求给消息平台110，消息平台110收到该发送请求后，根据发送请求生成对应的发送消息，并基于发送请求的时序将发送消息存储到数据库120，并按照一定的发送规则发送给消息中间件130，例如可以按照发送消息生成的时序以设定的时间间隔发送，当消息中间件130接收到该发送消息时，对该发送消息进行存储，当消息订阅端150发送订阅请求给消息平台110时，消息平台110对该订阅请求的数据结构进行解析，此时，消息中间件130将与解析结果对应的订阅消息发送给消息平台110，由消息平台110发送给相应的消息订阅端150。

本发明实施例提供一种消息传递系统，包括：消息平台、数据库和消息中间件，所述消息平台分别与消息订阅端和消息发送端连接，所述消息平台还分别与所述数据库和所述消息中间件连接，所述消息发送端用于将发送请求发送给所述消息平台，所述消息平台基于所述发送请求生成发送消息，并根据所述发送请求的时序，将对应的发送消息存储到所述数据库，并将所述发送消息发送给所述消息中间件，所述消息订阅端用于发送订阅请求给所述消息平台，与传统的消息中间件相比，本方案的消息平台，与消息中间件连接，既可以作为消息生产者，又可以作为消息消费者，降低了系统的复杂度，提高了系统的性能，同时，通过将消息存储到数据库，保证了消息的完整性。

在上述实施例的基础上，所述发送消息包括事务消息和非事务消息，相应的，

当所述发送消息为事务消息时，消息平台用于将所述消息发送端确认后的发送消息发送给消息中间件；

当所述发送消息为非事务消息时，消息平台用于将所述发送消息直接发送给消息中间件。

具体的，事务消息是用于保证消息发送端和消息订阅端的业务在同一事务中，即消息发送端和消息订阅端具有事务关系，如果消息发送端的业务执行失败，则消息订阅端的业务也会失败，因此需要消息发送端发送消息确认指令，在消息发送端确认以后，由消息平台将该消息发送至消息中间件。非事务消息不需要考虑消息发送端和消息订阅端是否有事务关系，可以直接由消息平台发送，无需消息发送端的确认。

具体的，若发送消息为事务消息，则消息平台根据发送请求生成对应的发送消息后，将该发送消息持久化到数据库，然后向消息发送端回复ack(acknowledgement，确认字符)，以通知消息发送端发送请求发送成功，消息发送端在接收到该确认消息后，执行本地事务，并根据本地事务执行结果向消息平台发送确认指令或回滚指令，其中，确认指令表明事务成功，回滚指令表明事务失败，。当消息平台收到消息发送端发送的确认指令时，将该事务消息投递至消息中间件，并由消息中间件存储该消息，当消息平台收到消息发送端发送的回滚指令时，撤销该事务消息，不进行投递。若发送消息为非事务消息，消息平台在接收该非事务消息以后，直接将该消息投递至消息中间件。

在上述实施例的基础上，消息平台还用于接收所述消息订阅端发送的订阅请求，并对所述订阅请求进行解析。

具体的，消息订阅端向消息平台发送的是订阅请求，即订阅特定类型消息的请求，消息平台接收该订阅请求后，对该订阅请求的数据结构进行解析，以获取拟订阅的消息的信息，当消息平台接收到相关消息时发送给相应的消息订阅端，例如当消息订阅端要订阅的消息为c1，当消息平台接收到消息c1时，将消息c1发送给消息订阅端。

在上述实施例的基础上，所述消息中间件还用于发送订阅消息给所述消息平台，所述订阅消息为所述消息中间件中存储的与解析结果对应的消息。

具体的，消息平台获取的订阅消息来自于消息中间件，当消息平台解析订阅请求后，根据解析结果监听消息通道，以接收消息中间件发送的消息，并将该消息发送给消息订阅端，其中，不同类型的消息通过不同的消息通道传递，例如消息订阅端需要订阅业务类消息，而业务类消息通过消息通道a传递，则消息平台只需监听消息通道a即可，无需监听所有消息通道，提高了订阅消息获取的准确性和便捷性。

在上述实施例的基础上，所述消息平台还用于将所述订阅消息发送给所述消息订阅端。

可以理解的是，消息订阅端不止有一个，当消息订阅端有多个时，消息平台可以根据设定的发送规则将订阅消息分别发送给对应的消息订阅端，其中，发送规则可以根据实际需要设定，例如可以是根据消息订阅端的优先级，将订阅消息优先发送给优先级高的消息订阅端，其中消息订阅端的优先级可以预先存储在信息平台，当消息平台获取订阅消息后，查找相应的优先级，根据优先级确定当前订阅消息的发送。还可以是根据消息订阅端的要求进行发送，例如设定时间之内完成发送即可，此时消息平台可以优先发送比较紧急的订阅消息，这样设置的好处是可以合理安排发送时间，保证订阅消息发送的及时性。

在上述实施例的基础上，所述消息平台还用于当发送给所述消息中间件的发送消息或发送给所述消息订阅端的订阅消息发送失败时，根据预设的消息重试策略重新发送所述发送消息或所述订阅消息。

具体的，由于网络问题导致消息平台没有将发送消息正常发出或者正常发出后由于消息中间件本身异常导致其没有接收到该发送消息，此时，消息平台会根据预设的消息重试策略重新发送该发送消息，其中，消息重试策略可以是以设定时间间隔进行发送，直至发送成功，当重发次数达到次数阈值时，将停止发送，其中，次数阈值可以根据实际情况设置，也可以采用消息平台默认的重发次数。除了发送消息会发送失败，订阅消息也会存在发送失败的情况，例如当消息订阅端出现故障致使无法接收订阅消息时，消息平台同样会根据消息重试策略重新发送订阅消息，该重发过程与发送消息的重发过程类似，此处不再赘述。

在上述实施例的基础上，所述消息平台还用于根据所述发送消息的编号对所述发送消息进行幂等处理。

具体的，消息的编号可以是与发送消息对应的消息发送端的id。幂等性是使用相同参数对同一资源重复调用某个接口的结果与调用一次的结果相同，其数学表达形式为：f(f(x))＝f(x)。消息幂等性是同一消息被应用多次与应用一次产生的效果是一致的，这样处理的好处是：可以保证消息成功发送一次，假设不进行该处理，当由于网络原因，消息平台不确定消息中间件是否接收到发送消息时，再发送一次，则消息中间件会接收两次相同的发送消息，若该发送消息为加1，则由于重复发送导致在加1的基础上再加1，其结果明显与实际不符，严重降低了系统的可靠性。其中，消息平台对发送消息进行幂等处理的具体过程实施例不作限定，例如可以根据消息发送端的id对每条发送消息生成一个唯一的标识来标记该发送消息作为幂等处理的依据。

在上述实施例的基础上，所述消息平台还用于根据所述订阅消息的编号对所述订阅消息进行幂等处理。

订阅消息的编号可以是发送订阅请求的消息订阅端的id，对订阅消息进行幂等处理的过程与发送消息进行幂等处理的过程类似，此处不再赘述。

下面通过一个消息传递的信号流程图来描述一下完整的消息传递过程：

参考图2-图3，其中图2为事务消息执行的时序示意图，图3为非事务消息执行的时序示意图。参考图2，消息发送端发送事务消息给消息平台，消息平台在接收该事务消息以后，将其持久化到数据库，以避免消息发送过程中出现异常，导致数据不一致的问题，同时会向对应的消息发送端发送一个消息发送成功的信息，以通知消息发送端事务消息发送成功，消息发送端在接收到该信息以后执行本地事务，并向消息平台发送确认指令或回滚指令，如果消息平台接收到的是确认指令，表明事务执行成功，可以将该事务消息投递至消息中间件，如果接收到的是回滚指令，表明事务执行失败，需要撤销接收到的事务消息，不进行投递。当消息订阅端需要订阅消息时，发送订阅请求给消息平台，消息平台对该订阅请求进行解析，并根据解析结果向消息中间件发送订阅消息服务，与此同时，消息平台监听消息通道，以监听消息中间件发送的与订阅请求相关的消息，当消息平台接收到消息中间件发送的消息以后，对该消息进行解析并更新消息状态，最终发送给消息订阅端。

参考图3，当消息发送端发送的消息为非事务消息时，无需消息发送端发送确认指令或回滚指令，消息平台在接收到该非事务消息时，直接将其投递到消息中间件。当消息平台接收到订阅请求时，解析订阅请求，并根据解析结果向消息中间件发送订阅消息服务，并监听消息通道以监听消息中间件发送的与订阅请求相关的消息，当消息平台接收到消息中间件发送的消息以后，对该消息进行解析并更新消息状态，最终发送给消息订阅端。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。