CN111565229A - Communication system distributed method based on Redis - Google Patents
Communication system distributed method based on Redis Download PDFInfo
- Publication number
- CN111565229A CN111565229A CN202010355894.1A CN202010355894A CN111565229A CN 111565229 A CN111565229 A CN 111565229A CN 202010355894 A CN202010355894 A CN 202010355894A CN 111565229 A CN111565229 A CN 111565229A
- Authority
- CN
- China
- Prior art keywords
- cluster
- redis
- client
- message
- gateway
- 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.)
- Granted
Links
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/14—Session management
- H04L67/141—Setup of application sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
-
- 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
- H04L67/1004—Server selection for load balancing
- H04L67/1023—Server selection for load balancing based on a hash applied to IP addresses or costs
-
- 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
- H04L67/1034—Reaction to server failures by a load balancer
-
- 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/56—Provisioning of proxy services
-
- 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/143—Termination or inactivation of sessions, e.g. event-controlled end of session
- H04L67/145—Termination or inactivation of sessions, e.g. event-controlled end of session avoiding end of session, e.g. keep-alive, heartbeats, resumption message or wake-up for inactive or interrupted session
Abstract
The invention provides a communication system distributed method based on Redis.A client establishes Websocket long connection with a Gateway layer of a Gateway cluster through an Nginx cluster; the Gateway cluster acquires a cluster acquisition node list of a message processor and requests the message processor to establish connection; the client sends a message, and forwards a message request to a message processor, and the message processor issues the message to Redis; for subscribed clients, the publisher Redis Stream structure creates a corresponding Consumer Group through xadd, and then other clients ensure that messages are reliably consumed through an xreadgroup and ack mechanism. The invention integrates message pushing and subscription service to form a message processor cluster independently, monitors the health state of each node of the message processor cluster through an Eureka registration center cluster, deploys the cluster and achieves a high-efficiency service mode of high-availability and distributed cluster deployment.
Description
Technical Field
The invention relates to a message system based on a Redis topic subscription mode, in particular to a communication system distributed method based on Redis.
Background
As shown in fig. 1, the existing server architecture of the chat system has solved the shortcomings of single-machine deployment of the traditional chat system to a great extent, and achieves high availability, dynamic expansion, and the like. By adopting the layering idea, the message stream processors are independently extracted and used for processing push-pull message streams to form an independent middleware processor cluster, the messages are pushed and subscribed to a corresponding channel of the Redis cluster, and then the messages are forwarded to all other corresponding clients connected to the server.
The defects of the prior art scheme are as follows:
the existing chat system based on the Redis Pub/Sub topic subscription model still has some disadvantages, and the following analysis is performed.
1. The reliability of the data cannot be guaranteed:
one client issues messages and n clients receive messages. The publication of the message is stateless, i.e. after the publication of the message, the client does not care whether the message is received or not, and whether the message is lost in the transmission process or not, i.e. for the publisher, the message is "on-the-fly".
2. Scalability is too poor and data loss risk is large:
consumption of the publisher's written data cannot be accelerated by adding consumers, and if the publisher issues many messages, the data is blocked in the channel waiting to be consumed by the consumer. The longer the blocking time, the greater the risk of data loss (an instability of the network or server will result in loss of data).
The consumer needs to monopolize the link, during the subscription period, the redis-client cannot insert other operations, and at the moment, the client waits for the message of the 'pub end' in a blocking mode; the default connection time of the TCP is fixed, and if the sub end does not receive the message of the pub end in the period of time or the pub end does not generate the message, the connection of the sub end is forcibly recovered; once the sub terminal disconnects the link, part of the message will be lost, i.e. the message during the link failure will be lost.
In addition, the Pub/Sub message model of redis is Fire and Forgot. That is to say, Redis does not store any history message, if the network connection of a certain user is abnormal, after re-joining, the user can not see the chat records during the broken link, and the newly joined user can not see the history records in the latest period of time, which is very inconvenient for the user to quickly understand the problem in the current discussion. In addition, if Redis is restarted, all users also need to re-subscribe to the channel.
Disclosure of Invention
The invention provides a communication system distributed method based on Redis, which solves the problems of poor message processing reliability and large loss risk in the existing topic subscription mode based on Redis Pub/Sub, and the technical scheme is as follows:
a distributed method of a Redis-based communication system, the communication system comprises an Nginx cluster connected with a client, the load of the Nginx cluster adopts keepalive, the Nginx cluster is connected with a Gateway cluster, the Gateway cluster is connected with a message processor cluster and an Eureka registration center cluster, the message processor cluster is respectively connected with a Redis cluster and a Sentein cluster, and the distributed processing of the communication system comprises the following steps:
s1: all available message processor nodes in the message processor cluster register with an Eureka registration center, and the Eureka registration center cluster maintains communication with the message processor nodes through heartbeat detection;
s2: the client establishes Websocket long connection with a Gateway layer of the Gateway cluster through the Nginx cluster;
s3: the Gateway node acquires a message processor cluster acquisition node list through an Eureka registration center cluster, and requests a message processor to establish connection by performing modulo calculation on a node to be distributed for a server ip when an available node exists;
s4: the client sends a message, finds a gateway node according to ip _ hash modulo through nginx, the gateway node finds a corresponding message processor node again, forwards a message request to a message processor, and the message processor issues the message to Redis;
s5: for subscribed clients, the publisher Redis Stream structure creates a corresponding Consumer Group through xadd, and then other clients ensure that messages are reliably consumed through an xreadgroup and ack mechanism.
Further, in step S2, the client implements full duplex communication between the client and the Nginx cluster based on the Websocket layer, and the client obtains a token for accessing the server resource from the authentication service cluster, thereby being able to trust to access the corresponding server resource through the Gateway layer of the Gateway cluster.
The Nginx cluster carries out reverse proxy forwarding work on the request of the client, and the connection mode is long connection by adopting upstream.
The Gateway cluster integrates Ribbon, a load balancing strategy is realized by adopting a Hash modular mode aiming at a client ip, a connection state is kept, and the phenomenon that the client connection is reset and reconnection is interrupted due to stateless distribution is prevented.
Further, in step S4, the message processor cluster maintains a long connection established with the Gateway, and is responsible for forwarding the push message request to the corresponding Redis Stream, and simultaneously subscribes to a message existing in the Redis cluster Consumer Group in real time, and forwards the message to the corresponding client in real time.
Before the Gateway of the Gateway cluster distributes the request of the client, the Gateway needs to acquire the available message processor nodes from the Eureka registration center cluster and then distribute the request.
Furthermore, the Redis cluster is built with a three-master-three-slave structure, the health state of the nodes is monitored by utilizing sentinel, when the client is connected with the Redis cluster, the client is firstly connected with the sentinel, the address of the master node is inquired through the sentinel, and then the client is connected with the master node to perform data interaction; when the main node fails, the client sends an address to sentinel again, and the sentinel informs the client of the latest main node address.
Further, if a node of the message processor is down, the concerned client needs to reset the connection, reestablish the connection, and the gateway layer recalculates and allocates a new message processor node.
In the distributed communication system method based on Redis, the Redis cluster fault processing is better, the sentinel cluster is adopted to monitor the Redis cluster, and the standby nodes are automatically switched into the main node aiming at the fault main node, so that the availability of the Redis service is ensured. The data is persistent, and the Redis Stream structure performs persistent processing on the data, so that data loss caused by node downtime can be avoided. In addition, for the Redis Pub/Sub topic subscription model, messages generated during client connection interruption are lost, and Redis Stream solves the problem well.
Drawings
FIG. 1 is a schematic diagram of a server architecture of a conventional chat system;
FIG. 2 is a schematic diagram of a Redis-based communication system distributed approach provided by the present invention;
FIG. 3 is a schematic diagram of establishing a long connection lifecycle;
FIG. 4 is a schematic diagram of a message push lifecycle;
fig. 5 is a schematic diagram of a message subscription lifecycle.
Detailed Description
The invention provides a communication system distributed method based on Redis, which adopts the following architecture as shown in figure 2:
the network management system comprises an Nginx cluster connected with a client, wherein the load of the Nginx cluster adopts keepalive, the Nginx cluster is connected with a Gateway cluster, the Gateway cluster is connected with a message processor cluster and an Eureka registration center cluster, and the message processor cluster is respectively connected with a Redis cluster and a Sentinel cluster. The following is a detailed description of each cluster:
1. a client: based on a Websocket layer, full-duplex communication between a client and a server (a message processor service for building Websocket service) is realized; by establishing the long Websocket connection, the client can actively send messages to the server through the gateway, the server can also actively send messages to the client through the Websocket, and the real-time performance of information exchange can be guaranteed to the greatest extent.
Meanwhile, the client side has the characteristic of passing Gateway authentication, and the client side obtains the token of the access server side resource from the authentication service cluster, so that the access server side resource can be trusted through the Gateway layer of the Gateway cluster.
2. Cluster of Nginx: the method is responsible for carrying out reverse proxy forwarding work on the request of the client, reduces the times of three-way handshake and improves the connection efficiency. keepalived is used as the load of nginx, one vip is used for the external, and three nginx are highly available.
Three-way handshake on TCP:
when establishing a TCP connection, the client and the server are required to send 3 packets in total.
For the first time: client end sends request mark of initial sequence number x and syn ═ 1
Second time: the server sends a request flag syn, an acknowledgement flag ACK, its own sequence number seq ═ y, and the acknowledgement sequence number ACK of the sending client ═ x +1
Third time: the client sends an ACK (acknowledgement character) acknowledgement number, the sequence number seq of the client is x +1, and the acknowledgement number ACK of the client is y +1
By realizing upstream long connection, a connection pool is configured for the process, and the insides of the connection pools are all long connections. Once the connection is established with the back-end server, the connection is not immediately closed after the current request connection is finished, but the used connection is stored in a keepalive connection pool, and then when the backward connection is required to be established each time, the connection only needs to be found from the connection pool, if a proper connection is found, the connection can be directly used without recreating a socket or initiating a connection. Therefore, the time consumption of three-way handshake during connection establishment is saved, and the slow start of TCP connection can be avoided. If no suitable connection can be found in the keepalive connection pool, the connection is re-established.
3. Gateway cluster: the method is realized by netty and webflux used by Spring Cloud Gateway, and the real-time transmission and subscription of the message are maintained by routing the request of the client to the message processor cluster and establishing long connection with the message processor in a non-blocking IO mode; in addition, the gateway judges the authority of the current request and limits the current request concurrency, so as to prevent the concurrency from being too high and cause the crash of a background server (the gateway, the authentication service and the message processor service); and the performance index monitoring and early warning of a server (gateway, authentication service and message processor service) and the fusing measure when the service node (authentication service and message processor service) is unavailable are realized by organizing Hystrix.
The Gateway integration Ribbon realizes a load balancing strategy by adopting a mode of carrying out Hash modular extraction aiming at the client ip, keeps a connection state and prevents the problems of client connection resetting and reconnection interruption caused by stateless distribution.
4. Message processor cluster: and maintaining the long connection established with the Gateway, and being responsible for forwarding the push message request to the corresponding Redis Stream, simultaneously subscribing the message existing in the Consumer Group in real time, and forwarding the message to the corresponding client in real time.
5. Eureka registry cluster: all available message processor nodes in the message processor cluster need to register with an Eureka registration center to indicate that the current service is available, the Eureka registration center cluster maintains communication with the message processor nodes through heartbeat detection, monitors the health state of the message processor nodes, and if the message processor nodes are unavailable, the Eureka registration center cluster server removes the instances from an instance list maintained by the Eureka registration center cluster server and sends a node unavailable notice to an administrator; in addition, before the Gateway of the Gateway cluster distributes the request, the Gateway needs to acquire available message processor nodes from the Eureka registration center cluster, and then distributes the request.
6. Redis cluster + Sentinal cluster: by establishing a three-master-three-standby mode for the Redis cluster, adopting master-slave copy and utilizing sentinel to monitor the health state of the nodes, the unavailable service risk caused by node faults is resisted, and the characteristics of high availability of service and transverse expansion are achieved.
The method adopts 6 Redis nodes to form a three-master-three-slave Redis cluster, so that individual nodes are hung, and the cluster can also normally operate. Meanwhile, 3 Sentinel nodes are adopted to form a Sentinel cluster (an odd number of Sentinel nodes can ensure that the Sentinel cluster follows the principle that more than half of the Sentinel nodes vote when the main Redis node crashes and the main Sentinel node is voted and selected, the main Sentinel node subjectively switches the secondary Redis node to be the main Redis node, and ensures that automatic primary and secondary fault switching is achieved when the Redis cluster fails), the Sentinel cluster is responsible for continuously monitoring the health of the primary and secondary nodes, and when the primary node is hung, an optimal secondary node is automatically selected to be switched to be the primary node. When the client is connected with the Redis cluster, the client is firstly connected with sentinel, inquires the address of the main node through the sentinel and then is connected with the main node for data interaction. When the main node fails, the client sends an address to sentinel again, and the sentinel informs the client of the latest main node address. Therefore, the application program can automatically complete the node switching without restarting.
The invention integrates the message pushing and the subscription service, and is independently extracted into an independent service, namely a message processor cluster, and the health state of each node of the message processor cluster is monitored and the cluster is deployed through the Eureka registration center cluster, so that a high-efficiency service mode of high-availability and distributed cluster deployment is achieved.
As shown in fig. 2, for Gateway nodes obtaining a list of nodes through an Eureka registry cluster obtaining message processor cluster, the message processor is requested to establish a connection when there are available nodes modulo the server ip to compute the nodes to be allocated.
As shown in fig. 3, the whole process is implemented by establishing a Websocket long connection in advance, and then performing message pushing and subscribing. And forwarding the request of the client to a corresponding Gateway node in the Gateway cluster through the ip _ hash modulus of the Nginx reverse proxy, and establishing the Websocket long connection with the Gateway node, wherein the long connection establishing life cycle is ended.
As shown in fig. 4, the client sends a message, finds a gateway node according to ip _ hash modulo by nginx, the gateway node finds a corresponding message processor node again, forwards a message request to a message processor, and the message processor issues a message to Redis.
As shown in fig. 5, for subscribed clients, the publisher Redis Stream structure creates a corresponding Consumer Group through xadd, and then other clients ensure that messages are consumed reliably through xreadgroup and ack mechanisms.
The Redis cluster adopts a master-standby mode, and the sentinel cluster monitors master-standby nodes, so that the condition that the master node is down to cause unavailable service is prevented; therefore, the scheme of establishing long connection through integration of the Redis cluster, the message processor cluster and the gateway cluster achieves the scheme of high availability and high performance of publishing the messages and subscribing the messages in real time.
The method uses a unique data structure Stream of Redis5.0, which is a new powerful sustainable message queue supporting multicast and references the design of Kafka.
Redis Stream is essentially a message publish subscribe feature implemented on the Redis kernel (non-Redis Module). Compared with the existing PUB/SUB and BLOCKED LIST, although the method can be used as a message queue in a simple scene, Redis Stream is undoubtedly to be improved. Redis Stream provides the functions of message persistence and active-standby copy, a new RadixTree data structure to support more efficient memory usage and message reading, and even the Consumer Group function similar to Kafka.
Redis Stream's underlying principle, it has a linked list of messages, concatenating all the added messages, each message having a unique ID and corresponding content. The message is persistent and the content remains after the Redis restart. Each Stream has a unique name, which is Redis' key, which is automatically created when we append the message with the xadd instruction for the first time. Each Stream can hang multiple consuming groups, and each consuming group has a cursor last _ delayed _ id moving forward on the Stream array to indicate which message the current consuming group has consumed. Each consumption group has a unique name in Stream, the consumption group can not be automatically created, it needs a separate instruction xgroup create to create, and needs to specify that consumption is started from a certain message ID of Stream, and the ID is used to initialize last _ delivered _ ID variable.
The same Consumer Group (Consumer Group) can be hooked with a plurality of consumers (consumers) which are in competition, and when any Consumer reads the message, the cursor last _ delayed _ id can be moved forward. Each consumer has a unique name within the group. Inside the Consumer (Consumer) there is a state variable pending _ ids that records the messages that have currently been read by the client, but not yet ack. If the client does not have an ack, the message ID in this variable will be more and more, and once a message is acked, it will start to decrease. This Pending ids variable is called PEL in the Redis authority, i.e. Pending Entries List, which is a very core data structure that is used to ensure that a client consumes a message at least once.
In the method, a client needs to establish Websocket connection with a Gateway layer of a Gateway cluster; nginx of the Nginx cluster carries out load distribution, and simultaneously adopts an ip-hash strategy, calculates and distributes a unique gateway node according to the request, and forwards the request; the Gateway layer of the Gateway cluster performs hash modulo calculation according to the client ip, determines the message processor nodes needing to be distributed, and distributes the request; the message processor performs push/real-time monitoring on the subscription message.
If a certain node of the Gateway cluster is down, the clients which have established long connection with other normal Gateway nodes keep normal connection, and other clients which establish connection with the current fault Gateway need to reset connection and redistribute other gateways to establish connection.
If a certain node of the message processor is down, the related client needs to reset the connection, reestablish the connection, and simultaneously the gateway layer recalculates and allocates a new message processor node.
In order to achieve high availability, the method uses Spring Cloud Eureka as a registration center to achieve high availability of the message processor cluster. In addition, the Eureka is a distributed high-availability cluster, and the condition that a certain node of the registry is down to cause unavailable finishing service is not worried. The available state of each node of the whole core service is maintained by the heartbeat detection function of the message processor node by the Eureka.
Compared with the prior art, the Redis cluster fault processing method is more excellent in fault processing, the sentinel cluster is adopted to monitor the Redis cluster, the standby nodes are automatically switched into the main node aiming at the fault main node, and the availability of the Redis service is guaranteed.
And data persistence, namely performing persistence processing on the data by using the Redis Stream structure, so that data loss caused by node downtime can be avoided. In addition, for the Redis Pub/Sub topic subscription model, messages generated during client connection interruption are lost, and Redis Stream solves the problem well.
Claims (8)
1. A communication system distributed method based on Redis is characterized in that: the communication system comprises an Nginx cluster connected with a client, wherein the load of the Nginx cluster adopts keepalive, the Nginx cluster is connected with a Gateway cluster, the Gateway cluster is connected with a message processor cluster and an Eureka registration center cluster, the message processor cluster is respectively connected with a Redis cluster and a Sentinel cluster, and the distributed processing of the communication system comprises the following steps:
s1: all available message processor nodes in the message processor cluster register with an Eureka registration center, and the Eureka registration center cluster maintains communication with the message processor nodes through heartbeat detection;
s2: the client establishes Websocket long connection with a Gateway layer of the Gateway cluster through the Nginx cluster;
s3: the Gateway node acquires a message processor cluster acquisition node list through an Eureka registration center cluster, and requests a message processor to establish connection by performing modulo calculation on a node to be distributed for a server ip when an available node exists;
s4: the client sends a message, finds a gateway node according to ip _ hash modulo through nginx, the gateway node finds a corresponding message processor node again, forwards a message request to a message processor, and the message processor issues the message to Redis;
s5: for subscribed clients, the publisher Redis Stream structure creates a corresponding ConsumerGroup through xadd, and then other clients ensure that messages are reliably consumed through an xreadgroup and ack mechanism.
2. The Redis-based communication system distributed method according to claim 1, wherein: in step S2, the client implements full duplex communication between the client and the Nginx cluster based on the Websocket layer, and the client can trust access to the corresponding server resource through the Gateway layer of the Gateway cluster by obtaining the token for accessing the server resource from the authentication service cluster.
3. The Redis-based communication system distributed method according to claim 2, wherein: the Nginx cluster carries out reverse proxy forwarding work on the request of the client, and the connection mode is long connection by adopting upstream.
4. The Redis-based communication system distributed method according to claim 1, wherein: the Gateway cluster integrates Ribbon, a load balancing strategy is realized by adopting a Hash modular mode aiming at a client ip, a connection state is kept, and the phenomenon that the client connection is reset and reconnection is interrupted due to stateless distribution is prevented.
5. The Redis-based communication system distributed method according to claim 1, wherein: in step S4, the message processor cluster maintains the long connection established with the Gateway, and is responsible for forwarding the push message request to the corresponding RedisStream, and simultaneously subscribes to the message existing in the Redis cluster Consumer Group in real time, and forwards the message to the corresponding client in real time.
6. The Redis based communication system distributed method according to claim 5, wherein: before the Gateway of the Gateway cluster distributes the request of the client, the Gateway needs to acquire the available message processor nodes from the Eureka registration center cluster and then distribute the request.
7. The Redis-based communication system distributed method according to claim 1, wherein: the Redis cluster is established with a three-master-three-slave structure, the health state of nodes is monitored by utilizing sentinel, when the client is connected with the Redis cluster, the client is firstly connected with the sentinel, the address of a main node is inquired through the sentinel, and then the client is connected with the main node for data interaction; when the main node fails, the client sends an address to sentinel again, and the sentinel informs the client of the latest main node address.
8. The Redis-based communication system distributed method according to claim 1, wherein: if a certain node of the message processor is down, the related client needs to reset the connection, reestablish the connection, and simultaneously the gateway layer recalculates and allocates a new message processor node.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010355894.1A CN111565229B (en) | 2020-04-29 | 2020-04-29 | Communication system distributed method based on Redis |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010355894.1A CN111565229B (en) | 2020-04-29 | 2020-04-29 | Communication system distributed method based on Redis |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111565229A true CN111565229A (en) | 2020-08-21 |
| CN111565229B CN111565229B (en) | 2020-11-27 |
Family
ID=72071998
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010355894.1A Active CN111565229B (en) | 2020-04-29 | 2020-04-29 | Communication system distributed method based on Redis |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111565229B (en) |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112068956A (en) * | 2020-08-24 | 2020-12-11 | 北京首汽智行科技有限公司 | Load balancing method based on redis cache and server |
| CN112104740A (en) * | 2020-09-21 | 2020-12-18 | 浪潮云信息技术股份公司 | Software automatic pushing and upgrading system and method based on domestic CPU and OS |
| CN112511628A (en) * | 2020-11-30 | 2021-03-16 | 银盛支付服务股份有限公司 | Distributed real-time message pushing method |
| CN112650706A (en) * | 2020-12-31 | 2021-04-13 | 鲸灵科技股份有限公司 | Method for realizing high situation perception capability under big data technology system |
| CN112733051A (en) * | 2020-12-09 | 2021-04-30 | 新华智云科技有限公司 | Websocket-based information push management system and method |
| CN113157466A (en) * | 2021-04-27 | 2021-07-23 | 上海销氪信息科技有限公司 | Message pushing method, device, system, electronic equipment and storage medium |
| CN113194150A (en) * | 2021-05-12 | 2021-07-30 | 湖南快乐阳光互动娱乐传媒有限公司 | Long connection push service processing system |
| CN113676477A (en) * | 2021-08-20 | 2021-11-19 | 中邮科通信技术股份有限公司 | Method for realizing Socket session cluster communication based on star network and memory routing table |
| CN114095561A (en) * | 2022-01-20 | 2022-02-25 | 阿里巴巴（中国）有限公司 | Message processing system and method, device and storage medium |
| CN114422567A (en) * | 2021-12-09 | 2022-04-29 | 阿里巴巴（中国）有限公司 | Data request processing method, device, system, computer equipment and medium |
| CN115378926A (en) * | 2022-08-16 | 2022-11-22 | 山东浪潮超高清智能科技有限公司 | Emergency broadcast pushing method under mobile terminal equipment |
| CN115514609A (en) * | 2022-08-31 | 2022-12-23 | 北京控制工程研究所 | Socket link limited publishing and subscribing system and method |
| CN116055777A (en) * | 2023-01-03 | 2023-05-02 | 北京流金岁月传媒科技股份有限公司 | Remote control system of multi-channel set top box |
| CN117354117A (en) * | 2023-10-10 | 2024-01-05 | 南京汇银迅信息技术有限公司 | Java and MQ-based distributed message communication method and system |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107093138A (en) * | 2017-04-21 | 2017-08-25 | 山东佳联电子商务有限公司 | Auction Ask-Bid System and its operation method based on distributed clog-free asynchronous message tupe |
| CN107104961A (en) * | 2017-04-21 | 2017-08-29 | 中国电子科技集团公司第二十八研究所 | Distributed real-time video monitoring processing system based on ZooKeeper |
| CN107370663A (en) * | 2017-07-03 | 2017-11-21 | 中国南方电网有限责任公司 | A kind of browser instant messaging services distributed deployment method |
| CN108289055A (en) * | 2018-01-05 | 2018-07-17 | 创盛视联数码科技（北京）有限公司 | A kind of distributed live chat system and method based on Redis subscription services |
| US20180210834A1 (en) * | 2017-01-20 | 2018-07-26 | Mz Ip Holdings, Llc | Systems and methods for reconstructing cache loss |
| US20180276308A1 (en) * | 2015-01-12 | 2018-09-27 | Beijing Jingdong Shangke Information Technology Co., Ltd. | Method and system for increasing page loading rate |
| CN110333986A (en) * | 2019-06-19 | 2019-10-15 | 上海二三四五网络科技有限公司 | A method of ensureing redis cluster availability |
| CN110881060A (en) * | 2019-10-14 | 2020-03-13 | 紫光云(南京)数字技术有限公司 | Opening and authorized downloading platform for electronic files |
| CN110995797A (en) * | 2019-11-19 | 2020-04-10 | 湖北民族大学 | Multilayer B/S and C/S mixed software system and asynchronous real-time communication method between layers |
| CN111010444A (en) * | 2019-12-20 | 2020-04-14 | 创盛视联数码科技（北京）有限公司 | System and method for realizing Wowza streaming media engine distributed cluster |
-
2020
- 2020-04-29 CN CN202010355894.1A patent/CN111565229B/en active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180276308A1 (en) * | 2015-01-12 | 2018-09-27 | Beijing Jingdong Shangke Information Technology Co., Ltd. | Method and system for increasing page loading rate |
| US20180210834A1 (en) * | 2017-01-20 | 2018-07-26 | Mz Ip Holdings, Llc | Systems and methods for reconstructing cache loss |
| CN107093138A (en) * | 2017-04-21 | 2017-08-25 | 山东佳联电子商务有限公司 | Auction Ask-Bid System and its operation method based on distributed clog-free asynchronous message tupe |
| CN107104961A (en) * | 2017-04-21 | 2017-08-29 | 中国电子科技集团公司第二十八研究所 | Distributed real-time video monitoring processing system based on ZooKeeper |
| CN107370663A (en) * | 2017-07-03 | 2017-11-21 | 中国南方电网有限责任公司 | A kind of browser instant messaging services distributed deployment method |
| CN108289055A (en) * | 2018-01-05 | 2018-07-17 | 创盛视联数码科技（北京）有限公司 | A kind of distributed live chat system and method based on Redis subscription services |
| CN110333986A (en) * | 2019-06-19 | 2019-10-15 | 上海二三四五网络科技有限公司 | A method of ensureing redis cluster availability |
| CN110881060A (en) * | 2019-10-14 | 2020-03-13 | 紫光云(南京)数字技术有限公司 | Opening and authorized downloading platform for electronic files |
| CN110995797A (en) * | 2019-11-19 | 2020-04-10 | 湖北民族大学 | Multilayer B/S and C/S mixed software system and asynchronous real-time communication method between layers |
| CN111010444A (en) * | 2019-12-20 | 2020-04-14 | 创盛视联数码科技（北京）有限公司 | System and method for realizing Wowza streaming media engine distributed cluster |
Cited By (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112068956A (en) * | 2020-08-24 | 2020-12-11 | 北京首汽智行科技有限公司 | Load balancing method based on redis cache and server |
| CN112104740A (en) * | 2020-09-21 | 2020-12-18 | 浪潮云信息技术股份公司 | Software automatic pushing and upgrading system and method based on domestic CPU and OS |
| CN112511628A (en) * | 2020-11-30 | 2021-03-16 | 银盛支付服务股份有限公司 | Distributed real-time message pushing method |
| CN112733051A (en) * | 2020-12-09 | 2021-04-30 | 新华智云科技有限公司 | Websocket-based information push management system and method |
| CN112650706A (en) * | 2020-12-31 | 2021-04-13 | 鲸灵科技股份有限公司 | Method for realizing high situation perception capability under big data technology system |
| CN113157466A (en) * | 2021-04-27 | 2021-07-23 | 上海销氪信息科技有限公司 | Message pushing method, device, system, electronic equipment and storage medium |
| CN113194150A (en) * | 2021-05-12 | 2021-07-30 | 湖南快乐阳光互动娱乐传媒有限公司 | Long connection push service processing system |
| CN113676477A (en) * | 2021-08-20 | 2021-11-19 | 中邮科通信技术股份有限公司 | Method for realizing Socket session cluster communication based on star network and memory routing table |
| CN114422567A (en) * | 2021-12-09 | 2022-04-29 | 阿里巴巴（中国）有限公司 | Data request processing method, device, system, computer equipment and medium |
| CN114095561A (en) * | 2022-01-20 | 2022-02-25 | 阿里巴巴（中国）有限公司 | Message processing system and method, device and storage medium |
| CN115378926A (en) * | 2022-08-16 | 2022-11-22 | 山东浪潮超高清智能科技有限公司 | Emergency broadcast pushing method under mobile terminal equipment |
| CN115514609A (en) * | 2022-08-31 | 2022-12-23 | 北京控制工程研究所 | Socket link limited publishing and subscribing system and method |
| CN115514609B (en) * | 2022-08-31 | 2024-05-03 | 北京控制工程研究所 | Socket link limited publishing and subscribing system and method |
| CN116055777A (en) * | 2023-01-03 | 2023-05-02 | 北京流金岁月传媒科技股份有限公司 | Remote control system of multi-channel set top box |
| CN116055777B (en) * | 2023-01-03 | 2024-02-23 | 北京流金岁月传媒科技股份有限公司 | Remote control system of multi-channel set top box |
| CN117354117A (en) * | 2023-10-10 | 2024-01-05 | 南京汇银迅信息技术有限公司 | Java and MQ-based distributed message communication method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111565229B (en) | 2020-11-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111565229B (en) | Communication system distributed method based on Redis | |
| CN110912780B (en) | High-availability cluster detection method, system and controlled terminal | |
| US6934875B2 (en) | Connection cache for highly available TCP systems with fail over connections | |
| EP3490224B1 (en) | Data synchronization method and system | |
| US7702791B2 (en) | Hardware load-balancing apparatus for session replication | |
| US6330605B1 (en) | Proxy cache cluster | |
| US7844851B2 (en) | System and method for protecting against failure through geo-redundancy in a SIP server | |
| US6871296B2 (en) | Highly available TCP systems with fail over connections | |
| JP5557840B2 (en) | Distributed database monitoring mechanism | |
| CN111615066B (en) | Distributed micro-service registration and calling method based on broadcast | |
| US7409420B2 (en) | Method and apparatus for session replication and failover | |
| US7606929B2 (en) | Network load balancing with connection manipulation | |
| EP2347563B1 (en) | Distributed master election | |
| US7518983B2 (en) | Proxy response apparatus | |
| EP1415236B1 (en) | Method and apparatus for session replication and failover | |
| US20120239730A1 (en) | System including a middleware machine environment | |
| JP2004519024A (en) | System and method for managing a cluster containing multiple nodes | |
| WO2011140951A1 (en) | Method, device and system for load balancing | |
| CN102045270A (en) | Chat server system, method for constructing chat server system and chat system | |
| Abawajy | An Approach to Support a Single Service Provider Address Image for Wide Area Networks Environment | |
| WO2009117946A1 (en) | Main-spare realizing method for dispatch servers and dispatch server | |
| CN112671554A (en) | Node fault processing method and related device | |
| US20050270973A1 (en) | Cluster architecture communications | |
| EP2616967A1 (en) | System including a middleware machine environment | |
| CN111756780B (en) | Method for synchronizing connection information and load balancing system |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |