CN112583701A - 一种基于版本号的高可靠消息机制来保证消息的方法 - Google Patents
一种基于版本号的高可靠消息机制来保证消息的方法 Download PDFInfo
- Publication number
- CN112583701A CN112583701A CN202011486007.0A CN202011486007A CN112583701A CN 112583701 A CN112583701 A CN 112583701A CN 202011486007 A CN202011486007 A CN 202011486007A CN 112583701 A CN112583701 A CN 112583701A
- Authority
- CN
- China
- Prior art keywords
- message
- client
- server
- seqid
- localseqid
- 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
- 238000000034 method Methods 0.000 title claims abstract description 33
- 230000007246 mechanism Effects 0.000 title claims abstract description 17
- 230000002159 abnormal effect Effects 0.000 claims description 9
- 230000002452 interceptive effect Effects 0.000 claims description 2
- 238000013507 mapping Methods 0.000 claims description 2
- 238000012790 confirmation Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000005111 flow chemistry technique Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Debugging And Monitoring (AREA)
Abstract
一种基于版本号的可靠消息机制来保证消息的方法，1)初始化消息版本号，当客户端与服务器建立连接后，服务端为每一个客户端维护一个消息版本号和一个唯一的channelId，同时客户端自己也维护两个消息版本号，初始值都为0，服务端的为seqId，客户端中seqId表示的是服务端已产生的消息的版本号，localSeqId表示的是客户端已收到版本号，svrSeqId表示客户端已知服务器的最大的seqId值；2)设置服务端消息的版本号；3)服务端向客户端发送通知，让客户端来拉取具体的消息内容；4)客户端收到通知消息后处理，5)服务端处理客户端的拉取消息请求，6)客户端处理拉取到的消息集合，并更新localSeqId。
Description
技术领域
本发明涉及即时通讯技术领域。尤其是涉及提供可靠的消息机制的方法。
背景技术
在即时通讯技术领域，需要一种可靠的消息机制来保证消息的不丢失。然而传统的消息机制大多是使用回执确认的方式，首先这种方式并不能保证消息的不丢失，其次当部分客户端触发重发后，会影响服务器造的性能，严重时会导致服务器不可用。
因此，需要一种更加可靠的消息机制来确保消息的不丢失，同时也不会影响服务器的性能。
发明内容
本发明所要解决的技术问题是，克服现有技术的不足，提供一种基于版本号的可靠消息机制来保证消息的不丢失，同时也不会对服务器的性能造成影响。
本发明技术方案是，一种基于版本号的可靠消息机制来保证消息的方法，具体步骤包括：
步骤1：初始化消息版本号，具体为：当客户端与服务器建立连接后，服务端为每一个客户端维护一个消息版本号和一个唯一的channelId(通道识别)，同时客户端自己也维护两个消息版本号，初始值都为0，服务端的为seqId(SeqID：标识或版本号)，客户端的为localSeqId和svrSeqId；seqId表示的是服务端已产生的消息的版本号，localSeqId表示的是客户端已收到的消息的版本号，svrSeqId表示客户端已知服务器的最大的seqId值；
步骤2：设置服务端消息的版本号，具体为：当服务端每产生一条消息，就通过redis的命令incr使seqId值加1，然后将返回的seqId值和消息存入redis的zset结构中，其中zset的key为channelId，分数为seqId，值为消息；
步骤3：服务端向客户端发送通知，具体为：服务端每产生一条消息，都将步骤2中设置的seqId发送给客户端，告知客户端有新的消息，让客户端来拉取具体的消息内容；
步骤4：客户端收到通知消息后的处理，具体为：客户端收到的服务器的seqId后，首先比较svrSeqId和seqId的值，如果seqId大则将svrSeqId更新为seqId的值，然后将svrSeqId和localSeqId进行比较，如果localSeqId小于svrSeqId，表示客户端有消息需要拉取，否则表示暂时没有消息需要拉取；如果有消息需要拉取，客户端就向服务器发送拉取消息的请求，并且携带参数localSeqId；
步骤5：服务端处理客户端的拉取消息请求，并返回对应的消息，具体为：服务器收到拉取消息请求后，去zset中查找分数大于localSeqId的消息集合，并将每个消息以及它对应的版本号seqId一起发送给客户端；
步骤6：客户端处理拉取到的消息集合，并更新localSeqId，具体为：客户端收到拉取的消息集合后，将localSeqId更新为消息集合中最大的seqId值；
步骤7：心跳处理，具体为：客户端没间隔30秒发送一次心跳给服务器，并携带localSeqId值，服务器收到心跳后，比较localSeqId和seqId的大小，如果seqId大于localSeqId，则向客户端发送通知消息，并将服务端的seqId发给客户端，接着执行步骤4。
有益效果，本发明与现有技术相比，其显著优点有：
(1)本发明通过基于版本号的方式，实现了消息的不丢失；
(2)本发明通过客户端主动拉取代替服务端主动推送的方式了，不再需要向客户端发送确认消息，以及无需主动重发消息，大大的简化了服务器的逻辑，同时也降低了服务器的性能消耗。
附图说明
图1为本发明实施例中基于版本号消息机制客户端和服务端交互流程。
具体实施方式
下面结合附图和示例性实施例对本发明作进一步的说明：
如图1所示为本发明实施例中基于版本号消息机制客户端和服务端交互流程，具体可分为正常流程和异常流程两部分，下面分别对这两个流程进行具体说明。
正常流程的具体步骤包括：
步骤S1：客户端与服务端建立连接，初始化消息的版本号；客户端初始化localSeqId＝0，svrSeqId＝0，服务端初始化seqId＝0；
步骤S2：服务端端产生消息m1，并给消息设置版本号，具体值为seqId+1，此时seqId＝1；
步骤S3：服务端向客户端发送通知消息，不包含消息m1的具体内容，仅仅告诉客户端，服务端的seqId＝1了；
步骤S4：客户端收到通知消息后，将本地的svrSeqId设置为seqId的值，此时也就是1；
步骤S5：客户端向服务端发送拉取消息的请求，并告诉服务端localSeqId＝0；
步骤S6：服务端从消息缓存服务中查找seqId大于localSeqId的消息集合，并发送给客户端，如果没有则发送空集合给客户端；
步骤S7：客户端收到消息m1；
异常流程指的是，客户端没有收到客户端通知消息，或者客户端取拉取消息的失败了，后续如何保证消息不会丢失，具体步骤包括：
步骤S0：假定客户端localSeqId＝1，svrSeqId＝1，seqId＝3，服务端有消息m2,和m3，客户端没有拉取到；
步骤S1：客户端每隔30秒向服务端发送心跳请求，并告诉服务端localSeqId＝1；
步骤S2：服务端收到客户端的心跳请求后，从消息缓存服务中查找seqId大于localSeqId的消息集合，如果没有则流程结束，如果有则进入步骤S3；
步骤S3：服务端向客户端发送通知消息，告诉客户端seqId＝3；
步骤S4：客户端收到通知消息后，将本地的svrSeqId设置为seqId的值，此时也就是3；
步骤S5：客户端向服务端发送拉取消息的请求，并告诉服务端localSeqId＝1；
步骤S6：服务端从消息缓存服务中查找seqId大于localSeqId的消息集合即消息m2和m3，并发送给客户端；
步骤S7：客户端收到消息m2和m3。
Redis Incr命令将key中储存的数字值增一。如果key不存在，那么key的值会先被初始化为0，然后再执行INCR操作。如果值包含错误的类型，或字符串类型的值不能表示为数字，那么返回一个错误。
Redis zset底层的存储结构包括ziplist或skiplist，在同时满足以下两个条件的时候使用ziplist，其他时候使用skiplist，两个条件如下：
·有序集合保存的元素数量小于128个
·有序集合保存的所有元素的长度小于64字节；
zset结构中：分数为seqId，值为消息；zset是Redis(一种nosql数据库)中的一种数据类型。这种类型有有种属性，分别是分数属性和值属性，在使用的过程中，我们将seqId映射成zset中的分数属性，将消息内容映射成值属性。
当ziplist作为zset的底层存储结构时候，每个集合元素使用两个紧挨在一起的压缩列表节点来保存，第一个节点保存元素的成员，第二个元素保存元素的分值。当skiplist作为zset的底层存储结构的时候，使用skiplist按序保存元素及分值，使用dict来保存元素和分值的映射关系。
图1中异常流程中：图1中包含两种异常流程，分别为通知消息发送失败和消息内容发送失败；
这两种异常流程都会导致客户端无法收到服务端的消息，针对这些异常，我们加入了心跳机制，通过心跳机制能够让客户端重新拉取到消息，从而保证异常流程下消息也不会丢失，并且使流程重新恢复到正常流程，心跳机制每30秒触发一次，步骤如下：通知消息发送失败异常流程处理步骤：
步骤S1：客户端localSeqId＝1，svrSeqId＝1；
步骤S2-1：服务端产生消息m2，并向客户端发送通知消息告诉客户端seqId＝2；
步骤S2-2：服务端产生消息m3，并向客户端发送通知消息告诉客户端seqId＝3；
步骤S3：客户端没有收到通知消息，此时客户端localSeqId＝1，svrSeqId＝1，而服务端的seqId＝3；
步骤S4:客户端向服务端发送心跳，并告诉服务端localSeqId＝1，svrSeqId＝1；
步骤S5：服务端收到心跳信息，并查询到客户端有消息m2和m3没有收到，然后将m2和m3发送给客户端；
步骤S6:如果客户端依然没有收到消息m2和m3，此时进入[步骤S4],如果客户端收到消息m2和m3，则更新localSeqId＝3，svrSeqId＝3，此时流程恢复到正常流程,异常流程结束。
Claims (3)
1.一种基于版本号的可靠消息机制来保证消息的方法，其特征是，步骤如下：
步骤1：初始化消息版本号，具体为：当客户端与服务器建立连接后，服务端为每一个客户端维护一个消息版本号和一个唯一的channelId，同时客户端自己也维护两个消息版本号，初始值都为0，服务端的为seqId，客户端的两个消息版本号为localSeqId和svrSeqId；seqId表示的是服务端已产生的消息的版本号，localSeqId表示的是客户端已收到的消息的版本号，svrSeqId表示客户端已知服务器的最大的seqId值；
步骤2：设置服务端消息的版本号：当服务端每产生一条消息，就通过redis的命令incr使seqId值加1，然后将返回的seqId值和消息存入redis的zset结构中，其中zset的key为channelId，zset结构中：分数为seqId，值为消息；
步骤3：服务端向客户端发送通知，具体为：服务端每产生一条消息，都将步骤2中设置的seqId发送给客户端，告知客户端有新的消息，让客户端来拉取具体的消息内容；
步骤4：客户端收到通知消息后的处理，具体为：客户端收到的服务器的seqId后，首先比较svrSeqId和seqId的值，如果seqId大则将svrSeqId更新为seqId的值，然后将svrSeqId和localSeqId进行比较，如果localSeqId小于svrSeqId，表示客户端有消息需要拉取，否则表示暂时没有消息需要拉取。如果有消息需要拉取，客户端就向服务器发送拉取消息的请求，并且携带参数localSeqId；
步骤5：服务端处理客户端的拉取消息请求，并返回对应的消息，具体为：服务器收到拉取消息请求后，去zset中查找分数大于localSeqId的消息集合，并将每个消息以及它对应的版本号seqId一起发送给客户端；
步骤6：客户端处理拉取到的消息集合，并更新localSeqId，具体为：客户端收到拉取的消息集合后，将localSeqId更新为消息集合中最大的seqId值；
步骤7：心跳处理，具体为：客户端没间隔30秒发送一次心跳给服务器，并携带localSeqId值，服务器收到心跳后，比较localSeqId和seqId的大小，如果seqId大于localSeqId，则向客户端发送通知消息，并将服务端的seqId发给客户端，接着执行步骤4。
2.根据权利要求1所述的基于版本号的可靠消息机制来保证消息的方法，其特征是，步骤2中，Redis的Incr命令将key中储存的数字值增一；如果key不存在，那么key的值会先被初始化为0，然后再执行INCR操作；如果值包含错误的类型，或字符串类型的值不能表示为数字，那么返回一个错误；
步骤5中，Redis zset底层的存储结构包括ziplist或skiplist，在同时满足以下两个条件的时候使用ziplist，其他时候使用skiplist，两个条件如下：
·有序集合保存的元素数量小于128个，
·有序集合保存的所有元素的长度小于64字节；
当ziplist作为zset的底层存储结构时候，每个集合元素使用两个紧挨在一起的压缩列表节点来保存，第一个节点保存元素的成员，第二个元素保存元素的分值；当skiplist作为zset的底层存储结构的时候，使用skiplist按序保存元素及分值，使用dict来保存元素和分值的映射关系。
3.根据权利要求1-2之一所述的基于版本号的可靠消息机制来保证消息的方法，其特征是，基于版本号消息机制客户端和服务端交互流程，具体可分为正常流程和异常流程两部分，正常流程的具体步骤包括：
步骤S1：客户端与服务端建立连接，初始化消息的版本号；客户端初始化localSeqId＝0，svrSeqId＝0，服务端初始化seqId＝0；
步骤S2：服务端端产生消息m1，并给消息设置版本号，具体值为seqId+1，此时seqId＝1；
步骤S3：服务端向客户端发送通知消息，不包含消息m1的具体内容，仅仅告诉客户端，服务端的seqId＝1了；
步骤S4：客户端收到通知消息后，将本地的svrSeqId设置为seqId的值，此时也就是1；
步骤S5：客户端向服务端发送拉取消息的请求，并告诉服务端localSeqId＝0；
步骤S6：服务端从消息缓存服务中查找seqId大于localSeqId的消息集合，并发送给客户端，如果没有则发送空集合给客户端；
步骤S7：客户端收到消息m1；
异常流程指客户端没有收到客户端通知消息，或者客户端取拉取消息的失败，后续如何保证消息不会丢失，具体步骤包括：
步骤S0：假定客户端localSeqId＝1，svrSeqId＝1，seqId＝3，服务端有消息m2,和m3，客户端没有拉取到；
步骤S1：客户端每隔30秒向服务端发送心跳请求，并告诉服务端localSeqId＝1；
步骤S2：服务端收到客户端的心跳请求后，从消息缓存服务中查找seqId大于localSeqId的消息集合，如果没有则流程结束，如果有则进入步骤S3；
步骤S3：服务端向客户端发送通知消息，告诉客户端seqId＝3；
步骤S4：客户端收到通知消息后，将本地的svrSeqId设置为seqId的值，此时也就是3；
步骤S5：客户端向服务端发送拉取消息的请求，并告诉服务端localSeqId＝1；
步骤S6：服务端从消息缓存服务中查找seqId大于localSeqId的消息集合即消息m2和m3，并发送给客户端；
步骤S7：客户端收到消息m2和m3。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011486007.0A CN112583701A (zh) | 2020-12-16 | 2020-12-16 | 一种基于版本号的高可靠消息机制来保证消息的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011486007.0A CN112583701A (zh) | 2020-12-16 | 2020-12-16 | 一种基于版本号的高可靠消息机制来保证消息的方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112583701A true CN112583701A (zh) | 2021-03-30 |
Family
ID=75135615
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011486007.0A Pending CN112583701A (zh) | 2020-12-16 | 2020-12-16 | 一种基于版本号的高可靠消息机制来保证消息的方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112583701A (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113326275A (zh) * | 2021-06-09 | 2021-08-31 | 烽火通信科技股份有限公司 | 一种用于路由器的数据老化方法与系统 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105871703A (zh) * | 2016-06-03 | 2016-08-17 | 用友网络科技股份有限公司 | 推拉结合的即时通信消息获取系统和方法 |
| CN108667719A (zh) * | 2018-04-26 | 2018-10-16 | 广州品唯软件有限公司 | 一种实时消息传递方法及系统 |
-
2020
- 2020-12-16 CN CN202011486007.0A patent/CN112583701A/zh active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105871703A (zh) * | 2016-06-03 | 2016-08-17 | 用友网络科技股份有限公司 | 推拉结合的即时通信消息获取系统和方法 |
| CN108667719A (zh) * | 2018-04-26 | 2018-10-16 | 广州品唯软件有限公司 | 一种实时消息传递方法及系统 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113326275A (zh) * | 2021-06-09 | 2021-08-31 | 烽火通信科技股份有限公司 | 一种用于路由器的数据老化方法与系统 |
| CN113326275B (zh) * | 2021-06-09 | 2022-09-13 | 烽火通信科技股份有限公司 | 一种用于路由器的数据老化方法与系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7293045B2 (en) | Accounting for update notifications in synchronizing data that may be represented by different data structures | |
| RU2477517C2 (ru) | Система и способ усовершенствованной синхронизации между сервером и клиентом | |
| EP1631025A2 (en) | Method for streaming data between a server and a client | |
| US20100145914A1 (en) | Database management server apparatus, database management system, database management method and database management program | |
| US9396072B2 (en) | Delivery with reconciliation on client side | |
| CN112367149B (zh) | 消息获取方法、装置、设备及存储介质 | |
| US20070255823A1 (en) | Method for low-overhead message tracking in a distributed messaging system | |
| US6920476B2 (en) | Messaging system for computers | |
| CN109714409A (zh) | 一种消息的管理方法和系统 | |
| CN112583701A (zh) | 一种基于版本号的高可靠消息机制来保证消息的方法 | |
| US20090327805A1 (en) | Minimizing data loss in asynchronous replication solution using distributed redundancy | |
| US7924844B1 (en) | System and method for communicating messages among components in a computing environment | |
| CN112698969A (zh) | 一种基于消息落库的mq消息可靠性投递解决方法 | |
| US7363322B2 (en) | Methods and systems for performing reliable asynchronous notification of high-level document operations | |
| CN113535482B (zh) | 云备份链数据备份方法及装置、设备、可读介质 | |
| CN111669320B (zh) | 一种处理报文的方法及网络设备 | |
| US20030138041A1 (en) | Difference messaging protocol that uses prior state information | |
| CN113810266B (zh) | 针对消息对象的重试操作方法、装置、设备及存储介质 | |
| CN112866359B (zh) | 数据上链方法、装置、电子设备及存储介质 | |
| WO2024001213A1 (zh) | 消息处理方法、发布端、订阅端及计算机可读存储介质 | |
| CN112804312B (zh) | 文件上传方法、设备以及计算机可读介质 | |
| CN115914152B (zh) | 回执信息推送方法、系统及存储介质 | |
| CN115883683A (zh) | 一种报头解码方法和装置 | |
| CN117725075A (zh) | 一种基于比较并交换算法的n叉树数据同步补偿方法 | |
| CN117149137A (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 | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210330 |