Distributed service cluster data pushing method and system

Abstract

The invention discloses a method for pushing data by a distributed service cluster. The method comprises the following steps: acquiring an SSE connection request initiated by a client; selecting a service node from the distributed service cluster based on load balancing logic; forwarding the SSE connection request to the selected service node, and establishing SSE connection; and sending data through the established SSE connection. Through distributed deployment of the SSE in the service cluster, the SSE link is reasonably distributed in the cluster by using load balancing, and the problem that the distributed cluster pushes the data stream to the client side is solved more conveniently and efficiently.

Description

Technical Field

[0001] The present invention relates to the technical field of server message push technology, and in particular to a method and system for distributed server cluster data push. Background Art

[0002] One of the most important technologies in network software technology is server message push. In order to achieve more timely updates of client data, the server needs to push data to the client in a timely manner, such as real-time notifications, real-time data dashboards, and other scenarios.

[0003] The existing front-end and back-end data communications include long and short polling based on http. However, long and short polling based on http has poor security and occupies system resources and the number of system requests. WebSocket is a new protocol based on TCP. With the continuous improvement of the HTML5 draft, more and more modern browsers have begun to fully support WebSocket technology. It applies TCP's socket to webpage, so that the communicating parties can establish a connection channel that remains active. However, during data transmission, websocket transmission data needs to be parsed twice, which makes access difficult, development cost high, and load balancing issues more complicated to handle. Summary of the invention

[0004] In view of the above-mentioned deficiencies in current server message push, the present invention provides a method and system for pushing data by a distributed service cluster, which can achieve the effect of pushing a data stream by a distributed service cluster to a client.

[0005] To achieve the above object, the embodiments of the present invention adopt the following technical solutions:

[0006] A method for a distributed service cluster to push data, the method comprising the following modules:

[0007] Get the SSE connection request initiated by the client;

[0008] Select service nodes from the distributed service cluster based on load balancing logic;

[0009] Forward the SSE connection request to the selected service node and establish the SSE connection;

[0010] Data is sent via the established SSE connection.

[0011] According to one aspect of the present invention, the obtaining of the SSE connection request initiated by the client includes: the client initiating the SSE connection request, wherein the SSE connection request includes unique identification data.

[0012] According to one aspect of the present invention, the identification data is used to associate the client with the SSE connection, specifically including: combining the local cache and redis cache of the selected service node so that the SSE connection is bound to the identification data.

[0013] According to one aspect of the present invention, the selection of a service node from a distributed service cluster based on load balancing logic includes: registering a temporary service node; determining the number of service node connections; and selecting a temporary service node with the smallest number of current connections as the final selected service node.

[0014] According to one aspect of the present invention, the registering of the temporary service node includes: when the service node is started, registering the IP and port of the current node to the temporary node of zookeeper.

[0015] According to one aspect of the present invention, the selection of service nodes from a distributed service cluster based on load balancing logic includes: setting the maximum number of connections for each service node; determining whether the number of SSE connections established by the current service node has reached the maximum number of connections, and if so, the service node cannot be selected as the final selected service node.

[0016] According to one aspect of the present invention, the registering of the temporary service node includes: when the service node is started, registering the IP and port of the current node to the temporary node of zookeeper.

[0017] According to one aspect of the present invention, the selection of service nodes from a distributed service cluster based on load balancing logic includes: setting the maximum number of connections for each service node; determining whether the number of SSE connections established by the current service node has reached the maximum number of connections, and if so, the service node cannot be selected as the final selected service node.

[0018] According to one aspect of the present invention, the forwarding of the SSE connection request to the selected service node and establishing the SSE connection includes: obtaining the IP and port of the selected service node. The SSE connection request is forwarded to the corresponding IP and port with a selected identifier; if the service node determines that it is a selected node, it directly creates a connection.

[0019] According to one aspect of the present invention, sending data through an established SSE connection includes: the SSE connection request includes unique identification data; obtaining the SSE connection currently connected to the service node in the SSE connection in the redis cache according to the identification data; sending the data to be sent to the data sending interface of the corresponding service node; obtaining the SSE connection in the local cache of the current service node through the identification data; building a spring framework, and calling to complete the data sending.

[0020] According to one aspect of the present invention, the method also includes: closing the SSE connection; the closing of the SSE connection includes active closing of the connection and passive closing of the connection, the active closing of the connection is triggered by the client or the server itself; the passive closing of the connection is forced to close due to connection failure caused by the service node going offline or the network being interrupted.

[0021] A system for pushing data in a distributed service cluster, the system further comprising:

[0022] The request acquisition module is used to obtain the SSE connection request initiated by the client;

[0023] The node selection module is used to select service nodes from the distributed service cluster based on the load balancing logic;

[0024] The connection establishment module is used to forward the SSE connection request to the selected service node and establish the SSE connection;

[0025] The data sending module is used to send data through the established SSE connection.

[0026] The advantages of the implementation of the present invention are as follows: through reasonable load balancing distribution, SSE connection is established, and the distributed service cluster pushes the data stream to the client, solving the distributed deployment of SSE in the service cluster; increasing load balancing so that the SSE links are reasonably distributed in the cluster. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below.

[0028] Figure 1 This is a flow chart of a method for pushing data to a service cluster according to Embodiment 1 of the present invention;

[0029] Figure 2 This is a flow chart of a method for pushing data to a service cluster according to Embodiment 2 of the present invention;

[0030] Figure 3 A schematic diagram of establishing an Sse connection according to Embodiment 1 of the present invention;

[0031] Figure 4 This is a schematic diagram of sending data to a client according to Embodiment 1 of the present invention;

[0032] Figure 5 A temporary node structure registered for the service node described in the present invention. DETAILED DESCRIPTION

[0033] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0034] The terms involved in the present invention are explained as follows:

[0035] SSE: Server-Sent Events is a server push technology based on the persistent connection in the HTTP protocol. It enables the client to automatically receive updated data from the server through the persistent HTTP connection. Each notification is sent in the form of a text stream (utf-8) and ends with a pair of newline characters.

[0036] Distributed: A system consisting of a group of computer nodes that communicate through a network and coordinate their work to complete a common task.

[0037] Load balancing: A method of evenly distributing network traffic across a pool of resources that supports an application.

[0038] Service cluster: a server cluster consisting of multiple servers.

[0039] Client: A general term for PC, mobile app, and mobile browser H5.

[0040] Redis: A Key-value storage system.

[0041] ZooKeeper: A distributed, open source coordination service for distributed applications.

[0042] ZooKeeper temporary node: The life cycle of a temporary node is bound to the client session. If the client session fails (for example, when the service goes offline), the node will be automatically cleared.

[0043] Embodiment 1

[0044] like Figure 1 As shown, a method for a distributed service cluster to push data, the specific steps are as follows:

[0045] Step S01: Obtain an SSE connection request initiated by a client;

[0046] The step S01 obtains the SSE connection request initiated by the client, including: the client initiates the SSE connection request, and the request is forwarded to the backend service cluster through the nginx cluster. There are n service nodes in the cluster, SSE server 01 to SSEserver N.

[0047] The SSE connection request contains unique identification data; the identification data is used to associate the client with the SSE connection, specifically including: combining the local cache and redis cache of the selected service node to bind the SSE connection to the identification data. Based on the unique identification data in the request, such as the user's userId, create an sseId; identify the object of the current SSE connection, and associate the user with the SSE connection.

[0048] Step S02: Selecting a service node from a distributed service cluster based on load balancing logic;

[0049] The step S02 selects a service node from the distributed service cluster based on the load balancing logic, including: registering a temporary service node; determining the number of service node connections;

[0050] Register a temporary service node. When the service node is started, the IP and port of the current node are registered to the temporary node ( / sse_c_host) of Zookeeper and kept for 10 seconds to prevent the Zookeeper connection from being interrupted due to network jitter. At this time, the Zookeeper node is used to maintain the currently available service node and is used as a temporary node. The node structure is as follows: Figure 5 As shown; set a maximum number of connections for each service node to prevent the number of SSE connections from being too large (for example, 300). This value can be compared with the cached value of sse_connect_num to determine whether it is selected to create an SSE connection. The temporary service node with the smallest number of current connections is selected as the final selected service node, that is, the node IP and port with the smallest current connection data can be obtained in combination with the map cache sse_connect_num in redis, and the optimal service node is finally selected. sse_connect_num: service node IP+port: cnum (number of connections) is used to perform load balancing in a cluster environment based on the number of SSE connections of the service node. For example: sse_connet_num:172.19.29.111:8080:100.

[0051] Step S03: forwarding the SSE connection request to the selected service node and establishing an SSE connection;

[0052] like Figure 3 As shown, the step S03 forwards the SSE connection request to the selected service node and establishes the SSE connection, including: obtaining the IP and port of the selected service node. The SSE connection request is forwarded to the corresponding IP and port with a selected mark; if the service node determines that it is a selected node, it directly creates a connection.

[0053] Get the ip and port of the node from the optimal service node selected in the previous step, use the RestTemplate provided by springboot to complete the http request forwarding, and forward the http request to the corresponding ip and port.

[0054] An example of a service node SSE connection. For example, to create an SSE connection in a service node, use the SseEmitter class in the spring framework. Instantiate this type of SseEmitter sseEmitter = newSseEmitter() to get the sse connection. The current SSE connection needs to be bound to the sseId. The binding method is: combining the service node local cache and redis cache; that is, creating an sseCache in the current service node, such as static finalMap<String,SseEmitter> sseCache = new ConcurrentHashMap<>(); then put the SSE connection instance into the map, sseCache.put(sseId, sseEmitter), at this time, the sseId created by the user and the corresponding service node are effectively associated.

[0055] Step S04: Send data via the established SSE connection.

[0056] like Figure 4 As shown, the step S04 of sending data through the established SSE connection includes: the SSE connection request contains unique identification data; according to the identification data, the SSE connection currently connected to the service node is obtained in the SSE connection of the redis cache; the data to be sent is sent to the data sending interface of the corresponding service node; the SSE connection is obtained in the local cache of the current service node through the identification data; the spring framework is constructed, and the call is made to complete the data sending.

[0057] According to sseId, get the ip and port of the service node holding the current connection in the redis cache sse_connect, sse_connect:sseId, service node ip+port, which is used to find the SSE connection corresponding to the user in the cluster environment later. For example, sse_connect:10001:172.19.29.111:8080.

[0058] Inside the interface, get the SSE connection in the local cache sseCache of the current service node through sseId. Get the SSE connection in the local cache sseCache of the current service node through sseId. Build the SseEmitter.SseEventBuilder object, put the data to be sent into the data field, and specify that the MediaType is APPLICATION_JSON; the id field can contain the data sequence number you define. If the connection is disconnected, SSE will automatically put this id into the Last-Event-ID value of the http header. The server can determine whether to transmit subsequent data based on this id value; the name field can customize the event type to distinguish different data types for different client services. The code example is as follows:

[0059]

[0060] The data structure finally sent is as follows. The data is in json format. The data field and type can be customized according to the business. Different businesses can handle different types. You can even define the content format according to business needs to meet different scenarios. At this point, the data loading task has been completed. Calling the sseEmitter.send(sseEventBuilder) method completes the data sending.

[0061]

[0062] Embodiment 2

[0063] like Figure 2 As shown, a method for a distributed service cluster to push data, the specific steps are as follows:

[0064] Step S01: Obtain an SSE connection request initiated by a client;

[0065] The step S01 obtains the SSE connection request initiated by the client, including: the client initiates the SSE connection request, and the request is forwarded to the backend service cluster through the nginx cluster. There are n service nodes in the cluster, SSE server 01 to SSEserver N.

[0066] The SSE connection request contains unique identification data; the identification data is used to associate the client with the SSE connection, specifically including: combining the local cache and redis cache of the selected service node to bind the SSE connection to the identification data. Based on the unique identification data in the request, such as the user's userId, create an sseId; identify the object of the current SSE connection, and associate the user with the SSE connection.

[0067] Step S02: Selecting a service node from a distributed service cluster based on load balancing logic;

[0068] The step S02 selects a service node from the distributed service cluster based on the load balancing logic, including: registering a temporary service node; determining the number of service node connections;

[0069] Register a temporary service node. When the service node is started, the IP and port of the current node are registered to the temporary node ( / sse_c_host) of Zookeeper and kept for 10 seconds to prevent the Zookeeper connection from being interrupted due to network jitter. At this time, the Zookeeper node is used to maintain the currently available service node and is used as a temporary node. The node structure is as follows: Figure 5 As shown; set a maximum number of connections for each service node to prevent the number of SSE connections from being too large (for example, 300). This value can be compared with the cached value of sse_connect_num to determine whether it is selected to create an SSE connection. The temporary service node with the smallest number of current connections is selected as the final selected service node, that is, the node IP and port with the smallest current connection data can be obtained in combination with the map cache sse_connect_num in redis, and the optimal service node is finally selected. sse_connect_num: service node IP+port: cnum (number of connections) is used to perform load balancing in a cluster environment based on the number of SSE connections of the service node. For example: sse_connet_num:172.19.29.111:8080:100.

[0070] Step S03: forwarding the SSE connection request to the selected service node and establishing an SSE connection;

[0071] like Figure 3 As shown, the step S03 forwards the SSE connection request to the selected service node and establishes the SSE connection, including: obtaining the IP and port of the selected service node. The SSE connection request is forwarded to the corresponding IP and port with a selected mark; if the service node determines that it is a selected node, it directly creates a connection.

[0072] Get the ip and port of the node from the optimal service node selected in the previous step, use the RestTemplate provided by springboot to complete the http request forwarding, and forward the http request to the corresponding ip and port.

[0073] An example of a service node SSE connection. For example, to create an SSE connection in a service node, use the SseEmitter class in the spring framework. Instantiate this type of SseEmitter sseEmitter = newSseEmitter() to get the sse connection. The current SSE connection needs to be bound to the sseId. The binding method is: combining the service node local cache and redis cache; that is, creating an sseCache in the current service node, such as static finalMap<String,SseEmitter> sseCache = new ConcurrentHashMap<>(); then put the SSE connection instance into the map, sseCache.put(sseId, sseEmitter), at this time, the sseId created by the user and the corresponding service node are effectively associated.

[0074] Step S04: Send data via the established SSE connection.

[0075] like Figure 4 As shown, the step S04 of sending data through the established SSE connection includes: the SSE connection request contains unique identification data; according to the identification data, the SSE connection currently connected to the service node is obtained in the SSE connection of the redis cache; the data to be sent is sent to the data sending interface of the corresponding service node; the SSE connection is obtained in the local cache of the current service node through the identification data; the spring framework is constructed, and the call is made to complete the data sending.

[0076] According to sseId, get the ip and port of the service node holding the current connection in the redis cache sse_connect, sse_connect:sseId, service node ip+port, which is used to find the SSE connection corresponding to the user in the cluster environment later. For example, sse_connect:10001:172.19.29.111:8080.

[0077] Inside the interface, get the SSE connection in the local cache sseCache of the current service node through sseId. Get the SSE connection in the local cache sseCache of the current service node through sseId. Build the SseEmitter.SseEventBuilder object, put the data to be sent into the data field, and specify that the MediaType is APPLICATION_JSON; the id field can contain the data sequence number you define. If the connection is disconnected, SSE will automatically put this id into the Last-Event-ID value of the http header. The server can determine whether to transmit subsequent data based on this id value; the name field can customize the event type to distinguish different data types for different client services. The code example is as follows:

[0078]

[0079] The data structure finally sent is as follows. The data is in json format. The data field and type can be customized according to the business. Different businesses can handle different types. You can even define the content format according to business needs to meet different scenarios. At this point, the data loading task has been completed. Calling the sseEmitter.send(sseEventBuilder) method completes the data sending.

[0080]

[0081] The steps to complete the closing connection can be set as:

[0082] Step S05: Closing of SSE connection. The closing of SSE connection in step S05 includes active closing of connection and passive closing of connection. The active closing of connection is triggered by the client or server itself. When the data transmission is completed, the IP port of the corresponding service node can be obtained according to the sseId, and an http request ( / close_sse) for closing the connection is initiated through this IP port. Inside this interface, the sseEmitter in the sseCache cache is obtained, and the complete method is called to close the current connection.

[0083] The passively closed connection is a connection failure caused by the service node going offline or the network being interrupted, and is forced to close. When a service node is restarted or offline, monitor the removal event of the temporary node (the node under / sse_c_host) of Zookeeper. After monitoring the node removal event, determine whether the removed node IP is the same as the current service node. If the same, find the corresponding SSE connection and the corresponding sseId in the sseCache cache, and then call the close_sse method in step 1 to close the connection.

[0084] Embodiment 3

[0085] This embodiment is a system for pushing data in a distributed service cluster, and the system includes the following modules: a request acquisition module, a node selection module, a connection establishment module, and a data sending module.

[0086] The request acquisition module is used to obtain the SSE connection request initiated by the client; this module is used to obtain the SSE connection request with unique identification data, create sseId according to the unique identification data in the request, such as the user's userId; identify the object of the current SSE connection, and associate the user with the SSE connection.

[0087] The node selection module is used to select service nodes from the distributed service cluster based on load balancing logic. When the service node is started, the IP and port of the current node are registered to the temporary node of Zookeeper. At this time, the Zookeeper node is used to maintain the currently available service nodes and is used as a temporary node. Combined with the map cache sse_connect_num in redis, the node IP and port with the smallest current connection data can be obtained, and the optimal service node can be finally selected.

[0088] The connection establishment module is used to forward the SSE connection request to the selected service node and establish the SSE connection; the current SSE connection needs to be bound to the sseId, and the binding method is: combining the service node local cache and redis cache to complete; create an sseCache in the current service node, such as static finalMap<String,SseEmitter> sseCache = newConcurrentHashMap<>(); then put the sse connection instance into the map, sseCache.put(sseId, sseEmitter), at this time, the sseId created by the user and the corresponding service node are effectively associated.

[0089] The data sending module is used to send data through the established SSE connection. According to the sseId, the IP and port of the optimal service node of the current connection are obtained in the redis cache sse_connect, and the data to be sent is sent to the data sending interface ( / send_data) of the corresponding service node through an http request. Then the relevant method function is called, such as calling the sseEmitter.send(sseEventBuilder) method, to complete the data sending.

[0090] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by any technician familiar with the art within the technical scope disclosed in the present invention should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. A method for a distributed service cluster to push data, the method comprising the following modules: Get the SSE connection request initiated by the client; Select service nodes from the distributed service cluster based on load balancing logic; Forward the SSE connection request to the selected service node and establish the SSE connection; Data is sent via the established SSE connection.

2. The method for pushing data by a distributed service cluster according to claim 1, characterized in that: The obtaining of the SSE connection request initiated by the client includes: the client initiating the SSE connection request, wherein the SSE connection request includes unique identification data.

3. The method for pushing data by a distributed service cluster according to claim 2, characterized in that: The identification data is used to associate the client with the SSE connection, specifically including: combining the local cache and redis cache of the selected service node so that the SSE connection is bound to the identification data.

4. The method for pushing data by a distributed service cluster according to claim 1, characterized in that: The method of selecting a service node from a distributed service cluster based on load balancing logic includes: registering a temporary service node; determining the number of service node connections; and selecting a temporary service node with the smallest number of current connections as the final selected service node.

5. The method for pushing data by a distributed service cluster according to claim 4, characterized in that: The registering temporary service node includes: when the service node is started, registering the IP and port of the current node to the temporary node of zookeeper.

6. The method for pushing data by a distributed service cluster according to claim 4, characterized in that: The selection of service nodes from the distributed service cluster based on load balancing logic includes: setting the maximum number of connections for each service node; determining whether the number of SSE connections established by the current service node has reached the maximum number of connections, and if so, the service node cannot be selected as the final selected service node.

7. The method for pushing data by a distributed service cluster according to claim 1, characterized in that: The forwarding of the SSE connection request to the selected service node and establishing the SSE connection includes: obtaining the IP and port of the selected service node. The SSE connection request is forwarded to the corresponding IP and port with a selected identifier; if the service node determines that it is a selected node, it directly creates a connection.

8. The method for pushing data by a distributed service cluster according to any one of claims 1 to 7, characterized in that: The data sending through the established SSE connection includes: the SSE connection request contains unique identification data; according to the identification data, the SSE connection currently connected to the service node is obtained from the SSE connection in the redis cache; the data to be sent is sent to the data sending interface of the corresponding service node; the SSE connection is obtained in the local cache of the current service node through the identification data; the spring framework is constructed, and the call is made to complete the data sending.

9. The method for pushing data by a distributed service cluster according to claim 8, characterized in that: The method also includes: closing the SSE connection; the closing of the SSE connection includes active closing of the connection and passive closing of the connection, the active closing of the connection is triggered by the client or the server itself; the passive closing of the connection is forced to close due to connection failure caused by the service node going offline or the network being interrupted.

10. A system for pushing data by a distributed service cluster, comprising a client and a distributed cluster, characterized in that: The system further comprises: The request acquisition module is used to obtain the SSE connection request initiated by the client; The node selection module is used to select service nodes from the distributed service cluster based on the load balancing logic; A connection establishment module is used to forward the SSE connection request to the selected service node and establish the SSE connection; The data sending module is used to send data through the established SSE connection.

Images