CN112511628A - 一种分布式实时消息推送方法 - Google Patents
一种分布式实时消息推送方法 Download PDFInfo
- Publication number
- CN112511628A CN112511628A CN202011372787.6A CN202011372787A CN112511628A CN 112511628 A CN112511628 A CN 112511628A CN 202011372787 A CN202011372787 A CN 202011372787A CN 112511628 A CN112511628 A CN 112511628A
- Authority
- CN
- China
- Prior art keywords
- server
- alloc
- client
- pushing method
- time message
- 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 26
- 238000012217 deletion Methods 0.000 claims description 5
- 230000037430 deletion Effects 0.000 claims description 5
- 230000001737 promoting effect Effects 0.000 abstract description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
Images
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
-
- 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]
-
- 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/21—Monitoring or handling of messages
- H04L51/214—Monitoring or handling of messages using selective forwarding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
-
- 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/14—Session management
- H04L67/141—Setup of application sessions
-
- 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/50—Network services
- H04L67/55—Push-based network services
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明实施例提供一种分布式实时消息推送方法,包括以下步骤:S1:客户端通过Netty的NIO方式连接服务器;S2:ALLOC服务器查询服务器连接数最少的服务器地址和端口信息;S3:客户端通过IP地址和端口与若干服务器建立长连接;S4:ALLOC服务器根据redis中客户端与服务器连接关系表,自动将服务器的消息推送至对应的客户端;本发明实施例支持无限水平扩展服务器,进而促使客户端连接的服务器均衡。
Description
技术领域
本发明涉及通信技术领域,更具体地说,涉及到一种分布式实时消息推送方法。
背景技术
随着业务量的增长,现阶段单台服务器无法满足高并发的场景,我们需要多台机器提供消息推送服务,同时主要考虑到扩展的伸缩性,即加即用,支持无限扩展。
本发明内容
为了克服现有技术的不足,本发明提供一种分布式实时消息推送方法用来解决不支持无限水平扩展服务器,负载不均衡的技术问题。
本发明解决其技术问题所采用的技术方案是:提供一种分布式实时消息推送方法,包括以下步骤:
S1:客户端通过Netty的NIO方式连接服务器;
S2:ALLOC服务器查询服务器连接数最少的服务器地址和端口信息;
S3:客户端通过IP地址和端口与若干服务器建立长连接;
S4:ALLOC服务器根据redis中客户端与服务器连接关系表,自动将服务器的消息推送至对应的客户端。
优选地,在客户端通过Netty的NIO方式连接服务器之前,所述步骤还包括:
生成客户端和服务器密钥对、证书仓库以及自签名证书;
服务器的自签名证书导入至客户端证书库中;
客户端的自签名证书导入至服务器证书库中。
优选地,在客户端的自签名证书导入至服务器证书库中之后,所述步骤还包括:
对客户端以及服务器的自签名证书进行加载和校验。
具体地,ALLOC服务器查询服务器连接数最少的服务器地址和端口信息,所述步骤包括:
客户端基于Nginx通过负载均衡访问ALLOC服务器;
ALLOC服务器获取负载最少的服务器地址和端口信息。
优选地,客户端通过IP地址和端口与若干服务器建立长连接之后,ALLOC服务器根据redis中客户端与服务器连接关系表,自动将服务器的消息推送至对应的客户端之前,所述步骤还包括:
ALLOC服务器监听zookeeper的临时目录;
ALLOC服务器获取长连接服务器的状态与连接数量。
优选地,ALLOC服务器获取长连接服务器的状态与连接数量之后,所述步骤还包括:
当提供长连接业务的服务器出现宕机或者其他问题时,ALLOC服务器通过ZKClient监听到服务器对应节点的删除事件;
ALLOC服务器将对应的节点信息从payload服务器列表中删除;
当节点信息从payload服务器列表中删除时,客户端重新连接离线的服务器。
优选地,当节点信息从payload服务器列表中删除时,客户端重新连接离线的服务器之后,所述步骤还包括:
长连接业务的服务器启动之后,在zookeeper对应的根节点下生成服务器对应的节点以及更新节点连接数;
当服务器对应的节点数扩展时,ALLOC服务器自动发现新增的服务器。
优选地,当服务器对应的节点数扩展时,ALLOC服务器自动发现新增的服务器之后,所述步骤还包括:
ALLOC服务器监听ZKClient的节点增加事件,重新刷新提供服务的机器信息;
将刷新之后提供服务的机器信息存入至Redis。
优选地,将刷新之后提供服务的机器信息存入至Redis之后,所述步骤好包括:
ALLOC服务器与各个长连接业务服务器之间建立心跳;
优选地,ALLOC服务器与各个长连接业务服务器之间建立心跳之后,所述步骤还包括:
ALLOC服务器定期向定期各个长连接业务服务器发送报文,当连续三次没有回应,则将没有回应的服务器从服务器列表中删除。
本发明的有益效果是:S1:客户端通过Netty的NIO方式连接服务器;S2:ALLOC服务器查询服务器连接数最少的服务器地址和端口信息;S3:客户端通过IP地址和端口与若干服务器建立长连接;S4:ALLOC服务器根据redis中客户端与服务器连接关系表,自动将服务器的消息推送至对应的客户端;从而支持无限水平扩展服务器,进而促使客户端连接的服务器均衡。
附图说明
图1是一种分布式实时消息推送方法的流程示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
以下结合具体实施例对本发明的具体实现进行详细描述:
实施例一:
图1示出了本发明实施例一提供的一种分布式实时消息推送方法的实现流程,为了便于说明,仅示出了与本发明实施例相关的部分,详述如下:
在步骤S101中,客户端通过Netty的NIO方式连接服务器;
在本申请实施例中,客户端通过Netty的NIO方式连接服务器,该NIO方式只需要单线程就可以处理高并发连接,外部请求进来之后,当有消息需要推送,Selector找到对应标识进行通知,提高了消息推送的效率。
优选地,在客户端通过Netty的NIO方式连接服务器之前,所述步骤还包括:
生成客户端和服务器密钥对、证书仓库以及自签名证书;
服务器的自签名证书导入至客户端证书库中;
客户端的自签名证书导入至服务器证书库中。
优选地,在客户端的自签名证书导入至服务器证书库中之后,所述步骤还包括:
对客户端以及服务器的自签名证书进行加载和校验。
在步骤S102中,ALLOC服务器查询服务器连接数最少的服务器地址和端口信息;
在本申请实施例中,ALLOC服务器查询服务器连接数最少的服务器地址和端口信息,以便支持无限水平扩展服务器,进而促使客户端连接的服务器均衡。
具体地,ALLOC服务器查询服务器连接数最少的服务器地址和端口信息,所述步骤包括:
客户端基于Nginx通过负载均衡访问ALLOC服务器;
ALLOC服务器获取负载最少的服务器地址和端口信息。
在步骤S103中,客户端通过IP地址和端口与若干服务器建立长连接;
在本申请实施例中,为了将消息实时地推送至客户端,客户端通过IP地址和端口与若干服务器建立长连接。
优选地,客户端通过IP地址和端口与若干服务器建立长连接之后,ALLOC服务器根据redis中客户端与服务器连接关系表,自动将服务器的消息推送至对应的客户端之前,所述步骤还包括:
ALLOC服务器监听zookeeper的临时目录;
ALLOC服务器获取长连接服务器的状态与连接数量。
优选地,ALLOC服务器获取长连接服务器的状态与连接数量之后,所述步骤还包括:
当提供长连接业务的服务器出现宕机或者其他问题时,ALLOC服务器通过ZKClient监听到服务器对应节点的删除事件;
ALLOC服务器将对应的节点信息从payload服务器列表中删除;
当节点信息从payload服务器列表中删除时,客户端重新连接离线的服务器。
优选地,当节点信息从payload服务器列表中删除时,客户端重新连接离线的服务器之后,所述步骤还包括:
长连接业务的服务器启动之后,在zookeeper对应的根节点下生成服务器对应的节点以及更新节点连接数;
当服务器对应的节点数扩展时,ALLOC服务器自动发现新增的服务器。
优选地,当服务器对应的节点数扩展时,ALLOC服务器自动发现新增的服务器之后,所述步骤还包括:
ALLOC服务器监听ZKClient的节点增加事件,重新刷新提供服务的机器信息;
将刷新之后提供服务的机器信息存入至Redis。
优选地,将刷新之后提供服务的机器信息存入至Redis之后,所述步骤好包括:
ALLOC服务器与各个长连接业务服务器之间建立心跳;
优选地,ALLOC服务器与各个长连接业务服务器之间建立心跳之后,所述步骤还包括:
ALLOC服务器定期向定期各个长连接业务服务器发送报文,当连续三次没有回应,则将没有回应的服务器从服务器列表中删除。
在步骤S104中,ALLOC服务器根据redis中客户端与服务器连接关系表,自动将服务器的消息推送至对应的客户端。
在本申请实施例中,客户端首先访问ALLOC服务器,ALLOC服务器根据查询缓存,获取目前连接数最少的业务服务器,然后再将连接数最少的业务服务器的IP地址返回给客户端,客户端再和该业务服务器建立起长连接。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,所述的程序可以存储于一计算机可读取存储介质中,所述的存储介质,如ROM/RAM、磁盘、光盘等。
实施例二:
S201:生成客户端和服务器密钥对与证书仓库以及自签名证书;
S202:服务器的自签名证书导入至客户端证书库中;
S203:客户端的自签名证书导入至服务器证书库中;
S204:对客户端以及服务器的自签名证书进行加载和校验;
S204:客户端通过Netty的NIO方式连接服务器;
S205:ALLOC服务器查询服务器连接数最少的服务器地址和端口信息;
具体地,客户端基于Nginx通过负载均衡访问ALLOC服务器;
ALLOC服务器获取负载最少的服务器地址和端口信息;
S206:客户端通过IP地址和端口与对应的服务器建立长连接;
当客户端通过IP地址和端口与对应的服务器建立的长连接关闭时,则重新进行长连接;
S207:ALLOC服务器监听zookeeper的临时目录;
S208:ALLOC服务器获取长连接服务器的状态与连接数量;
S209:当提供长连接业务的服务器出现宕机或者其他问题时,ALLOC服务器通过ZKClient监听到服务器对应节点的删除事件;
S210:ALLOC服务器将对应的节点信息从payload服务器列表中删除;
S211:当节点信息从payload服务器列表中删除时,客户端重新连接离线的服务器;
S212:长连接业务的服务器启动之后,在zookeeper对应的根节点下生成服务器对应的节点以及更新节点连接数;
S213:当服务器对应的节点数扩展时,ALLOC服务器自动发现新增的服务器;
S214:ALLOC服务器监听ZKClient的节点增加事件,重新刷新提供服务的机器信息;
S215:将刷新之后提供服务的机器信息存入至Redis;
S216:ALLOC服务器与各个长连接业务服务器之间建立心跳;
S217:ALLOC服务器定期向定期各个长连接业务服务器发送报文,当连续三次没有回应,则将没有回应的服务器从服务器列表中删除;
S218:当客户端查询长连接业务服务器信息时,不返回宕机的服务器的地址与端口信息。
S219:ALLOC服务器根据redis中客户端与服务器连接关系表,自动将服务器的消息推送至对应的客户端。
具体实现方法
1、生成证书库和导入自签名证书:
通过java的keytool工具生成服务器端的密钥对和证书仓库;例如:可以通过如下命令keytool-genkey-alias securesPush-keysize 2048-validity 365-keyalg RSA-dname"CN=www.xxxx.com"-keypass sNetty-storepass sNetty-keystore sPush.jks
生成服务器端证书的签名:
keytool-export-alias securesPush-keystore sPush.jks-storepass sNetty-file sPush.cer
生成客户端秘钥对和证书仓库:
keytool-genkey-alias securecPush-keysize 2048-validity 365-keyalgRSA-dname"CN=www.xxxx.com"-keypass sNetty-storepass sNetty-keystorecPush.jks生成客户端证书的签名
keytool-export-alias securecPush-keystore cPush.jks-storepass sNetty-file cPush.cer
将服务器签名导入到客户端证书库:
keytool-import-trustcacerts-alias securesPush-file sPush.cer-storepass sNetty-keystore cPush.jks
将客户端签名导入到服务器证书库:
keytool-import-trustcacerts-alias securecPush-file cPush.cer-storepass sNetty-keystore sPush.jks
证书的加载和校验;主要通过java.security.KeyStore的load方法将秘钥和服务端信任的证书加载到证书库中,然后通过javax.net.ssl.SSLContext的init方法初始化刚才的秘钥和信任证书加载到SSL上下文中,然后创建一个SSLEngin,传入io.netty.handler.ssl.SslHandler构造函数中,最后传到io.netty.channel.ChannelPipeline中处理输入发送报文。
客户端基于Nginx通过负载均衡访问ALLOC服务器获取负载最少的长连接业务服务器的IP和端口信息,然后客户端连接到对应的长连接服务器建立起长连接。当建立起连接长连接后出现连接关闭,则重新重复上面的步骤获取长连接。
ALLOC服务器通过监听zookeeper的临时目录获取长连接服务器的状态和连接数量。
当提供长连接业务服务的服务器出现宕机或者其他问题而无法提供长连接服务的时候,ALLOC可以通过ZKClient监听到对应的服务器节点的删除事件,然后ALLOC服务器会把对应的节点服务器信息从payload服务器列表中删除。客户端重连的时候,再经过步骤2就不再把离线的服务器信息分配给新的请求的连接。
提供长连接的业务服务器启动后,在zookeeper对应的根节点下生成自己的服务器对应的节点和更新连接数,然后ALLOC服务器通过监听到ZKClient的节点增加事件,重新刷新提供服务的机器信息,存入redis。
节点数的扩展,服务器端只需要增加新的服务器,ALLOC模块自动发现新增的服务器,从而新的连接会自动落在新增服务器上面。
ALLOC服务器与各个长连接业务服务器之间建立心跳,每隔1秒钟发送一个报文,如果连续3次没有回应,则将该服务器从服务器列表删除;当外部客户端查询长连接业务服务器信息的时候,不会给外部客户端返回宕机的服务器地址和端口信息。
由于每一个客户端和长连接业务服务器已经建立起连接,ALLOC服务器在redis里面维护一套对应关系表,如果内部服务器需要给客户端推送消息,则通过客户端唯一标识,从该关系表里面查询到对应的服务器,ALLOC服务器自动连接该服务器,向该客户端发送消息,客户端接收到消息后,根据消息类型,做对应的业务操作。
当客户端发送到服务器的报文,转发模块会根据消息的类型,调用对应的方法完成业务操作,并给客户端返回处理结果。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各实施例的单元及算法步骤,能够以电子硬件或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。
专业技术人员可以对每个特定的应用来使用不同的方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉技术领域的人员在本发明揭露的技术范围内,可轻易想到变化或者替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以权利要求的保护范围为准。
Claims (10)
1.一种分布式实时消息推送方法,其特征在于,包括以下步骤:
S1:客户端通过Netty的NIO方式连接服务器;
S2:ALLOC服务器查询服务器连接数最少的服务器地址和端口信息;
S3:客户端通过IP地址和端口与若干服务器建立长连接;
S4:ALLOC服务器根据redis中客户端与服务器连接关系表,自动将服务器的消息推送至对应的客户端。
2.根据权利要求1所述的一种分布式实时消息推送方法,其特征在于,在客户端通过Netty的NIO方式连接服务器之前,所述步骤还包括:
生成客户端和服务器密钥对、证书仓库以及自签名证书;
服务器的自签名证书导入至客户端证书库中;
客户端的自签名证书导入至服务器证书库中。
3.根据权利要求2所述的一种分布式实时消息推送方法,其特征在于,在客户端的自签名证书导入至服务器证书库中之后,所述步骤还包括:
对客户端以及服务器的自签名证书进行加载和校验。
4.根据权利要求3所述的一种分布式实时消息推送方法,其特征在于,ALLOC服务器查询服务器连接数最少的服务器地址和端口信息,所述步骤包括:
客户端基于Nginx通过负载均衡访问ALLOC服务器;
ALLOC服务器获取负载最少的服务器地址和端口信息。
5.根据权利要求4所述的一种分布式实时消息推送方法,其特征在于,客户端通过IP地址和端口与若干服务器建立长连接之后,ALLOC服务器根据redis中客户端与服务器连接关系表,自动将服务器的消息推送至对应的客户端之前,所述步骤还包括:
ALLOC服务器监听zookeeper的临时目录;
ALLOC服务器获取长连接服务器的状态与连接数量。
6.根据权利要求5所述的一种分布式实时消息推送方法,其特征在于,ALLOC服务器获取长连接服务器的状态与连接数量之后,所述步骤还包括:
当提供长连接业务的服务器出现宕机或者其他问题时,ALLOC服务器通过ZKClient监听到服务器对应节点的删除事件;
ALLOC服务器将对应的节点信息从payload服务器列表中删除;
当节点信息从payload服务器列表中删除时,客户端重新连接离线的服务器。
7.根据权利要求6所述的一种分布式实时消息推送方法,其特征在于,当节点信息从payload服务器列表中删除时,客户端重新连接离线的服务器之后,所述步骤还包括:
长连接业务的服务器启动之后,在zookeeper对应的根节点下生成服务器对应的节点以及更新节点连接数;
当服务器对应的节点数扩展时,ALLOC服务器自动发现新增的服务器。
8.根据权利要求7所述的一种分布式实时消息推送方法,其特征在于,当服务器对应的节点数扩展时,ALLOC服务器自动发现新增的服务器之后,所述步骤还包括:
ALLOC服务器监听ZKClient的节点增加事件,重新刷新提供服务的机器信息;
将刷新之后提供服务的机器信息存入至Redis。
9.根据权利要求8所述的一种分布式实时消息推送方法,其特征在于,将刷新之后提供服务的机器信息存入至Redis之后,所述步骤好包括:
ALLOC服务器与各个长连接业务服务器之间建立心跳。
10.根据权利要求9所述的一种分布式实时消息推送方法,其特征在于,ALLOC服务器与各个长连接业务服务器之间建立心跳之后,所述步骤还包括:
ALLOC服务器定期向定期各个长连接业务服务器发送报文,当连续三次没有回应,则将没有回应的服务器从服务器列表中删除。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011372787.6A CN112511628A (zh) | 2020-11-30 | 2020-11-30 | 一种分布式实时消息推送方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011372787.6A CN112511628A (zh) | 2020-11-30 | 2020-11-30 | 一种分布式实时消息推送方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN112511628A true CN112511628A (zh) | 2021-03-16 |
Family
ID=74968012
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011372787.6A Pending CN112511628A (zh) | 2020-11-30 | 2020-11-30 | 一种分布式实时消息推送方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112511628A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113472846A (zh) * | 2021-05-28 | 2021-10-01 | 乐融致新电子科技(天津)有限公司 | 消息处理方法、装置、设备和计算机可读存储介质 |
CN115866286A (zh) * | 2023-01-31 | 2023-03-28 | 北京微吼时代科技有限公司 | 直播业务中消息服务的方法与系统 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103475566A (zh) * | 2013-07-10 | 2013-12-25 | 北京发发时代信息技术有限公司 | 一种实时消息交换平台及分布式集群组建方法 |
CN109698785A (zh) * | 2017-10-24 | 2019-04-30 | 广东亿迅科技有限公司 | 一种分布式高并发的实时消息推送方法及装置 |
CN111565229A (zh) * | 2020-04-29 | 2020-08-21 | 创盛视联数码科技(北京)有限公司 | 一种基于Redis的通信系统分布式方法 |
-
2020
- 2020-11-30 CN CN202011372787.6A patent/CN112511628A/zh active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103475566A (zh) * | 2013-07-10 | 2013-12-25 | 北京发发时代信息技术有限公司 | 一种实时消息交换平台及分布式集群组建方法 |
CN109698785A (zh) * | 2017-10-24 | 2019-04-30 | 广东亿迅科技有限公司 | 一种分布式高并发的实时消息推送方法及装置 |
CN111565229A (zh) * | 2020-04-29 | 2020-08-21 | 创盛视联数码科技(北京)有限公司 | 一种基于Redis的通信系统分布式方法 |
Non-Patent Citations (2)
Title |
---|
一直不懂: "(【Netty权威指南】20-安全性", 《CSDN》 * |
徐龙光等: "基于Netty的消息推送服务器集群设计与实现", 《软件导刊》 * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113472846A (zh) * | 2021-05-28 | 2021-10-01 | 乐融致新电子科技(天津)有限公司 | 消息处理方法、装置、设备和计算机可读存储介质 |
CN113472846B (zh) * | 2021-05-28 | 2023-04-28 | 乐融致新电子科技(天津)有限公司 | 消息处理方法、装置、设备和计算机可读存储介质 |
CN115866286A (zh) * | 2023-01-31 | 2023-03-28 | 北京微吼时代科技有限公司 | 直播业务中消息服务的方法与系统 |
CN115866286B (zh) * | 2023-01-31 | 2023-05-16 | 北京微吼时代科技有限公司 | 直播业务中消息服务的方法与系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11907359B2 (en) | Event-based user state synchronization in a local cloud of a cloud storage system | |
US7251689B2 (en) | Managing storage resources in decentralized networks | |
US8688803B2 (en) | Method for efficient content distribution using a peer-to-peer networking infrastructure | |
US7069318B2 (en) | Content tracking in transient network communities | |
US7143139B2 (en) | Broadcast tiers in decentralized networks | |
US7181536B2 (en) | Interminable peer relationships in transient communities | |
US20070230468A1 (en) | Method to support mobile devices in a peer-to-peer network | |
CN112511628A (zh) | 一种分布式实时消息推送方法 | |
JP5000763B2 (ja) | ピアツーピアネットワーク | |
CN107251518B (zh) | 用于中立应用程序编程接口的系统和方法 | |
WO2006096928A1 (en) | A method and system of communication with identity and directory management | |
CN111030818A (zh) | 一种基于微服务网关的统一会话管理方法及系统 | |
EP1491026B1 (en) | Dynamic addressing in transient networks | |
CN111343286A (zh) | 一种网络接入系统及网络接入方法 | |
CN114036236A (zh) | 多网关集群系统 | |
CN107547512B (zh) | 一种多级云平台中的用户认证方法和装置 | |
Guo et al. | Enabling blockchain applications over named data networking | |
CN113612811B (zh) | 一种在多通道中客户端挂载的方法、系统、设备及介质 | |
CN114615315A (zh) | 线上会话的通讯方法、装置、设备及存储介质 | |
CN111343002B (zh) | 服务器扩容部署的方法、装置及服务器 | |
KR100646346B1 (ko) | 동등 계층 통신을 이용한 유무선 통합 스토리지 서비스제공 방법 및 시스템 | |
CN114996241A (zh) | 存储方法、迁移方法、下载方法、存储系统、电子设备、以及介质 | |
Pecori | Trust-based storage in a Kademlia network infected by Sybils | |
KR100498231B1 (ko) | 커드 시스템을 이용한 분산 처리 환경에서의 검색 방법 | |
CN117834634A (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: 20210316 |
|
RJ01 | Rejection of invention patent application after publication |