A method, system, and apparatus for distributed cache publish-subscribe

Abstract

This invention relates to the field of middleware technology, specifically to a method, system, and apparatus for distributed cache publish-subscribe. The method includes: receiving a specific message sent by a publisher; performing ACCSEE protocol decomposition on the message sent by the publisher; saving the message to a specific Redis shard based on the ACCSEE protocol decomposition data; automatically notifying subscribers via ACCSEE when a Redis shard receives the message; and routing the application's multi-channel subscriptions to the corresponding shards using consistent hashing through an ACCESS proxy layer. This solves the problem that native clusters cannot support cross-shard node publish-subscribe, and directly routes PUBLISH messages published to the actual channel subscription shard nodes for the application's subscription channels, addressing the pain points of decentralized publish scenarios in native clusters. Furthermore, it automatically reconnects to backend clusters during master-slave switching and scaling operations, without affecting the loss of application-side subscription channels, thus solving some scenarios where native clusters cannot cover the stability issues of subscription channels.

Description

Technical Field

[0001] This invention relates to the field of middleware technology, and more specifically, to a method, system, and apparatus for distributed cache publish-subscribe. Background Technology

[0002] ACCESS is a distributed cache access proxy middleware developed by China Telecom Tianyi Cloud. This middleware receives data processing requests from clients and then forwards them to the underlying cache storage shard nodes, such as Redis backend storage.

[0003] Distributed caching is a NoSQL in-memory database software compatible with the Redis protocol. It can accept data query and storage requests from other client applications, and transmit them to the backend cache storage shard nodes through consistent hash sharding via the ACCESS proxy middleware and respond accordingly.

[0004] Publish / subscribe (pub / sub) is a messaging pattern where a sender (pub) sends messages and a subscriber (sub) receives them. Subscribers (such as clients) express their interest in receiving a specific event or a class of events by subscribing to events; publishers (such as servers) can notify subscribers of events that interest them.

[0005] To address the issue of native clusters not supporting cross-node publish / subscribe—specifically, when subscribed channels reside on different shards—native clusters currently lack effective methods to support publish / subscribe across shard nodes. Furthermore, due to design flaws in native clusters based on publish / subscribe, a so-called "subscription storm" problem may occur during message publishing. When a node receives a PUBLISH command, it broadcasts the message to all nodes in the cluster, and all nodes subscribed to the corresponding channel or pattern will receive the message. The existing publish / subscribe pattern in native clusters can significantly impact network and cluster performance. Moreover, when the backend cluster undergoes node switching, crash restarts, or other changes, the application side is aware of the broken subscription connection and must manually re-subscribe.

[0006] This application proposes a method, system, and apparatus for distributed cache publish-subscribe. Summary of the Invention

[0007] To achieve the above objectives, the present invention provides a method, system, and apparatus for distributed cache publish-subscribe, in order to solve the problem that native clusters do not support cross-node publish-subscribe.

[0008] To address the aforementioned technical problems, this invention provides a distributed cache publish-subscribe method, the method comprising:

[0009] Receive specific messages sent by the publisher;

[0010] The message sent by the publisher is deconstructed using the ACCSEE protocol;

[0011] Data is broken down according to the ACCSEE protocol and messages are saved to specific Redis shards;

[0012] Once a Redis shard receives a message, it automatically notifies the subscribers via ACCSEE.

[0013] Preferably, users need to subscribe to the channel before the Redis shard automatically notifies subscribers via ACCSEE after receiving a message.

[0014] Preferably, when a user subscribes to a channel, the specific steps are as follows:

[0015] When a user sends a channel subscription request, it is sent to the distributed cache proxy layer, which routes the user's consistent hash to the corresponding Redis shard.

[0016] When a user sends a multi-channel subscription request, the multi-channel subscription SUBSCRIBE consistent hash routing is used to the corresponding Redis shard. The ACCESS proxy layer automatically simulates multiple subscription clients to subscribe to the corresponding data shard node in the backend.

[0017] ACCESS caches all channel subscription information.

[0018] Preferably, before splitting the data according to the ACCSEE protocol and saving the message to a specific Redis shard, the method further includes:

[0019] Nodes are selected using key-based hash sharding;

[0020] Set up a Redis cluster and configure node and shard mappings; each shard is independent of the others, and each shard node stores its own subscription channels.

[0021] Preferably, after ACCESS caches all channel subscription information, the method further includes:

[0022] Periodically re-consistently hash the cached subscription channel information and simulate different subscription models to resubscribe to data shard nodes.

[0023] Preferably, after ACCESS caches all channel subscription information, the method further includes that when the distributed cache cluster undergoes changes such as master-slave switching, node expansion, or node crash restart, when Access detects that the shard node that caused the change has disconnected, it automatically re-consistently hashes the cached subscription channel information and simulates different subscribers to reconnect and subscribe to the data shard node.

[0024] Preferably, before performing ACCSEE protocol decomposition on the message sent by the publisher, the method further includes: writing and running a distributed cache proxy layer service ACCSEE using Java.

[0025] Further preferably, this application also includes a distributed cache publish-subscribe system, comprising:

[0026] Message receiving module: Used to receive specific messages sent by the publisher;

[0027] Protocol decomposition module: Used to decompose messages sent by the publisher using the ACCSEE protocol;

[0028] Message caching module: used to break down data according to the ACCSEE protocol and save messages to specific Redis shards;

[0029] Message sending module: When a Redis shard receives a message, this Redis shard automatically notifies the subscribers via ACCSEE.

[0030] Further preferably, this application also includes a server, characterized in that the server comprises:

[0031] One or more processors;

[0032] Storage device for storing one or more programs.

[0033] When the one or more programs are executed by the one or more processors, the one or more processors implement the distributed cache publish-subscribe method as described in any one of claims 1-7.

[0034] Further preferably, this application also includes a computer storage medium, characterized in that it stores a computer program that, when executed, implements the distributed cache publish-subscribe method as described in any one of claims 1-7.

[0035] Compared with existing technologies, the distributed cache publish-subscribe method, system, and apparatus of this invention offer the following advantages: This method optimizes the distributed cache ACCESS proxy layer through self-developed optimization. For distributed cache publish-subscribe application scenarios, the ACCESS proxy layer routes the application's multi-channel subscriptions to the corresponding shards using consistent hashing, solving the problem that native clusters cannot support cross-shard node publish-subscribe. Furthermore, for applications publishing PUBLISH messages on subscription channels, the messages are directly routed to the actual channel subscription shard nodes without broadcasting messages to all shard nodes in the cluster, addressing the pain points of decentralized publish scenarios in native clusters. In addition, automatic reconnection is provided for backend cluster master-slave switching, scaling, and other operations, without affecting the loss of application-side subscription channels, thus solving some scenarios where native clusters cannot cover the stability of subscription channels. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0037] Figure 1 This is a structural diagram of a distributed caching publish-subscribe method provided in an embodiment of the present invention. Detailed Implementation

[0038] The technical solutions in the embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0039] In the description of this application, it should be understood that the terms "center", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application.

[0040] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0041] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0042] See Figure 1 As shown, a preferred embodiment of the present invention provides a method, system, and apparatus for distributed cache publish-subscribe, to solve the problem that native clusters do not support cross-node publish-subscribe.

[0043] In existing native clusters, when subscribed channels fall on different shards, there is currently no effective way to support publish-subscribe across shard nodes. Furthermore, due to design flaws in native clusters based on publish-subscribe, a so-called "subscription storm" problem may occur during message publishing. When a node receives a PUBLISH command, it broadcasts the message to all nodes in the entire cluster. All nodes subscribed to the corresponding channel or pattern will receive the message. The existing publish-subscribe pattern in native clusters can significantly impact network and cluster performance. Moreover, when the backend cluster undergoes changes such as node switching, system crashes, or restarts, the application side can detect the broken subscription connection and manually resubscribe.

[0044] In other words, native clusters have significant drawbacks in the following scenarios:

[0045] Scenario 1: The "subscription storm" problem in the native cluster severely affects the cluster's processing performance.

[0046] Scenario 2: Native clusters lack effective means to support cross-shard nodes, especially in publish-subscribe scenarios.

[0047] Scenario 3: When the native cluster experiences failures such as downtime or master-slave switching, the application side needs to redeploy the subscription, making it impossible to achieve transparent and seamless publishing and subscription.

[0048] To address the aforementioned technical problems, this invention provides a distributed cache publish-subscribe method, the method comprising:

[0049] Receive specific messages sent by the publisher;

[0050] The message sent by the publisher is deconstructed using the ACCSEE protocol;

[0051] Data is broken down according to the ACCSEE protocol and messages are saved to specific Redis shards;

[0052] Once a Redis shard receives a message, it automatically notifies the subscribers via ACCSEE.

[0053] Preferably, users need to subscribe to the channel before the Redis shard automatically notifies subscribers via ACCSEE after receiving a message.

[0054] Preferably, when a user subscribes to a channel, the specific steps are as follows:

[0055] When a user sends a channel subscription request, it is sent to the distributed cache proxy layer, which routes the user's consistent hash to the corresponding Redis shard.

[0056] When a user sends a multi-channel subscription request, the multi-channel subscription SUBSCRIBE consistent hash routing is used to the corresponding Redis shard. The ACCESS proxy layer automatically simulates multiple subscription clients to subscribe to the corresponding data shard node in the backend.

[0057] ACCESS caches all channel subscription information.

[0058] Preferably, before splitting the data according to the ACCSEE protocol and saving the message to a specific Redis shard, the method further includes:

[0059] Nodes are selected using key-based hash sharding;

[0060] Set up a Redis cluster and configure node and shard mappings; each shard is independent of the others, and each shard node stores its own subscription channels.

[0061] Preferably, after ACCESS caches all channel subscription information, the method further includes:

[0062] Periodically re-consistently hash the cached subscription channel information and simulate different subscription models to resubscribe to data shard nodes.

[0063] Preferably, after ACCESS caches all channel subscription information, the method further includes that when the distributed cache cluster undergoes changes such as master-slave switching, node expansion, or node crash restart, when Access detects that the shard node that caused the change has disconnected, it automatically re-consistently hashes the cached subscription channel information and simulates different subscribers to reconnect and subscribe to the data shard node.

[0064] Preferably, before performing ACCSEE protocol decomposition on the message sent by the publisher, the method further includes: writing and running a distributed cache proxy layer service ACCSEE using Java.

[0065] In summary, the distributed cache publish-subscribe method provided by the embodiments of this application has been specifically optimized for the above-mentioned scenario, as follows:

[0066] To address the "subscription storm" problem in the native cluster in Scenario 1: The distributed cache cluster in this patent differs from the decentralized architecture of the native cluster. Each shard is independent of the others, and each shard node stores its own subscription channel. When a message is published, the specified Redis shard node automatically notifies the application via Access, without having to "broadcast" the message to all nodes in the cluster. This avoids the "subscription storm" problem in the native cluster and greatly reduces cluster network congestion and performance bottlenecks caused by message publishing and subscription.

[0067] For the cross-node subscription problem in the native cluster in Scenario 2: This patented distributed cache proxy layer Access can intelligently parse the application's subscription channel protocol, integrate the subscription information of different channels, and simulate subscribers to subscribe to the corresponding data shard nodes in the backend. This makes up for the scenario where the native cluster JedisCluster cannot subscribe across shard nodes. The application can use the cluster in the same way as a single-machine Redis, which greatly improves the application development efficiency.

[0068] To address the issue of transparent awareness in native cluster applications in scenario three: When a native cluster undergoes changes such as master-slave switching or scaling up, the application's subscription connection is directly disconnected. This patented distributed cache, Access, caches all subscription channel information of the application. When a backend data node crashes, switches, or scales up, Access detects that the shard node that caused the change has disconnected. It then automatically re-hashes the cached subscription channel information in a consistent manner and simulates different subscribers to reconnect and subscribe to the data shard node, achieving transparency and awareness for the application.

[0069] The above method will be described in detail below through examples:

[0070] Example 1:

[0071] 1. Use Java to write and run the distributed cache proxy layer service Access.

[0072] 2. The code that receives the REDIS publish / subscribe request and initiates the response in Access sends request and response events, which are received by the distributed cache proxy layer smart protocol processing module.

[0073] 3. The Access smart protocol processing module automatically parses the client's multi-channel subscription request protocol and routes it to the corresponding Redis shard based on the SUBSCRIBE consistent hash of the multi-channel subscription. The Access proxy layer automatically simulates multiple subscription clients to subscribe to the corresponding data shard nodes in the backend (solving the problem that the native cluster cannot support cross-shard node operations).

[0074] 4. When a subscribed channel publishes a PUBLISH message, the corresponding Redis shard node automatically notifies the application via Access, without having to "broadcast" the message to all nodes in the cluster, thus avoiding the "subscription storm" problem in the native cluster.

[0075] 5. When changes occur in the cluster, such as master-slave switching, node expansion, or node crash restart, Access detects that the shard node that caused the change has lost connection. It automatically re-hashes the cached subscription channel information in a consistent manner and simulates different subscribers to reconnect and subscribe to the data shard node, achieving transparency and seamlessness for the application.

[0076] Furthermore, this application also includes a distributed cache publish-subscribe system, comprising:

[0077] Message receiving module: Used to receive specific messages sent by the publisher;

[0078] Protocol decomposition module: Used to decompose messages sent by the publisher using the ACCSEE protocol;

[0079] Message caching module: used to break down data according to the ACCSEE protocol and save messages to specific Redis shards;

[0080] Message sending module: When a Redis shard receives a message, this Redis shard automatically notifies the subscribers via ACCSEE.

[0081] Furthermore, this application also includes a server, characterized in that the server comprises:

[0082] One or more processors;

[0083] Storage device for storing one or more programs.

[0084] When the one or more programs are executed by the one or more processors, the one or more processors implement the distributed cache publish-subscribe method described in any embodiment.

[0085] Memory, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the distributed cache publish-subscribe method in this embodiment of the invention (e.g., the message receiving module, protocol decomposition module, message storage module, and message sending module in the distributed cache publish-subscribe system). The processor executes various server functions and data processing by running the software programs, instructions, and modules stored in the memory, thus implementing the aforementioned Redis-based multi-user publish-subscribe method.

[0086] The memory may primarily comprise a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a given function; the data storage area may store data created based on terminal usage. Furthermore, the memory may include high-speed random access memory (RAM) and non-volatile memory, such as at least one disk storage device, flash memory, or other non-volatile solid-state storage device. In some instances, the memory may further include memory remotely located relative to the processor, which can be connected to a server via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks (LANs), mobile communication networks, and combinations thereof.

[0087] The communication device can be used to receive messages from user terminals and to send messages to user terminals.

[0088] Furthermore, this application also includes a computer storage medium, characterized in that it stores a computer program that, when executed, implements the distributed cache publish-subscribe method described in any embodiment.

[0089] In summary, this invention provides a method, system, and apparatus for distributed cache publish-subscribe. Through optimization of a self-developed distributed cache ACCESS proxy layer, it addresses the issue of native clusters not supporting cross-shard node publish-subscribe in distributed cache publish-subscribe application scenarios. By using the ACCESS proxy layer to route multi-channel subscriptions of the application to the corresponding shards using consistent hashing, it solves the problem of native clusters not supporting publish-subscribe across shard nodes. Furthermore, it directly routes PUBLISH messages published to the actual channel subscription shard node, eliminating the need to broadcast messages to all shard nodes in the cluster, thus resolving the pain points of decentralized publish scenarios in native clusters. In addition, it automatically reconnects to backend clusters during master-slave switching and scaling operations, without affecting the loss of application-side subscription channels, thus addressing scenarios where native clusters cannot cover the stability issues of subscription channels.

[0090] The above description is merely one embodiment of the present invention, but it cannot be used to limit the scope of the present invention. Any structural changes made based on the present invention, as long as they do not lose the essence of the present invention, should be considered to fall within the protection scope of the present invention and be subject to its restrictions.

[0091] It should be noted that the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the modules or steps in the embodiments of the present invention can be further decomposed or combined. For example, the modules in the above embodiments can be merged into one module, or further divided into multiple sub-modules to complete all or part of the functions described above. The names of the modules and steps involved in the embodiments of the present invention are only for distinguishing the various modules or steps and are not considered as an improper limitation of the present invention.

[0092] The term "comprising" or any other similar term is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus / device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent in such process, method, article, or apparatus / device.

[0093] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after such changes or substitutions will all fall within the scope of protection of the present invention.

[0094] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention.

Claims

1. A distributed cache publish-subscribe method, characterized in that, The method includes: Receive specific messages sent by the publisher; The message sent by the publisher is deconstructed using the ACCSEE protocol; Data is broken down according to the ACCSEE protocol and messages are saved to specific Redis shards; Once a Redis shard receives a message, it automatically notifies the subscribers via ACCSEE. Before a Redis shard can automatically notify subscribers after receiving a message via ACCSEE, users need to subscribe to the channel. When a user subscribes to a channel, the specific steps are as follows: When a user sends a channel subscription request, it is sent to the distributed cache proxy layer, which routes the user's consistent hash to the corresponding Redis shard. When a user sends a multi-channel subscription request, the multi-channel subscription SUBSCRIBE consistent hash routing is used to the corresponding Redis shard. The ACCESS proxy layer automatically simulates multiple subscription clients to subscribe to the corresponding data shard node in the backend. ACCESS caches all channel subscription information; Before splitting the data according to the ACCSEE protocol and saving the message to a specific Redis shard, the method further includes: Nodes are selected using key-based hash sharding; Set up a Redis cluster and configure node and shard mappings; each shard is independent of the others, and each shard node stores its own subscription channels; After ACCESS caches all channel subscription information, the method further includes: Periodically re-hash the cached subscription channel information for consistency and simulate different subscription schemes to resubscribe to data shard nodes; After ACCESS caches all channel subscription information, the method further includes that when the distributed cache cluster undergoes changes such as master-slave switching, node expansion, or node crash restart, when Access detects that the shard node that caused the change has disconnected, it automatically re-consistently hashes the cached subscription channel information and simulates different subscribers to reconnect and subscribe to the data shard node.

2. The distributed cache publish-subscribe method according to claim 1, characterized in that, Before performing ACCSEE protocol decomposition on the message sent by the publisher, the method further includes: writing and running a distributed cache proxy layer service ACCSEE in Java.

3. A distributed cache publish-subscribe system, characterized in that, include: Message receiving module: Used to receive specific messages sent by the publisher; It is also used to receive channel subscription requests and multi-channel subscription requests sent by users; Protocol decomposition module: used to decompose messages sent by publishers using the ACCSEE protocol; also used to parse user channel subscription requests and multi-channel subscription requests, select nodes through key-based hash sharding, and route user consistent hashes to the corresponding Redis shards; The message caching module is used to break down data according to the ACCSEE protocol and save messages to specific Redis shards; it is also used to cache all channel subscription information. The message sending module is used to automatically notify subscribers via ACCSEE when a Redis shard receives a message; it is also used to automatically simulate multiple subscription clients subscribing to the corresponding data shard nodes in the backend when a user sends a multi-channel subscription request; it is also used to periodically re-consistently hash the cached subscription channel information and simulate different subscribers re-subscribing to the data shard nodes; and when the distributed cache cluster undergoes changes such as master-slave switching, node expansion, or node crash restart, and Access detects that the shard node that caused the change has lost connection, it automatically re-consistently hashes the cached subscription channel information and simulates different subscribers reconnecting to subscribe to the data shard nodes.

4. A server, characterized in that, The server includes: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the distributed cache publish-subscribe method as described in any one of claims 1-2.

5. A computer storage medium, characterized in that, It stores a computer program that, when executed, implements the distributed cache publish-subscribe method as described in any one of claims 1-2.

Images