CN110198312A - 消息处理方法和装置 - Google Patents

Abstract

本申请提供一种消息处理方法和装置，该方法包括：通过目标服务Socket组件与发送端包括的目标客户Socket组件建立通信连接；其中，目标服务Socket组件是多个服务Socket组件中的任意一个，目标客户Socket组件是所述发送端包括的至少一个客户Socket组件中的任意一个；将所述发送端通过所述通信连接发送的业务消息，存储到所述目标服务Socket组件对应的接收队列。通过本申请的方案，即使发送端发送大量业务消息，也能够避免业务消息发送失败。

Description

消息处理方法和装置

技术领域

本申请涉及通信技术领域，尤其是涉及一种消息处理方法和装置。

背景技术

对于设备内部的多个功能模块来说，这些功能模块之间需要交互业务消息，即发送端向接收端发送业务消息。例如，发送端(如应用模块)获取日志消息，并将日志消息发送给接收端(如日志模块)，由接收端根据日志消息进行处理。

发送端在向接收端发送日志消息时，采用非阻塞方式(DONTWAIT)发送日志消息，也就是说，发送端向接收端发送日志消息1后，不需要等待接收端的响应，发送端可以继续向接收端发送日志消息2，以此类推。

为了避免发送端向接收端发送大量日志消息，导致接收端无法及时处理这些日志消息，还需要对发送端的消息总长度阈值、接收端的消息总数量阈值进行限制，例如，消息总长度阈值为A，消息总数量阈值为B。

基于此，当发送端需要发送日志消息时，若该日志消息的长度(如长度1)与当前消息长度(如长度2)之和大于消息总长度阈值A，则发送端不能成功将该日志消息发送给接收端，即该日志消息发送失败。若长度1与长度2之和不大于消息总长度阈值A，则发送端能够成功将该日志消息发送给接收端，并将当前消息长度更新为长度1与长度2之和。

当发送端需要发送日志消息时，若接收端的接收队列中已经存储的日志消息数量达到消息总数量阈值B，则发送端不能成功将该日志消息发送给接收端，即日志消息发送失败。若接收端的接收队列中已经存储的日志消息数量未达到消息总数量阈值B，则发送端能够成功将该日志消息发送给接收端。

综上所述，由于消息总长度阈值A和消息总数量阈值B的限制，发送端可能无法将日志消息发送给接收端，从而导致日志消息的发送失败。

发明内容

有鉴于此，本申请提供一种消息处理方法和装置，避免业务消息发送失败。

第一方面，本申请提供一种消息处理方法，应用于接收端，所述接收端包括多个服务套接字Socket组件，每个服务Socket组件对应一个接收队列，包括：

通过目标服务Socket组件与发送端包括的目标客户Socket组件建立通信连接；其中，所述目标服务Socket组件是所述多个服务Socket组件中的任意一个，所述目标客户Socket组件是所述发送端包括的至少一个客户Socket组件中的任意一个；

将所述发送端通过所述通信连接发送的业务消息，存储到所述目标服务Socket组件对应的接收队列。

第二方面，本申请提供一种消息处理装置，应用于接收端，所述接收端包括多个服务套接字Socket组件，每个服务Socket组件对应一个接收队列，包括：

建立模块，用于通过目标服务Socket组件与发送端包括的目标客户Socket组件建立通信连接；其中，所述目标服务Socket组件是所述多个服务Socket组件中的任意一个，所述目标客户Socket组件是所述发送端包括的至少一个客户Socket组件中的任意一个；

存储模块，用于将所述发送端通过所述通信连接发送的业务消息，存储到所述目标服务Socket组件对应的接收队列。

由以上技术方案可见，本申请中，在接收端部署多个服务套接字(Socket)组件，每个服务Socket组件的限制条件为消息总数量阈值，假设服务Socket组件的数量为N，则接收端能够存储消息总数量阈值*N个业务消息，从而增加接收端存储的业务消息数量，避免业务消息发送失败。在发送端部署多个客户Socket组件，每个客户Socket组件的限制条件为消息总长度阈值，假设客户Socket组件的数量为M，则发送端能够发送的业务消息长度为消息总长度阈值*M，从而增加发送端发送的业务消息长度，避免业务消息发送失败。

综上所述，在非阻塞方式的场景下，即使发送端需要发送大量的业务消息，也能够避免业务消息的发送失败，即业务消息不会发生丢失。

附图说明

为了更加清楚地说明本申请实施例或者现有技术中的技术方案，下面将对本申请实施例或者现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据本申请实施例的这些附图获得其他的附图。

图1A和图1B是本申请一种实施方式中的应用场景示意图；

图2A-图2G是本申请一种实施方式中的业务消息处理的示意图；

图3A和图3B是本申请一种实施方式中的多个服务Socket组件的示意图；

图4是本申请一种实施方式中的消息处理方法的流程图；

图5是本申请一种实施方式中的Socket组件连接的示意图；

图6是本申请一种实施方式中的存储的业务消息顺序示意图；

图7是本申请一种实施方式中的消息处理方法的流程图；

图8A-图8E是本申请一种实施方式中的数据结构的示意图；

图9A-图9F是本申请一种实施方式中的数据结构的变化示意图；

图10是本申请一种实施方式中的消息处理装置的结构图；

图11是本申请一种实施方式中的服务端的硬件结构图。

具体实施方式

在本申请实施例使用的术语仅仅是出于描述特定实施例的目的，而非限制本申请实施例。本申请实施例和权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其它含义。本文中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，此外，所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本申请实施例中提出一种消息处理方法，该方法可以应用于包括发送端(即客户端)和接收端(即服务端)的电子设备，该电子设备可以是路由器、交换机、服务器或者个人计算机等，对此不做限制。其中，发送端和接收端均可以是电子设备内部的功能模块，且发送端需要向接收端发送业务消息。例如，发送端可以是应用模块，接收端可以是日志模块，应用模块用于获取日志消息，并将该日志消息发送给日志模块，由日志模块根据该日志消息进行处理。

在一个例子中，发送端和接收端可以部署在容器。例如，发送端和接收端部署在相同的容器；或者，发送端和接收端部署在不同的容器。当然，发送端和接收端也可以未部署在容器，只是作为电子设备内部的功能模块。

参见图1A和图1B所示，为本申请实施例的应用场景示意图，以发送端11、发送端12和接收端13均部署在容器为例。参见图1A所示，发送端11、发送端12和接收端13，是部署在不同的容器；参见图1B所示，发送端11、发送端12和接收端13，是部署在相同的容器。在图1A和图1B中，是以2个发送端为例进行说明，在实际应用中，发送端的数量还可以更多，对此不做限制。

可选地，在一个例子中，发送端11包括Socket组件111(为了区分方便，将Socket组件111称为主客户Socket组件)，发送端12包括Socket组件121(为了区分方便，将Socket组件121称为主客户Socket组件)，接收端13包括Socket组件131(为了区分方便，将Socket组件131称为主服务Socket组件)。

发送端11通过Socket组件111与接收端13的Socket组件131建立通信连接，发送端11通过该通信连接将业务消息发送给接收端13，接收端13将业务消息存储到Socket组件131的接收队列。发送端12通过Socket组件121与接收端13的Socket组件131建立通信连接，发送端12通过该通信连接将业务消息发送给接收端13，接收端13将业务消息存储到Socket组件131的接收队列。

在发送端11将业务消息发送给接收端13时，可以采用非阻塞方式发送业务消息，也就是说，发送端11每次向接收端13发送业务消息后，不需要等待接收端13的响应，可以继续向接收端13发送下一个业务消息。同理，在发送端12将业务消息发送给接收端13时，可以采用非阻塞方式发送业务消息。

显然，若发送端11和发送端12短时间内向接收端13发送大量的业务消息，则接收端13可能无法及时处理这些业务消息，导致业务消息堆积。为了避免上述情况发生，则可以对发送端11的消息总长度阈值、发送端12的消息总长度阈值、接收端13的消息总数量阈值进行限制，如发送端11的消息总长度阈值为500，发送端12的消息总长度阈值为600，接收端13的消息总数量阈值为3。

其中，消息总长度阈值可以是指：发送端发送的、尚未被接收端调用的消息长度上限值。例如，发送端11的消息总长度阈值为500，其表示发送端11发送的、仍然存储在Socket组件131的接收队列中的消息总长度不能超过500。

其中，消息总数量阈值可以是指：接收端的接收队列中、尚未被接收端调用的消息数量上限值。例如，接收端13的消息总数量阈值为3，其表示在接收端13的Socket组件131的接收队列中，存储的业务消息数量不能超过3个。

参见图2A所示，发送端11通过Socket组件111与Socket组件131建立通信连接，发送端12通过Socket组件121与Socket组件131建立通信连接，Socket组件131对应接收队列C1，接收队列C1的队列深度为3，队列深度3表示Socket组件131的消息总数量阈值为3，即限制接收队列中的消息数量不能超过3个。

参见图2B所示，发送端11通过Socket组件111向接收端13发送一个100字节的业务消息A1，并将Socket组件111的缓冲存(Buffer)更新为100，表示发送端11已经在Socket组件131对应的接收队列C1中，存储了100字节的业务消息。发送端12通过Socket组件121向接收端13发送一个200字节的业务消息B1，并将Socket组件121的Buffer更新为200，表示发送端12已经在Socket组件131对应的接收队列C1中，存储了200字节的业务消息。

参见图2C所示，接收端13在接收到业务消息A1后，将业务消息A1存储到Socket组件131对应的接收队列C1中。接收端13在接收到业务消息B1后，将业务消息B1存储到Socket组件131对应的接收队列C1中。

参见图2D所示，假设发送端11的消息总长度阈值为500，发送端11需要向接收端13发送一个500字节的业务消息A2时，由于业务消息A2的长度(500)与Buffer中记录的当前消息长度(100)之和大于消息总长度阈值500，因此，发送端11不能将业务消息A2发送给接收端13，即业务消息A2发送失败。

参见图2E所示，假设发送端11需要向接收端13发送300字节的业务消息A3，由于业务消息A3的长度(300)与Buffer中记录的当前消息长度100之和小于消息总长度阈值500，因此，发送端11能够将业务消息A3发送给接收端13，并将Buffer更新为400(即业务消息A3的长度与当前消息长度之和)。接收端13接收到业务消息A3后，将业务消息A3存储到接收队列C1。

参见图2F所示，假设发送端12的消息总长度阈值为600，接收队列C1的队列深度为3(即接收队列C1的消息总数量阈值为3)，发送端12需要向接收端13发送一个100字节的业务消息B2时，虽然业务消息B2的长度(100)与Buffer中记录的当前消息长度(200)之和小于消息总长度阈值600，但是，由于接收队列C1中已经存储了3个业务消息，即已经达到了消息总数量阈值，因此，发送端12不能将业务消息B2发送给接收端13，即业务消息B2发送失败。

参见图2G所示，假设接收端13调用接收队列C1中的业务消息A1，将业务消息A1输出给上层业务模块进行处理，则发送端11将Buffer更新为300(即当前消息长度与业务消息A1的长度之差)，且接收队列C1存储2个业务消息。

综上所述，由于消息总长度阈值和消息总数量阈值的限制，业务消息可能发送失败。在一个可能的实现方式中，可以修改消息总长度阈值和消息总数量阈值的限制，例如，将消息总长度阈值的限制从500字节修改为5000字节，将消息总数量阈值的限制从3个修改为10个，从而避免业务消息发送失败。

但是，当发送端和接收端部署在容器时，没有权限修改系统配置，即不能修改消息总长度阈值和消息总数量阈值的限制，从而导致业务消息发送失败。

针对上述发现，本申请实施例中，接收端13可以包括多个服务Socket组件，每个服务Socket组件对应一个接收队列。所述多个服务Socket组件包括一个主服务Socket组件和至少一个从服务Socket组件。参见图3A所示，以接收端13包括一个从服务Socket组件为例，在实际应用中，从服务Socket组件的数量可以更多，对此不做限制。在图3A中，Socket组件131为主服务Socket组件，且接收队列C1为主服务Socket组件对应的接收队列，Socket组件132为从服务Socket组件，且接收队列C2为从服务Socket组件对应的接收队列。

其中，主服务Socket组件对应一个Socket组件地址(为了区分方便，将该Socket组件地址称为主地址)，即主服务Socket组件与主地址绑定。进一步的，可以利用地址映射策略将主地址映射为至少一个新Socket组件地址(为了区分方便，将映射的新Socket组件地址称为从地址)，从地址的数量与从服务Socket组件的数量相同，也就是说，至少一个从服务Socket组件中的每个从服务Socket组件与一个从地址绑定，即不同的从服务Socket组件对应不同的从地址。

其中，地址映射策略可以根据经验配置，对此地址映射策略不做限制，只要能够基于主地址确定从地址即可。例如，地址映射策略为主地址+特定后缀，当然，上述只是地址映射策略的示例。假设地址映射策略为主地址+特定后缀，那么，从地址包括主地址以及预设后缀，每个从地址包括的预设后缀均不同。

例如，主服务Socket组件对应的主地址为/myipc，则从地址可以为/myipc.1、/myipc.2、…，以此类推。这样，第一个从服务Socket组件对应的从地址是/myipc.1，第二个从服务Socket组件对应的从地址是/myipc.2，…，以此类推。

综上所述，通过在接收端13部署多个服务Socket组件，每个服务Socket组件的限制条件为消息总数量阈值，这样，假设服务Socket组件的数量为N，则接收端13能够存储消息总数量阈值*N个业务消息，从而增加接收端13存储的业务消息数量，避免业务消息的发送失败。例如，当消息总数量阈值的限制为3时，若接收端13包括5个服务Socket组件，则这5个服务Socket组件对应5个接收队列，每个接收队列最多能够存储3个业务消息，这样，接收端13一共可以存储15个业务消息，从而增加存储的业务消息数量。

本申请实施例中，发送端11包括至少一个客户Socket组件。例如，所述至少一个客户Socket组件只包括一个客户Socket组件，该客户Socket组件为主客户Socket组件，参见图3A所示，Socket组件111为主客户Socket组件。又例如，所述至少一个客户Socket组件包括一个主客户Socket组件和至少一个从客户Socket组件。参见图3B所示，以发送端11包括一个从客户Socket组件为例，实际应用中，从客户Socket组件的数量可以更多，对此不做限制。在图3B中，Socket组件111为主客户Socket组件，Socket组件112为从客户Socket组件。

其中，当发送端11的主客户Socket组件发送业务消息失败时，则发送端11可以新建一个从客户Socket组件，由于独自限制每个客户Socket组件的消息总长度阈值，因此，在建立从客户Socket组件后，能够通过从客户Socket组件将业务消息发送给接收端13，使得业务消息的发送成功。当从客户Socket组件发送业务消息失败时，发送端11可以新建一个从客户Socket组件，通过这个新建的从客户Socket组件将业务消息发送给接收端13，以此类推。

综上所述，通过在发送端11部署多个客户Socket组件，每个客户Socket组件的限制条件为消息总长度阈值，这样，假设客户Socket组件的数量为M，则发送端11能够发送的业务消息长度为消息总长度阈值*M，从而增加发送端11发送的业务消息长度，避免业务消息的发送失败。例如，当消息总长度阈值为500字节时，若发送端11包括5个客户Socket组件，则每个客户Socket组件能够发送500字节的业务消息，也就是说，5个客户Socket组件最多能够发送2500字节的业务消息，从而增加发送端11发送的业务消息长度。

基于上述应用场景，如图4所示，为消息处理方法的流程图，该方法包括：

步骤401，接收端通过目标服务Socket组件与发送端的目标客户Socket组件建立通信连接；其中，目标服务Socket组件是多个服务Socket组件中的任意一个，目标客户Socket组件是至少一个客户Socket组件中的任意一个。

例如，参见图3A所示，目标服务Socket组件为主服务Socket组件或者从服务Socket组件，目标客户Socket组件为主客户Socket组件。又例如，参见图3B所示，目标服务Socket组件为主服务Socket组件或者从服务Socket组件，目标客户Socket组件为主客户Socket组件或者从客户Socket组件。

步骤402，接收端将发送端通过该通信连接发送的业务消息，存储到目标服务Socket组件对应的接收队列。例如，接收端可以通过该通信连接接收发送端发送的业务消息，将该业务消息存储到目标服务Socket组件对应的接收队列。

具体的，当在目标服务Socket组件与目标客户Socket组件之间建立通信连接后，发送端的目标客户Socket组件可以通过该通信连接向目标服务Socket组件发送业务消息，而接收端的目标服务Socket组件可以通过该通信连接接收该业务消息。然后，接收端的目标服务Socket组件通过该通信连接接收到该业务消息后，可以将该业务消息存储到该目标服务Socket组件对应的接收队列。

由以上技术方案可见，本申请实施例中，在接收端部署多个服务Socket组件，每个服务Socket组件的限制条件为消息总数量阈值，假设服务Socket组件的数量为N，则接收端能够存储消息总数量阈值*N个业务消息，从而增加接收端存储的业务消息数量，避免业务消息发送失败。在发送端部署多个客户Socket组件，每个客户Socket组件的限制条件为消息总长度阈值，假设客户Socket组件的数量为M，则发送端能够发送的业务消息长度为消息总长度阈值*M，从而增加发送端发送的业务消息长度，避免业务消息发送失败。综上所述，即使发送端需要发送大量业务消息，也能够避免业务消息的发送失败。

可选地，在一个例子中，若目标服务Socket组件为主服务Socket组件，目标客户Socket组件为主客户Socket组件，参见图3A或图3B所示，则目标服务Socket组件为Socket组件131，目标客户Socket组件为Socket组件111，因此，发送端11和接收端13可以在Socket组件111与Socket组件131之间建立通信连接。基于所述通信连接，发送端11通过Socket组件111向接收端13的Socket组件131发送业务消息，接收端13通过Socket组件131接收该业务消息，在接收到业务消息后，将该业务消息存储到Socket组件131对应的接收队列C1。

若目标服务Socket组件为从服务Socket组件，目标客户Socket组件为主客户Socket组件，参见图3A或者图3B所示，则目标服务Socket组件为Socket组件132，目标客户Socket组件为Socket组件111，因此，在Socket组件111与Socket组件132之间建立通信连接。基于所述通信连接，发送端11通过Socket组件111向Socket组件132发送业务消息，接收端13通过Socket组件132接收业务消息，将该业务消息存储到Socket组件132对应的接收队列C2。

此外，若目标服务Socket组件为主服务Socket组件，目标客户Socket组件为从客户Socket组件，参见图3B所示，则目标服务Socket组件为Socket组件131，目标客户Socket组件为Socket组件112，因此，在Socket组件112与Socket组件131之间建立通信连接。基于所述通信连接，发送端11通过Socket组件112向Socket组件131发送业务消息，接收端13通过Socket组件131接收业务消息，并将该业务消息存储到Socket组件131对应的接收队列C1。

此外，若目标服务Socket组件为从服务Socket组件，目标客户Socket组件为从客户Socket组件，参见图3B所示，则目标服务Socket组件为Socket组件132，目标客户Socket组件为Socket组件112，因此，在Socket组件112与Socket组件132之间建立通信连接。基于所述通信连接，发送端11通过Socket组件112向Socket组件132发送业务消息，接收端13通过Socket组件132接收业务消息，将该业务消息存储到Socket组件132对应的接收队列C2。

可选地，在一个例子中，接收端包括多个服务Socket组件，发送端包括多个客户Socket组件时，客户Socket组件与服务Socket组件的连接方式可以参见图5所示。发送端的从客户Socket组件可以连接接收端的任意从服务Socket组件。发送端的主客户Socket组件可以连接接收端的主服务Socket组件。此外，发送端的主客户Socket组件不会发生变化，发送端的从客户Socket组件不会长久维护，如果从客户Socket组件发送业务消息失败，则可以关闭这个从客户Socket组件，重新建立一个新的从客户Socket组件继续发送业务消息。

例如，在正常情况下，发送端使用主客户Socket组件与接收端的主服务Socket组件通信。当主客户Socket组件发送业务消息失败时，发送端建立一个新的从客户Socket组件1，并使用从客户Socket组件1与接收端的从服务Socket组件通信。由于从客户Socket组件1已经将业务消息成功发送给接收端的从服务Socket组件，因此业务消息不会发生丢失。当从客户Socket组件1发送业务消息失败时，发送端关闭从客户Socket组件1，并建立新的从客户Socket组件2，并使用从客户Socket组件2与接收端的从服务Socket组件通信，以此类推。

可选地，在一个例子中，针对在目标服务Socket组件与目标客户Socket组件之间建立通信连接的过程，可以包括：发送端通过目标客户Socket组件向接收端发送连接请求，且接收端接收该连接请求。其中，该连接请求是发送端从所有从服务Socket组件中选择一个从服务Socket组件，并将选择的从服务Socket组件作为目标服务Socket组件后发送的，且该连接请求包括所述选择的从服务Socket组件对应的目标地址(即从地址)，该目标地址包括主服务Socket组件的主地址以及目标后缀(即所述选择的从服务Socket组件对应的预设后缀)。

接收端在接收到该连接请求后，根据目标地址，确定该目标地址对应的从服务Socket组件(即目标服务Socket组件)，并通过所述从服务Socket组件与目标客户Socket组件建立通信连接，对此建立方式不做限制。

其中，根据目标地址，确定该目标地址对应的从服务Socket组件，包括：根据主服务Socket组件的主地址以及目标后缀，确定对应的从服务Socket组件。

例如，发送端11通过Socket组件111(即主客户Socket组件)与接收端13的Socket组件131(即主服务Socket组件)建立通信连接，Socket组件111通过该通信连接向Socket组件131发送业务消息，由Socket组件131将业务消息存储到接收队列C1。在业务消息的发送过程中，若业务消息发送失败，则发送端11建立Socket组件112(即从客户Socket组件)，并通过Socket组件112与Socket组件131建立通信连接，Socket组件112通过该通信连接向Socket组件131发送业务消息。若业务消息发送失败，则发送端11从所有的从服务Socket组件中选择一个从服务Socket组件，如Socket组件132，并通过Socket组件112与Socket组件132建立通信连接，Socket组件112通过该通信连接向Socket组件132发送业务消息，由Socket组件132将该业务消息存储到接收队列C2。

综上所述，在Socket组件112与Socket组件132之间建立通信连接，Socket组件112作为目标客户Socket组件，Socket组件132作为目标服务Socket组件。

可选地，在一个例子中，发送端从所有从服务Socket组件中选择一个从服务Socket组件作为目标服务Socket组件，可以包括：发送端确定主服务Socket组件的主地址，并利用地址映射策略(即预先配置在发送端的地址映射策略)确定与该主地址对应的目标地址，该目标地址包括主地址以及目标后缀，并将该目标地址对应的从服务Socket组件确定为目标服务Socket组件。

例如，假设地址映射策略为主地址+特定后缀，且主地址为/myipc，则基于地址映射策略，确定目标地址为/myipc.1，将/myipc.1对应的从服务Socket组件确定为目标服务Socket组件。基于此，发送端通过目标客户Socket组件向接收端发送连接请求时，该连接请求包括的目标地址为/myipc.1。接收端接收到连接请求后，将/myipc.1对应的从服务Socket组件确定为目标服务Socket组件。

发送端再次确定目标服务Socket组件时，基于地址映射策略，发送端确定目标地址为/myipc.2，并将/myipc.2对应的从服务Socket组件确定为目标服务Socket组件。基于此，发送端在通过目标客户Socket组件向接收端发送连接请求时，该连接请求包括的目标地址为/myipc.2。接收端接收到该连接请求后，将/myipc.2对应的从服务Socket组件确定为目标服务Socket组件，以此类推。

可选地，在一个例子中，当采用上述方式发送业务消息时，还可能存在业务消息的乱序问题。例如，参见图6所示，假设接收端13包括Socket组件131(即主服务Socket组件)、Socket组件132(即从服务Socket组件)和Socket组件133(即从服务Socket组件)，接收端13的每个Socket组件的队列深度为5(即消息总数量阈值可以为5)，此外，发送端11发送业务消息的顺序依次是：业务消息A1-业务消息A2-业务消息A3-业务消息A4-业务消息A5。

发送端11通过Socket组件111向Socket组件131发送业务消息A1时，若业务消息A1发送成功，则Socket组件131将业务消息A1存储到Socket组件131的接收队列C1。发送端11通过Socket组件111向Socket组件131发送业务消息A2时，若业务消息A2发送失败，则发送端11建立Socket组件112，在Socket组件112与Socket组件132之间建立通信连接。发送端11通过Socket组件112向Socket组件132发送业务消息A2时，若业务消息A2发送成功，则Socket组件132将业务消息A2存储到Socket组件132的接收队列C2。

发送端11通过Socket组件112向Socket组件132发送业务消息A3时，若业务消息A3发送失败，则发送端11关闭Socket组件112(即删除Socket组件112，发送端11不包括Socket组件112)，并建立新的Socket组件113，在Socket组件113与Socket组件133之间建立通信连接。发送端11通过Socket组件113向Socket组件133发送业务消息A3时，若业务消息A3发送成功，则Socket组件133将业务消息A3存储到Socket组件133的接收队列C3。发送端11通过Socket组件113向Socket组件133发送业务消息A4时，若业务消息A4发送成功，则Socket组件133将业务消息A4存储到Socket组件133的接收队列C3。

发送端11通过Socket组件113向Socket组件133发送业务消息A5时，若业务消息A5发送失败，则发送端11关闭Socket组件113，建立新的Socket组件114，在Socket组件114与Socket组件132之间建立通信连接。发送端11通过Socket组件114向Socket组件132发送业务消息A5时，若业务消息A5发送成功，则Socket组件132将业务消息A5存储到Socket组件132的接收队列C2。

经过上述发送过程，则接收端13存储的业务消息顺序示意图参见图6所示。

进一步的，基于图6所示的业务消息顺序，在第1个计数周期，接收端13可以从接收队列C1中读取业务消息B1，从接收队列C2中读取业务消息A2，从接收队列C3中读取业务消息B3。在第2个计数周期，接收端13可以从接收队列C1中读取业务消息B2，从接收队列C2中读取业务消息B4，从接收队列C3中读取业务消息A3。在第3个计数周期，接收端13可以从接收队列C1中读取业务消息B5，从接收队列C2中读取业务消息A5，从接收队列C3中读取业务消息B8。在第4个计数周期，接收端13可以从接收队列C1中读取业务消息B6，从接收队列C2中读取业务消息B7，从接收队列C3中读取业务消息B10。在第5个计数周期，接收端13可以从接收队列C1中读取业务消息A1，从接收队列C2中读取业务消息B9，从接收队列C3中读取业务消息A4。

综上所述，针对发送端11发送的业务消息，接收端13从接收队列中读取到的业务消息顺序依次是：业务消息A2-业务消息A3-业务消息A5-业务消息A1-业务消息A4。显然，上述业务消息顺序(业务消息A2-业务消息A3-业务消息A5-业务消息A1-业务消息A4)与发送端11发送的业务消息顺序(业务消息A1-业务消息A2-业务消息A3-业务消息A4-业务消息A5)不符，造成乱序问题。

针对上述发现，本申请实施例中，发送端11向接收端13发送业务消息时，该业务消息可以包括消息头和真正数据，该消息头包括用户客户端属性参数(如发送端11的进程标识(Process Identification，PID)、主客户Socket组件的文件描述符(File Descriptor，FD)等)、业务消息序号、目标服务Socket组件的地址、主客户Socket组件的地址等。其中，用户客户端属性参数用于唯一确定业务消息的来源；业务消息序号用于确定业务消息的顺序；目标服务Socket组件的地址，用于确定业务消息发送给哪个服务Socket组件；主客户Socket组件的地址，用于向接收端13提供对端地址，即接收端13获取主客户Socket组件的地址，利用主客户Socket组件的地址向主客户Socket组件返回响应消息。

例如，发送端11通过Socket组件111向Socket组件131发送业务消息A1时，消息头包括：发送端11的PID100、Socket组件111的FD0、序号1、Socket组件131的主地址、Socket组件111的地址。发送端11通过Socket组件112向Socket组件132发送业务消息A2时，消息头包括：PID100、Socket组件112对应的主客户Socket组件(即Socket组件111)的FD0、序号2、Socket组件132的从地址、Socket组件112对应的Socket组件111的地址。发送端11通过Socket组件113向Socket组件133发送业务消息A3时，消息头包括：PID100、FD0、序号3、Socket组件133的从地址、Socket组件111的地址。发送端11通过Socket组件113向Socket组件133发送业务消息A4时，消息头包括：PID100、FD0、序号4、Socket组件133的从地址、Socket组件111的地址。发送端11通过Socket组件114向Socket组件132发送业务消息A5时，消息头包括：PID100、FD0、序号5、Socket组件131的从地址、Socket组件111的地址。

在上述应用场景下，参见图7所示，数据处理方法还可以包括：

步骤701，在每个计数周期内，接收端分别从每个服务Socket组件对应的接收队列读取相同数量的业务消息。其中，接收端的一次读取过程可以称为一个计数周期，在每个计数周期内，分别从每个服务Socket组件对应的接收队列读取相同数量的业务消息，如从每个接收队列读取1个业务消息。

步骤702，接收端从读取的所有业务消息中获取属于同一发送端的多个目标业务消息。其中，当发送端向接收端发送多个业务消息时，接收端从读取的所有业务消息中获取属于所述发送端的多个业务信息，将其称为目标业务消息。

具体的，针对已读取的每个业务消息，该业务消息可以包括用户客户端属性参数，如发送端的PID、主客户Socket组件的FD等。若已读取的业务消息包括的用户客户端属性参数与发送端的用户客户端属性参数相同，则说明这个已读取的业务消息就是属于该发送端的目标业务消息。在对已读取的每个业务消息进行上述处理后，就可以得到属于该发送端的多个目标业务消息。

步骤703，接收端按照多个目标业务消息的发送顺序，对多个目标业务消息(即属于同一发送端的多个目标业务消息)进行排序。

具体的，针对发送端发送的多个目标业务消息，每个目标业务消息还包括业务消息序号。基于业务消息序号，可以确定每个目标业务消息的发送顺序，并按照所述多个目标业务消息的发送顺序，对多个目标业务消息进行排序。

步骤704，接收端基于多个目标业务消息的排序结果，向上层业务模块依次输出多个目标业务消息，即先向上层业务模块输出排序靠前的目标业务消息。

例如，参见图6所示，在第1个计数周期，接收端13从每个接收队列中读取的业务消息包括：业务消息B1、业务消息A2、业务消息B3。业务消息A2的消息头包括：PID100、FD0、序号2。由于发送端11对应的用户客户端属性参数为PID100和FD0，因此，业务消息A2是属于发送端11的目标业务消息。

在第2个计数周期，接收端13读取的业务消息包括：业务消息B2、业务消息B4、业务消息A3。业务消息A3的消息头包括：PID100、FD0、序号3，因此，业务消息A3是属于发送端11的目标业务消息。以此类推，在第3个计数周期，确定业务消息A5是属于发送端11的目标业务消息。在第4个计数周期，读取的所有业务消息均不是属于发送端11的目标业务消息。在第5个计数周期，确定业务消息A1和业务消息A4是属于发送端11的目标业务消息。

综上所述，接收端13能够从读取的所有业务消息中获取到属于发送端11的目标业务消息，如业务消息A2、业务消息A3、业务消息A5、业务消息A1、业务消息A4。基于业务消息A2包括的序号2、业务消息A3包括的序号3、业务消息A5包括的序号5、业务消息A1包括的序号1、业务消息A4包括的序号4，接收端13可以确定这些目标业务消息的发送顺序，即序号从小到大的顺序。

然后，接收端13按照这些目标业务消息的发送顺序，对这些目标业务消息进行排序，排序结果为业务消息A1-业务消息A2-业务消息A3-业务消息A4-业务消息A5。进一步的，基于目标业务消息的排序结果，接收端13先输出业务消息A1，然后输出业务消息A2，然后输出业务消息A3，然后输出业务消息A4，然后输出业务消息A5，从而向上层业务模块依次输出多个目标业务消息。

其中，接收端13可以将这些目标业务消息输出给上层业务模块，由上层业务模块利用这些目标业务消息进行处理，具体处理方式可以参见传统方式。

由以上技术方案可见，本申请实施例中，通过对属于发送端的多个目标业务消息进行排序，从而能够按照目标业务消息的发送顺序(如业务消息A1-业务消息A2-业务消息A3-业务消息A4-业务消息A5)，向上层业务模块依次输出所述多个目标业务消息，从而避免多个目标业务消息的乱序问题。

可选地，在一个例子中，接收端13还可以维护一个数据结构，该数据结构可以包括多个数据项，针对该数据结构中的每个数据项，该数据项以用户客户端属性参数(如发送端的PID、发送端的主客户Socket组件的FD)为键值(Key)，该数据项的值(Value)为业务消息链表。业务消息链表的元素为业务消息和业务消息对应的初始计数周期，表示该业务消息是在该初始计数周期读取的。该业务消息链表中的业务消息可以按照序号由小到大的顺序进行排序。

基于此，在步骤702中，针对每个已读取的业务消息，接收端判断数据结构中是否存在与所述业务消息包括的用户客户端属性参数对应的数据项；如果存在，则在该数据项中存储所述业务消息；如果未存在，则在数据结构中建立与该用户客户端属性参数对应的数据项，并在当前建立的数据项中存储所述业务消息。进一步的，接收端可以从数据结构中获取与发送端的用户客户端属性参数对应的数据项，并将获取的数据项中的所有业务消息，均确定为属于所述发送端的目标业务消息，即得到属于所述发送端的多个目标业务消息。

例如，数据结构的初始状态为空。在第1个计数周期，接收端13从每个接收队列中读取的业务消息包括：业务消息B1、业务消息A2、业务消息B3。针对业务消息B1和业务消息B3的处理不再赘述。业务消息A2的消息头包括：PID100、FD0和序号2。由于数据结构不存在与PID100和FD0对应的数据项，因此在数据结构中建立数据项，该数据项以PID100和FD0为键值，在该数据项的业务消息链表中增加元素，该元素包括业务消息A2、业务消息A2对应的初始计数周期(即计数周期1)，还包括业务消息A2的序号2，参见图8A所示。

在第2个计数周期，接收端13从每个接收队列中读取的业务消息可以包括：业务消息B2、业务消息B4、业务消息A3。业务消息A3的消息头包括：PID100、FD0和序号3。由于数据结构中存在与PID100和FD0对应的数据项，因此，在该数据项的业务消息链表中增加新元素，该元素包括业务消息A3、业务消息A3对应的初始计数周期(即计数周期2)、序号3，参见图8B所示。

在第3个计数周期，接收端13读取的业务消息包括业务消息A5，消息头包括PID100、FD0和序号5，在数据项的业务消息链表中增加新元素，包括业务消息A5、业务消息A5对应的计数周期3、序号5，参见图8C所示。

在第5个计数周期，接收端13读取的业务消息包括业务消息A1和业务消息A4，业务消息A1的消息头包括PID100、FD0和序号1，业务消息A4的消息头包括PID100、FD0和序号4。在数据项的业务消息链表增加两个新元素，一个元素包括业务消息A1、业务消息A1对应的计数周期5、序号1，另一元素包括业务消息A4、业务消息A4对应的计数周期5、序号4，参见图8D所示。

进一步的，针对业务消息链表的每个业务消息，可以按照序号由小到大的顺序进行排序，参见图8E所示，为排序后的示例，也就是说，序号由小到大的排序结果为业务消息A1-业务消息A2-业务消息A3-业务消息A4-业务消息A5。

其中，针对图8D，按照序号由小到大的顺序排序后，得到图8E。针对图8B和图8C，也可以按照序号由小到大的顺序排序，在此不再赘述。

可选地，在上述实施例中，接收端可以维护一个计数器，通过这个计数器更新计数周期。例如，计数器的初始值为0，接收端从每个服务Socket组件对应的接收队列读取业务消息后，将计数器的值加1，即计数器的值为1，表示当前读取的这些业务消息的初始计数周期为计数周期1。接收端再次从每个服务Socket组件对应的接收队列读取业务消息后，将计数器的值加1，即计数器的值为2，表示当前读取的这些业务消息的初始计数周期为计数周期2，以此类推。

可选地，在一个例子中，针对步骤704，接收端基于多个目标业务消息的排序结果，向上层业务模块依次输出多个目标业务消息，，可以包括但不限于：接收端从多个目标业务消息中选取排序靠前的待输出目标业务消息，并获取待输出目标业务消息对应的初始计数周期。接收端判断当前计数周期与初始计数周期的差值，是否小于接收队列的队列深度(即消息总数量阈值)；如果否，则向上层业务模块输出待输出目标业务消息；如果是，则等到下一个计数周期，并判断当前计数周期与初始计数周期的差值，是否小于接收队列的队列深度。

例如，在第1个计数周期，接收端13得到图8A所示的数据项，排序靠前的待输出目标业务消息是业务消息A2，假设接收队列的队列深度为5，由于业务消息A2的初始计数周期为计数周期1，当前计数周期为计数周期1，因此，当前计数周期与初始计数周期的差值小于接收队列的队列深度，即未满足业务消息A2的输出条件，因此，需要等到下一个计数周期，重新上述处理过程。

在第2个计数周期，接收端13得到图8B所示的数据项，排序靠前的待输出目标业务消息是业务消息A2，当前计数周期为计数周期2，由于当前计数周期与初始计数周期的差值小于接收队列的队列深度，即未满足业务消息A2的输出条件，因此，需要等到下一个计数周期，重新上述处理过程。

在第3个计数周期，接收端13得到图8C所示的数据项，排序靠前的待输出目标业务消息是业务消息A2，当前计数周期为计数周期3，由于当前计数周期与初始计数周期的差值小于接收队列的队列深度，即未满足业务消息A2的输出条件，因此，需要等到下一个计数周期，重新上述处理过程。

在第4个计数周期，接收端13得到图8C所示的数据项，排序靠前的待输出目标业务消息是业务消息A2，当前计数周期为计数周期4，由于当前计数周期与初始计数周期的差值小于接收队列的队列深度，即未满足业务消息A2的输出条件，因此，需要等到下一个计数周期，重新上述处理过程。

在第5个计数周期，接收端13得到图8E所示的数据项，排序靠前的待输出目标业务消息是业务消息A1，而不再是业务消息A2。而且，由于业务消息A1的初始计数周期为计数周期5，当前计数周期为计数周期5，因此，当前计数周期与初始计数周期的差值小于接收队列的队列深度，即未满足业务消息A1的输出条件，因此，需要等到下一个计数周期，重新上述处理过程。

在第6-9个计数周期，排序靠前的待输出目标业务消息是业务消息A1，当前计数周期与初始计数周期的差值小于队列深度，即未满足业务消息A1的输出条件，因此，需要等到下一个计数周期，重新上述处理过程。

在第10个计数周期，排序靠前的待输出目标业务消息是业务消息A1，当前计数周期为计数周期10，当前计数周期10与业务消息A1的初始计数周期5之间的差值，等于接收队列的队列深度，因此向上层业务模块输出业务消息A1。

在输出业务消息A1后，排序靠前的待输出目标业务消息是业务消息A2，由于当前计数周期10与业务消息A2的初始计数周期1的差值，大于接收队列的队列深度，因此向上层业务模块输出业务消息A2。在输出业务消息A2后，排序靠前的待输出目标业务消息是业务消息A3，由于当前计数周期10与业务消息A3的初始计数周期2的差值，大于接收队列的队列深度，因此向上层业务模块输出业务消息A3。在输出业务消息A3后，排序靠前的待输出目标业务消息是业务消息A4，由于当前计数周期10与业务消息A4的初始计数周期5的差值，等于接收队列的队列深度，因此向上层业务模块输出业务消息A4。在输出业务消息A4后，排序靠前的待输出目标业务消息是业务消息A5，由于当前计数周期10与业务消息A5的初始计数周期3的差值，大于接收队列的队列深度，因此向上层业务模块输出业务消息A5。显然，在上述方式中，能够按照顺序依次输出业务消息A1-业务消息A2-业务消息A3-业务消息A4-业务消息A5。

其中，采用上述时机输出业务消息(即当前计数周期与初始计数周期的差值，大于或等于队列深度，才输出业务消息)，其原因可以在于：

发送端11先向接收端13发送业务消息A1，后向接收端13发送业务消息A2，接收端13需要先输出业务消息A1，后输出业务消息A2。如图6所示，接收端13在第1个计数周期，将业务消息A2存储到数据项，在第5个计数周期，将业务消息A1存储到该数据项。显然，若在第1-5个计数周期的这段时间内，接收端13输出业务消息A2，那么，就存在先输出业务消息A2，后输出业务消息A1的问题。综上所述，接收端13应该保证输出业务消息A2之前，已经在数据项中存储业务消息A1，从而确保先输出业务消息A1，后输出业务消息A2。

由于发送端11先向接收端13发送业务消息A1，后向接收端13发送业务消息A2，因此，接收端13在接收队列中存储业务消息A2之前，已经在接收队列中存储业务消息A1，也就是说，业务消息A1对应的初始计数周期与业务消息A2对应的初始计数周期之间的差值，小于接收端13的接收队列的队列深度。

综上所述，由于业务消息A1对应的初始计数周期与业务消息A2对应的初始计数周期之间的差值，小于接收队列的队列深度，因此，若当前计数周期与业务消息A2对应的初始计数周期之间的差值，大于或等于接收队列的队列深度，则说明当前计数周期之前，接收端13已经将业务消息A1存储到数据项中。

针对上述发现，本申请实施例中，针对每个业务消息(如业务消息A2)来说，若当前计数周期与该业务消息对应的初始计数周期之间的差值，大于或者等于接收队列的队列深度，则允许输出该业务消息。进一步的，当该业务消息是数据项中排序最靠前的待输出目标业务消息时，则可以输出该业务消息。

可选地，在一个例子中，当接收端13的接收队列中已经不存在业务消息时，即接收队列的所有业务消息均存储在数据项中，接收端13也可以输出数据项中排序靠前的业务消息，而不需要在当前计数周期与业务消息的初始计数周期的差值，大于或者等于队列深度后，才输出数据项中的业务消息。

可选地，在一个例子中，接收端13在输出业务消息时，可以将业务消息存储到上层业务模块的缓冲区(buffer)中，这样，上层业务模块能够从缓冲区(buffer)中读取这些业务消息，并利用这些业务消息进行处理。

可选地，在一个例子中，接收端13在输出业务消息时，先从数据项中获取多个业务消息，并将这些业务消息存储到接收端13的准备队列(ReadyQueue)。然后，接收端13可以将ReadyQueue中的每个业务消息，依次存储到上层业务模块的缓冲区中，这样，上层业务模块能够从缓冲区中读取这些业务消息。

参见上述实施例，在第10个计数周期，能够输出业务消息A1、业务消息A2、业务消息A3、业务消息A4和业务消息A5，因此，接收端13从数据项中获取业务消息A1、业务消息A2、业务消息A3、业务消息A4和业务消息A5，并将业务消息A1、业务消息A2、业务消息A3、业务消息A4和业务消息A5存储到ReadyQueue。然后，从ReadyQueue中获取排序靠前的业务消息A1，将业务消息A1存储到上层业务模块的缓冲区中；从ReadyQueue中获取排序靠前的业务消息A2，将业务消息A2存储到上层业务模块的缓冲区中，以此类推。

可选地，在一个例子中，可以结合如下实施例介绍数据结构的变化过程。

首先，参见图9A所示，为时刻1的接收队列，假设计数器为100，表示当前计数周期为第100个计数周期，数据结构可以为空。

然后，假设每个接收队列的第一个业务消息被接收，即MSG 2被接收，则MSG 2需要存储到数据结构的数据项中，且MSG 2对应的初始计数周期可以为100。参见图9B所示，为时刻2的接收队列，计数器的值被更新为101。

然后，假设每个接收队列的第一个业务消息被接收，即MSG 3被接收，则MSG 3需要存储到数据结构的数据项中，且MSG 3对应的初始计数周期可以为101。参见图9C所示，为时刻3的接收队列，计数器的值被更新为102。

然后，假设每个接收队列的第一个业务消息被接收，即MSG 5被接收，则MSG 5需要存储到数据结构的数据项中，且MSG 5对应的初始计数周期可以为102。参见图9D所示，为时刻4的接收队列，计数器的值被更新为103。

然后，假设每个接收队列的第一个业务消息被接收，当前没有业务消息存储到数据项中，参见图9E所示，为时刻5的接收队列，计数器的值被更新为104。

然后，假设每个接收队列的第一个业务消息被接收，即MSG 1和MSG 4被接收，则MSG 1和MSG 4需要存储到数据结构的数据项中，而且，MSG 1对应的初始计数周期可以为104，MSG 4对应的初始计数周期可以为104。参见图9F所示，为时刻6的接收队列，计数器的值被更新为105。

相应地，基于与上述方法同样的申请构思，本申请实施例还提出一种消息处理装置，应用于接收端，所述接收端包括多个服务Socket组件，每个服务Socket组件对应一个接收队列，参见图10所示，为所述装置的结构图，所述装置包括：

建立模块1001，用于通过目标服务Socket组件与发送端包括的目标客户Socket组件建立通信连接；其中，所述目标服务Socket组件是所述多个服务Socket组件中的任意一个，所述目标客户Socket组件是所述发送端包括的至少一个客户Socket组件中的任意一个；

存储模块1002，用于将所述发送端通过所述通信连接发送的业务消息，存储到所述目标服务Socket组件对应的接收队列。

可选地，在一个例子中，所述多个服务Socket组件包括主服务Socket组件和至少一个从服务Socket组件；所述建立模块1001，具体用于：

接收所述发送端通过所述目标客户Socket组件发送的连接请求；其中，所述连接请求是所述发送端从所有从服务Socket组件中选择一个从服务Socket组件，并将选择的从服务Socket组件作为目标服务Socket组件后发送的；所述连接请求包括所述选择的从服务Socket组件对应的目标地址；

根据所述目标地址，确定所述目标地址对应的从服务Socket组件；

通过所述从服务Socket组件与所述目标客户Socket组件建立通信连接。

可选地，在一个例子中，所述主服务Socket组件与主地址绑定，所述至少一个从服务Socket组件中的每个从服务Socket组件与一个从地址绑定，所述从地址包括所述主地址以及预设后缀，每个从地址包括的预设后缀均不同；

所述目标地址包括所述主地址以及目标后缀；所述建立模块1001根据所述目标地址，确定所述目标地址对应的从服务Socket组件时用于：根据所述主地址以及目标后缀，确定对应的从服务Socket组件。

可选地，在一个例子中，所述装置还包括(在图10中未示出)：

读取模块，用于在每个计数周期内，分别从每个服务Socket组件对应的接收队列读取相同数量的业务消息；

获取模块，用于从读取的所有业务消息中获取属于同一发送端的多个目标业务消息；

排序模块，用于按照多个目标业务消息的发送顺序，对所述多个目标业务消息进行排序；

输出模块，用于基于所述多个目标业务消息的排序结果，向上层业务模块依次输出所述多个目标业务消息。

可选地，在一个例子中，所述业务消息包括用户客户端属性参数；所述获取模块，具体用于：判断数据结构中是否存在与已读取的业务消息包括的用户客户端属性参数对应的数据项；

如果存在，则在所述数据项中存储所述业务消息；如果未存在，则在所述数据结构中建立与所述用户客户端属性参数对应的数据项，并在建立的数据项中存储所述业务消息；

从所述数据结构中获取与发送端的用户客户端属性参数对应的数据项，将获取的数据项中的所有业务消息，确定为属于所述发送端的目标业务消息。

可选地，在一个例子中，所述输出模块，具体用于：

从所述多个目标业务消息中选取排序靠前的待输出目标业务消息；

获取所述待输出目标业务消息对应的初始计数周期；

判断当前计数周期与初始计数周期的差值，是否小于接收队列的队列深度；

如果否，则向上层业务模块输出所述待输出目标业务消息；

如果是，则等到下一个计数周期，并判断当前计数周期与初始计数周期的差值，是否小于接收队列的队列深度。

本申请实施例提供的服务端，从硬件层面而言，硬件架构示意图可以参见图11所示，可以包括：机器可读存储介质和处理器，其中：

机器可读存储介质：存储指令代码。

处理器：与机器可读存储介质通信，读取和执行机器可读存储介质中存储的所述指令代码，实现本申请上述示例公开的消息处理操作。

这里，机器可读存储介质可以是任何电子、磁性、光学或其它物理存储装置，可以包含或存储信息，如可执行指令、数据，等等。例如，机器可读存储介质可以是：RAM(RadomAccess Memory，随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等)，或者类似的存储介质，或者它们的组合。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可以由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其它可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其它可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

而且，这些计算机程序指令也可以存储在能引导计算机或其它可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或者多个流程和/或方框图一个方框或者多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其它可编程数据处理设备上，使得在计算机或者其它可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其它可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (13)

1.一种消息处理方法，其特征在于，应用于接收端，所述接收端包括多个服务套接字Socket组件，每个服务Socket组件对应一个接收队列，包括：

通过目标服务Socket组件与发送端包括的目标客户Socket组件建立通信连接；其中，所述目标服务Socket组件是所述多个服务Socket组件中的任意一个，所述目标客户Socket组件是所述发送端包括的至少一个客户Socket组件中的任意一个；

将所述发送端通过所述通信连接发送的业务消息，存储到所述目标服务Socket组件对应的接收队列。

2.根据权利要求1所述的方法，其特征在于，所述多个服务Socket组件包括主服务Socket组件和至少一个从服务Socket组件；所述通过目标服务Socket组件与发送端包括的目标客户Socket组件建立通信连接，包括：

接收所述发送端通过所述目标客户Socket组件发送的连接请求；其中，所述连接请求是所述发送端从所有从服务Socket组件中选择一个从服务Socket组件，并将选择的从服务Socket组件作为目标服务Socket组件后发送的；所述连接请求包括所述选择的从服务Socket组件对应的目标地址；

根据所述目标地址，确定所述目标地址对应的从服务Socket组件；

通过所述从服务Socket组件与所述目标客户Socket组件建立通信连接。

3.根据权利要求2所述的方法，其特征在于，所述主服务Socket组件与主地址绑定，所述至少一个从服务Socket组件中的每个从服务Socket组件与一个从地址绑定，所述从地址包括所述主地址以及预设后缀，每个从地址包括的预设后缀均不同；

所述目标地址包括所述主地址以及目标后缀；

所述根据所述目标地址，确定所述目标地址对应的从服务Socket组件，包括：

根据所述主地址以及目标后缀，确定对应的从服务Socket组件。

4.根据权利要求1所述的方法，其特征在于，所述将所述发送端通过所述通信连接发送的业务消息，存储到所述目标服务Socket组件对应的接收队列之后，所述方法还包括：

在每个计数周期内，分别从每个服务Socket组件对应的接收队列读取相同数量的业务消息；

从读取的所有业务消息中获取属于同一发送端的多个目标业务消息；

按照多个目标业务消息的发送顺序，对所述多个目标业务消息进行排序；

基于所述多个目标业务消息的排序结果，向上层业务模块依次输出所述多个目标业务消息。

5.根据权利要求4所述的方法，其特征在于，所述业务消息包括用户客户端属性参数；

所述从读取的所有业务消息中获取属于同一发送端的多个目标业务消息，包括：

判断数据结构中是否存在与已读取的业务消息包括的用户客户端属性参数对应的数据项；

如果存在，则在所述数据项中存储所述业务消息；如果未存在，则在所述数据结构中建立与所述用户客户端属性参数对应的数据项，并在建立的数据项中存储所述业务消息；

从所述数据结构中获取与发送端的用户客户端属性参数对应的数据项，将获取的数据项中的所有业务消息，确定为属于所述发送端的目标业务消息。

6.根据权利要求4所述的方法，其特征在于，所述基于所述多个目标业务消息的排序结果，向上层业务模块依次输出所述多个目标业务消息，包括：

从所述多个目标业务消息中选取排序靠前的待输出目标业务消息；

获取所述待输出目标业务消息对应的初始计数周期；

判断当前计数周期与初始计数周期的差值，是否小于接收队列的队列深度；

如果否，则向上层业务模块输出所述待输出目标业务消息；

如果是，则等到下一个计数周期，并判断当前计数周期与初始计数周期的差值，是否小于接收队列的队列深度。

7.根据权利要求1-6任一所述的方法，其特征在于，所述发送端和所述接收端部署在相同的容器；或者，所述发送端和所述接收端部署在不同的容器。

8.一种消息处理装置，其特征在于，应用于接收端，所述接收端包括多个服务套接字Socket组件，每个服务Socket组件对应一个接收队列，包括：

建立模块，用于通过目标服务Socket组件与发送端包括的目标客户Socket组件建立通信连接；其中，所述目标服务Socket组件是所述多个服务Socket组件中的任意一个，所述目标客户Socket组件是所述发送端包括的至少一个客户Socket组件中的任意一个；

存储模块，用于将所述发送端通过所述通信连接发送的业务消息，存储到所述目标服务Socket组件对应的接收队列。

9.根据权利要求8所述的装置，其特征在于，所述多个服务Socket组件包括主服务Socket组件和至少一个从服务Socket组件；所述建立模块，具体用于：

接收所述发送端通过所述目标客户Socket组件发送的连接请求；其中，所述连接请求是所述发送端从所有从服务Socket组件中选择一个从服务Socket组件，并将选择的从服务Socket组件作为目标服务Socket组件后发送的；所述连接请求包括所述选择的从服务Socket组件对应的目标地址；

根据所述目标地址，确定所述目标地址对应的从服务Socket组件；

通过所述从服务Socket组件与所述目标客户Socket组件建立通信连接。

10.根据权利要求9所述的装置，其特征在于，所述主服务Socket组件与主地址绑定，所述至少一个从服务Socket组件中的每个从服务Socket组件与一个从地址绑定，所述从地址包括所述主地址以及预设后缀，每个从地址包括的预设后缀均不同；

所述目标地址包括所述主地址以及目标后缀；

所述建立模块根据所述目标地址，确定所述目标地址对应的从服务Socket组件时用于：根据所述主地址以及目标后缀，确定对应的从服务Socket组件。

11.根据权利要求8所述的装置，其特征在于，还包括：

读取模块，用于在每个计数周期内，分别从每个服务Socket组件对应的接收队列读取相同数量的业务消息；

获取模块，用于从读取的所有业务消息中获取属于同一发送端的多个目标业务消息；

排序模块，用于按照多个目标业务消息的发送顺序，对所述多个目标业务消息进行排序；

输出模块，用于基于所述多个目标业务消息的排序结果，向上层业务模块依次输出所述多个目标业务消息。

12.根据权利要求11所述的装置，其特征在于，所述业务消息包括用户客户端属性参数；所述获取模块，具体用于：

判断数据结构中是否存在与已读取的业务消息包括的用户客户端属性参数对应的数据项；

如果存在，则在所述数据项中存储所述业务消息；如果未存在，则在所述数据结构中建立与所述用户客户端属性参数对应的数据项，并在建立的数据项中存储所述业务消息；

从所述数据结构中获取与发送端的用户客户端属性参数对应的数据项，将获取的数据项中的所有业务消息，确定为属于所述发送端的目标业务消息。

13.根据权利要求11所述的装置，其特征在于，所述输出模块，具体用于：

从所述多个目标业务消息中选取排序靠前的待输出目标业务消息；

获取所述待输出目标业务消息对应的初始计数周期；

判断当前计数周期与初始计数周期的差值，是否小于接收队列的队列深度；

如果否，则向上层业务模块输出所述待输出目标业务消息；

如果是，则等到下一个计数周期，并判断当前计数周期与初始计数周期的差值，是否小于接收队列的队列深度。