CN106941461A - 一种利用消息队列优化服务器处理请求的方法 - Google Patents
一种利用消息队列优化服务器处理请求的方法 Download PDFInfo
- Publication number
- CN106941461A CN106941461A CN201710101436.3A CN201710101436A CN106941461A CN 106941461 A CN106941461 A CN 106941461A CN 201710101436 A CN201710101436 A CN 201710101436A CN 106941461 A CN106941461 A CN 106941461A
- Authority
- CN
- China
- Prior art keywords
- message
- queue
- server
- request
- backup
- 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
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
Abstract
本发明公开了一种利用消息队列优化服务器处理请求的方法，涉及数据通信领域。设置消息队列，实时观测服务器的状态。用户的请求率先到达消息队列，而不是服务器。若服务器处于空闲状态，则请求消息直接放入可执行消息队列中推送给服务器处理；若服务器处于忙碌状态，则请求消息放入排队等候消息队列末尾。在此期间，如果同一用户或不同用户发送的请求消息和排队等候消息队列中的请求消息相同，则此请求不再放到排队等候队列末尾，而是和排队等候队列中已存在的相同请求消息合并，等待执行。可执行消息队列将用户请求发往服务器之前将做备份并放入备份消息队列中，实现可靠投递，避免消息重复。消息队列端和服务器之间利用报文传送进行通信。
Description
技术领域
本发明涉及数据通信技术领域，具体是一种利用消息队列优化服务器处理请求的方法。
背景技术
“消息”是在两台计算机间传送的数据单位。“消息队列”是在消息的传输过程中保存消息的容器。消息队列将消息从源传递到目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。传统的用户和服务器之间的通信不可避免通信过程的复杂性，而用户往往希望关注的只是最后得到的通知，利用消息队列可以很好的实现这一需求。
发明内容
本发明提供了一种利用消息队列优化服务器处理请求的方法，解决了消息队列中信息丢失和重复不能同时实现的问题，较好的实现了用户和服务器之间的分离，提高了服务器处理请求的效率。
本发明是通过如下技术方案实现的：
一种利用消息队列优化服务器处理请求的方法，包括用户和服务器，在用户与服务器之间有消息队列，所述消息队列处理、合并用户请求消息，将处理结果推送给服务器执行，提高服务器处理用户请求的效率。
优选的是，所述消息队列分为三种类型：可执行消息队列：存放的用户请求直接推送给相应的空闲服务器执行；排队等候消息队列：存放的用户请求按到达的先后顺序在此队列中排队等候；备份消息队列：存放复制过的用户请求消息。
优选的是，用户请求到达消息队列后的处理过程如下步骤：
步骤一：用户请求到达消息队列端后，消息队列判断此时服务器是否处于空闲状态；若是，则请求消息被放入可执行消息队列中，依次推送给服务器执行；步骤二：若服务器处于忙碌状态，则用户请求消息被放入排队等候队列，依次加入队列末尾排队等候；步骤三：当有新的用户请求到达后，消息队列将判断排队等候消息队列中是否有与该新到达的请求相同的消息：如果有，则依次遍历排队等候消息队列，找到与新到达请求相同的消息所处的位置，将两个请求消息进行合并，放入该位置；如果排队等候队列中没有与该请求相同的消息，则新到达的请求将被放到排队等候队列的末尾，等待执行；步骤四：当服务器由忙碌状态转换到空闲状态后，可执行消息队列将排队等候队列中存放的请求消息依次调入，并推送给服务器端执行；步骤五：推送请求消息之前，将备份一份此请求放入备份消息队列中。
优选的是，所述消息队列与所述服务器之间利用报文传送进行通信。
优选的是，所述报文传送包括以下报文：Request报文：用户向消息队列发送请求消息使用的报文；Reply报文：服务器向用户返回处理结果使用的报文；Push报文：可执行消息队列向服务器推送可执行的请求消息使用的报文；Invalid报文：服务器返回无效的请求给消息队列使用的报文；Ack报文：服务器确认消息队列端发送的请求消息使用的报文。
优选的是，所述消息队列将可执行消息推送给服务器之前，将会做一份备份，放入备份消息队列中；如果请求消息推送失败，将重传备份消息队列中的该请求消息；服务器成功收到此请求消息后，备份队列中的备份信息将被删除；每发送一次备份消息，将会在此备份消息中添加一个序列号来防止因链路故障而导致服务器端接收到重复消息。
优选的是，所述消息队列和所述服务器沟通过程如下步骤：步骤一：取出可执行消息队列最前端的请求消息，将此请求消息备份一份放入备份消息队列中，利用Push报文将该请求消息发送到服务器；步骤二：服务器接收到此请求消息后，将判断是否能够处理此请求消息：如果能处理，则向消息队列端返回一个Ack报文，确认自己正确收到并可以处理此消息；如果不能，则向消息队列返回一个Invalid报文，通知消息队列端自己无法处理此请求消息；步骤三：如果消息队列收到服务器发来的报文是Ack报文，则将备份消息队列中关于该已被确认的请求消息的备份删除；步骤四：如果消息队列端收到服务器发来的报文是Invalid报文，则将备份消息队列中的该请求消息通过Push报文发向其他的空闲服务器；步骤五：如果消息队列端没有收到服务器发回的任何响应报文，则将会重传备份消息队列中的该请求消息的备份，并在此备份消息中加入一个起始序列号1，此后每一次重传，序列号都会增加1，直至序列号加到5，便直接删除备份消息队列中的该请求消息的备份。
优选的是，所述步骤五中，造成消息队列收不到服务器发回的任何响应报文的原因是链路故障造成的。
优选的是，在链路故障恢复，而备份消息却已经发出的情况下，备份请求消息的序号便能够解决服务器收到重复消息的问题；服务器接收到相同的请求消息时，发现里面带有序列号或者序列号比自己之前已经收到的备份请求消息中的序列号要大，则会直接丢弃新收到的重复消息，并向消息队列端重发确认消息。
本发明的有益效果是：
消息队列的使用使得用户只需关注最后的通知，而不需参与整个请求处理的过程；消息队列的分类机制较好的适应了服务器的状态变化，请求消息的备份、相同请求消息的合并、消息重传机制的实现，提高了服务器处理用户请求的效率。
附图说明
图1为发明中的整体架构示意图；
图2为消息队列原理框图；
图3为数据流图；
图4为消息队列工作过程。
具体实施方式
以下结合附图1至附图4所示，通过具体实施例对本发明作进一步的说明。
一、消息队列接收用户请求消息的机制：
可执行消息队列：存放的用户请求直接推送给相应的空闲服务器执行；
排队等候消息队列：存放的用户请求按到达的先后顺序在此队列中排队等候；
备份消息队列：存放复制过的用户请求消息。
(1)用户请求到达消息队列端后，消息队列判断此时服务器是否处于空闲状态；若是，则请求消息被放入可执行消息队列中，依次推送给服务器执行。
(2)若服务器处于忙碌状态，则用户请求消息被放入排队等候队列，依次加入队列末尾排队等候。
(3)当有新的用户请求到达后，消息队列端将判断排队等候消息队列中是否有与该新到达的请求相同的消息：
如果有，则依次遍历排队等候消息队列，找到与新到达请求相同的消息所处的位置，将两个请求消息进行合并，放入该位置；
如果排队等候队列中没有与该请求相同的消息，则新到达的请求将被放到排队等候队列的末尾，等待执行。
(4)当服务器由忙碌状态转换到空闲状态后，可执行消息队列将排队等候队列中存放的请求消息依次调入，并推送给服务器端执行。
(5)推送请求消息之前，将备份一份此请求放入备份消息队列中。
二、消息队列端实现可靠投递与避免消息重复机制：
消息队列将可执行消息推送给服务器之前，将会做一份备份，放入备份消息队列中。如果请求消息推送失败，可以重传备份消息队列中的该请求消息；服务器成功收到此请求消息后，备份队列中的备份信息将被删除。每发送一次备份消息，将会在此备份消息中添加一个序列号来防止因链路故障而导致服务器端接收到重复消息。
三、消息队列端和服务器之间利用报文传送进行通信机制：
Request报文：用户向消息队列发送请求消息使用的报文；
Reply报文：服务器向用户返回处理结果使用的报文；
Push报文：可执行消息队列向服务器推送可执行的请求消息使用的报文；
Invalid报文：服务器返回无效的请求给消息队列使用的报文；
Ack报文：服务器确认消息队列端发送的请求消息使用的报文。
(1)取出可执行消息队列最前端的请求消息，将此请求消息备份一份放入备份消息队列中。利用Push报文将该请求消息发送到服务器；
(2)服务器接收到此请求消息后，将判断是否能够处理此请求消息：
如果能处理，则向消息队列端返回一个Ack报文，确认自己正确收到并可以处理此消息；
如果不能，则向消息队列返回一个Invalid报文，通知消息队列端自己无法处理此请求消息。
(3)如果消息队列收到服务器发来的报文是Ack，则将备份消息队列中关于该已被确认的请求消息的备份删除；
(4)如果消息队列端收到服务器发来的报文是Invalid，则将备份消息队列中的该请求消息通过Push报文发向另外的空闲服务器；
(5)如果消息队列端没有收到服务器发回的任何响应报文，则将会重传备份消息队列中的该请求消息的备份，并在此备份消息中加入一个起始序列号1，此后每一次重传，序列号都会增加1，直至序列号加到5，便直接删除备份消息队列中的该请求消息的备份；
(6)造成消息队列端收不到服务器发回的任何响应报文的原因可能是链路故障造成的。在链路故障恢复，而备份消息却已经发出的情况下，备份请求消息的序号便可以解决服务器收到重复消息的问题。服务器接收到相同的请求消息时，发现里面带有序列号或者序列号比自己之前已经收到的备份请求消息中的序列号要大，则会直接丢弃新收到的重复消息，并向消息队列端重发确认消息。
实施例：
如图1所示，用户与服务器之间增加了消息队列端，效果是用户和服务器不直接相连，消息队里起到中间人的作用。
如图2所示，消息队列端中包含的三个部分：
可执行消息队列：存放的用户请求直接推送给相应的空闲服务器执行；
排队等候消息队列：存放的用户请求按到达的先后顺序在此队列中排队等候；
备份消息队列：存放复制过的用户请求消息。
如图3和图4所示，消息队列实现服务器性能优化工作流程如下：
(1)用户通过Request报文向消息队列发送请求消息。
(2)用户请求到达消息队列端后，消息队列判断此时服务器是否处于空闲状态；若是，则请求消息被放入可执行消息队列中，等待推送给服务器执行。
(3)若服务器处于忙碌状态，则用户请求消息被放入排队等候队列，依次加入队列末尾排队等候。
(4)当有新的用户请求到达后，消息队列端将判断排队等候消息队列中是否有与该新到达的请求相同的消息；
如果有，则依次遍历排队等候消息队列，找到与新到达请求相同的消息所处的位置，将两个请求消息进行合并，放入该位置；
如果排队等候队列中没有与该请求相同的消息，则新到达的请求将被放到排队等候队列的末尾，等待执行。
(5)当服务器由忙碌状态转换到空闲状态后，可执行消息队列将排队等候队列中存放的请求消息依次调入，等待推送给服务器端执行。
(6)取出可执行消息队列最前端的请求消息，将此请求消息备份一份放入备份消息队列中。利用Push报文将该请求消息发送到服务器。
(7)服务器接收到此请求消息后，将判断是否能够处理此请求消息：
如果能处理，则向消息队列端返回一个Ack报文，确认自己正确收到并可以处理此消息；
如果不能，则向消息队列返回一个Invalid报文，通知消息队列端自己无法处理此请求消息。
(8)如果消息队列收到服务器发来的报文是Ack，则将备份消息队列中关于该已被确认的请求消息的备份删除。
(9)如果消息队列端收到服务器发来的报文是Invalid，则将备份消息队列中的该请求消息通过Push报文发向另外的空闲服务器。
(10)如果消息队列端没有收到服务器发回的任何响应报文，则将会重传备份消息队列中的该请求消息的备份，并在此备份消息中加入一个起始序列号1，此后每一次重传，序列号都会增加1，直至序列号加到5，便直接删除备份消息队列中的该请求消息的备份；
造成消息队列端收不到服务器发回的任何响应报文的原因可能是链路故障造成的。在链路故障恢复，而备份消息却已经发出的情况下，备份请求消息的序号便可以解决服务器收到重复消息的问题。服务器接收到相同的请求消息时，发现里面带有序列号或者序列号比自己之前已经收到的备份请求消息中的序列号要大，则会直接丢弃新收到的重复消息，并向消息队列端重发确认消息。
(11)服务器将处理好的请求消息直接通过Reply报文返还给用户。
Claims (10)
1.一种利用消息队列优化服务器处理请求的方法，包括用户和服务器，其特征在于：在用户与服务器之间有消息队列，所述消息队列处理、合并用户请求消息，将处理结果推送给服务器执行，提高服务器处理用户请求的效率。
2.根据权利要求1所述的一种利用消息队列优化服务器处理请求的方法，其特征在于：所述消息队列分为三种类型：
可执行消息队列：存放的用户请求直接推送给相应的空闲服务器执行；
排队等候消息队列：存放的用户请求按到达的先后顺序在此队列中排队等候；
备份消息队列：存放复制过的用户请求消息。
3.根据权利要求2所述的一种利用消息队列优化服务器处理请求的方法，其特征在于，用户请求到达消息队列后的处理过程如下步骤：
步骤一：用户请求到达消息队列端后，消息队列判断此时服务器是否处于空闲状态；若是，则请求消息被放入可执行消息队列中，依次推送给服务器执行；
步骤二：若服务器处于忙碌状态，则用户请求消息被放入排队等候队列，依次加入队列末尾排队等候；
步骤三：当有新的用户请求到达后，消息队列将判断排队等候消息队列中是否有与该新到达的请求相同的消息：
如果有，则依次遍历排队等候消息队列，找到与新到达请求相同的消息所处的位置，将两个请求消息进行合并，放入该位置；
如果排队等候队列中没有与该请求相同的消息，则新到达的请求将被放到排队等候队列的末尾，等待执行；
步骤四：当服务器由忙碌状态转换到空闲状态后，可执行消息队列将排队等候队列中存放的请求消息依次调入，并推送给服务器端执行；
步骤五：推送请求消息之前，将备份一份此请求放入备份消息队列中。
4.根据权利要求1至3任一项所述的一种利用消息队列优化服务器处理请求的方法，其特征在于：所述消息队列与所述服务器之间利用报文传送进行通信。
5.根据权利要求4所述的一种利用消息队列优化服务器处理请求的方法，其特征在于：所述报文传送包括以下报文：
Request报文：用户向消息队列发送请求消息使用的报文；
Reply报文：服务器向用户返回处理结果使用的报文；
Push报文：可执行消息队列向服务器推送可执行的请求消息使用的报文；
Invalid报文：服务器返回无效的请求给消息队列使用的报文；
Ack报文：服务器确认消息队列端发送的请求消息使用的报文。
6.根据权利要求1至3任一项所述的一种利用消息队列优化服务器处理请求的方法，其特征在于：所述消息队列将可执行消息推送给服务器之前，将会做一份备份，放入备份消息队列中；
如果请求消息推送失败，将重传备份消息队列中的该请求消息；服务器成功收到此请求消息后，备份队列中的备份信息将被删除；每发送一次备份消息，将会在此备份消息中添加一个序列号来防止因链路故障而导致服务器端接收到重复消息。
7.根据权利要求5所述的一种利用消息队列优化服务器处理请求的方法，其特征在于：所述消息队列将可执行消息推送给服务器之前，将会做一份备份，放入备份消息队列中；
如果请求消息推送失败，将重传备份消息队列中的该请求消息；服务器成功收到此请求消息后，备份队列中的备份信息将被删除；每发送一次备份消息，将会在此备份消息中添加一个序列号来防止因链路故障而导致服务器端接收到重复消息。
8.根据权利要求7所述的一种利用消息队列优化服务器处理请求的方法，其特征在于：所述消息队列和所述服务器沟通过程如下步骤：
步骤一：取出可执行消息队列最前端的请求消息，将此请求消息备份一份放入备份消息队列中，利用Push报文将该请求消息发送到服务器；
步骤二：服务器接收到此请求消息后，将判断是否能够处理此请求消息：
如果能处理，则向消息队列端返回一个Ack报文，确认自己正确收到并可以处理此消息；
如果不能，则向消息队列返回一个Invalid报文，通知消息队列端自己无法处理此请求消息；
步骤三：如果消息队列收到服务器发来的报文是Ack报文，则将备份消息队列中关于该已被确认的请求消息的备份删除；
步骤四：如果消息队列端收到服务器发来的报文是Invalid报文，则将备份消息队列中的该请求消息通过Push报文发向其他的空闲服务器；
步骤五：如果消息队列端没有收到服务器发回的任何响应报文，则将会重传备份消息队列中的该请求消息的备份，并在此备份消息中加入一个起始序列号1，此后每一次重传，序列号都会增加1，直至序列号加到5，便直接删除备份消息队列中的该请求消息的备份。
9.根据权利要求8所述的一种利用消息队列优化服务器处理请求的方法，其特征在于：所述步骤五中，造成消息队列收不到服务器发回的任何响应报文的原因是链路故障造成的。
10.根据权利要求9所述的一种利用消息队列优化服务器处理请求的方法，其特征在于：在链路故障恢复，而备份消息却已经发出的情况下，备份请求消息的序号便能够解决服务器收到重复消息的问题；服务器接收到相同的请求消息时，发现里面带有序列号或者序列号比自己之前已经收到的备份请求消息中的序列号要大，则会直接丢弃新收到的重复消息，并向消息队列端重发确认消息。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710101436.3A CN106941461A (zh) | 2017-02-23 | 2017-02-23 | 一种利用消息队列优化服务器处理请求的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710101436.3A CN106941461A (zh) | 2017-02-23 | 2017-02-23 | 一种利用消息队列优化服务器处理请求的方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN106941461A true CN106941461A (zh) | 2017-07-11 |
Family
ID=59469278
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710101436.3A Pending CN106941461A (zh) | 2017-02-23 | 2017-02-23 | 一种利用消息队列优化服务器处理请求的方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106941461A (zh) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018223789A1 (zh) * | 2017-06-05 | 2018-12-13 | 中兴通讯股份有限公司 | 事务标识操作方法、系统和计算机可读存储介质 |
| CN110636013A (zh) * | 2019-09-30 | 2019-12-31 | 佛山科学技术学院 | 一种消息队列的动态调度方法及装置 |
| CN110750361A (zh) * | 2019-10-25 | 2020-02-04 | 北京亿信华辰软件有限责任公司武汉分公司 | 一种处理并发请求的优化算法 |
| CN114125021A (zh) * | 2021-10-20 | 2022-03-01 | 安徽峰泰技术开发有限公司 | 一种基于Netty消息驱动的终端信息发布系统 |
| CN114817120A (zh) * | 2022-06-29 | 2022-07-29 | 湖北芯擎科技有限公司 | 一种跨域数据共享方法、系统级芯片、电子设备及介质 |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1889489A (zh) * | 2006-07-28 | 2007-01-03 | 清华大学 | 一种无线局域网中语音通信的方法 |
| CN101056194A (zh) * | 2006-06-30 | 2007-10-17 | 华为技术有限公司 | 一种简单网络管理协议消息传送方法及装置 |
| CN102457986A (zh) * | 2010-10-29 | 2012-05-16 | 联芯科技有限公司 | 终端的上行数据传输方法及终端 |
| CN103902348A (zh) * | 2012-12-25 | 2014-07-02 | 华为技术有限公司 | 一种虚拟化环境下用户数据的读写方法、系统及物理机 |
| CN104092707A (zh) * | 2014-07-31 | 2014-10-08 | 中国电子科技集团公司第五十四研究所 | 基于分块校验与确认的卫星网络tcp协议性能增强方法 |
| CN104468509A (zh) * | 2014-10-29 | 2015-03-25 | 北方工业大学 | 手机网络游戏数据传输的方法、系统和手机用户端 |
| CN104821947A (zh) * | 2015-05-08 | 2015-08-05 | 四川天上友嘉网络科技有限公司 | 网络游戏数据的传输方法 |
| CN103036904B (zh) * | 2012-12-27 | 2015-10-21 | 东方通信股份有限公司 | 一种在通信网络中使用udp协议进行数据可靠传输的方法 |
| CN105763608A (zh) * | 2016-02-05 | 2016-07-13 | 浪潮(北京)电子信息产业有限公司 | 一种用于云存储系统的消息处理方法和装置 |
| CN105897792A (zh) * | 2014-11-27 | 2016-08-24 | 北京北信源软件股份有限公司 | 一种comet技术中的消息防丢失方法 |
-
2017
- 2017-02-23 CN CN201710101436.3A patent/CN106941461A/zh active Pending
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101056194A (zh) * | 2006-06-30 | 2007-10-17 | 华为技术有限公司 | 一种简单网络管理协议消息传送方法及装置 |
| CN1889489A (zh) * | 2006-07-28 | 2007-01-03 | 清华大学 | 一种无线局域网中语音通信的方法 |
| CN102457986A (zh) * | 2010-10-29 | 2012-05-16 | 联芯科技有限公司 | 终端的上行数据传输方法及终端 |
| CN103902348A (zh) * | 2012-12-25 | 2014-07-02 | 华为技术有限公司 | 一种虚拟化环境下用户数据的读写方法、系统及物理机 |
| CN103036904B (zh) * | 2012-12-27 | 2015-10-21 | 东方通信股份有限公司 | 一种在通信网络中使用udp协议进行数据可靠传输的方法 |
| CN104092707A (zh) * | 2014-07-31 | 2014-10-08 | 中国电子科技集团公司第五十四研究所 | 基于分块校验与确认的卫星网络tcp协议性能增强方法 |
| CN104468509A (zh) * | 2014-10-29 | 2015-03-25 | 北方工业大学 | 手机网络游戏数据传输的方法、系统和手机用户端 |
| CN105897792A (zh) * | 2014-11-27 | 2016-08-24 | 北京北信源软件股份有限公司 | 一种comet技术中的消息防丢失方法 |
| CN104821947A (zh) * | 2015-05-08 | 2015-08-05 | 四川天上友嘉网络科技有限公司 | 网络游戏数据的传输方法 |
| CN105763608A (zh) * | 2016-02-05 | 2016-07-13 | 浪潮(北京)电子信息产业有限公司 | 一种用于云存储系统的消息处理方法和装置 |
Non-Patent Citations (2)
| Title |
|---|
| 何炎祥: "《操作系统原理》", 31 October 2001 * |
| 李名世: "《计算机网络实验教程》", 30 June 2009 * |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018223789A1 (zh) * | 2017-06-05 | 2018-12-13 | 中兴通讯股份有限公司 | 事务标识操作方法、系统和计算机可读存储介质 |
| CN110636013A (zh) * | 2019-09-30 | 2019-12-31 | 佛山科学技术学院 | 一种消息队列的动态调度方法及装置 |
| CN110636013B (zh) * | 2019-09-30 | 2022-08-16 | 佛山科学技术学院 | 一种消息队列的动态调度方法及装置 |
| CN110750361A (zh) * | 2019-10-25 | 2020-02-04 | 北京亿信华辰软件有限责任公司武汉分公司 | 一种处理并发请求的优化算法 |
| CN114125021A (zh) * | 2021-10-20 | 2022-03-01 | 安徽峰泰技术开发有限公司 | 一种基于Netty消息驱动的终端信息发布系统 |
| CN114125021B (zh) * | 2021-10-20 | 2024-01-30 | 安徽峰泰技术开发有限公司 | 一种基于Netty消息驱动的终端信息发布系统 |
| CN114817120A (zh) * | 2022-06-29 | 2022-07-29 | 湖北芯擎科技有限公司 | 一种跨域数据共享方法、系统级芯片、电子设备及介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106941461A (zh) | 一种利用消息队列优化服务器处理请求的方法 | |
| RU2345408C2 (ru) | Улучшение доступности и масштабируемости в системе передачи сообщений способом, прозрачным для приложения | |
| US8612617B2 (en) | Reliable multicast transport protocol | |
| US7912058B1 (en) | Point-to-multipoint connections for data delivery | |
| WO2007109986A1 (fr) | Procédé et dispositif fiables de notification de messages entre systèmes | |
| US7676580B2 (en) | Message delivery with configurable assurances and features between two endpoints | |
| CN110297801A (zh) | 基于容错fpga的事务系统的正好一次事务语义 | |
| WO2007112667A1 (fr) | procédé et appareil pour la transmission de message, procédé et appareil pour la notification de messages inter-systèmes | |
| JP5537181B2 (ja) | メッセージシステム | |
| CN101651526B (zh) | 一种网络设备间的消息传递方法 | |
| CN105871703A (zh) | 推拉结合的即时通信消息获取系统和方法 | |
| CN110708175B (zh) | 分布式网络中消息同步的方法 | |
| US9442781B2 (en) | Optimistic processing of messages in a messaging system | |
| CN103532822A (zh) | 消息投递的管理方法、服务器和系统 | |
| CN112118171A (zh) | 消息互通系统、方法、装置、计算机设备及可读存储介质 | |
| US20130191680A1 (en) | Handling of messages in a message system | |
| CN102647365A (zh) | 处理消息及消息状态的方法、装置和数据交换服务器 | |
| CN114500552A (zh) | 边缘计算场景下的云边消息可靠性传输方法及装置 | |
| CN111416823A (zh) | 一种数据传输方法和装置 | |
| KR102071955B1 (ko) | 분산 캐시 환경에서 멀티캐스트를 수행하는 방법 및 이를 이용한 분산 캐시 서버 | |
| CN104348874A (zh) | 云平台组件之间消息传输的方法与装置 | |
| US8156174B2 (en) | Method and system for information exchange utilizing an asynchronous persistent store protocol | |
| TW201101747A (en) | Transmission method, node, and system of linked data | |
| JP5865424B2 (ja) | メッセージシステムおよびデータストアサーバ | |
| KR100310285B1 (ko) | 실시간 객체지향 분산 플랫폼에서 고장감내 서비스를지원하는 그룹통신 방법 |
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: 20170711 |
|
| RJ01 | Rejection of invention patent application after publication |