CN107888637A - 拉取消息的方法、装置及系统 - Google Patents
拉取消息的方法、装置及系统 Download PDFInfo
- Publication number
- CN107888637A CN107888637A CN201610873366.9A CN201610873366A CN107888637A CN 107888637 A CN107888637 A CN 107888637A CN 201610873366 A CN201610873366 A CN 201610873366A CN 107888637 A CN107888637 A CN 107888637A
- Authority
- CN
- China
- Prior art keywords
- message
- thread
- request
- pulling
- pull
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
Abstract
本发明提供了一种拉取消息的方法、装置及系统，通过第一线程发送用于拉取消息的拉取请求给对应的消息服务器，通过第二线程接收该消息服务器返回的应答消息。本实施例中，将启动的两个线程进行专属化，其中第一线程专门用来发送拉取请求，第二线程专门用于接收应答消息，从而Consumer能够利用第一线程持续地向Broker发送拉取请求，通过第二线程持续接收从Broker返回的应答消息，即Consumer能够连续地从Broker拉取消息，实现了兼顾消息的拉取效率和资源利用率的目的。
Description
技术领域
本发明属于计算机领域，尤其涉及一种拉取消息的方法、装置及系统。
背景技术
消息中间件是用来发布/订阅消息的消息系统，该消息中间件通常提供两种消费消息的方式：推送(Push)和拉取(Pull)。消息中间件包括消息产生器(Producer)、消息消费端(Consumer)和消息服务器(Broker)，其中，Producer通过Push方式将消息发布/推送到Broker上，Consumer通过Pull方式从Broker中拉取消息。
针对Pull方式，在大规范分布式系统下，Consumer需要向多个Broker轮询发起拉取请求。例如，在分布式系统下有100个Broker，一个Consumer要消息这100个Broker上的消息，此时，Consumer可以通过Pull方式从Broker拉取消息。
目前，Consumer通过Pull方式从Broker上拉取消息有以下两种方法：
(1)启动100个线程，每个线程对应于一个Broker，然后通过该线程发送pull(拉取)请求，然后Broker对该pull请求进行处理获取相应的应答消息，再利用线程接收返回给Consumer的应答消息，这样就完成Consumer从Broker上拉取消息的过程。
(2)仅启动一个线程，当需要从100个Broker上拉取消息时，Consumer只能通过该线程逐次轮询这100个Broker，Consumer首先利用该线程发送拉取请求到一个Broker，Broker接收到拉取请求后对该拉取请求进行处理，获取相应的应答消息，然后向Consumer返回一个应答消息，Consumer利用该线程接收返回的应答消息。Consumer通过Pull方法拉取Broker上的消息的过程：每个Broker都要花费发送拉取请求的时间T1，处理拉取请求的时间T2以及返回应答消息的时间为T3，共花费的时间为T＝T1+T2+T3。在该方案中由于Consumer只能够使用一个线程，因此需要接收返回的应答消息之后，才能进行下一个消息的拉取，因此这样拉取100个Broker上的消息需要花费100倍的T。
第一种方式虽然实时性较好，但是需要使用100个线程，占用资源较多。第二种方式虽然占用资源较少，但是需要耗费时间较长，导致拉取消息的实时性和效率较差，上述两种Pull消息的方式，均无法同时兼顾拉取效率和资源利用率。
发明内容
本发明提供一种拉取消息的方法、装置及系统，用于解决现有Consumer从Broker上拉取消息的两种方式无法同时兼顾拉取效率和资源利用率的问题。
为了实现上述目的，本发明提供了一种拉取消息的系统，包括：消息消费端和消息服务器；
所述消息消费端，用于启动并初始化第一线程和第二线程，其中所述第一线程用于向所述消息服务器发送用于拉取消息的拉取请求；所述第二线程用于接收所述消息服务器返回的应答消息；
所述消息消费端，用于通过所述第一线程将所述拉取请求发送给对应的所述消息服务器，以及通过第二线程接收所述消息服务器发送的应答消息；
所述消息服务器，用于接收所述消息消费端发送的所述拉取请求，获取与所述拉取请求对应的所述应答消息并发送给所述消息消费端。
为了实现上述目的，本发明提供了一种拉取消息的方法，包括：
通过第一线程发送用于拉取消息的拉取请求给对应的消息服务器；
通过第二线程接收所述消息服务器返回的应答消息。
为了实现上述目的，本发明提供了一种拉取消息的装置，包括：
发送模块，用于通过第一线程发送用于拉取消息的拉取请求给对应的消息服务器；
接收模块，用于通过第二线程接收所述消息服务器返回的应答消息。
为了实现上述目的，本发明提供了一种拉取消息的系统，包括：消息消费端和至少一个消息服务器；
所述消息消费端，用于启动并初始化第一线程和第二线程，其中所述第一线程用于向所述消息服务器发送用于拉取消息的拉取请求；所述第二线程用于接收所述消息服务器返回的应答消息；
所述消息消费端，用于当拉取多个消息服务器上的消息时，将所有待发送的拉取请求进行排序，按照顺序通过所述第一线程将每个拉取请求发送给对应的消息服务器，以及通过所述第二线程逐次接收各消息服务器返回的应答消息；
所述消息服务器，用于接收所述消息消费端发送的所述拉取消息，获取与所述拉取请求对应的所述应答消息，以及将所述应答消息发送给所述消息消费端。
为了实现上述目的，本发明提供了一种拉取消息的方法，包括：
当拉取多个消息服务器上的消息时，将所有待发送的拉取请求进行排序；
按照顺序通过所述第一线程将每个拉取请求发送给对应的所述消息服务器；
通过第二线程接收各消息服务器返回的所述应答消息。
为了实现上述目的，本发明提供了一种拉取消息的装置，包括：
排序模块，用于当拉取多个消息服务器上的消息时，将所有待发送的拉取请求进行排序；
发送模块，用于按照顺序通过所述第一线程将每个拉取请求发送给对应的所述消息服务器；
接收模块，用于通过第二线程接收各消息服务器返回的所述应答消息。
为了实现上述目的，本发明提供了一种拉取消息的方法，包括：
接收通过第一线程发送的用于拉取消息的拉取请求，所述第一线程由消息消费端设置为专门用于发送所述拉取请求；
向第二线程返回与所述拉取请求对应的应答消息，所述第二线程由所述消息消费端设置为专门用于接收所述应答消息。
为了实现上述目的，本发明提供了一种拉取消息的装置，包括：
接收模块，用于接收通过第一线程发送的用于拉取消息的拉取请求，所述第一线程由消息消费端设置为专门用于发送所述拉取请求；
返回模块，用于向第二线程返回与所述拉取请求对应的应答消息，所述第二线程由所述消息消费端设置为专门用于接收所述应答消息。
本发明提供的拉取消息的方法、装置及系统，通过第一线程发送用于拉取消息的拉取请求给对应的消息服务器，通过第二线程接收该消息服务器返回的应答消息。本实施例中，将启动的两个线程进行专属化，其中第一线程专门用来发送拉取请求，第二线程专门用于接收应答消息，从而Consumer能够利用第一线程持续地向Broker发送拉取请求，通过第二线程持续接收从Broker返回的应答消息，即Consumer能够连续地从Broker拉取消息，实现了兼顾消息的拉取效率和资源利用率的目的。
附图说明
图1为本发明实施例一的拉取消息的方法的流程示意图；
图2为本发明实施例二的拉取消息的方法的流程示意图；
图3为本发明实施例三的拉取消息的方法的流程示意图；
图4为本发明实施例三中的拉取消息的方法的应用示意图之一；
图5为本发明实施例三中的拉取消息的方法的应用示意图之二；
图6为本发明实施例三中的拉取消息的方法的应用示意图之三；
图7为本发明实施例四的拉取消息的方法的流程示意图；
图8为本发明实施例五的拉取消息的装置的结构示意图；
图9为本发明实施例六的拉取消息的装置的结构示意图；
图10为本发明实施例七的拉取消息的装置的结构示意图；
图11为本发明实施例八的拉取消息的装置的结构示意图；
图12为本发明实施例九的拉取消息的系统的结构示意图；
图13为本发明实施例十的拉取消息的系统的结构示意图。
具体实施方式
下面结合附图对本发明实施例提供的拉取消息的方法、装置及系统进行详细描述。
实施例一
如图1所示，其为本发明实施例一的拉取消息的方法的流程示意图。该拉取消息的方法包括以下步骤：
S101、通过第一线程发送用于拉取消息的拉取请求给对应的消息服务器。
首先，从闲置的多个线程中，选取两个线程，然后将对选取的两个线程进行初始化，在初始化的过程中，将一个线程初始化成专门用于向Broker发送拉取请求的第一线程，以及将另一个初始化成专门用于接收Broker返回的应答消息的第二线程。
当Consumer需要从Broker上拉取消息，Consumer则可以通过第一线程发送拉取请求时，将该拉取请求发送给对应的消息服务器上。
当一个拉取请求发送出去后，则该第一线程就可以处于等待状态，当有下一个拉取请求需要发送时，由于第一线程只负责向Broker发送拉取请求，第一线程则可以立刻发送下一个拉取请求。
S102、通过第二线程接收对应的消息服务器返回的应答消息。
当通过第一线程将消息发送给对应的消息服务器即对应的Broker后，对应的Broker根据接收到的拉取请求，获取与该拉取请求对应的数据。对应的Broker将这些拉取到的数据作为应答消息返给Consumer。Consumer则通过第二线程接收对应的Broker返回的应答消息。
相应地，由于第二线程只负责接收Broker返回应答消息，当接收完一个应答消息后，则该第二线程就可以处于等待状态，当有下一个应答消息需要接收时，第二线程则可以立刻接收下一个应答消息。
本实施例提供的拉取消息的方法，通过第一线程发送用于拉取消息的拉取请求给对应的消息服务器，通过第二线程接收该消息服务器返回的应答消息。本实施例中，将启动的两个线程进行专属化，其中第一线程专门用来发送拉取请求，第二线程专门用于接收应答消息，从而Consumer能够利用第一线程持续地向Broker发送拉取请求，通过第二线程持续接收从Broker返回的应答消息，即Consumer能够连续地从Broker拉取消息，实现了兼顾消息的拉取效率和资源利用率的目的。
实施例二
如图2所示，其为本发明实施例二的拉取消息的方法的流程示意图。该拉取消息的方法包括以下步骤：
S201、启动两个线程。
具体地，从闲置的多个线程中，选取两个线程，然后将对选取的两个线程进行初始化，在初始化的过程中，将一个线程初始化成专门用于向Broker发送拉取请求的第一线程，以及将另一个初始化成专门用于接收Broker返回的应答消息的第二线程。
S202、分析拉取请求的目标类型。
当Consumer需要从Broker上拉取消息，Consumer通过第一线程将该拉取请求发送给对应的消息服务器。一般情况下，一个Broker上存放相同类型的消息，为相同类型的消息设置一个拉取请求类型。具体地，对拉取请求进行分析，获取到该拉取请求的目标类型。
S203、获取与目标类型对应的消息服务器。
在获取到该目标类型后，确定与该目标类型对应的消息服务器。本实施例中，在Consumer中预先存储有拉取请求类型与消息服务器标识之间的映射关系。其中，该映射关系可以以一个列表的形式存储在Consumer中。在获取到目标类型后，可以查询上述映射关系，能够得到与该目标类型对应的消息服务器的标识信息。其中，消息服务器的标识可以为消息服务器的地址信息，包括IP地址和端口号。本实施例中，在Consumer上存储有拉取请求类型与消息服务器标识之间的映射关系，从而能够将拉取请求发送给对应的消息服务器上。
S204、将拉取请求通过第一线程发送给对应的消息服务器。
在获取到拉取请求对应的消息服务器之后，可以根据该消息服务器的标识即地址信息，按照该消息服务器的IP地址以及端口号，将该拉取请求通过第一线程发送给该消息服务器。
本实施例中，当一个拉取请求发送出去后，则该第一线程就可以处于等待状态，当有下一个拉取请求需要发送时，由于第一线程只负责向Broker发送拉取请求，第一线程则可以立刻发送下一个拉取请求。
S205、通过第二线程接收消息服务器返回的应答消息。
当通过第一线程将拉取请求发送给对应的消息服务器即对应的Broker后，对应的Broker根据接收到的拉取请求，获取与该拉取请求对应的数据。对应的Broker将这些拉取到的数据作为应答消息返给Consumer。Consumer则通过第二线程接收对应的Broker返回的应答消息。其中，应答消息中可以携带Consumer的标识，从能够将该应答消息返回给Consumer。
相应地，由于第二线程只负责接收Broker返回应答消息，当接收完一个应答消息后，则该第二线程就可以处于等待状态，当有下一个应答消息需要接收时，第二线程则可以立刻接收下一个应答消息。
本实施例提供的拉取消息的方法，启动了两个线程，根据拉取请求的类型获取到对应的消息服务器，然后通过第一线程发送拉取请求给对应的消息服务器，通过第二线程接收该消息服务器返回的应答消息。本实施例中，将启动的两个线程进行专属化，其中第一线程专门用来发送拉取请求，第二线程专门用于接收应答消息，从而Consumer能够利用第一线程持续地向Broker发送拉取请求，通过第二线程持续接收从Broker返回的应答消息，即Consumer能够连续地从Broker拉取消息，实现了兼顾消息的拉取效率和资源利用率的目的。
实施例三
如图3所示，其为本发明实施例三的拉取消息的方法的流程示意图。该拉取消息的方法包括以下步骤：
S301、启动两个线程。
具体地，从闲置的多个线程中，选取两个线程，然后将对选取的两个线程进行初始化，在初始化的过程中，将一个线程初始化成专门用于向Broker发送拉取请求的第一线程，以及将另一个初始化成专门用于接收Broker返回的应答消息的第二线程。
S302、当拉取多个消息服务器上的消息时，将所有待发送的拉取请求进行排序。
当需要同时对多个Broker上的消息进行拉取时，为了避免多个拉取请求出现资源竞争，而导致第一线程出现拥堵，无法及时发送拉取请求的现象，可以将所有待发送的拉取请求进行排序。本实施例中，可以预先为每个拉取请求的类型设置一个优先级，然后按照预设的拉取请求类型的优先级，对拉取请求进行排序。在排序后生成一个请求队列，该请求队列中包括排序后的拉取请求。
例如，同时有三个拉取请求需要通过第一线程发送时，三个拉取请求分别为：拉取请求1、拉取请求2和拉取请求3。需要对三个拉取请求进行排序，三个拉取请求分别对应的类型为类型1、类型2和类型3。由于预先设置了这三个类型的优先级顺序为类型2、类型1和类型3，按照拉取请求类型的优先级对三个拉取请求进行排序，排序后的顺序为：拉取请求2、拉取请求1和拉取请求3，则相应的请求队列为拉取请求2、拉取请求1和拉取请求3。
S303、按照顺序通过第一线程将每个拉取请求发送给对应的消息服务器。
在生成请求队列后，当前一个拉取请求通过第一线程发送完成后，可以按照顺序依次从请求队列中取出一个拉取请求，通过第一线程发送给该拉取请求到对应的消息服务器上。通过所述第一线程将下一个拉取请求发送给对应的消息服务器。
本实施例中，在Consumer中预先存储有拉取请求类型与消息服务器标识之间的映射关系。其中，该映射关系可以一个列表的形式存储在Consumer中。在获取到目标类型后，可以查询上述映射关系，能够得到与该目标类型对应的消息服务器的标识信息。其中，消息服务器的标识信息可以为消息服务器的地址信息，包括IP地址和端口号。本实施例中，在Consumer上存储有拉取请求类型与消息服务器标识之间的映射关系，从而能够将拉取请求发送给对应的消息服务器上。
在获取到拉取请求对应的消息服务器之后，可以根据该消息服务器的标识即地址信息，按照该消息服务器的IP地址以及端口号，将该拉取请求通过第一线程发送给该消息服务器。
本实施例中，当一个拉取请求发送出去后，则该第一线程就可以处于等待状态，当有下一个拉取请求需要发送时，由于第一线程只负责向Broker发送拉取请求，第一线程则可以立刻发送下一个拉取请求。
S304、通过第二线程接收各消息服务器返回的应答消息。
当通过第一线程将消息发送给对应的消息服务器即对应的Broker后，对应的Broker根据接收到的拉取请求，获取与该拉取请求对应的数据。对应的Broker将这些拉取到的数据作为应答消息返给Consumer。Consumer则通过第二线程接收对应的Broker返回的应答消息。其中，应答消息中可以携带Consumer的标识，从能够将该应答消息返回给Consumer。
相应地，由于第二线程只负责接收Broker返回应答消息，当接收完一个应答消息后，则该第二线程就可以处于等待状态，当有下一个应答消息需要接收时，第二线程则可以立刻接收下一个应答消息。
为了更好地理解本实施例提供的拉取消息的方法，下面举例进行说明：
Consumer需要从4个Broker上拉取消息，每个Broker上的消息类型不同，相应对应的拉取请求的类型也不一样。一个Broker对应一个拉取请求的类型，Broker1～Broker4分别对应拉取请求的类型1～拉取请求的类型4。而Broker上存储有与拉取请求的类型对应的消息。例如，Broker1上存储有消息1～消息20，消息1～消息20对应拉取请求的类型1。
在Consumer上存储有一个映射关系表，映射关系表里面包括拉取请求类型与Broker的ID之间的对应关系，其中，Broker的ID可以为地址信息，如IP地址、端口号等信息。
对这4个拉取请求进行排序，生成一个请求队列，例如预先设置为不同的拉取请求的类型设置优先级，然后可以按照拉取请求的类型的优先级对拉取请求进行排序，也可以随机排序。例如，拉取请求的类型可以包括：拉取账户账单、拉取账户余额、拉取账户信用度以及拉取账户基本信息等。拉取请求的类型的优先级顺序为：拉取账户余额、拉取账户账单、拉取账户信用度、拉取账户基本信息。
当Consumer想同时拉取账户账单的拉取请求1、拉取账户余额的拉取请求2以及拉取账户信用度的拉取请求3时，则可以按照优先级对拉取请求进行排序，生成一个请求队列，则该请求队列为：拉取请求2、拉取请求1和拉取请求3。逐次从请求队列中取出一个拉取请求，通过第一线程将取出的拉取请求发送给对应的Broker，通过第二线程接收对应Broker返回的应答消息。
如图4～图6为从Broker上拉取消息的示意图。
如4所示，从请求队列中取出第一个拉取请求，即拉取请求2，分析该拉取请求2的类型为拉取账户余额，查询映射关系表，获取到与该类型对应的Broker 2的地址信息即IP地址和端口号，然后按照Broker 2的IP地址和端口号，通过第一线程将拉取请求2发送给Broker 2。
如图5所示，在发送出该拉取请求2后，立刻从请求队列中取出下一个拉取请求，在该示例中为拉取请求1，分析该拉取请求1的类型为拉取账户账单，查询映射关系表，获取到与该类型对应的Broker 1的地址信息即IP地址和端口号，然后按照Broker 1的IP地址和端口号，通过第一线程将拉取请求1发送给Broker 1。
类似地，在发送出该拉取请求1后，立马从请求队列中取出下一个拉取请求，在该示例中为拉取请求3，分析该拉取请求3的类型为拉取账户信用度，查询映射关系表，获取到与该类型对应的Broker 3的地址信息即IP地址和端口号，然后按照Broker 3的IP地址和端口号，通过第一线程将拉取请求3发送给Broker 3。
如图6所示，当Broker2接收到拉取请求2后，获取相应的数据，生成一个应答消息，然后第二线程异步地接收Broker 2返回给Consumer的应答消息。相应地，在该第二线程上也是逐次接收Broker1和Broker2返回的应答消息。
本实施例中，将启动的两个线程进行专属化，其中第一线程专门用来发送拉取请求，第二线程专门用于接收应答消息，从而Consumer能够利用第一线程持续地向Broker发送拉取请求，通过第二线程持续接收从Broker返回的应答消息，即Consumer能够连续地从Broker拉取消息，实现了兼顾消息的拉取效率和资源利用率的目的。
进一步地通过对拉取请求进行排序，按照顺序通过第一线程将拉取请求发送给对应的消息服务器，可以避免资源竞争导致第一线程出现拥堵，无法及时地发送拉取请求的现象，更加提高了从Broker上拉取消息的效率。
实施例四
如图7所示，其为本发明实施例四的拉取消息的方法的流程示意图。该拉取消息的方法包括以下步骤：
S401、接收通过消息消费端上的第一线程发送的用于拉取消息的拉取请求。
其中，第一线程由消息消费端设置为专门用于发送所述拉取请求。
S402、向消息消费端上的第二线程返回与拉取请求对应的应答消息。
其中，第二线程由消息消费端设置为专门用于接收应答消息。
本实施例中，当Consumer需要从Broker上拉取消息时，Consumer需要启动两个线程，包括第一线程和第二线程，将第一线程和第二线程进行专属化设置，将第一线程初始化为专门用于发送拉取请求，以及将第二线程初始化为专门用于接收从Broker处返回的与拉取请求对应的应答消息。
Broker接收Consumer通过第一线程发送来过来的拉取请求，然后根据拉取请求进行数据查询，将获取到与该拉取请求对应的数据作为应答消息。
在获取到与拉取请求对应的应答消息后，Broker需要将该应该消息反馈给Consumer。由于Consumer通过第二线程专门接收Broker发送的应答消息，则Broker相应地需要将应答消息发送给Consumer上的第二线程。
本实施例中，由于第一线程专门作为发送拉取消息的线程，这样拉取请求可以不间断地发送给Broker，相应地Broker就可以根据接收到的拉取请求，获取相应的应答消息，从而可以提高拉取消息的效率，而且由于第二线程专门用于接收从Broker上返回的应答消息，当Consumer接收到当前的应答消息后，就可以准备接收下一个应答消息，从而Broker可以将获取到的应答消息及时地反馈给Consumer，这样Consumer能够连续地从Broker拉取消息，从而实现了兼顾消息的拉取效率和资源利用率的目标。
实施例五
如图8所示，其为本发明实施例五的拉取消息的装置的结构示意图。该拉取消息的装置包括：启动模块11、发送模块12和接收模块13。
其中，启动模块11，用于启动两个线程；其中所述两个线程包括第一线程和第二线程。
启动模块11从闲置的多个线程中，选取两个线程，然后将对选取的两个线程进行初始化，在初始化的过程中，启动模块11将一个线程初始化成专门用于向Broker发送拉取请求的第一线程，以及将另一个初始化成专门用于接收Broker返回的应答消息的第二线程。
发送模块12，用于通过所述第一线程发送用于拉取消息的拉取请求给对应的消息服务器。
当Consumer需要从Broker上拉取消息，发送模块12通过第一线程发送拉取请求时，将该拉取请求发送给对应的消息服务器上。
当一个拉取请求发送出去后，则该第一线程就可以处于等待状态，当有下一个拉取请求需要发送时，由于第一线程只负责向Broker发送拉取请求，第一线程则可以立刻发送下一个拉取请求。
接收模块13，用于通过第二线程接收消息服务器返回的应答消息。
当通过第一线程将消息发送给对应的消息服务器即对应的Broker后，对应的Broker根据接收到的拉取请求，获取与该拉取请求对应的数据。对应的Broker将这些拉取到的数据作为应答消息返给Consumer。接收模块13则通过第二线程接收对应的Broker返回的应答消息。
相应地，由于第二线程只负责接收Broker返回应答消息，当接收完一个应答消息后，则该第二线程就可以处于等待状态，当有下一个应答消息需要接收时，第二线程则可以立刻接收下一个应答消息。
本实施例提供的拉取消息的装置，启动了两个线程，通过第一线程发送用于拉取消息的拉取请求给对应的消息服务器，通过第二线程接收该消息服务器返回的应答消息。本实施例中，将启动的两个线程进行专属化，其中第一线程专门用来发送拉取请求，第二线程专门用于接收应答消息，从而Consumer能够利用第一线程持续地向Broker发送拉取请求，通过第二线程持续接收从Broker返回的应答消息，即Consumer能够连续地从Broker拉取消息，实现了兼顾消息的拉取效率和资源利用率的目的。
实施例六
如图9所示，其为本发明实施例六的拉取消息的装置的结构示意图。该拉取消息的装置包括上述实施例五中的启动模块11、发送模块12和接收模块13。
本实施例中，发送模块12一种可选地结构方式，包括：
分析单元121，用于分析所述拉取请求的目标类型。
获取单元122，用于获取与所述目标类型对应的所述消息服务器。
发送单元123，用于将所述拉取请求通过所述第一线程发送到所述消息服务器。
进一步地，获取单元122，具体用于查询预存的拉取请求类型与消息服务器标识之间的映射关系，以获取与所述目标类型对应的所述消息服务器的目标标识。
本实施例中，发送单元123一种可选地结构方式，包括：
排序子单元1231，用于当拉取多个消息服务器上的消息时，将所有待发送的拉取消息进行排序。
发送子单元1232，用于按照顺序通过所述第一线程将所述拉取请求发送给对应的所述消息服务器。
进一步地，排序子单元1231，具体用于当拉取多个消息服务器上的消息时，获取所有待发送的拉取请求的类型，按照预设的拉取请求类型的优先级，对所有待发送的拉取请求进行排序，以及将排序后的所有拉取请求生成一个请求队列。
进一步地，发送子单元1232，具体用于当前一个拉取请求通过所述第一线程发送完成后，从所述请求队列中取出下一个拉取请求，通过所述第一线程将所述下一个拉取请求发送给对应的所述消息服务器。
本实施例中，应答消息中携带消息消费端的标识。
启动模块11，具体用于从闲置的线程中选取两个线程，将一个线程初始化成专门用于发送所述拉取请求的所述第一线程，以及将另一个初始化成专门用于接收所述应答消息的所述第二线程。
本实施例中，消息服务器标识为所述消息服务器的地址信息，包括IP地址和端口号。
本实施例中，将启动的两个线程进行专属化，其中第一线程专门用来发送拉取请求，第二线程专门用于接收应答消息，从而Consumer能够利用第一线程持续地向Broker发送拉取请求，通过第二线程持续接收从Broker返回的应答消息，即Consumer能够连续地从Broker拉取消息，实现了兼顾消息的拉取效率和资源利用率的目的。进一步地，在多个拉取请求需要发送时，通过对拉取请求进行排序，按照顺序通过第一线程将拉取请求发送给对应的消息服务器，可以避免资源竞争导致第一线程出现拥堵，无法及时地发送拉取请求的现象，更加提高了从Broker上拉取消息的效率。
实施例七
图10所示，其为本发明实施例七的拉取消息的装置的结构示意图。该拉取消息的装置包括：排序模块21、发送模块22和接收模块23。
排序模块21，用于当拉取多个消息服务器上的消息时，将所有待发送的拉取请求进行排序。
发送模块22，用于按照顺序通过所述第一线程将每个拉取请求发送给对应的所述消息服务器。
接收模块23，用于通过第二线程接收各消息服务器返回的所述应答消息。
其中，排序模块21，具体用于获取所有待发送的拉取请求的类型，按照预设的拉取请求类型的优先级，对所有待发送的拉取请求进行排序，将排序后的所有拉取请求生成一个请求队列。
发送模块22，具体用于按序从所述请求队列中取出一个拉取请求，查询预存的拉取请求类型与消息服务器标识之间的映射关系，获取到与所述拉取请求类型对应的消息服务器的标识信息，通过所述第一线程将所述拉取请求发送给与所述标识信息对应的所述消息服务器。
本实施例中，拉取消息的装置，还包括：
初始化模块24，用于从闲置的线程中选取两个线程，将一个线程初始化成专门用于发送所述拉取请求的所述第一线程，以及将另一个初始化成专门用于接收所述应答消息的所述第二线程。
本实施例中，将启动的两个线程进行专属化，其中第一线程专门用来发送拉取请求，第二线程专门用于接收应答消息，在多个拉取请求需要发送时，通过对拉取请求进行排序，按照顺序通过第一线程将拉取请求发送给对应的消息服务器，可以避免资源竞争导致第一线程出现拥堵，无法及时地发送拉取请求的现象，更加提高了从Broker上拉取消息的效率。
实施例八
图11所示，其为本发明实施例八的拉取消息的装置的结构示意图。该拉取消息的装置包括：接收模块31和返回模块32。
其中，接收模块31，用于接收通过消息消费端上的第一线程发送的用于拉取消息的拉取请求，所述第一线程由消息消费端设置为专门用于发送所述拉取请求。
返回模块32，用于向所述消息消费端上的第二线程返回与所述拉取请求对应的应答消息，所述第二线程由所述消息消费端设置为专门用于接收所述应答消息。
本实施例中，当Consumer需要从Broker上拉取消息时，Consumer需要启动两个线程，包括第一线程和第二线程，将第一线程和第二线程进行专属化设置，将第一线程初始化为专门用于发送拉取请求，以及将第二线程初始化为专门用于接收从Broker处返回的与拉取请求对应的应答消息。
接收模块31接收Consumer通过第一线程发送来过来的拉取请求。在获取到拉取请求后，返回模块32根据拉取请求进行数据查询，将获取到与该拉取请求对应的数据作为应答消息。
在获取到与拉取请求对应的应答消息后，返回模块32需要将该应该消息反馈给Consumer。由于Consumer通过第二线程专门接收Broker发送的应答消息，则返回模块32相应地需要将应答消息发送给Consumer上的第二线程。
本实施例中，由于第一线程专门作为发送拉取消息的线程，这样拉取请求可以不间断地发送给Broker，相应地Broker就可以根据接收到的拉取请求，获取相应的应答消息，从而可以提高拉取消息的效率，而且由于第二线程专门用于接收从Broker上返回的应答消息，当Consumer接收到当前的应答消息后，就可以准备接收下一个应答消息，从而Broker可以将获取到的应答消息及时地反馈给Consumer，这样Consumer能够连续地从Broker拉取消息，从而实现了兼顾消息的拉取效率和资源利用率的目标。
实施例九
如图12所示，其为本发明实施例九的拉取消息的系统的结构示意图。该拉取消息的系统包括：消息消费端41和消息服务器42。
其中，消息消费端41，用于启动两个线程；其中所述两个线程包括第一线程411和第二线程412。具体地，消息消费端41从闲置的多个线程中，选取两个线程，然后将对选取的两个线程进行初始化，在初始化的过程中，消息消费端41将一个线程初始化成专门用于向Broker 42发送拉取请求的第一线程411，并将另一个初始化成专门用于接收Broker 42返回的应答消息的第二线程412。
当Consumer 41需要从Broker 42上拉取消息，Consumer 41通过第一线程411将该拉取请求发送给对应的Broker 42。
一般情况下，一个Broker 42上存放相同类型的消息，为相同类型的消息设置一个拉取请求类型。具体地，Consumer 41可以分析拉取请求的目标类型，获取与所述目标类型对应的消息服务器42即Broker 42，然后Consumer 41将该拉取请求通过第一线程411发送到对应的Broker 42上。
Consumer 41在获取到该目标类型后，确定与该目标类型对应的消息服务器42。本实施例中，在Consumer 41中预先存储有拉取请求类型与消息服务器标识之间的映射关系。其中，该映射关系可以以一个列表的形式存储在Consumer 41中。在获取到目标类型后，可以查询上述映射关系，能够得到与该目标类型对应的消息服务器的标识信息。其中，消息服务器的标识可以为消息服务器的地址信息，包括IP地址和端口号。
在获取到对应的消息服务器42的标识信息后，Consumer 41通过第一线程411，将拉取请求发送给与该标识信息对应的Broker 42，进一步地，Broker 42获取与该拉取请求对应的数据，Broker 42将获取到的数据作为应答消息返给Consumer 41，Consumer 41通过该第二线程412接收应答消息。
进一步地，当Consumer 41需要同时对多个Broker 42上的消息进行拉取时，为了避免多个拉取请求出现资源竞争，而导致第一线程111出现拥堵，无法及时发送拉取请求的现象，可以将所有待发送的拉取请求进行排序。本实施例中，可以预先为每个拉取请求的类型设置一个优先级，然后按照预设的拉取请求类型的优先级，对拉取请求进行排序。在排序后生成一个请求队列，该请求队列中包括排序后的拉取请求。
关于对多个拉取请求排序的介绍，可参见上述实施例中相关内容的记载，此处不再赘述。
本实施例中，当一个拉取请求发送出去后，则该第一线程411就可以处于等待状态，当有下一个拉取请求需要发送时，由于第一线程411只负责向Broker 42发送拉取请求，第一线程411则可以立刻发送下一个拉取请求。
在生成请求队列后，当前一个拉取请求通过第一线程411发送完成后，Consumer41可以按照顺序依次从请求队列中取出一个拉取请求，通过第一线程411发送给该拉取请求到对应的Broker 42上。
当通过第一线程411将消息发送给对应的消息服务器42即对应的Broker 42后，对应的Broker 42根据接收到的拉取请求，获取与该拉取请求对应的数据。对应的Broker 42将这些拉取到的数据作为应答消息返给Consumer 41。Consumer 41则通过第二线程412接收对应的Broker 42返回的应答消息。
相应地，由于第二线程412只负责接收Broker 42返回应答消息，当接收完一个应答消息后，则该第二线程412就可以处于等待状态，当有下一个应答消息需要接收时，第二线程412则可以立刻接收下一个应答消息。
本实施例提供的拉取消息的系统，启动了两个线程，通过第一线程发送用于拉取消息的拉取请求给对应的消息服务器，通过第二线程接收该消息服务器返回的应答消息。本实施例中，将启动的两个线程进行专属化，其中第一线程专门用来发送拉取请求，第二线程专门用于接收应答消息，从而Consumer能够利用第一线程持续地向Broker发送拉取请求，通过第二线程持续接收从Broker返回的应答消息，即Consumer能够连续地从Broker拉取消息，实现了兼顾消息的拉取效率和资源利用率的目的。
实施例十
如图13所示，其为本发明实施例十的拉取消息的系统的结构示意图。该拉取消息的系统包括：消息消费端51和至少一个消息服务器52。
消息消费端51，用于启动两个线程；其中所述两个线程包括第一线程511和第二线程512。消息消费端51将一个线程初始化成专门用于向Broker 52发送拉取请求的第一线程511，以及将另一个初始化成专门用于接收Broker 52返回的应答消息的第二线程512。
当Consumer 51需要拉取多个Broker 52上的消息时，可以通过第一线程511逐次将每个拉取请求发送给对应的Broker 52。
本实施例中，Consumer 51首先需要将所有待发送的拉取请求进行排序，再按照顺序通过第一线程511将每个拉取请求发送给对应的Broker 52。
一般情况下，一个Broker 52上存放相同类型的消息，为相同类型的消息设置一个拉取请求类型。具体地，Consumer 51可以对所有拉取请求的类型进行分析，获取所有待发送的拉取请求的类型，按照预设的拉取请求类型的优先级，对所有待发送的拉取请求进行排序，将排序后的所有拉取请求生成一个请求队列。
本实施例中，当前一个拉取请求通过第一线程511发送完成后，由于第一线程511只负责向Broker 52发送拉取请求，Consumer 51就可以从请求队列中取出下一个拉取请求，则可以通过该第一线程511立刻发送下一个拉取请求给对应的Broker 52。具体地，Consumer 51按照顺序从请求队列中取出一个拉取请求后，查询预存的拉取请求类型与消息服务器标识之间的映射关系，获取到与该拉取请求类型对应的消息服务器的标识信息，然后通过第一线程511将该拉取请求发送给与标识信息对应的消息服务器Broker 52。其中，消息服务器的标识信息可以为该消息服务器的地址信息，包括IP地址和端口号。
为了更好地理解本实施例提供的拉取消息的系统，可参见上述实施例三中的具体示例的描述，以及图4～图6中的相关内容，此处不再赘述。
本实施例中，将启动的两个线程进行专属化，其中第一线程专门用来发送拉取请求，第二线程专门用于接收应答消息，在消息消费端需要从多个消息服务器上拉取消息时，先对拉取请求进行排序，按照顺序通过第一线程将拉取请求发送给对应的消息服务器，可以避免资源竞争导致第一线程出现拥堵，无法及时地发送拉取请求的现象，更加提高了从消息服务器上拉取消息的效率。
本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。
Claims (23)
1.一种拉取消息的系统，其特征在于，包括：消息消费端和消息服务器；
所述消息消费端，用于启动并初始化第一线程和第二线程，其中所述第一线程用于向所述消息服务器发送用于拉取消息的拉取请求；所述第二线程用于接收所述消息服务器返回的应答消息；
所述消息消费端，用于通过所述第一线程将所述拉取请求发送给对应的所述消息服务器，以及通过第二线程接收所述消息服务器发送的应答消息；
所述消息服务器，用于接收所述消息消费端发送的所述拉取请求，获取与所述拉取请求对应的所述应答消息并发送给所述消息消费端。
2.根据权利要求1所述的拉取消息的系统，其特征在于，所述消息消费端，具体用于分析所述拉取请求的目标类型，获取与所述目标类型对应的所述消息服务器，并将所述拉取请求通过所述第一线程发送到所述消息服务器。
3.根据权利要求2所述的拉取消息的系统，其特征在于，所述消息消费端，具体用于查询预存的拉取请求类型与消息服务器标识之间的映射关系，以获取与所述目标类型对应的所述消息服务器的标识信息，根据所述标识信息将所述拉取请求通过所述第一线程发送给所述消息服务器。
4.根据权利要求3所述的拉取消息的系统，其特征在于，所述消息消费端，还用于当拉取多个消息服务器上的消息时，将所有待发送的拉取请求进行排序，按照顺序通过所述第一线程逐次将所述拉取请求发送给对应的所述消息服务器。
5.一种拉取消息的方法，其特征在于，包括：
通过第一线程发送用于拉取消息的拉取请求给对应的消息服务器；
通过第二线程接收所述消息服务器返回的应答消息。
6.根据权利要求5所述的拉取消息的方法，其特征在于，所述通过第一线程发送用于拉取消息的拉取请求给对应的消息服务器，包括：
分析所述拉取请求的目标类型；
获取与所述目标类型对应的所述消息服务器；
将所述拉取请求通过所述第一线程发送到所述消息服务器。
7.根据权利要求6所述的拉取消息的方法，其特征在于，所述获取与所述目标类型对应的所述消息服务器，包括：
查询预存的拉取请求类型与消息服务器标识之间的映射关系，以获取与所述目标类型对应的所述消息服务器的标识信息。
8.根据权利要求7所述的方法，其特征在于，所述将所述拉取请求通过所述第一线程发送到所述消息服务器，包括：
当拉取多个消息服务器上的消息时，将所有待发送的拉取请求进行排序；
按照顺序通过所述第一线程将所述拉取请求发送给对应的所述消息服务器。
9.根据权利要求8所述的拉取消息的方法，其特征在于，所述当拉取多个消息服务器上的消息时，将所有待发送的拉取请求进行排序，包括：
当拉取多个消息服务器上的消息时，获取所有待发送的拉取请求的类型；
按照预设的拉取请求类型的优先级，对所有待发送的拉取请求进行排序；
将排序后的所有拉取请求生成一个请求队列。
10.根据权利要求9所述的拉取消息的方法，其特征在于，所述按照顺序通过所述第一线程将所述拉取请求发送给对应的所述消息服务器，包括
当前一个拉取请求通过所述第一线程发送完成后，从所述请求队列中取出下一个拉取请求；
通过所述第一线程将所述下一个拉取请求发送给对应的所述消息服务器。
11.根据权利要求6-10任一项所述的拉取消息的方法，其特征在于，所述应答消息中携带消息消费端的标识。
12.根据权利要求11所述的拉取消息的方法，其特征在于，所述通过第一线程发送用于拉取消息的拉取请求给对应的消息服务器之前，包括：
从闲置的线程中选取两个线程；
将一个线程初始化成专门用于发送所述拉取请求的所述第一线程，以及将另一个初始化成专门用于接收所述应答消息的所述第二线程。
13.根据权利要求7所述的拉取消息的方法，其特征在于，所述消息服务器标识为所述消息服务器的地址信息，包括IP地址和端口号。
14.一种拉取消息的装置，其特征在于，包括：
发送模块，用于通过第一线程发送用于拉取消息的拉取请求给对应的消息服务器；
接收模块，用于通过第二线程接收所述消息服务器返回的应答消息。
15.一种拉取消息的系统，其特征在于，包括：消息消费端和至少一个消息服务器；
所述消息消费端，用于启动并初始化第一线程和第二线程，其中所述第一线程用于向所述消息服务器发送用于拉取消息的拉取请求；所述第二线程用于接收所述消息服务器返回的应答消息；
所述消息消费端，用于当拉取多个消息服务器上的消息时，将所有待发送的拉取请求进行排序，按照顺序通过所述第一线程将每个拉取请求发送给对应的消息服务器，以及通过所述第二线程逐次接收各消息服务器返回的应答消息；
所述消息服务器，用于接收所述消息消费端发送的所述拉取消息，获取与所述拉取请求对应的所述应答消息，以及将所述应答消息发送给所述消息消费端。
16.根据权利要求15所述的拉取消息的系统，其特征在于，所述消息消费端，具体用于获取所有待发送的拉取请求的类型，按照预设的拉取请求类型的优先级，对所有待发送的拉取请求进行排序，将排序后的所有拉取请求生成一个请求队列，按序从所述请求队列中取出一个拉取请求，查询预存的拉取请求类型与消息服务器标识之间的映射关系，获取到与所述拉取请求类型对应的消息服务器的标识信息，通过所述第一线程将所述拉取请求发送给与所述标识信息对应的所述消息服务器。
17.一种拉取消息的方法，其特征在于，包括：
当拉取多个消息服务器上的消息时，将所有待发送的拉取请求进行排序；
按照顺序通过所述第一线程将各拉取请求发送给对应的所述消息服务器；
通过第二线程接收各消息服务器返回的所述应答消息。
18.根据权利要求17所述的拉取消息的方法，其特征在于，所述将所有待发送的拉取请求进行排序，包括：
获取所有待发送的拉取请求的类型；
按照预设的拉取请求类型的优先级，对所有待发送的拉取请求进行排序，将排序后的所有拉取请求生成一个请求队列；
所述按照顺序通过所述第一线程将所述拉取请求发送给对应的所述消息服务器，包括：
按序从所述请求队列中取出一个拉取请求，查询预存的拉取请求类型与消息服务器标识之间的映射关系，获取到与所述拉取请求类型对应的消息服务器的标识信息；
通过所述第一线程将所述拉取请求发送给与所述标识信息对应的所述消息服务器。
19.根据权利要求18所述的拉取消息的方法，其特征在于，还包括：
从闲置的线程中选取两个线程；
将一个线程初始化成专门用于发送所述拉取请求的所述第一线程，以及将另一个初始化成专门用于接收所述应答消息的所述第二线程。
20.一种拉取消息的装置，其特征在于，包括：
排序模块，用于当拉取多个消息服务器上的消息时，将所有待发送的拉取请求进行排序；
发送模块，用于按照顺序通过所述第一线程将每个拉取请求发送给对应的所述消息服务器；
接收模块，用于通过第二线程接收各消息服务器返回的所述应答消息。
21.一种拉取消息的方法，其特征在于，包括：
接收通过消息消费端上的第一线程发送的用于拉取消息的拉取请求，所述第一线程由消息消费端设置为专门用于发送所述拉取请求；
向所述消息消费端上的第二线程返回与所述拉取请求对应的应答消息，所述第二线程由所述消息消费端设置为专门用于接收所述应答消息。
22.根据权利要求21所述的拉取消息的方法，其特征在于，所述第二线程返回与所述拉取请求对应的应答消息，包括：
获取与所述拉取请求对应的数据；
将所述数据作为所述应答消息返给所述第二线程。
23.一种拉取消息的装置，其特征在于，包括：
接收模块，用于接收通过消息消费端上的第一线程发送的用于拉取消息的拉取请求，所述第一线程由消息消费端设置为专门用于发送所述拉取请求；
返回模块，用于向所述消息消费端上的第二线程返回与所述拉取请求对应的应答消息，所述第二线程由所述消息消费端设置为专门用于接收所述应答消息。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610873366.9A CN107888637A (zh) | 2016-09-30 | 2016-09-30 | 拉取消息的方法、装置及系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610873366.9A CN107888637A (zh) | 2016-09-30 | 2016-09-30 | 拉取消息的方法、装置及系统 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN107888637A true CN107888637A (zh) | 2018-04-06 |
Family
ID=61768876
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610873366.9A Pending CN107888637A (zh) | 2016-09-30 | 2016-09-30 | 拉取消息的方法、装置及系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107888637A (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109495303A (zh) * | 2018-11-19 | 2019-03-19 | 广州开信通讯系统有限公司 | 获取设备参量信息的方法、设备网络管理装置及系统、电子装置和存储介质 |
| WO2021174382A1 (zh) * | 2020-03-02 | 2021-09-10 | 深圳市欢太科技有限公司 | 一种消息拉取方法、装置以及计算机存储介质 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101217415A (zh) * | 2008-01-18 | 2008-07-09 | 深圳国人通信有限公司 | 轮询直放站设备的方法 |
| CN101226525A (zh) * | 2007-01-19 | 2008-07-23 | 国际商业机器公司 | 控制web页面的下载和显示的方法、服务器、客户端及系统 |
| CN102457554A (zh) * | 2010-10-29 | 2012-05-16 | 镇江雅迅软件有限责任公司 | 一种基于多线程并发执行技术的文件下载方法 |
| CN102567111A (zh) * | 2011-12-23 | 2012-07-11 | 深圳市融创天下科技股份有限公司 | 一种异步过程调用的方法、系统和终端设备 |
| CN105933146A (zh) * | 2016-04-13 | 2016-09-07 | 浪潮集团有限公司 | 一种管理交换机的方法及装置 |
-
2016
- 2016-09-30 CN CN201610873366.9A patent/CN107888637A/zh active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101226525A (zh) * | 2007-01-19 | 2008-07-23 | 国际商业机器公司 | 控制web页面的下载和显示的方法、服务器、客户端及系统 |
| CN101217415A (zh) * | 2008-01-18 | 2008-07-09 | 深圳国人通信有限公司 | 轮询直放站设备的方法 |
| CN102457554A (zh) * | 2010-10-29 | 2012-05-16 | 镇江雅迅软件有限责任公司 | 一种基于多线程并发执行技术的文件下载方法 |
| CN102567111A (zh) * | 2011-12-23 | 2012-07-11 | 深圳市融创天下科技股份有限公司 | 一种异步过程调用的方法、系统和终端设备 |
| CN105933146A (zh) * | 2016-04-13 | 2016-09-07 | 浪潮集团有限公司 | 一种管理交换机的方法及装置 |
Non-Patent Citations (1)
| Title |
|---|
| 邓新国: "消息中间件中多线程池并发模型的研究", 《铁路计算机应用》 * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109495303A (zh) * | 2018-11-19 | 2019-03-19 | 广州开信通讯系统有限公司 | 获取设备参量信息的方法、设备网络管理装置及系统、电子装置和存储介质 |
| WO2021174382A1 (zh) * | 2020-03-02 | 2021-09-10 | 深圳市欢太科技有限公司 | 一种消息拉取方法、装置以及计算机存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102917075B (zh) | 用户请求处理方法及系统 | |
| CN102546467A (zh) | 会议专用的状态指示符 | |
| CN108492454A (zh) | 出货方法、装置、自动售货机、服务器、系统和介质 | |
| CN111626452B (zh) | 智能政务处理方法、装置、终端和介质 | |
| CN102413156B (zh) | 一种分布式数据存储系统和方法 | |
| CN107391277B (zh) | 信息处理方法和装置 | |
| CN110489440B (zh) | 数据查询方法和装置 | |
| CN109756428A (zh) | 广告投放方法及装置 | |
| CN101408877A (zh) | 树节点加载系统及其方法 | |
| CN102955717A (zh) | 在分布式消息处理系统中的消息管理设备和方法 | |
| CN102981911A (zh) | 一种分布式消息处理系统及其中的设备和方法 | |
| JP6275860B2 (ja) | チャット情報伝送方法および装置、ならびにチャット情報プッシュ方法およびサーバ | |
| CN109951374B (zh) | 一种虚拟资源对象分配的方法及设备 | |
| CN107451227A (zh) | 分页查询方法及装置 | |
| CN110392312A (zh) | 群聊构建方法、系统、介质和电子设备 | |
| JP6335978B2 (ja) | 通信セッション上の一部の参加者のための仮想の通信セッションを提供するシステムおよび方法 | |
| CN107888637A (zh) | 拉取消息的方法、装置及系统 | |
| CN113365092A (zh) | 资源处理方法及装置 | |
| CN108182119A (zh) | 读写分离控制方法和装置、存储介质及电子装置 | |
| CN107018045A (zh) | 基于rpc的分布式存储系统测试方法及系统 | |
| CN102611638B (zh) | 一种即时通讯软件的文字传输方法及其传输系统 | |
| CN109902182A (zh) | 知识数据处理方法、装置、设备及存储介质 | |
| US8264725B1 (en) | Providing printable content | |
| CN108966034B (zh) | 虚拟物品显示方法、装置和存储介质 | |
| CN106533891B (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 | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20180406 |
|
| RJ01 | Rejection of invention patent application after publication |