CN112118266B - Distributed state synchronization method based on cooperation of HTTP and WebSocket - Google Patents
Distributed state synchronization method based on cooperation of HTTP and WebSocket Download PDFInfo
- Publication number
- CN112118266B CN112118266B CN202011012551.1A CN202011012551A CN112118266B CN 112118266 B CN112118266 B CN 112118266B CN 202011012551 A CN202011012551 A CN 202011012551A CN 112118266 B CN112118266 B CN 112118266B
- Authority
- CN
- China
- Prior art keywords
- websocket
- session
- client
- service
- server
- 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.)
- Active
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/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
- H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
-
- 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/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- 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/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- 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/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
- H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
Abstract
The invention discloses a distributed state synchronization method based on cooperation of HTTP and WebSocket, which is characterized by comprising the following steps: step 1: initializing the WebSocket server cluster, and step 2: reconstructing a WebSocket server cluster URL, and step 3: distributing a WebSocket session for each client, and step 4: detecting whether the long connection is normal or not, and step 5: determining a service state change request; step 6: calling a service server to process the request, and feeding back a result to the client, wherein the step 7: and sending the request to a WebSocket server node, and step 8: the long connection is closed. The WebSocket server replaces the original client to send heartbeat detection, information or external storage is not used, the effects of simplicity in deployment and easiness in expansion are achieved, and the use function requirements of different scenes are met.
Description
Technical Field
The invention relates to the technical field of data communication, in particular to a distributed state synchronization method based on cooperation of HTTP and WebSocket.
Background
In the field of real-time communication such as audio and video and screen sharing, a real-time state synchronization system is needed for efficient collaboration among users, and the browser and the APP are compatible at the same time. WebSocket can realize instant communication from a server to a client by using long connection, but the client requests the server, and operation results can not be sensed in real time by using asynchronous messages, so that errors can be caused in operation; and the WebSocket protocol is used independently, so that an additional authentication mechanism is required.
In the aspect of long WebSocket connection, in the prior art, a client side is mostly used for sending heartbeats and only can send texts, and the client side and a server side are required to be simultaneously realized, so that certain complexity is achieved; the current distributed WebSocket server cluster still uses a common external storage or message mechanism in a distributed scene, and the architecture is complex.
Patent CN 201811429767-a novel real-time information flow interaction method, which provides a technical scheme for establishing long connection between a client and a server by cooperating with a WebSocket protocol, and performing information interaction by using multi-channel multi-concurrent communication and heartbeat detection; similar to the patent CN 201811622417-a data processing method and system based on Websocket long connection and the patent CN 2019103628180-a method for maintaining Websocket long connection without service data exchange, the heartbeat detection of the client is also explicitly adopted, which increases the burden of the client.
Patent CN 2019104677729-a method for multiple login distributed push by a single user based on WebSocket, and patent CN 2019113338150-a method and device for distributed server cluster interaction based on WebSocket all provide technical solutions based on a distributed scenario, but need to use messages or store, and are not concise in practical application. Meanwhile, in the prior art, only one protocol is used at the same time, and the expansibility is limited.
Therefore, a distributed state synchronization method capable of realizing simple deployment is needed to solve the problem of multi-terminal distributed real-time communication.
Disclosure of Invention
The invention aims to solve the technical problem of overcoming the defects of the prior art and provides a distributed state synchronization method for cooperation of an HTTP (hyper text transport protocol) and a WebSocket protocol, wherein the invention acquires a WebSocket server node address through an authenticated HTTP request; when a user initiates operation, the user uses an HTTP request to ensure that a result is sensed in real time and is not easy to make errors, and other users are informed of using a WebSocket protocol to ensure real-time delivery after the state is updated; in the aspect of long connection, a server sends a WebSocket Ping package defined based on a WebSocket protocol, so that a client of the WebSocket protocol does not need extra processing; the WebSocket server cluster does not depend on any external storage or message mechanism any more, and is simple to deploy and expand.
The invention provides a distributed state synchronization method based on cooperation of HTTP and WebSocket, which comprises the following specific steps:
step 1: initializing a WebSocket server cluster, specifically: deploying a WebSocket server cluster, configuring an initial URL of the WebSocket server cluster, and initializing and generating a concurrent hash table and a heartbeat detection thread when each WebSocket server node in the WebSocket server cluster is started; the WebSocket server cluster initial URL comprises a WSS protocol suitable for a browser end, a WSS protocol suitable for an APP end and a WS protocol; the concurrent hash table adopts a Key-Value storage structure and comprises a session hash table and a heartbeat detection hash table; the session hash table is used for recording connection information between a client and a WebSocket server node, and the connection information comprises WebSocket session information and a connection identifier; the WebSocket session refers to a connection channel established between a client and a WebSocket server node, and comprises a reconstructed WebSocket server cluster URL, a user ID, a message sending and call-back method and an error call-back method; the user ID is an automatically generated unique user identity identifier; a session identifier is allocated when the WebSocket session is generated; the connection identifier consists of a WebSocket server node IP and a session identifier; the heartbeat hash table is used for recording heartbeat detection information between a WebSocket server node and a client; the heartbeat hash table contains a session identifier and the last heartbeat detection time sent by the WebSocket server node; the heartbeat detection thread starts traversing the session hash table every 10 seconds;
and 2, step: reconstructing a WebSocket server cluster URL: when a client accesses an application server for the first time, acquiring a client access request parameter and writing the client access request parameter into a WebSocket server cluster initial URL to form a WebSocket server cluster URL with client authentication; the client access request parameter comprises a client access IP and an access identity; the format of the client access IP is IPv4 or IPv 6; the application server is used for processing HTTP requests;
and 3, step 3: after a long connection between a client and a WebSocket server node is established, distributing a WebSocket session for each client; in a session hash table of a WebSocket server node, recording the long connection established this time by taking a connection identifier as a Key Value and a WebSocket session as a Value; extracting a user ID from the WebSocket session, establishing a corresponding relation between the user ID and a connection identifier, and storing the corresponding relation into a database server through a service server, wherein the service server is used for actual service logic processing;
and 4, step 4: detecting whether the long connection is normal in the long connection maintaining process: every 10 seconds, the WebSocket server node sends a heartbeat detection data packet to the client through the WebSocket session established in the step 2, meanwhile, Value values in a session hash table, namely the WebSocket session, are sequentially traversed, and a session identifier automatically generated when each WebSocket session is established is obtained during traversal; according to the connection identifier, whether a matched data record exists is searched in the heart beat hash table, if not, the session identifier is used as a Key Value, and the current time is used as a Value to be stored in the heart beat hash table; if yes, acquiring the last time when the WebSocket server node corresponding to the session identifier sends the heartbeat detection packet, taking the difference between the current time and the value, judging whether the difference is greater than 20 seconds, if the difference is greater than 20 seconds, deleting the data record corresponding to the session identifier in a heartbeat hash table, closing the WebSocket session, and deleting the data record corresponding to the WebSocket session in a session hash table; if the difference is less than 20 seconds, continuously traversing the next Value in the session hash table until the session hash table is traversed;
and 5: determining whether the service state change request is user active operation or user passive operation according to the type of the service processing result; the service state comprises the state of service logic, and the type of the service processing result comprises that the service processing result needs to be informed to a user and the service processing result does not need to be informed to the user; if the service processing result needs to be informed to the user, the service state change request is regarded as the active operation of the user, based on the HTTP, the client sends the service state change request to the application server for processing, and step 6 is executed; if the service processing result does not need to inform the user, the service state change request is regarded as passive operation of the user, based on the WebSocket protocol, the client sends the service state change request to the WebSocket server node for processing, and step 7 is executed;
step 6: when the application server receives the service state change request, calling the service server to process the request, and feeding back a result to the client; when the service server processes the service state change request, finding out other user IDs needing to synchronously change the service state; searching a connection identifier corresponding to the user ID in the database server according to the user ID, acquiring a WebSocket server node IP by analyzing the connection identifier, determining a WebSocket session by the WebSocket server node according to the connection identifier, sending a service state change notice to the client through the WebSocket session, and informing the user that the service state is changed;
and 7: acquiring a user ID of a login client, finding a WebSocket session containing the user ID, and sending a service state change notification request to a WebSocket server node through the WebSocket session; the WebSocket server node acquires a connection identifier corresponding to the WebSocket session from a session hash table, and sends the connection identifier together with a WebSocket server cluster URL, the current time and a service state change notification to a service server for processing;
and 8: closing long connection between the client and the WebSocket server node, specifically: when a WebSocket server node receives a long connection closing request sent by a client, deleting related WebSocket sessions and connection identifiers matched with the long connection in a concurrent hash table; the method comprises the steps that a WebSocket server node initiates a long connection closing request to a service server in a one-way calling mode, and request parameters comprise a WebSocket server cluster URL and a connection identifier; the service server searches the corresponding relation between the connection identifier and the user ID in the database server according to the connection identifier, and deletes the data record of the corresponding relation;
the step 2 specifically comprises the following steps: a user logs in for access for the first time, and when the application server is accessed through a client side by an HTTP (hyper text transport protocol), the application server calls a service server to obtain an initial URL (uniform resource locator) of a WebSocket server cluster; the application server acquires a client access request parameter, and adds a client access IP and an access identity identifier at the tail part of the initial URL of the WebSocket server cluster to generate a final WebSocket service cluster URL;
if the client in the step 2 accesses the IP in the IPv4 format, the IP is converted into a 32-bit integer and then converted into an 8-byte 16-system numeric letter format; if the IP is in IPv6 format, the IP is converted into 128-bit integer and then converted into 32-byte 16-system numeric letter format.
In step 3, the WebSocket server node records long connection information including a connection identifier and WebSocket session information in a session hash table, specifically: initiating a connection request to the WebSocket server cluster according to the WebSocket server cluster URL and a WebSocket protocol matched with the type of the client, if the client is a browser, initiating the connection request to the WebSocket server cluster according to a WSS protocol; if the client is the APP, initiating a connection request to the WebSocket server cluster according to a WSS protocol or a WS protocol; the WebSocket server cluster forwards the request to any WebSocket server node in the cluster, and establishes connection between the client and the WebSocket server node; if the connection fails, prompting that the network is abnormal, and restarting the connection request by the client; if the connection is successful, the WebSocket server node distributes a WebSocket session for the client and automatically generates a 64-bit session identifier; acquiring a WebSocket server node IP address, and splicing the WebSocket server node IP and a session identifier in a front-back manner to form a connection identifier; writing a WebSocket session and a connection identifier into a session hash table for storage, wherein the connection identifier is a Key Value, and the WebSocket session is a Value;
the forming of the connection identifier in step 3 specifically includes: converting the WebSocket server node IP into a 32-bit integer, and moving the 32-bit integer to the left to form a numerical value which is used as the first 64 bits of the connection identifier; the session connector is used as the last 64 bits of the connection identifier;
in the traversal process in the step 4, if the WebSocket server node receives a heartbeat detection packet sent by a certain client, finding a session identifier of a WebSocket session corresponding to the client in a heartbeat hash table, and deleting a heartbeat detection data record corresponding to the session identifier;
the step 6 specifically includes:
step 601: when the service server processes the service state change request, the service state change notice in the JSON format is established, and meanwhile, other user IDs of all service states needing to be synchronously changed are found;
step 602: taking the first 8 bits of the connection identifier, and converting the first 8 bits into a 32-bit integer to be a WebSocket server node IP; according to the IP, sending a service state change notification and a connection identifier to a WebSocket server node in a one-way calling mode;
step 603: after receiving a service state change notification sent by a service server, a WebSocket server node searches a corresponding WebSocket session WebSocket in a session hash table WebSocket according to a connection identifier, extracts a user ID in WebSocket session information, sends the service state change notification to a client where the user ID is located through WebSocket session, and informs that the state is synchronously changed; if the corresponding WebSocket session cannot be found, recording a log and notifying an exception;
in step 603, if a transmission error occurs when a service state change notification is sent to a client where the user ID is located through the WebSocket session, the WebSocket server node deletes the data record corresponding to the connection identifier from the session hash table; meanwhile, calling a service server to delete the corresponding relation between the user ID and the connection identifier stored in the database server;
in step 7, after the processing by the service server is completed, if the service states of other users need to be changed, synchronizing the service states of multiple users according to step 601 and 603;
the current time in the steps 1 to 8 is the number of seconds after 0 minute and 0 second from 1 month and 1 day 0 in 1970.
The invention has the following beneficial effects:
(1) according to the invention, the cooperation of HTTP and Websocket is realized by constructing a Websocket server cluster, and a service state change request initiated by any user through a client can not only obtain a request feedback result in real time based on HTTP, but also notify other users affected by service state change in real time by utilizing a Websocket connecting channel, and simultaneously, the use function requirements of different scenes are met;
(2) according to the invention, the reconstruction of the URL address of the Websocket server node is completed in a form of adding the client access parameter, and the URL address is returned to the client based on the HTTP protocol, so that the problems that the user authentication and the client IP tracking cannot be realized by the existing Websocket are solved;
(3) according to the invention, the heartbeat hash table is generated by initialization when the WebSocket server node is started, the configuration of the session hash table, the adaptation with heartbeat detection and the actual application parameter configuration of connection state detection are included, the WebSocket server sends heartbeat detection to replace the original client to send heartbeat detection, and no message or external storage is used, so that the client access cost is greatly simplified;
(4) according to the invention, by binding and storing the relation among the WebSocket server node IP, the WebSocket session and the user ID, the binding relation is directly called from the database server by the service server in the service processing process, so that the direct access to the specific node in the WebSocket server cluster is realized, the service server can directly access the specific node in the distributed WebSocket server cluster, the distributed WebSocket server is simplified, the deployment is simple, and the expansion is easy.
Drawings
FIG. 1 is a flowchart of a distributed state synchronization method based on cooperation of HTTP and WebSocket according to an embodiment of the present invention;
FIG. 2 is a schematic structural diagram of a distributed state synchronization system in which HTTP and WebSocket cooperate in an embodiment of the present invention;
FIG. 3 is a schematic diagram illustrating that a client opens a page for the first time to establish a long connection according to an embodiment of the present invention;
fig. 4 is a flowchart illustrating synchronization of a service status of a user a to a user B according to an embodiment of the present invention;
fig. 5 is a schematic view of a heartbeat detection process of the WebSocket server in the embodiment of the present invention.
Detailed Description
The invention will be further described with reference to the drawings and the exemplary embodiments:
fig. 1 is a flowchart of a distributed state synchronization method based on HTTP and WebSocket cooperation in an embodiment of the present invention, which specifically includes:
step S1: initializing a WebSocket server cluster, and initializing each WebSocket server node to generate a concurrent hash table and a heartbeat detection thread: deploying a WebSocket server cluster, configuring an initial URL of the server cluster, and initializing and generating a concurrent hash table and a heartbeat detection thread when each WebSocket server node in the cluster is started; the initial URL of the server cluster comprises a WSS protocol suitable for a browser end, a WSS protocol suitable for an APP end and a WS protocol; the concurrent hash table adopts a Key-Value storage structure and comprises a session hash table session and a heartbeat detection hash table pinged;
the session hash table session is used for recording connection information between the client and the WebSocket server node, and comprises a WebSocket session and a connection identifier channel Id; the WebSocket session refers to a connection channel established between a client and a WebSocket server node, and comprises a WebSocket server cluster URL, a user ID, a message sending method send, a session closing method close and a callback method, such as oneror (), onMessage (), onClose () and the like, wherein the user ID is a unique identification of an automatically generated system user identity; when the WebSocket session is generated, a session identifier sessionId is allocated; the connection identifier is used for identifying identities of two parties establishing WebSocket connection and consists of a WebSocket server node IP and a session identifier sessionId;
the heartbeat detection method comprises the steps that heartbeat detection information between a WebSocket server node and a client is recorded in the heartbeat hash table pinged, and the heartbeat detection is that the WebSocket server sends a connection confirmation notice to the client to detect whether the connection with the client is normal or not; the heartbeat hash table pinged comprises a session identifier and the last heartbeat detection time sent by the WebSocket server node; the heartbeat detection thread starts traversing the session hash table every 10 seconds; the heartbeat hash table is generated by initialization when the WebSocket server node is started, the WebSocket server sends heartbeat detection to replace the original client to send heartbeat detection, and the client access cost is greatly reduced
Step S2: reconstructing a WebSocket server cluster URL: when a user accesses an application server for the first time through a client by an HTTP (hyper text transport protocol), the application server calls a service server to obtain a WebSocket server cluster initial URL; the application server acquires a client access IP and an access identity identifier, and adds the client access IP and the access identity identifier at the tail part of the initial URL of the WebSocket server cluster to generate a final WebSocket service cluster URL; if the client access IP is in the IPv4 format, converting the IP into a 32-bit integer and then converting the IP into an 8-byte 16-system numeric letter format; if the client access IP is in the IPv6 format, converting the IP into a 128-bit integer and then converting the IP into a 32-byte 16-system numeric letter format;
if the client is a browser, the browser accesses a WEB application server to obtain a WebSocket server URL, the WEB application server serves to call a service server, the service server returns an address suitable for a browser WSS protocol, and the client access IP and an access identity are traced behind the address;
if the client is an APP, when the APP accesses the APP application server to obtain a WebSocket server URL, the APP application server serves to call a service server, the service server returns a WSS or WS protocol address suitable for the APP, and the client access IP and an access identity are traced behind the address;
step S3: establishing long connection between a client and a WebSocket server node, and storing the corresponding relation between connection information and a user ID into a database server, wherein the method specifically comprises the following steps:
step S301: the client initiates Websocket connection through a Websocket protocol and is connected to a remote Websocket server node to realize bidirectional communication. At present, mainstream browsers all support the WebSocket protocol, and if a client is an APP application, a third-party WebSocket library is used to support the WebSocket protocol. (ii) a
Step S302: according to the URL of the WebSocket server cluster, a client initiates a connection request to the WebSocket server cluster according to a WSS protocol, and the WebSocket server cluster forwards the request to any WebSocket server node in the cluster; if the request connection fails, prompting that the network is abnormal, and restarting the connection request by the client; if the WebSocket server node is successfully connected with the client, the WebSocket server node distributes a WebSocket session for the client and automatically generates a 64-bit session identifier sessionId; acquiring an IP address of a WebSocket server node, and splicing the WebSocket server node IP and a session identifier sessionId back and forth to form a connection identifier channelId; writing the WebSocket session and a connection identifier into a session hash table (namely an original session hash table) for storage, wherein the connection identifier is a Key Value, and the WebSocket session is a Value;
step S303: extracting a user ID from WebSocket session information, establishing a corresponding relation between the user ID and a connection identifier, and informing a service server of the corresponding relation to store the corresponding relation into a database server; by binding and storing the relationship among the WebSocket server node IP, the WebSocket session and the user ID, the service server directly calls the binding relationship from the database server in the service processing process, so that the direct access to the specific node in the WebSocket server cluster is realized, the deployment of the distributed WebSocket server is simplified, and the expansion is easy.
Step S4: in the long connection maintaining process, the WebSocket server node periodically sends a heartbeat detection packet to the client, the sending time is recorded in the heartbeat hash table pinged, and whether the long connection is normally maintained or not is detected by judging the interval between the current time and the sending time, specifically:
step S401: sending a Ping packet to the client by the WebSocket server node through the connection channel established in the step 2 every 10 seconds by using a Ping/Pong mechanism of the WebSocket, sequentially traversing Value values in session hash tables session, namely WebSocket sessions, and acquiring session identifiers sessionId automatically generated when each WebSocket session is established during traversal;
step S402: according to the session identifier sessionId, whether a corresponding data record exists or not is searched in the heartbeat hash table, if not, the session identifier sessionId is used as a Key Value, and the current time is used as a Value and stored in the heartbeat hash table; if yes, acquiring the last time of sending the Ping packet by the WebSocket server node corresponding to the sessionId, taking the difference between the current time and the last time of sending the Ping packet, judging whether the difference is greater than 20 seconds, if the difference is greater than 20 seconds, deleting the data record corresponding to the sessionId in the heartbeat hash table, closing the session connection channel, and deleting the data record corresponding to the session in the session hash table; if the difference is less than 20 seconds, continuously traversing the next Value in the session hash table until the session hash table is traversed;
step S403: in the traversal process, if a WebSocket server node receives a WebSocket Pong package sent by a certain client, removing a data record corresponding to the sessionId of a WebSocket session corresponding to the client from a heartbeat hash table pinged;
step S5: determining whether the service state change request is user active operation or user passive operation according to the service type, and further selecting to initiate the request by an HTTP protocol or a WebSocket protocol; if the service processing result needs to be notified to the user, the client sends the service state change request to the application server for processing based on the HTTP protocol for the user active operation, such as entering a waiting response of the home page, and performs step S6; if the service processing result does not need to inform the user, the client sends the service state change request to the WebSocket server node for processing for the passive operation of the user, such as the audio and video switch state in the conference room page, based on the WebSocket protocol, and executes the step S7;
step S6: the method comprises the following steps that an application server processes a service state change request and feeds the service state change request back to a client, determines other clients needing to synchronously inform of service state change, and informs other clients of the change of service states through WebSocket conversation between each client and a WebSocket server node, and specifically comprises the following steps:
step S601: when the service server processes the service state change request, the service state change notice in the JSON format is established, and meanwhile, other user IDs of all service states needing to be synchronously changed are found;
step S602: taking the first 8 bits of the connection identifier, and converting the first 8 bits into a 32-bit integer to be a WebSocket server node IP; according to the IP, sending the service state change notification and the connection identifier to a WebSocket server node in a one-way calling mode;
step S603: after receiving a service state change notification sent by a service server, a WebSocket server node searches a corresponding WebSocket session in a session hash table session according to a connection identifier, extracts a user ID in the WebSocket session, sends the service state change notification to a client where the user ID is located through the WebSocket session, and informs that the state is synchronously changed; if the corresponding WebSocket session cannot be found, recording a log and notifying an exception;
in step S603, if a transmission error occurs when the WebSocket session sends a service state change notification to the client where the user ID is located, the WebSocket server node deletes the data record corresponding to the connection identifier from the session hash table session; meanwhile, calling a service server to clear the corresponding relation between the user ID and the connection identifier in the database server;
step S7: acquiring a WebSocket server node which establishes a WebSocket session with a client, and sending a service change request to a service server for processing through the WebSocket server node; the method specifically comprises the following steps: acquiring a user ID of a login client, finding a WebSocket session containing the user ID, and sending a service state change request to a WebSocket server node through the WebSocket session; the WebSocket server node acquires a connection identifier channel Id corresponding to the WebSocket session in a session hash table, and transmits a service state change request by unidirectionally calling a deliverMessage () method of a service server by taking the connection identifier channel Id, a WebSocket server cluster URL, the current time and a service state change notice as parameters; after the processing of the service server is finished, if the service states of other users need to be changed, the synchronization is executed according to the steps S601-S603;
step S8: closing the long connection between the client and the WebSocket server node, clearing long connection information in a session hash table, and clearing the corresponding relation between the long connection stored in the database server and the user, wherein the method specifically comprises the following steps: when the WebSocket server node receives a long connection closing request sent by a client, deleting related WebSocket sessions and connection identifiers matched with the long connection in a concurrent hash table session; using a WebSocket server cluster URL and a connection identifier as parameters, and unidirectionally calling connectionClosed () of a service server to send a long connection closing request; the service server extracts user information from the WebSocket server cluster URL and deletes data records corresponding to the connection identifiers and the user information in the database server;
the current time in step S1-step S8 is taken as the number of seconds from 0 minute 0 second at 0 point on 1/1970.
Fig. 2 is a schematic structural diagram of a distributed state synchronization system with HTTP and WebSocket in cooperation in an embodiment of the present invention, which mainly includes a client, a WebSocket server cluster, an application server cluster, a service server cluster, and a database server; the client comprises a browser end and an APP end; the application server comprises a Web application server cluster accessed by a browser and an APP application server cluster accessed by an APP; the client establishes communication with the application server cluster through an HTTP protocol; the client establishes two-way communication with the WebSocket server cluster through a WebSocket protocol; the application server cluster communicates with the service server in a service calling mode; the WebSocket server cluster carries out bidirectional communication with the service server in a unidirectional service calling mode; and the service server cluster accesses the database server to obtain the pre-stored information.
As shown in fig. 3, which is a schematic diagram illustrating that a client opens a page for the first time to establish a long connection in an embodiment of the present invention, taking an example that a user a enters an audio/video shared page for the first time, when the user a acquires the audio/video shared page for the first time through a browser (such as a client in the figure), the client requests to access an application server to acquire an audio/video shared main page based on an Http protocol, the application server receives the request, acquires an initial URL of a WebSocket server cluster from a service server, and writes a client access request parameter into the initial URL of the WebSocket server cluster, where the request parameter includes an eip parameter, a pid parameter, a ts parameter, and the like, to form the URL of the WebSocket server cluster with client authentication, and returns the URL to the client a; the eip parameter is an IP (Internet protocol) when the client accesses the application server, and the pid parameter is a unique identity when the client accesses the application server; the ts parameter is the number of seconds the application server currently has since 1970, 1, 0 minutes and 0 seconds. By adding client parameters to the initial URL of the WebSocket server cluster, the problem that information tracking such as user IP and user identity cannot be realized by common WebSocket is solved;
the client side sends a request for establishing long connection according to the WebSocket server cluster URL with the client authentication and connects a remote WebSocket server; after the connection is successful, the WebSocket server automatically sends Ping packets to the client every 10s, and the client replies Pong packets;
after the connection is successful, a user A requests to turn on the audio and video switch through a browser (such as a client in the figure), because the request for turning on the audio and video switch does not need to inform the user A of a processing result, the request belongs to the passive operation of the user, and based on a WebSocket protocol, the client sends the request for turning on the audio and video switch to a WebSocket server for processing in a message form; the WebSocket server obtains a connection identifier channel Id-A of a user A client and the WebSocket server in a session hash table session, the connection identifier channel Id-A, a WebSocket server cluster URL containing client parameters such as eip and pid, the current time and the opening of a video-audio switch are used as request contents, a deliverMessage () method of a service server is called in a one-way mode and sent to the service server to be processed, the service server processes the audio-video switch state of the user A, and the audio-video switch off state of the user A is changed into the on state to complete message processing;
when a user A and a user B both enter the same video sharing page, taking a service request that the user A starts an audio switch as an example, the service state change request is to change the audio switch in a closed state into an open state; fig. 4 is a flowchart illustrating synchronization of service state change of the user a to the user B according to an embodiment of the present invention. A user A operates and starts an audio switch in a browser (namely a client A in the figure), the client A sends a request for starting the audio switch to a Web application server, the Web application server calls a service server to process the request according to a preset service logic, the service processor acquires an ID of a user B which is in a video sharing page with the user A, and further acquires a connection identifier channel Id-B corresponding to the ID of the user B from a database server; the service server analyzes the channelId-B to obtain a WebSocket server node IP, informs a user A of opening an audio switch to the WebSocket server node in a WebSocket text message mode, and informs the user B of a connection channel between the WebSocket server node and a browser (and a client B in the figure) where the user B is located; by realizing the cooperation of the HTTP and the Websocket, any user can obtain a request feedback result in real time through a service state change request initiated by a client based on the HTTP and can also notify other users affected by the service state change in real time by utilizing a Websocket connecting channel;
as shown in fig. 5, which is a schematic view of a heartbeat detection process of a WebSocket server in an embodiment of the present invention, taking an example that a user a enters an audio/video shared page through a browser (see a client a in the figure), in a long connection maintaining process, a WebSocket server node periodically sends a heartbeat detection Ping packet to a client, records sending time in a heartbeat hash table pined, and detects whether a long connection is normally maintained by determining an interval between current time and sending time, where the specific steps are as follows: the WebSocket server node sends Ping packets to the client through the established connection channel every 10 s; after receiving the ping packet, if a pong packet is immediately returned to the Websocket server node, the Websocket server node deletes the heartbeat record between the user A and the Websocket server node in the heartbeat hash table;
while the WebSocket server node sends the Ping package to the client, sequentially traversing Value values in session hash table sessions, namely WebSocket sessions, and acquiring a session identifier sessionId automatically generated when each WebSocket session is established during traversal; according to the session identifier sessionId, whether a corresponding session record exists or not is searched in the heartbeat hash table, if not, the session identifier sessionId is used as a Key Value, and the current time is used as a Value and stored in the heartbeat hash table; if yes, acquiring the last time of sending the Ping packet by the WebSocket server node corresponding to the sessionId, taking the difference between the current time and the last time of sending the Ping packet, judging whether the difference is greater than 20 seconds, if the difference is greater than 20 seconds, deleting the data record corresponding to the sessionId in the heartbeat hash table, closing the session connection channel, and deleting the data record corresponding to the session in the session hash table; the service server initiates a long connection closing request; and if the difference is less than 20 seconds, continuously traversing the next Value in the session hash table until the session hash table is traversed.
The invention has the following beneficial effects:
(1) according to the invention, the cooperation of HTTP and Websocket is realized by constructing a Websocket server cluster, and a service state change request initiated by any user through a client can not only obtain a request feedback result in real time based on HTTP, but also notify other users affected by service state change in real time by utilizing a Websocket connecting channel, and simultaneously, the use function requirements of different scenes are met;
(2) according to the invention, the reconstruction of the URL address of the Websocket server node is completed in a form of adding the client access parameter, and the URL address is returned to the client based on the HTTP protocol, so that the problems that the user authentication and the client IP tracking cannot be realized by the existing Websocket are solved;
(3) according to the invention, the heartbeat hash table is generated by initialization when the WebSocket server node is started, the configuration of the session hash table, the adaptation with heartbeat detection and the actual application parameter configuration of connection state detection are included, the WebSocket server sends heartbeat detection to replace the original client to send heartbeat detection, and no message or external storage is used, so that the client access cost is greatly simplified;
(4) according to the invention, by binding and storing the relation among the WebSocket server node IP, the WebSocket session and the user ID, the binding relation is directly called from the database server by the service server in the service processing process, so that the direct access to the specific node in the WebSocket server cluster is realized, the service server can directly access the specific node in the distributed WebSocket server cluster, the distributed WebSocket server is simplified, the deployment is simple, and the expansion is easy.
The above embodiments do not limit the present invention in any way, and all other modifications and applications that can be made to the above embodiments in equivalent ways are within the scope of the present invention.
Claims (7)
1. A distributed state synchronization method based on cooperation of HTTP and WebSocket is characterized by comprising the following specific steps:
step 1: initializing a WebSocket server cluster, specifically: deploying a WebSocket server cluster, configuring an initial URL of the WebSocket server cluster, and initializing and generating a concurrent hash table and a heartbeat detection thread when each WebSocket server node in the WebSocket server cluster is started; the WebSocket server cluster initial URL comprises a WSS protocol applicable to a browser end, a WSS protocol applicable to an APP end and a WS protocol applicable to the APP end; the concurrent hash table adopts a Key-Value storage structure and comprises a session hash table and a heartbeat detection hash table; the session hash table is used for recording connection information between a client and a WebSocket server node, and the connection information comprises WebSocket session information and a connection identifier; the WebSocket session refers to a connection channel established between a client and a certain WebSocket server node, and the WebSocket session information comprises a reconstructed WebSocket server cluster URL, a user ID, a message sending and call-back method and an error call-back method; the user ID is an automatically generated unique user identity identifier; a session identifier is allocated when the WebSocket session is generated; the connection identifier consists of a WebSocket server node IP and a session identifier; the heartbeat detection hash table is used for recording heartbeat detection information between the WebSocket server node and the client; the heartbeat detection hash table comprises a session identifier and the last time when the WebSocket server node sends a heartbeat detection packet; the heartbeat detection thread starts traversing the session hash table every 10 seconds;
step 2: reconstructing a WebSocket server cluster URL: when a client accesses an application server for the first time, the application server calls a service server to obtain a WebSocket server cluster initial URL; obtaining a client access request parameter, writing the client access request parameter into a WebSocket server cluster initial URL, and forming a reconstructed WebSocket server cluster URL with client authentication; the client access request parameter comprises a client access IP and an access identity; the format of the client access IP is IPv4 or IPv 6; the application server is used for processing HTTP requests;
and step 3: after a long connection between a client and a WebSocket server node is established, distributing a WebSocket session for each client; in a session hash table of a WebSocket server node, recording the long connection established this time by taking a connection identifier as a Key Value and WebSocket session information as a Value; extracting a user ID from WebSocket session information, establishing a corresponding relation between the user ID and a connection identifier, and storing the corresponding relation into a database server through a service server, wherein the service server is used for actual service logic processing;
and 4, step 4: detecting whether the long connection is normal during the long connection maintaining process: every 10 seconds, the WebSocket server node sends a heartbeat detection packet to the client through the established WebSocket session, simultaneously sequentially traverses the Value in the session hash table, namely the WebSocket session information, and acquires a session identifier automatically generated when each WebSocket session is established during traversal; according to the session identifier, whether a matched data record exists is searched in the heartbeat detection hash table, if not, the session identifier is used as a Key Value, and the current time is used as a Value and is stored in the heartbeat detection hash table; if yes, acquiring the last time of sending a heartbeat detection packet by the WebSocket server node corresponding to the session identifier, taking the difference between the current time and the last time of sending the heartbeat detection packet, judging whether the difference is more than 20 seconds, if the difference is more than 20 seconds, deleting the data record corresponding to the session identifier in a heartbeat detection hash table, closing the WebSocket session, and deleting the data record corresponding to the WebSocket session in a session hash table; if the difference is less than 20 seconds, continuously traversing the next Value in the session hash table until the session hash table is traversed;
and 5: determining whether the service state change request is user active operation or user passive operation according to the type of the service processing result; the service state comprises the state of service logic, and the type of the service processing result comprises that the service processing result needs to be informed to a user and the service processing result does not need to be informed to the user; if the service processing result needs to be informed to the user, the service state change request is regarded as the active operation of the user, based on the HTTP, the client sends the service state change request to the application server for processing, and step 6 is executed; if the service processing result does not need to inform the user, the service state change request is regarded as passive operation of the user, based on the WebSocket protocol, the client sends the service state change request to the WebSocket server node for processing, and step 7 is executed;
step 6: when the application server receives the service state change request, calling the service server to process the service state change request, feeding back a service processing result to the client, and executing the step 8; when the service server processes the service state change request, finding out other user IDs (identity) needing to synchronously change the service state; searching a connection identifier corresponding to the user ID in the database server according to the user ID, acquiring a WebSocket server node IP by analyzing the connection identifier, determining a WebSocket session by the WebSocket server node according to the connection identifier, sending a service state change notice to the client through the WebSocket session, and informing the user that the service state is changed; the method specifically comprises the following steps: step 601: when the service server processes the service state change request, the service state change notice in the JSON format is established, and meanwhile, other user IDs of all service states needing to be synchronously changed are found;
step 602: taking the front 8 bits of a connection identifier corresponding to a user ID, and converting into a 32-bit integer to be a WebSocket server node IP; according to the IP, a service state change notice and a connection identifier are sent to a WebSocket server node in a one-way calling mode;
step 603: after receiving a service state change notification sent by a service server, a WebSocket server node searches corresponding WebSocket session information in a session hash table WebSocket according to a connection identifier, extracts a user ID in the WebSocket session information, sends the service state change notification to a client where the user ID is located through WebSocket session, and informs that the service state is synchronously changed; if the corresponding WebSocket session information cannot be found, recording a log and notifying an exception;
if a transmission error occurs when a service state change notification is sent to a client where a user ID is located through a WebSocket session, a WebSocket server node deletes a data record corresponding to a connection identifier from a session hash table; simultaneously calling a service server to delete the corresponding relation between the user ID and the connection identifier stored in the database server;
and 7: acquiring a user ID of a login client, finding WebSocket session information containing the user ID, and sending a service state change request to a WebSocket server node through the WebSocket session; the WebSocket server node acquires a connection identifier corresponding to the WebSocket session in a session hash table, and sends the connection identifier together with a reconstructed WebSocket server cluster URL, current time and a service state change request to a service server for processing;
and 8: closing long connection between the client and the WebSocket server node, specifically: after receiving a long connection closing request sent by a client, a WebSocket server node deletes WebSocket session information and a connection identifier matched with the long connection in a concurrent hash table; the WebSocket server node initiates a long connection closing request to a service server in a one-way calling mode, and request parameters comprise a reconstructed WebSocket server cluster URL and a connection identifier; and the service server searches the corresponding relation between the connection identifier and the user ID in the database server according to the connection identifier, and deletes the data record of the corresponding relation.
2. The distributed state synchronization method based on cooperation of the HTTP and the WebSocket, as claimed in claim 1, wherein: the step 2 specifically comprises the following steps: a user logs in for access for the first time, and when the application server is accessed through a client side by an HTTP (hyper text transport protocol), the application server calls a service server to obtain an initial URL (uniform resource locator) of a WebSocket server cluster; the application server acquires a client access request parameter, and adds a client access IP and an access identity identifier at the tail part of the initial URL of the WebSocket server cluster to generate a reconstructed WebSocket service cluster URL; if the client in the step 2 accesses the IP in the IPv4 format, the IP is converted into a 32-bit integer and then converted into an 8-byte 16-system numeric letter format; if the IP is in IPv6 format, the IP is converted into 128-bit integer and then converted into 32-byte 16-system numeric letter format.
3. The distributed state synchronization method based on cooperation of the HTTP and the WebSocket, as claimed in claim 2, wherein: in step 3, the WebSocket server node records long connection information including a connection identifier and WebSocket session information in a session hash table, specifically: initiating a connection request to the WebSocket server cluster according to the reconstructed WebSocket server cluster URL and a WebSocket protocol matched with the type of the client, if the client is a browser, initiating the connection request to the WebSocket server cluster according to a WSS protocol; if the client is the APP, initiating a connection request to the WebSocket server cluster according to a WSS protocol or a WS protocol; the WebSocket server cluster forwards the request to any WebSocket server node in the cluster, and establishes connection between the client and the WebSocket server node; if the connection fails, prompting that the network is abnormal, and restarting the connection request by the client; if the connection is successful, the WebSocket server node distributes a WebSocket session for the client and automatically generates a 64-bit session identifier; acquiring a WebSocket server node IP address, splicing the WebSocket server node IP and a session identifier front and back to form a connection identifier; and writing the WebSocket session information and a connection identifier into a session hash table for storage, wherein the connection identifier is a Key Value, and the WebSocket session information is a Value.
4. The distributed state synchronization method for cooperation of HTTP and WebSocket as recited in claim 3, wherein: the connection identifier formation specifically includes: converting the WebSocket server node IP into a 32-bit integer, and moving the 32-bit integer to the left to form a numerical value which is used as the first 64 bits of the connection identifier; the session identifier is the last 64 bits of the connection identifier.
5. The distributed state synchronization method for cooperation of the HTTP and the WebSocket according to claim 4, wherein: in the traversal process of step 4, if the WebSocket server node receives a heartbeat detection packet sent by a certain client, a session identifier of a WebSocket session corresponding to the client is found in a heartbeat detection hash table, and heartbeat detection information corresponding to the session identifier is deleted.
6. The distributed state synchronization method based on cooperation of the HTTP and the WebSocket, as claimed in claim 1, wherein: in the step 7, after the processing by the service server is completed, if the service states of other users need to be changed, the service state synchronization of multiple users is realized according to the step 601 and 603.
7. The distributed state synchronization method based on cooperation of the HTTP and the WebSocket, as claimed in claim 1, wherein: the current time is the number of seconds from 0 minute 0 second on 1/1970.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011012551.1A CN112118266B (en) | 2020-09-24 | 2020-09-24 | Distributed state synchronization method based on cooperation of HTTP and WebSocket |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011012551.1A CN112118266B (en) | 2020-09-24 | 2020-09-24 | Distributed state synchronization method based on cooperation of HTTP and WebSocket |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112118266A CN112118266A (en) | 2020-12-22 |
| CN112118266B true CN112118266B (en) | 2022-05-31 |
Family
ID=73800544
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011012551.1A Active CN112118266B (en) | 2020-09-24 | 2020-09-24 | Distributed state synchronization method based on cooperation of HTTP and WebSocket |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112118266B (en) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112788144A (en) * | 2021-01-19 | 2021-05-11 | 深圳市位元领航科技有限公司 | Method for realizing communication mode, server and client |
| CN113472748B (en) * | 2021-05-31 | 2023-03-24 | 四川万益能源科技有限公司 | Audit log system communication method based on non-blocking input and output |
| CN113342492A (en) * | 2021-06-08 | 2021-09-03 | 杭州遥望网络科技有限公司 | Task instruction issuing method, device, system, electronic equipment and medium |
| CN113923249A (en) * | 2021-10-12 | 2022-01-11 | 工银科技有限公司 | High-performance network long connection establishing method and device |
| CN115334066B (en) * | 2022-10-13 | 2023-02-24 | 飞天诚信科技股份有限公司 | Distributed cluster system and method for processing synchronous request response |
| CN116233233A (en) * | 2023-03-13 | 2023-06-06 | 霞智科技有限公司 | Development method and system for background pushing based on ws protocol |
| CN116881984B (en) * | 2023-09-08 | 2024-02-23 | 云筑信息科技(成都)有限公司 | Data monitoring method |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108111634A (en) * | 2018-02-28 | 2018-06-01 | 北京焦点新干线信息技术有限公司 | A kind of instant data transmission method and system based on websocket protocol Yu http agreements |
| CN109936601A (en) * | 2017-12-18 | 2019-06-25 | 厦门本能管家科技有限公司 | A kind of block chain duplex communication network based on WebSocket connection |
| CN111211934A (en) * | 2019-12-25 | 2020-05-29 | 曙光信息产业(北京)有限公司 | Cluster remote communication test method and system |
| EP3678348A1 (en) * | 2019-01-04 | 2020-07-08 | Ping Identity Corporation | Methods and systems for data traffic based adpative security |
-
2020
- 2020-09-24 CN CN202011012551.1A patent/CN112118266B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109936601A (en) * | 2017-12-18 | 2019-06-25 | 厦门本能管家科技有限公司 | A kind of block chain duplex communication network based on WebSocket connection |
| CN108111634A (en) * | 2018-02-28 | 2018-06-01 | 北京焦点新干线信息技术有限公司 | A kind of instant data transmission method and system based on websocket protocol Yu http agreements |
| EP3678348A1 (en) * | 2019-01-04 | 2020-07-08 | Ping Identity Corporation | Methods and systems for data traffic based adpative security |
| CN111211934A (en) * | 2019-12-25 | 2020-05-29 | 曙光信息产业(北京)有限公司 | Cluster remote communication test method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112118266A (en) | 2020-12-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112118266B (en) | Distributed state synchronization method based on cooperation of HTTP and WebSocket | |
| US11172023B2 (en) | Data synchronization method and system | |
| CN109889762B (en) | Conference control method and device | |
| US11316909B2 (en) | Data transmission method and apparatus, and computer storage medium | |
| US9432408B2 (en) | Signalling gateway, method, computer program and computer program product for communication between HTTP and SIP | |
| CN112738140B (en) | Video stream transmission method, device, storage medium and equipment based on WebRTC | |
| WO2018166415A1 (en) | Cloud storage system, media data storage method and system | |
| US10182086B2 (en) | Method and apparatus for transmitting streaming media data | |
| WO2010072081A1 (en) | Method and system for realizing massive terminals access of a streaming media server | |
| CN109634988B (en) | Monitoring polling method and device | |
| US20220209878A1 (en) | Method, system and device for pushing information, and storage medium thereof | |
| US20210051301A1 (en) | Multi-device recording synchronization method and system, and conference system | |
| US9948500B2 (en) | Method and apparatus of performing simultaneous multi-agent access for command execution through a single client | |
| CN110557612B (en) | Control method of monitoring equipment and video networking system | |
| CN110113558B (en) | Data processing method, device, system and computer readable storage medium | |
| CN109347856A (en) | A kind of login method and system regarding networked terminals | |
| CN108810475A (en) | A kind of Android video monitoring apparatus based on Onvif standards and Sip agreements | |
| CN114900707B (en) | Live broadcast method and system | |
| US8036141B2 (en) | Apparatus and method for managing a network | |
| CN112054953B (en) | Multimedia instant messaging method, system, terminal equipment and computer storage medium | |
| CN110120937B (en) | Resource acquisition method, system, device and computer readable storage medium | |
| TW201835783A (en) | Data synchronization system and method, and server, client and electronic device | |
| CN110557611B (en) | Information synchronization method, device and storage medium | |
| JP6807952B2 (en) | Methods and devices for determining the communication network that provides communication services to terminal communication devices | |
| WO2018036327A1 (en) | Data synchronization method and apparatus |
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 |