1.本发明实施例涉及金融科技(fintech)领域，尤其涉及一种消息处理方法及系统。
背景技术：
：：2.随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技转变，但由于金融行业的安全性、实时性要求，也对技术提出的更高的要求。3.现有的消息处理方法主要是消息生产者producer生产消息，并在该消息的消息头上标注reply_to标识和broker标识。再将标注后的消息传输到消息服务端broker，消息服务端将标注后的消息存储在topic中。消息消费者可以根据订阅需求从消息服务端的topic中拉取与订阅需求对应的标注后的消息，并基于该标注后的消息进行业务处理，在业务处理完成后，将业务处理已完成的消息、reply_to标识和broker标识组装成应答消息。然后基于broker标识将应答消息发送给对应的消息服务端，消息服务端基于reply_to标识从内存映射表中查询出标注后的消息对应的socketchannel，并通过socketchannel直接将应答消息回包给对应的消息生产者。然而，这种处理方式需要对消息服务端做较多改动，不利于后续业务的使用；同时消息服务端没有对应答消息进行存储，导致应答消息丢失的概率增加，并无法对应答消息进行重放。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.可选地，所述第一处理单元具体用于：48.根据自身的应用实例的个数和所述第二订阅主题下的队列信息中的队列数量，按照平均分配的方式，确定每个应用实例的响应队列信息；所述响应队列信息用于存储所述应用实例产生的请求消息对应的响应消息。49.可选地，所述第二处理单元具体用于：50.生成所述第一订阅主题对应的消息拉取请求；51.通过所述第一订阅机制将所述消息拉取请求发送给所述消息服务端；所述消息拉取请求用于指示所述消息服务端基于所述第一订阅主题从所述第一存储区中确定出所述请求消息。52.可选地，所述第二处理单元具体用于：53.基于所述请求消息，对与所述请求消息对应的业务进行处理，并在确定所述业务处理完成后，基于所述业务已处理完成的消息以及所述请求消息对应的第二订阅主题，生成所述响应消息。54.可选地，所述第三处理单元还用于：55.通过回放线程确定出所述第一存储区中各待解析消息的位置；所述各待解析消息为所述第一存储区中待解析的各请求消息；56.基于所述各待解析消息的位置，对所述各待解析消息进行解析处理，得到所述各待解析消息的消息偏移量，并将所述各待解析消息的消息偏移量存储至所述第一订阅主题的偏移量缓存队列中；所述消息偏移量用于所述消息服务端根据所述第二消息端发送的消息拉取请求对应的消息偏移量从所述第一存储区中查询出对应的请求消息。57.第三方面，本发明实施例提供一种计算设备，包括至少一个处理器以及至少一个存储器，其中，所述存储器存储有计算机程序，当所述程序被所述处理器执行时，使得所述处理器执行上述第一方面任意所述的消息处理方法。58.第四方面，本发明实施例提供一种计算机可读存储介质，其存储有可由计算设备执行的计算机程序，当所述程序在所述计算设备上运行时，使得所述计算设备执行上述第一方面任意所述的消息处理方法。附图说明59.为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。60.图1为本发明实施例提供的一种消息处理系统架构的示意图；61.图2为本发明实施例提供的一种消息处理方法的流程示意图；62.图3为本发明实施例提供的一种消息处理系统的结构示意图；63.图4为本发明实施例提供的一种计算设备的结构示意图。具体实施方式64.为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。65.下面首先对本发明实施例中涉及的部分用语进行解释说明，以便于本领域技术人员进行理解。66.(1)broker：负责消息存储，以topic为维度支持轻量级的队列，单机可以支撑上万队列规模，支持消息推拉模型，具备多副本容错机制(2副本或3副本)、强大的削峰填谷以及上亿级消息堆积能力，同时可严格保证消息的有序性。67.(2)producer：用户部署的消息发布客户端，即消息请求方。68.(3)consumer：用户部署的消息订阅客户端，即消息应答方。支持push和pull模型，支持广播模式和集群模式。69.(4)nameserver：是一个轻量级的服务注册中心。每个nameserver节点中有所有broker中topic的路由信息，rocketmq架构中broker与所有的nameserver维持长连接，producer和consumer与任一个nameserver维持长连接。70.(5)consumergroup：消费者组，消费同一类消息的多个consumer实例组成一个消费者组，也可以指消费者集群。71.(6)topic：是一种消息的逻辑分类，例如既有订单类的消息，也有库存类的消息，那么就需要进行分类，一个是订单topic存放订单相关的消息，一个是库存topic存储库存相关的消息。72.(7)message：是消息的载体，一个message必须指定topic，相当于寄信的地址，producer发送消息和consumer接收消息必须预先设定topic。73.(8)messagequeue：消息队列，topic的细分，多个queue从逻辑上组成了一个topic，可以通过扩展messagequeue实现水平横向扩展。它有topic、brokername、queueid三个属性。74.(9)tag：每条发送的message都可以有一个tag，这样同一个topic可以按tag区分不同的业务场景。在实践上，一个业务系统使用一个topic，用不同的tag区分不同的消息。75.(10)commitlog：是broker端消息主体以及元数据的存储主体，存储producer端写入的消息主体内容,消息内容不是定长的。76.(11)consumequeue：是broker端记载消息的偏移量的载体，它不负责存储具体消息，只是负责记录它所属topic的消息在commitlog中的偏移量，这样当消费者从broker拉取消息的时候，就可以快速根据偏移量定位到消息。其中，consumerqueue中每个条目都是20个字节，包含8字节在commitlog文件中的偏移量，4字节消息的所占的字节大小以及8字节消息的tags标签对应的hashcode。77.(12)remotingcommand：是rocketmq进行远程交互的消息封装，它包含code、customheader、extfields、body属性。其中，code是指交易码，比如心跳有心跳对应的交易码，topic管理有topic管理对应的交易码，不同的交易对应了不同的交易码。服务端(指broker)或者客户端(指producer或者consumer)在启动时，会同时初始化并启动remoting模块，并且将交易码对应的消息处理类注册到remoting模块中。78.(13)rocket‑remoting：remoting模块是服务端或者客户端用来进行消息发送和接收的地方，rocketmq默认使用netty进行socket交互，netty是一个成熟的nio处理框架，使用netty可以大大简化javanio的开发。79.(14)tcp长连接：是指client向server端发送消息之后，不会关闭连接，后续新消息继续通过这条连接进行交互，同时client端定时向server端发送心跳消息，以保证连接不会被超时关闭。80.如上介绍了本发明实施例中涉及的部分用语，下面对本发明实施例涉及的技术特征进行介绍。81.下面对本发明实施例的设计思想进行简要介绍：82.现有技术中，producer端在生成的消息头上标注reply_to标识和broker标识。再将标注后的消息传输到消息服务端broker，消息服务端将标注后的消息存储在topic中。消息消费者可以根据订阅需求从消息服务端的topic中拉取与订阅需求对应的标注后的消息，并基于该标注后的消息进行业务处理，在业务处理完成后，将业务处理已完成的消息、reply_to标识和broker标识组装成应答消息。然后基于broker标识将应答消息发送给对应的消息服务端，消息服务端基于reply_to标识从内存映射表中查询出标注后的消息对应的socketchannel，并通过socketchannel直接将应答消息回包给对应的消息生产者。83.然而，现有技术在消息处理的过程中，消息服务端没有对应答消息进行存储，导致应答消息丢失的概率增加，并无法对应答消息进行重放。而且还需要进行多次修改代码，即：(1)修改broker端启动代码，在启动过程中需要新建一个defaultcluster‑reply‑topic的特殊topic。(2)修改broker端代码，扩展发送消息处理器并注册到remoting模块中。remoting模块接收到producer模块的请求消息解析成remotingcommand，获取到交易码code对应的发送消息处理器。这个处理器从remotingcommand的扩展属性extfields中先获取消息头的reply_to标识，并把这个唯一标识和producer对应的socketchannel保存到broker的内存映射中，用以方便后续再次通过reply_to找到对应的socketchannel。(3)扩展producer端messagequeueseletor代码，在producer端发送消息到broker端时，获取消息的messagetype属性，当判断为reply类型(即应答消息)时，优先选择与消息头broker名称相同的messagequeue进行消息发送。consumer拉取到请求消息并完成业务处理，获取原请求的reply_to信息及broker信息，组装成应答reply消息，然后通过扩展的消息选择器优先发送到名称相同的broker上面去，这样就相当于回包到原请求消息的broker上面。(4)扩展broker端代码，新增回包消息处理器并注册到remoting模块中。remoting模块接收到consumer的应答消息解析成remotingcommand，获取交易码code对应的回包消息处理器。回包消息处理器从remotingcommand的扩展属性extfields中找到reply_to唯一标识，然后通过这个唯一标识从内存映射表producerchanneltable中找到原请求消息的socketchannel连接信息，并通过这个socketchannel直接回包到消息请求方。84.鉴于此，本发明实施例提出了一种消息处理方法及系统。在本发明实施例中，第一消息端通过第一订阅机制，将请求消息发送至消息服务端。消息服务端在接收到请求消息后，根据请求消息中的第一订阅主题，将请求消息存储至第一订阅主题的第一存储区。然后，第二消息端通过第一订阅机制，从消息服务端获取请求消息并进行处理得到响应消息，并通过第二订阅机制，将响应消息发送至消息服务端。消息服务端在接收到响应消息后，将响应消息存储至第二订阅主题的第二存储区，以便第一消息端通过第二订阅机制，及时准确地从消息服务端获取响应消息。由于在消息服务端创建有接收并存储响应消息的第二存储区，如此可以避免响应消息的丢失，从而可以实现响应消息的重放。此外，该方案在消息处理的过程中由于使响应消息携带有第二订阅主题，可以确保响应消息及时准确地存储至对应的第二存储区，以便第一消息端正常接收，而无需在消息服务端通过更改代码来扩展发送消息处理器和新增回包消息处理器，从而可以避免对消息服务端在消息处理过程中所涉及的代码进行更改，如此便于后续业务可以及时有效地使用，并可以提高消息处理的效率。85.为了便于理解本发明实施例，首先以图1中示出的系统架构为例说明适用于本发明实施例的消息处理系统架构。该消息处理系统架构可以应用于金融交易场景中的消息发布订阅等，在实际应用场景中，本发明对此并不作限定。如图1所示，该系统架构可以包括第一消息端110、消息服务端120和第二消息端130。其中，第一消息端110与消息服务端120进行连接，第二消息端130与消息服务端120进行连接，比如可以通过有线方式连接，或者通过无线方式连接，具体不作限定。需要说明的是，第一消息端110可以作为消息生产端，也可以作为消息消费端，第二消息端130可以作为消息消费端，也可以为消息生产端，本发明实施例对此并不作限定。86.示例性地，以第一消息端110作为消息生产端，第二消息端130作为消息消费端为例对消息处理的过程进行描述。第一消息端110在接入消息服务端120时，先在消息服务端120上创建用于接收请求消息的topic(比如topica)和用于接收响应消息的replytopic，即systema‑reply‑topic，并在启动时订阅用于业务系统的topic(比如topica、topcib、topicc等)和用于接收响应消息的replytopic。之后生产出与topic对应的消息(比如与topica对应的消息、与topcib对应的消息、与topicc对应的消息等)，并将该消息标识上topic和replytopic，再将标识后的消息传输给消息服务端120，消息服务端120将与topic对应的消息(比如与topica对应的消息、与topcib对应的消息、与topicc对应的消息等)存储在对应的topic中。第二消息端130接入消息服务端120，并在启动时订阅用于业务系统的topic(比如topica、topcib、topicc等)和用于接收响应消息的replytopic。然后，第二消息端130在想要获取topica对应的消息时，向消息服务端120发送消息拉取请求，以使消息服务端120基于消息拉取请求将topica存储的消息发送给第二消息端130，第二消息端130基于topica对应的消息进行对应的业务处理，并在业务处理完成后，基于业务已处理完成的消息以及topica，生成响应消息，将响应消息发送给消息服务端120的systema‑reply‑topic响应消息队列上面。最后，第一消息端110在想要获取topica对应的响应消息时，向消息服务端120发送响应消息拉取请求，以使消息服务端120基于响应消息拉取请求将systema‑reply‑topic响应消息队列存储的topica对应的响应消息发送给第一消息端110。87.需要说明的是，上述图1所示的结构仅是一种示例，本发明实施例对此不做限定。88.基于上述描述，图2示例性的示出了本发明实施例提供的一种消息处理方法的流程，该流程可以由消息处理系统执行。89.如图2所示，该流程具体包括：90.步骤201，第一消息端通过第一订阅机制，将请求消息发送至消息服务端。91.步骤202，所述消息服务端根据所述请求消息中的第一订阅主题，将所述请求消息存储至所述第一订阅主题的第一存储区。92.步骤203，所述第二消息端通过所述第一订阅机制，从所述消息服务端获取所述请求消息。93.步骤204，所述第二消息端对所述请求消息进行处理得到响应消息。94.步骤205，所述第二消息端通过第二订阅机制，将所述响应消息发送至所述消息服务端。95.步骤206，所述消息服务端根据所述响应消息中的第二订阅主题，将所述响应消息存储至所述第二订阅主题的第二存储区。96.步骤207，所述第一消息端通过所述第二订阅机制，从所述消息服务端获取所述响应消息。97.上述步骤201和步骤202中，在将请求消息发送至消息服务端之前，第一消息端在消息服务端创建请求消息的第一订阅主题及请求消息的响应消息的第二订阅主题。再通过服务注册中心确定第二订阅主题下的队列信息，并从第二订阅主题下的队列信息中确定响应消息的响应队列信息，该响应队列信息作为第二订阅主题的第二存储区，如此可以实现在消息服务端有接收并存储响应消息的第二存储区，以便确保第一消息端可以及时准确地接收到请求消息对应的响应消息，并可以避免响应消息的丢失，以实现响应消息的重放。其中，从第二订阅主题下的队列信息中确定响应消息的响应队列信息，即，第一消息端根据自身的应用实例的个数和第二订阅主题下的队列信息中的队列数量，按照平均分配的方式，确定每个应用实例的响应队列信息，如此可以确保每个应用实例平均分担第二订阅主题下的队列信息，并可以避免某一应用实例因负载压力过大而出现故障或数据处理缓慢的情况。其中，响应队列信息用于存储应用实例产生的请求消息对应的响应消息。然后，第一消息端基于第一订阅机制(第一消息端为生产端，第二消息端为消费端，第二消息端订阅第一订阅主题。即，第二消息端作为消费端订阅这个topic，第一消息端作为生产端不需要订阅，它与所有拥有topic的broker进行连接，在发送请求消息时采用轮询机制发送到broker端)，生成第一订阅主题对应的请求消息，并将请求消息发送至消息服务端，以使消息服务端根据请求消息中的第一订阅主题，将请求消息存储至第一订阅主题的第一存储区。98.同时，在将请求消息存储至第一订阅主题的第一存储区之后，消息服务端通过回放线程确定出第一存储区中各待解析消息的位置，并基于各待解析消息的位置，对各待解析消息进行解析处理，得到各待解析消息的消息偏移量，并将各待解析消息的消息偏移量存储至第一订阅主题的偏移量缓存队列中，如此可以便于第二消息端在从消息服务端拉取请求消息时，消息服务端可以基于消息拉取请求对应的消息偏移量快速准确地定位到对应的请求消息。其中，各待解析消息为第一存储区中待解析的各请求消息；消息偏移量用于消息服务端根据第二消息端发送的消息拉取请求对应的消息偏移量从第一存储区中查询出对应的请求消息。具体地，消息服务端通过回放线程确定第一存储区中上一次解析完的请求消息的位置，并从该位置开始对位于该位置之后的多个请求消息进行解析处理，得到多个请求消息的偏移量，将该多个请求消息的偏移量存储在与第一订阅主题对应的consumequeue中，以便消费端在从消息服务端拉取请求消息时，消息服务端可以基于请求消息的偏移量快速定位到对应的请求消息。需要说明的是，回放线程拥有commitlog文件的已有offset偏移量(即上一次解析完成时的消息位置)，新进入commitlog的消息会追加在commitlog的末尾，回放线程若确定commitlog文件的长度大于已有offset偏移量，则从offset处开始解析每一条消息并放到消息对应topic的consumerqueue里面。99.上述步骤203和步骤204中，第二消息端通过第一订阅机制，从消息服务端获取请求消息，并对请求消息进行处理得到响应消息。具体地，第二消息端生成第一订阅主题对应的消息拉取请求，并通过第一订阅机制将消息拉取请求发送给消息服务端，该消息拉取请求用于指示消息服务端基于第一订阅主题从第一存储区中及时准确地确定出请求消息。然后，基于请求消息，对与请求消息对应的业务进行处理，并在确定业务处理完成后，基于业务已处理完成的消息以及请求消息对应的第二订阅主题，生成响应消息，如此可以便于消息服务端有效准确地将响应消息存储至第二订阅主题的第二存储区，并有助于第一消息端通过第二订阅机制，准确地从消息服务端获取响应消息。具体地，第二消息端在从消息服务端拉取到请求消息后，基于该请求消息进行对应的业务处理，并在业务处理完成后，获取请求消息的消息头中的reply_topic、reply_broker、reply_queueid等属性。再基于reply_topic、reply_broker、reply_queueid等属性以及业务处理已完成的信息组装成响应消息，并将响应消息发送到第一消息端监听的replytopic响应消息队列上面。如此，由于响应消息中携带有reply_topic、reply_broker、reply_queueid等属性，因此可以确保响应消息及时准确地存储至第一消息端监听的replytopic响应消息队列上面，以便第一消息端正常接收，而无需在消息服务端通过更改代码来扩展发送消息处理器和新增回包消息处理器，从而可以避免对消息服务端在消息处理过程中所涉及的代码进行更改。100.上述步骤205、步骤206和步骤207中，第二消息端通过第二订阅机制(第一消息端为消费端，第二消息端为生产端，第一消息端订阅第二订阅主题。即，第一消息端作为消费端订阅这个replytopic，第二消息端作为生产端不需要订阅，它与所有拥有replytopic的broker进行连接，在发送响应消息时采用轮询机制发送到broker端)，将响应消息发送至消息服务端。消息服务端根据响应消息中的第二订阅主题，将响应消息存储至第二订阅主题的第二存储区，以便第一消息端通过第二订阅机制，从消息服务端的第二存储区中获取对应的响应消息。具体地，消息服务端在接收到响应消息后，将响应消息存储至第一消息端监听的replytopic响应消息队列上面，以便第一消息端及时准确地获取对应的响应消息。即，第一消息端生成第二订阅主题对应的响应消息拉取请求，并将响应消息拉取请求发送给消息服务端，以使消息服务端基于响应消息拉取请求中的第二订阅主题从第二存储区中查询出响应消息，之后将响应消息发送给第一消息端。第一消息端在获取到响应消息之后，继续进行后续接收到的响应消息的处理流程其中，响应消息与请求消息相对应。101.有鉴于此，下面对本发明实施例中消息处理的实施过程进行具体描述。102.step1：producer端的处理。103.producer端在发送消息到broker端时，需要在消息头附带上当前系统监听的replytopic的消息队列信息。其中，对消息头进行附带replytopic的具体过程为：104.a、创建用于接收响应消息的replytopic。105.每个系统(通常指producer生产者和consumer消费者的组合)接入时，都需要在broker端新建一个用于接收响应消息的replytopic。比如systema(producer生产者和consumer消费者的组合)在接入时，在broker端创建用于接收响应消息的replytopic，即为systema‑reply‑topic。106.b、系统启动时，订阅用于接收响应消息replytopic。107.一个应用于生产环境的系统，通常是producer生产者和consumer消费者的组合。在系统启动时，除了正常订阅该系统用于业务系统的各个topic之外，还需要额外订阅用于接收响应消息的replytopic，以便用于接收下游子系统返回的响应消息。需要说明的是，一个topic可以由同一个消费者组consumergroup(也可以指消费者集群)下所有消费者平均分担消费。示例性地，假如topica有3个队列，某个消费者group起了3个应用实例(指将这个producer应用部署了到3台服务器，每启动一个服务就是指一个应用实例)，那每个实例负责1个队列的消费，如果再启动一个实例，即4个消费者实例消费3个topic队列消息，则最后启动的实例无法消费这个topic的消息，会出现接收不到请求的情况。因此，一个topic对应的队列消息通常由同一个消费者组consumergroup下所有消费者平均分担消费。108.c、producer端发送消息时附带上该实例订阅的replytopic消息队列信息。109.每个消息都是有topic的，producer发送消息到broker端，broker端会把消息保存到topic对应的commitlog中，并在将消息进行保存后，通过回放线程从最新点(位于上一次解析完的点之后的点)解析每一条消息并放到consumequeue中。其中，每个topic都有对应的consumequeue，consumequeue是不负责存储消息的，只是负责记录它所属topic的消息在commitlog中的偏移量，这样当消费者从broker端拉取消息时，就可以快速地根据偏移量定位到所需的消息。即，订阅这个topic的consumer向broker端发送拉取消息的请求，broker端从该topic所属的consumequeue中查找出消息，并返回对应的消息给consumer端，consumer进行相应的业务处理，返回应答消息到broker端。110.为了确保应答消息能够被发出请求消息的producer端实例接收到，则需要producer端在发送请求消息时，在消息头上附带该producer端订阅的replytopic对应的messagequeue信息。具体地，对于一个适用于生产环境的应用系统，在系统上线之后，应用实例个数通常是固定的，因此它订阅的replytopic的消息队列messagequeue的数量也是不变的。可以根据这个原则在发送请求消息时附带上这个实例订阅的replytopic的messagequeue信息，下游收到请求回包应答消息到当前系统监听的messagequeue上面来，这样就可以确保应答消息能够被当前系统正常接收到。111.需要说明的是，consumer客户端实例一般是defaultmqpushconsumer，在启动时使用平均消息分配策略算法进行初始化，然后通过该consumer实例从nameserver端获取replytopic下面所有消息队列messagequeue集合，即mqall。再通过该consumer实例获取当前实例所属的消费者组consumergroup对应的所有客户端列表，即cidall。最后通过负载均衡算法从当前实例监听的消息队列messagequeue列表中随机选择一个作为回报消息的messagequeue附加到请求消息头的reply_topic、reply_broker、reply_queueid字段上面，这样以便接收到此消息的下游子系统能够解析消息头并回包应答消息到broker端上面来。112.step2：consumer端的处理。113.consumer端根据自己订阅的topic，在从broker端拉取到对应的消息之后，进行对应的业务处理。并在处理完业务之后，获取请求消息头的reply_topic、reply_broker、reply_queueid等属性。再基于reply_topic、reply_broker、reply_queueid等属性以及业务处理已完成的信息封装成messagequeue，并指定这个messagequeue队列进行应答消息发送，这样就可以把应答消息发送到producer监听的replytopic队列上面。114.step3：producer端接收应答消息的处理。115.原请求消息发送的producer端通过订阅replytopic，从broker端拉取到与原请求消息对应的应答消息，并在拉取到应答消息之后继续进行后续接收到的应答消息的处理流程。116.上述实施例表明，第一消息端通过第一订阅机制，将请求消息发送至消息服务端。消息服务端在接收到请求消息后，根据请求消息中的第一订阅主题，将请求消息存储至第一订阅主题的第一存储区。然后，第二消息端通过第一订阅机制，从消息服务端获取请求消息并进行处理得到响应消息，并通过第二订阅机制，将响应消息发送至消息服务端。消息服务端在接收到响应消息后，将响应消息存储至第二订阅主题的第二存储区，以便第一消息端通过第二订阅机制，及时准确地从消息服务端获取响应消息。由于在消息服务端创建有接收并存储响应消息的第二存储区，如此可以避免响应消息的丢失，从而可以实现响应消息的重放。此外，该方案在消息处理的过程中由于使响应消息携带有第二订阅主题，可以确保响应消息及时准确地存储至对应的第二存储区，以便第一消息端正常接收，而无需在消息服务端通过更改代码来扩展发送消息处理器和新增回包消息处理器，从而可以避免对消息服务端在消息处理过程中所涉及的代码进行更改，如此便于后续业务可以及时有效地使用，并可以提高消息处理的效率。117.基于相同的技术构思，图3示例性的示出了本发明实施例提供的一种消息处理系统，该系统可以执行消息处理方法的流程。118.如图3所示，该系统包括第一消息端、第二消息端和消息服务端；119.所述第一消息端包括第一发送单元301和第一处理单元302；120.所述第一发送单元301，用于通过第一订阅机制，将请求消息发送至消息服务端；所述第一订阅机制中所述第一消息端为生产端，第二消息端为消费端；121.所述第一处理单元302，用于通过所述第二订阅机制，从所述消息服务端获取所述响应消息；122.所述第二消息端包括第二发送单元303和第二处理单元304；123.所述第二发送单元303，用于通过第二订阅机制，将所述响应消息发送至所述消息服务端；所述第二订阅机制中所述第一消息端为消费端，所述第二消息端为生产端；124.所述第二处理单元304，用于通过所述第一订阅机制，从所述消息服务端获取所述请求消息并进行处理得到响应消息；所述响应消息包括所述请求消息中的第二订阅主题；125.所述消息服务端包括接收单元305和第三处理单元306；126.所述接收单元305，用于接收所述请求消息，接收所述响应消息；127.所述第三处理单元306，用于根据所述请求消息中的第一订阅主题，将所述请求消息存储至所述第一订阅主题的第一存储区；将所述响应消息存储至所述第二订阅主题的第二存储区。128.可选地，所述第一处理单元302还用于：129.在所述消息服务端创建请求消息的第一订阅主题及请求消息的响应消息的第二订阅主题；130.通过服务注册中心确定所述第二订阅主题下的队列信息；131.从所述第二订阅主题下的队列信息中确定所述响应消息的响应队列信息；所述响应队列信息作为所述第二订阅主题的第二存储区。132.可选地，所述第一处理单元302具体用于：133.根据自身的应用实例的个数和所述第二订阅主题下的队列信息中的队列数量，按照平均分配的方式，确定每个应用实例的响应队列信息；所述响应队列信息用于存储所述应用实例产生的请求消息对应的响应消息。134.可选地，所述第二处理单元304具体用于：135.生成所述第一订阅主题对应的消息拉取请求；136.通过所述第一订阅机制将所述消息拉取请求发送给所述消息服务端；所述消息拉取请求用于指示所述消息服务端基于所述第一订阅主题从所述第一存储区中确定出所述请求消息。137.可选地，所述第二处理单元304具体用于：138.基于所述请求消息，对与所述请求消息对应的业务进行处理，并在确定所述业务处理完成后，基于所述业务已处理完成的消息以及所述请求消息对应的第二订阅主题，生成所述响应消息。139.可选地，所述第三处理单元306还用于：140.通过回放线程确定出所述第一存储区中各待解析消息的位置；所述各待解析消息为所述第一存储区中待解析的各请求消息；141.基于所述各待解析消息的位置，对所述各待解析消息进行解析处理，得到所述各待解析消息的消息偏移量，并将所述各待解析消息的消息偏移量存储至所述第一订阅主题的偏移量缓存队列中；所述消息偏移量用于所述消息服务端根据所述第二消息端发送的消息拉取请求对应的消息偏移量从所述第一存储区中查询出对应的请求消息。142.基于相同的技术构思，本发明实施例还提供了一种计算设备，如图4所示，包括至少一个处理器401，以及与至少一个处理器连接的存储器402，本发明实施例中不限定处理器401与存储器402之间的具体连接介质，图4中处理器401和存储器402之间通过总线连接为例。总线可以分为地址总线、数据总线、控制总线等。143.在本发明实施例中，存储器402存储有可被至少一个处理器401执行的指令，至少一个处理器401通过执行存储器402存储的指令，可以执行前述的消息处理方法中所包括的步骤。144.其中，处理器401是计算设备的控制中心，可以利用各种接口和线路连接计算设备的各个部分，通过运行或执行存储在存储器402内的指令以及调用存储在存储器402内的数据，从而实现数据处理。可选的，处理器401可包括一个或多个处理单元，处理器401可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理下发指令。可以理解的是，上述调制解调处理器也可以不集成到处理器401中。在一些实施例中，处理器401和存储器402可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。145.处理器401可以是通用处理器，例如中央处理器(cpu)、数字信号处理器、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本发明实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合消息处理实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。146.存储器402作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器402可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(randomaccessmemory，ram)、静态随机访问存储器(staticrandomaccessmemory，sram)、可编程只读存储器(programmablereadonlymemory，prom)、只读存储器(readonlymemory，rom)、带电可擦除可编程只读存储器(electricallyerasableprogrammableread‑onlymemory，eeprom)、磁性存储器、磁盘、光盘等。存储器402是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本发明实施例中的存储器402还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。147.基于相同的技术构思，本发明实施例还提供了一种计算机可读存储介质，其存储有可由计算设备执行的计算机程序，当所述程序在所述计算设备上运行时，使得所述计算设备执行上述消息处理方法的步骤。148.本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd‑rom、光学存储器等)上实施的计算机程序产品的形式。149.本发明是参照根据本发明的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。150.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。151.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。152.尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。153.显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。当前第1页1 2 3 当前第1页1 2 3