High-availability redis distributed cache system and control method therefor

Abstract

The present application relates to the technical field of computers. Disclosed are a high-availability Redis distributed cache system and a control method therefor. The method comprises: by means of a Redis master-slave-sentinel module, deploying in available regions of a target cache region Redis master nodes, Redis slave nodes and Redis sentinel nodes (step S201); selecting a coordinator node from amongst the Redis master nodes by means of a coordinator and sentinel module, and, on the basis of a read / write command request sent by a client, using the coordinator node to perform data synchronous replication, so as to obtain a read / write execution feedback result (step S202); and, by means of an automatic disaster recovery module, acquiring node state data of the Redis sentinel nodes during a read / write execution process, and performing disaster recovery on the basis of the node state data of the Redis sentinel nodes (step S203).

Description

A Highly Available Redis Distributed Caching System and Its Control Method

[0001] Related applications

[0002] This application claims priority to Chinese Patent Application No. 202411654109.7, filed on November 18, 2024, entitled “A High-Availability Redis Distributed Caching System and Its Control Method”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of computer technology, specifically to a highly available Redis distributed caching system and its control method. Background Technology

[0004] With the continuous development of the Internet, Redis (Remote Dictionary Server) database has become a core component of many online applications and services. Redis's high performance and in-memory storage features make it the preferred solution for data caching and real-time data analysis.

[0005] However, Redis node failures can lead to data loss and business interruptions, posing an unacceptable challenge for applications that rely on Redis. Furthermore, high-availability Redis deployments suffer from data inconsistencies, potentially resulting in information loss during failure and disaster recovery. On the other hand, recovery requires significant manual setup and intervention, limiting its availability and automation. Summary of the Invention

[0006] This application provides a highly available Redis distributed caching system and its control method.

[0007] Firstly, this application provides a control method for a highly available Redis distributed caching system. The highly available Redis distributed caching system includes: a Redis master-slave sentinel module, a coordinator and sentinel module, and an automatic disaster recovery module. The Redis master-slave sentinel module, coordinator and sentinel module, and automatic disaster recovery module are connected sequentially, and the coordinator and sentinel module is connected to the client. The method includes:

[0008] The Redis master node, Redis slave node, and Redis sentinel node are deployed in the availability zone of the target cache region using the Redis master-slave sentinel module; wherein, one Redis master node connects to multiple Redis slave nodes, and there is a one-to-one correspondence between the Redis master node and the Redis sentinel node.

[0009] The Redis master node elects a coordinator node through the coordinator and sentinel modules, and performs data synchronization and replication using the coordinator node based on read and write command requests sent by clients, obtaining read and write execution feedback results; and,

[0010] The automatic disaster recovery module obtains the node status data of the Redis Sentinel node during the read and write execution process, and performs disaster recovery based on the node status data of the Redis Sentinel node.

[0011] In one optional implementation, a coordinator node is elected in the Redis master node through the coordinator and sentinel modules. Based on the read and write command requests sent by the client, the coordinator node is used to perform data synchronization and replication, and the read and write execution feedback results are obtained, including:

[0012] The pre-defined election strategy is obtained. The coordinator and sentinel modules elect a coordinator node in the Redis master node based on the pre-defined election strategy, and construct a synchronization set based on the connection relationship between the coordinator node and the Redis master node.

[0013] The coordinator and sentinel modules send read / write command requests to the coordinator node;

[0014] The coordinator node sends the write command request from the read / write command request to the Redis master node and Redis slave node for data synchronization and replication, and receives the first execution feedback result after data synchronization and replication, and sends the first execution feedback result to the client through the coordinator and sentinel modules;

[0015] The coordinator node distributes read command requests from the read / write command requests to the Redis master nodes in the synchronization set in a round-robin fashion; and...

[0016] The Redis master node executes a read command request, receives a second execution feedback result, and then sends the second execution feedback result to the client sequentially through the coordinator node and the coordinator and sentinel modules.

[0017] In one optional implementation, the coordinator node sends the write command request from the read / write command request to the Redis master and Redis slave nodes for data synchronization and replication, and receives the first execution feedback result after data synchronization and replication. The first execution feedback result is then sent to the client through the coordinator and sentinel modules, including:

[0018] The coordinator node distributes write command requests to the Redis master nodes in the synchronization set;

[0019] Write command requests are executed through the Redis master node. Once the Redis master node executes the write command request successfully, it is distributed to the Redis slave nodes that are in a synchronized state.

[0020] The Redis slave node executes write command requests and sends the execution results to the Redis master node.

[0021] The Redis master node receives confirmation data from the Redis slave node indicating that the data is synchronized, and sends the first execution feedback result to the coordinator node based on the confirmation data; and,

[0022] The coordinator node sends the first execution feedback result to the client.

[0023] In one optional implementation, the Redis master node receives acknowledgment data from the Redis slave node whose data is synchronized, and sends a first execution feedback result to the coordinator node based on the acknowledgment data, including:

[0024] If the confirmed data contains only successful execution data, the Redis master node sends the first execution feedback result to the coordinator node based on the successful execution data; and,

[0025] Alternatively, if it is confirmed that there is data in the data where execution failed, the Redis master node sends a rollback command to the Redis slave node.

[0026] In one optional implementation, the node status data of the Redis Sentinel node during read / write operations is obtained through an automatic disaster recovery module, and disaster recovery is performed based on the node status data of the Redis Sentinel node, including:

[0027] The automatic disaster recovery module determines the number of surviving Redis Sentinel nodes based on the node status data of the Redis Sentinel nodes;

[0028] Compare the number of surviving Redis Sentinel nodes with a preset number; the preset number is half the total number of Redis Sentinel nodes; and,

[0029] If the number of surviving Redis Sentinel nodes is less than the preset number, the control coordinator and Sentinel modules will re-elect a coordinator node and use the re-elected coordinator node for data synchronization and replication.

[0030] In one optional implementation, the automatic disaster recovery module obtains the node status data of the Redis Sentinel node during read / write operations, and performs disaster recovery based on the node status data of the Redis Sentinel node, further including:

[0031] If the number of surviving Redis Sentinel nodes is greater than the preset number, or if the number of surviving Redis Sentinel nodes is zero, a monitoring alarm message will be sent to the client.

[0032] Secondly, this application provides a highly available Redis distributed caching system, which includes: a Redis master-slave sentinel module, a coordinator and sentinel module, and an automatic disaster recovery module, wherein the Redis master-slave sentinel module, the coordinator and sentinel module, and the automatic disaster recovery module are connected sequentially, and the coordinator and sentinel module is connected to the client; and,

[0033] The Redis Master-Slave Sentinel module is used to deploy Redis master nodes, Redis slave nodes, and Redis Sentinel nodes in the availability zone of the target cache region. One Redis master node connects to multiple Redis slave nodes, and there is a one-to-one correspondence between Redis master nodes and Redis Sentinel nodes.

[0034] The coordinator and sentinel module is used to elect a coordinator node in the Redis master node, and to use the coordinator node to perform data synchronization and replication based on the read and write command requests sent by the client, and obtain the read and write execution feedback results;

[0035] The automatic disaster recovery module is used to obtain the node status data of the Redis Sentinel node during read and write operations, and to perform disaster recovery based on the node status data of the Redis Sentinel node.

[0036] Thirdly, this application provides a computer device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer-readable instructions, and the processor executes the computer-readable instructions to perform the control method of the high-availability Redis distributed caching system described in the first aspect or any corresponding embodiment.

[0037] Fourthly, this application provides a computer-readable storage medium storing computer-readable instructions for causing a computer to execute the control method of the highly available Redis distributed caching system described in the first aspect or any corresponding embodiment thereof.

[0038] Fifthly, this application provides a computer program product including computer-readable instructions for causing a computer to execute a control method for a highly available Redis distributed caching system as described in the first aspect or any corresponding embodiment thereof. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments of this application or the conventional technology, the drawings used in the description of the embodiments or the conventional technology will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the disclosed drawings without creative effort.

[0040] Figure 1 is a structural block diagram of a highly available Redis distributed caching system according to an embodiment of this application;

[0041] Figure 2 is a flowchart illustrating a control method for a highly available Redis distributed caching system according to an embodiment of this application;

[0042] Figure 3 is a flowchart illustrating another control method for a highly available Redis distributed caching system according to an embodiment of this application;

[0043] Figure 4 is a schematic diagram of the processing flow of a write command request according to an embodiment of this application;

[0044] Figure 5 is a schematic diagram of the processing flow of a read command request according to an embodiment of this application;

[0045] Figure 6 is a flowchart illustrating another control method for a highly available Redis distributed caching system according to an embodiment of this application;

[0046] Figure 7 is a schematic diagram of the coordinator node election process according to an embodiment of this application;

[0047] Figure 8 is a schematic diagram of the hardware structure of a computer device according to an embodiment of this application. Detailed Implementation

[0048] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0049] The Redis architecture mainly includes the following components:

[0050] (1) Redis Master-Slave Deployment: Deploying a Redis architecture with one master and multiple slaves on multiple hosts has the following advantages: slave nodes have hot backups of the master node's data; read and write separation can be achieved. The disadvantages are: asynchronous replication does not guarantee strong data consistency between master and slave; fault or disaster recovery requires manual intervention and there is a risk of data loss.

[0051] (2) Redis Master-Slave Sentinel: Based on the Redis master-slave architecture, Redis Sentinel is introduced. Sentinels are interconnected and monitor the status of each master and slave node. When the master node fails, the Sentinels elect a new master node. Advantages: Automatic recovery from master node failures. Disadvantages: Asynchronous replication still cannot guarantee strong data consistency; if more than half of the Sentinels fail or a disaster occurs, the Sentinels cannot elect a new master node, and if the master node fails, normal service will be unavailable.

[0052] (3) Redis Cluster: A representative of sharded data storage, typically deploying an odd number of peer master nodes and corresponding slave nodes. Each master node is responsible for a different slot. When it receives a read or write command request, it forwards it to the master node of the corresponding slot for operation and returns the result. On the other hand, when a master node fails, the corresponding slave node is promoted to master node to provide services. The advantages are: it implements sharded storage, making full use of multi-machine resources; a single piece of data is stored on only one master node and its corresponding slave node. The disadvantages are: strong consistency of data is not guaranteed between master and slave nodes; a slave node promoted to master node may lose data; when the host of the master node and its corresponding slave node fails or is involved in a disaster, the stored data is completely lost, and the cluster cannot provide services.

[0053] Therefore, the above Redis architecture has the following drawbacks: on the one hand, the inconsistency of data between master and slave nodes leads to data loss during fault recovery; on the other hand, in the face of more serious faults and disasters, the remaining few nodes are insufficient to support normal services.

[0054] To address the aforementioned technical problems, this application provides a highly available Redis distributed caching system and its control method. As shown in Figure 1, the highly available Redis distributed caching system includes a Redis master-slave sentinel module 101, a coordinator and sentinel module 102, and an automatic disaster recovery module 103. The Redis master-slave sentinel module 101, the coordinator and sentinel module 102, and the automatic disaster recovery module 103 are connected sequentially. The coordinator and sentinel module 102 is connected to the client.

[0055] According to an embodiment of this application, a control method embodiment for a highly available Redis distributed caching system is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0056] This embodiment provides a control method for a highly available Redis distributed caching system, which can be used in the aforementioned highly available Redis distributed caching system. Figure 2 is a flowchart of a control method for a highly available Redis distributed caching system according to an embodiment of this application. As shown in Figure 2, the process includes the following steps:

[0057] Step S201: Deploy Redis master nodes, Redis slave nodes, and Redis sentinel nodes in the availability zone of the target cache area through the Redis master-slave sentinel module; wherein, one Redis master node connects to multiple Redis slave nodes, and there is a one-to-one correspondence between the Redis master node and the Redis sentinel node.

[0058] Specifically, as shown in Figure 1, there are n availability zones {AZ1, AZ2, ..., AZ3} in the target cache region. n Each availability zone is isolated from the others in terms of network and power, so even if one availability zone fails or suffers a disaster, it will not affect the service of other availability zones; a master-slave sentinel architecture with one master and multiple slaves is built in n availability zones, and the Redis master nodes are denoted as {M1, M2, ..., M}. n Each availability zone has one Redis master node and one Redis sentinel node, and one Redis master node is connected to multiple Redis slave nodes.

[0059] Furthermore, set up an automatic startup script for the Redis Sentinel node. If the Redis Sentinel node detects that the deployment port is not in use, then start the instance.

[0060] Step S202: Elect a coordinator node in the Redis master node through the coordinator and sentinel modules, and use the coordinator node to perform data synchronization and replication based on the read and write command requests sent by the client, and obtain the read and write execution feedback results.

[0061] Specifically, in a master-slave Redis node architecture, data synchronization between master and slave nodes adopts a state-based synchronization replication method.

[0062] Furthermore, the coordinator node is one and only one among the Redis master nodes. The coordinator node is the external service node of the highly available Redis distributed caching system, that is, the client maintains a connection with the coordinator node.

[0063] Step S203: Obtain the node status data of the Redis Sentinel node during the read / write execution process through the automatic disaster recovery module, and perform disaster recovery based on the node status data of the Redis Sentinel node.

[0064] Specifically, Redis sentinel nodes typically focus on monitoring the running status of nodes and can achieve master election and master-slave switching through a series of mechanisms when the Redis master node fails, thus realizing failover; disaster recovery refers to the ability to ensure the continuous and uninterrupted operation of system services during a disaster, and the system's recovery capability after a disaster.

[0065] Furthermore, the automatic disaster recovery module monitors the status of all nodes and automatically recovers in a timely manner when a fault or disaster occurs, so that the highly available Redis distributed caching system can still provide external services.

[0066] This embodiment provides a control method for a highly available Redis distributed caching system. Redis master nodes, Redis slave nodes, and Redis sentinel nodes are deployed in the availability zone. The coordinator and sentinel modules elect a coordinator node from the Redis master nodes and use the coordinator node to perform data synchronization and replication based on read and write command requests sent by clients. When the Redis master node fails or becomes unavailable, the Redis slave nodes that have been promoted to master nodes will not lose data, ensuring strong data consistency across available nodes. Furthermore, the automatic disaster recovery module performs disaster recovery based on the node status data of the Redis sentinel nodes. In the face of failures or disasters, this ensures that the highly available Redis distributed caching system provides normal service, avoiding data loss and business interruption caused by Redis node failures, thus achieving high availability and stability for the highly available Redis distributed caching system.

[0067] This embodiment provides a control method for a highly available Redis distributed caching system, which can be used in the aforementioned highly available Redis distributed caching system. Figure 3 is a flowchart of a control method for a highly available Redis distributed caching system according to an embodiment of this application. As shown in Figure 3, the process includes the following steps:

[0068] Step S301 involves deploying Redis master nodes, Redis slave nodes, and Redis sentinel nodes in the availability zone of the target cache area using the Redis master-slave sentinel module. Each Redis master node connects to multiple Redis slave nodes, and there is a one-to-one correspondence between the Redis master node and the Redis sentinel node. For details, please refer to step S201 of the embodiment shown in Figure 2, which will not be repeated here.

[0069] Step S302: Elect a coordinator node in the Redis master node through the coordinator and sentinel modules, and use the coordinator node to perform data synchronization and replication based on the read and write command requests sent by the client, and obtain the read and write execution feedback results.

[0070] Specifically, step S302 includes:

[0071] Step S3021: Obtain the preset election strategy. The coordinator and sentinel modules elect a coordinator node in the Redis master node based on the preset election strategy, and construct a synchronization set based on the connection relationship between the coordinator node and the Redis master node.

[0072] Specifically, the coordinator node uses a heartbeat mechanism to establish connections with each Redis master node, adding all Redis master nodes that can be connected at initialization to the synchronization set. When the connection between a Redis master node and the coordinator node is lost, the coordinator node removes the disconnected Redis master node from the synchronization set and continuously attempts to reconnect to the disconnected Redis master node. When the connection is re-established, the reconnected Redis master node synchronizes the data with the coordinator node and is added to the synchronization set after incremental replication is complete.

[0073] In step S3022, the coordinator and sentinel modules send read / write command requests to the coordinator node.

[0074] In step S3023, the coordinator node sends the write command request from the read / write command request to the Redis master node and Redis slave node for data synchronization and replication, and receives the first execution feedback result after data synchronization and replication, and sends the first execution feedback result to the client through the coordinator and sentinel modules.

[0075] In some optional implementations, step S3023 above includes:

[0076] In step a1, the coordinator node distributes write command requests to the Redis master nodes in the synchronization set.

[0077] Step a2: Execute the write command request through the Redis master node. After the Redis master node executes the request successfully, it distributes the write command request to the Redis slave nodes that are in a synchronized state.

[0078] Specifically, each Redis node maintains a state set, which stores the states of Redis slave nodes. The state set includes three states: "Disconnected," "Data Synchronizing," and "Data Synchronized." When a Redis slave node cannot connect to the Redis master node, the state set changes to "Disconnected." When a Redis slave node establishes a connection with the Redis master node, the state set changes to "Data Synchronizing." Once a Redis slave node in the "Data Synchronizing" state completes data synchronization with the Redis master node, the state set changes to "Data Synchronized." For Redis slave nodes, the state set is always empty.

[0079] Step a3: The Redis slave node executes a write command request and sends the execution result to the Redis master node.

[0080] Step a4: The Redis master node receives confirmation data from the Redis slave node whose data has been synchronized, and sends the first execution feedback result to the coordinator node based on the confirmation data.

[0081] Specifically, if the confirmed data contains only successful execution data, the Redis master node sends the first execution feedback result to the coordinator node based on the successful execution data; or, if the confirmed data contains failed execution data, the Redis master node sends a rollback command to the Redis slave node.

[0082] Further, as shown in Figure 4, when the Redis master node receives a write command request, it executes the write command request itself. If the execution fails, it returns a failure message. If the execution succeeds, it sends write command requests to all Redis slave nodes in the "data synchronized" state in the state set and waits. Only when all Redis slave nodes in the "data synchronized" state have correctly received the write command request and executed it successfully do they return confirmation information to the Redis master node within the timeout period. The Redis master node then executes the write command request and returns a success message. Otherwise, the Redis master node rolls back the write command request itself, sends a rollback command to the Redis slave nodes, and returns a failure message. If each Redis master node returns a success message after processing the write command request, the coordinator node (i.e., the coordinator in Figure 4) returns the written success data (i.e., the first execution feedback result) to the client. Otherwise, if any Redis master node returns a failure message, the coordinator node initiates a rollback to the Redis master node that has executed the successful write command request, and the coordinator node returns a failure message.

[0083] In step a5, the coordinator node sends the first execution feedback result to the client.

[0084] This embodiment provides a control method for a highly available Redis distributed caching system. The coordinator node performs data synchronization replication with the Redis master node, and the Redis master node performs data synchronization replication with the Redis slave nodes. This ensures that all data-synchronized nodes in the highly available Redis distributed caching system maintain strong data consistency with the coordinator node, retains multiple redundant copies of consistent data, and avoids infinite blocking caused by the disconnection of the Redis master and slave nodes when the Redis master node and all Redis slave nodes are synchronously replicating. This improves the high availability of the highly available Redis distributed caching system.

[0085] Step S3024: The read command requests in the read / write command requests are distributed in a round-robin fashion to the Redis master nodes in the synchronization set through the coordinator node.

[0086] In step S3025, the Redis master node executes a read command request, obtains the second execution feedback result, and sends the second execution feedback result to the client sequentially through the coordinator node and the coordinator and sentinel modules.

[0087] Specifically, as shown in Figure 5, after receiving a read command request, the coordinator node sends the read command request to the Redis master node in a synchronization set using a round-robin load balancing method. The coordinator node then returns the data returned by the Redis master node (i.e., the second execution feedback result) to the client.

[0088] Step S303: Obtain the node status data of the Redis Sentinel node during the read / write execution process through the automatic disaster recovery module, and perform disaster recovery based on the node status data of the Redis Sentinel node. For details, please refer to step S203 of the embodiment shown in Figure 2, which will not be repeated here.

[0089] This embodiment provides a control method for a highly available Redis distributed caching system. It constructs a synchronization set through the connection between the coordinator node and the Redis master node, laying the foundation for subsequent data synchronization and replication between the coordinator node and the Redis master node. Furthermore, the coordinator node sends write command requests from read / write command requests to the Redis master node and Redis slave nodes for data synchronization and replication, achieving synchronized data replication among the coordinator node, Redis master node, and Redis slave nodes, ensuring strong data consistency and preventing data loss. Finally, during the processing of client read command requests, the coordinator node polls all Redis master nodes that are synchronizing data to process the read command requests, enabling load balancing of the read command requests.

[0090] This embodiment provides a control method for a highly available Redis distributed caching system, which can be used in the aforementioned highly available Redis distributed caching system. Figure 6 is a flowchart of a control method for a highly available Redis distributed caching system according to an embodiment of this application. As shown in Figure 6, the process includes the following steps:

[0091] Step S601 involves deploying Redis master nodes, Redis slave nodes, and Redis sentinel nodes in the availability zone of the target cache area using the Redis master-slave sentinel module. Each Redis master node connects to multiple Redis slave nodes, and there is a one-to-one correspondence between the Redis master node and the Redis sentinel node. For details, please refer to step S301 of the embodiment shown in Figure 3, which will not be repeated here.

[0092] Step S602 involves electing a coordinator node in the Redis master node through the coordinator and sentinel modules, and using the coordinator node to perform data synchronization and replication based on the read and write command requests sent by the client, thereby obtaining read and write execution feedback results. For details, please refer to step S302 of the embodiment shown in Figure 3, which will not be repeated here.

[0093] Step S603: Obtain the node status data of the Redis Sentinel node during the read / write execution process through the automatic disaster recovery module, and perform disaster recovery based on the node status data of the Redis Sentinel node.

[0094] Specifically, step S603 includes:

[0095] Step S6031: The automatic disaster recovery module determines the number of surviving Redis Sentinel nodes based on the node status data of the Redis Sentinel nodes.

[0096] Specifically, a Redis Sentinel node is deployed in each availability zone. The Redis Sentinel node maintains information about the coordinator node and also maintains a synchronization set to support the election, which stores the Redis master nodes that keep data synchronized with the coordinator node.

[0097] Furthermore, Redis Sentinel nodes have a recalculation function, which redefines the total number of Sentinels based on the number of connectable Sentinels. This function will be used for automatic disaster recovery.

[0098] Step S6032: Compare the number of surviving Redis Sentinel nodes with the preset number; where the preset number is half of the total number of Redis Sentinel nodes.

[0099] Step S6033: If the number of surviving Redis Sentinel nodes is less than the preset number, the control coordinator and Sentinel modules will re-elect a coordinator node and use the re-elected coordinator node to perform data synchronization and replication.

[0100] Specifically, the Redis Sentinel node is no longer elected from any one of the Redis slave nodes, but instead elected from the "data synchronized" slave node in the state set.

[0101] Furthermore, Redis Sentinel nodes have the function of recalculating the total number (i.e., redefining the total number of Redis Sentinel nodes based on the number of connectable Redis Sentinel nodes). Each Redis Sentinel node monitors each Redis master node {M1, M2, ..., M...}. nIn the state of Redis Sentinel nodes, communication between them is as shown in Figure 7. When the number of Redis Sentinel nodes is less than half, it indicates that the current Redis Sentinel nodes are unable to complete the election of a coordinator node. The automatic disaster recovery module automatically calls the recalculation function, and the Redis Sentinel nodes update the current number of Sentinel nodes and re-elect a new coordinator node. This maximizes system availability during disasters. At the same time, it is necessary to notify the operations and maintenance personnel to handle physical disaster recovery. The Redis Sentinel nodes notify the Redis master nodes, and the newly selected coordinator node establishes a connection relationship with other Redis master nodes and rebuilds the synchronization set.

[0102] Furthermore, if the number of surviving Redis Sentinel nodes is greater than the preset number, or if the number of surviving Redis Sentinel nodes is zero, a monitoring alarm message will be sent to the client.

[0103] Furthermore, when the number of surviving Redis Sentinel nodes decreases to more than half, the highly available Redis distributed caching system remains available. An alert is sent to operations personnel via email or SMS, who then manually handle the disaster and restart the downed machines in the availability zone. The Redis nodes and Sentinels automatically restart and reconnect. When the number of surviving Redis Sentinel nodes reaches zero, it indicates a disaster has occurred in all availability zones, and operations personnel are notified to handle the situation.

[0104] Furthermore, an automatic restart function is configured for each Redis node and Redis Sentinel node. The Redis Sentinel node ensures automatic fault recovery capability in the partition, and its election mechanism ensures that the newly elected Redis master node will necessarily have consistent data.

[0105] This embodiment provides a control method for a highly available Redis distributed caching system. When the automatic disaster recovery module detects that more than half of the Redis sentinel nodes have failed or suffered a disaster, it calls the recalculation function of the Redis sentinel nodes, enabling the remaining Redis sentinel nodes to still elect a new coordinator node normally. This ensures the availability of the highly available Redis distributed caching system and gives the automatic disaster recovery module maximum automatic disaster recovery capability. Furthermore, the coordinator node re-elected by the coordinator and sentinel modules belongs to the Redis master node in the synchronization set, ensuring data consistency of the new coordinator node and avoiding data loss.

[0106] This embodiment also provides a highly available Redis distributed caching system, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0107] This embodiment provides a highly available Redis distributed caching system, as shown in Figure 1, including: a Redis master-slave sentinel module 101, a coordinator and sentinel module 102, and an automatic disaster recovery module 103. The Redis master-slave sentinel module 101, the coordinator and sentinel module 102, and the automatic disaster recovery module 103 are connected in sequence, and the coordinator and sentinel module 102 is connected to the client.

[0108] The Redis master-slave sentinel module 101 is used to deploy Redis master nodes, Redis slave nodes, and Redis sentinel nodes in the availability zone of the target cache region; wherein, one Redis master node connects to multiple Redis slave nodes, and there is a one-to-one correspondence between the Redis master node and the Redis sentinel node.

[0109] The coordinator and sentinel module 102 is used to elect a coordinator node in the Redis master node, and to perform data synchronization and replication using the coordinator node based on the read and write command requests sent by the client, and to obtain the read and write execution feedback results.

[0110] The automatic disaster recovery module 103 is used to obtain the node status data of the Redis Sentinel node during the read and write execution process, and to perform disaster recovery based on the node status data of the Redis Sentinel node.

[0111] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0112] In this embodiment, a highly available Redis distributed caching system is presented in the form of functional units. Here, a unit refers to an ASIC (Application Specific Integrated Circuit), a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0113] This application also provides a computer device having a highly available Redis distributed caching system as shown in FIG1 above.

[0114] Please refer to Figure 8, which is a schematic diagram of the structure of a computer device provided in an optional embodiment of this application. As shown in Figure 8, the computer device includes: one or more processors 10, memory 20, and interfaces for connecting the various components, including high-speed interfaces and low-speed interfaces. The various components communicate with each other using different buses and can be installed on a common motherboard or otherwise as needed. The processor can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, multiple processors and / or multiple buses can be used with multiple memories, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 8 uses one processor 10 as an example.

[0115] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0116] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0117] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0118] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0119] The computer device also includes an input device 30 and an output device 40. The processor 10, memory 20, input device 30 and output device 40 can be connected via a bus or other means, as shown in Figure 8, which illustrates a connection via a bus.

[0120] Input device 30 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the computer device, such as a touchscreen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 40 may include display devices, auxiliary lighting devices (e.g., LEDs), and haptic feedback devices (e.g., vibration motors). The aforementioned display devices include, but are not limited to, liquid crystal displays, light-emitting diodes, displays, and plasma displays. In some alternative embodiments, the display device may be a touchscreen.

[0121] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods shown in the above embodiments are implemented.

[0122] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0123] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0124] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A control method of a high-availability Redis distributed cache system, wherein, Executed by computer equipment, the highly available Redis distributed caching system includes: a Redis master-slave sentinel module, a coordinator and sentinel module, and an automatic disaster recovery module, wherein the Redis master-slave sentinel module, the coordinator and sentinel module, and the automatic disaster recovery module are connected sequentially, and the coordinator and sentinel module is connected to the client; the method includes: The Redis master-slave sentinel module is used to deploy Redis master nodes, Redis slave nodes, and Redis sentinel nodes in the availability zone of the target cache area; wherein, one Redis master node connects to multiple Redis slave nodes, and there is a one-to-one correspondence between the Redis master node and the Redis sentinel node. The coordinator and sentinel modules elect a coordinator node in the Redis master node, and based on the read and write command requests sent by the client, the coordinator node performs data synchronization and replication, obtaining read and write execution feedback results; and, The automatic disaster recovery module obtains the node status data of the Redis Sentinel node during the read and write execution process, and performs disaster recovery based on the node status data of the Redis Sentinel node.

2. The method of claim 1, wherein, The coordinator and sentinel modules elect a coordinator node in the Redis master node, and based on the read and write command requests sent by the client, the coordinator node performs data synchronization and replication, obtaining read and write execution feedback results, including: The pre-defined election strategy is obtained, and the coordinator and sentinel modules elect the coordinator node in the Redis master node based on the pre-defined election strategy, and construct a synchronization set based on the connection relationship between the coordinator node and the Redis master node; The coordinator and sentinel modules send the read / write command request to the coordinator node; The coordinator node sends the write command request in the read / write command request to the Redis master node and the Redis slave node for data synchronization and replication, and receives the first execution feedback result after data synchronization and replication, and sends the first execution feedback result to the client through the coordinator and sentinel modules; The coordinator node distributes the read command requests from the read / write command requests to the Redis master nodes in the synchronization set in a round-robin fashion; and... The Redis master node executes the read command request, obtains the second execution feedback result, and sends the second execution feedback result to the client sequentially through the coordinator node and the coordinator and sentinel module.

3. The method of claim 2, wherein, The coordinator node sends the write command request from the read / write command request to the Redis master node and the Redis slave node for data synchronization and replication, and receives the first execution feedback result after data synchronization and replication. The first execution feedback result is then sent to the client through the coordinator and sentinel modules, including: The coordinator node distributes the write command request to the Redis master node in the synchronization set; The write command request is executed by the Redis master node. After the Redis master node executes the request successfully, it distributes the write command request to the Redis slave node that is in a synchronized state. The Redis slave node executes the write command request and sends the Redis slave node execution result to the Redis master node; The Redis master node receives confirmation data from the Redis slave node indicating that the data is synchronized, and sends the first execution feedback result to the coordinator node based on the confirmation data; and, The coordinator node sends the first execution feedback result to the client.

4. The method of claim 3, wherein, The Redis master node receives confirmation data from the Redis slave node indicating that the data is synchronized, and sends the first execution feedback result to the coordinator node based on the confirmation data, including: If all the confirmed data contains successful execution data, then the Redis master node sends the first execution feedback result to the coordinator node based on the successful execution data; and, Alternatively, if the confirmation data contains data indicating execution failure, the Redis master node sends a rollback command to the Redis slave node.

5. The method of claim 1, wherein, The automatic disaster recovery module obtains the node status data of the Redis Sentinel node during read / write operations, and performs disaster recovery based on the node status data of the Redis Sentinel node, including: The automatic disaster recovery module determines the number of surviving Redis Sentinel nodes based on the node status data of the Redis Sentinel nodes; The number of surviving Redis sentinel nodes is compared with a preset number; wherein the preset number is half of the total number of Redis sentinel nodes; and, If the number of surviving Redis sentinel nodes is less than the preset number, the coordinator and sentinel modules are controlled to re-elect the coordinator node, and the re-elected coordinator node is used for data synchronization and replication.

6. The method of claim 5, wherein, The automatic disaster recovery module obtains the node status data of the Redis Sentinel node during read / write operations, and performs disaster recovery based on the node status data of the Redis Sentinel node, which also includes: If the number of surviving Redis Sentinel nodes is greater than the preset number, or if the number of surviving Redis Sentinel nodes is zero, a monitoring alarm message is sent to the client.

7. A high availability Redis distributed cache system, wherein, The system includes: a Redis master-slave sentinel module, a coordinator and sentinel module, and an automatic disaster recovery module. The Redis master-slave sentinel module, the coordinator and sentinel module, and the automatic disaster recovery module are connected in sequence. The coordinator and sentinel module is connected to the client. The Redis master-slave sentinel module is used to deploy Redis master nodes, Redis slave nodes, and Redis sentinel nodes in the availability zone of the target cache region; wherein, one Redis master node connects to multiple Redis slave nodes, and there is a one-to-one correspondence between the Redis master node and the Redis sentinel node; and, The coordinator and sentinel modules are used to elect a coordinator node in the Redis master node, and based on the read and write command requests sent by the client, utilize the coordinator node to perform data synchronization and replication, obtaining read and write execution feedback results; and The automatic disaster recovery module is used to obtain the node status data of the Redis Sentinel node during the read and write execution process, and to perform disaster recovery based on the node status data of the Redis Sentinel node.

8. A computer device, wherein, include: A memory and a processor are communicatively connected, the memory stores computer-readable instructions, and the processor executes the control method of the high-availability Redis distributed caching system according to any one of claims 1 to 6 by executing the computer-readable instructions.

9. A computer readable storage medium, wherein, The computer-readable storage medium stores computer-readable instructions for causing a computer to execute the control method of the high-availability Redis distributed caching system as described in any one of claims 1 to 6.

10. A computer program product, wherein, Includes computer-readable instructions for causing a computer to perform a control method for a highly available Redis distributed caching system as described in any one of claims 1 to 6.

Images