Switching method and device for redis cluster

Abstract

This application provides a method and apparatus for switching Redis clusters, applied to the switching control subsystem of a Redis dual-active switching system. The system also includes an availability detection subsystem and a proxy node. The proxy node is configured as the unified entry point for business systems to access Redis services. The method includes: upon receiving a fault trigger signal sent by the availability detection subsystem, determining the service availability of the second Redis cluster. The fault trigger signal is generated and sent by the availability detection subsystem when the first Redis cluster is determined to be faulty; when the service availability of the second Redis cluster is available, modifying the backend service address configuration of the proxy node to switch the backend service from the first Redis cluster to the second Redis cluster. The modification of the backend service address configuration is transparent to the business system. This ensures the effectiveness of the switch and avoids prolonged business interruption due to switching to an unavailable cluster.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a method and apparatus for switching a remote dictionary service (Redis) cluster. Background Technology

[0002] With the rapid development of internet services, Redis, as a high-performance caching and data storage middleware, has become a core component of various business systems, and its availability directly determines the stability of these systems. To avoid Redis service interruption due to a single data center failure, enterprises generally adopt a dual-data center deployment model, where two data centers each deploy a Redis cluster, maintaining data consistency between the two centers through data synchronization and achieving mutual backup.

[0003] In related technologies, in a dual-datacenter deployment scenario, when the primary datacenter Redis cluster fails, the access traffic of the business system needs to be switched from the primary datacenter Redis cluster to the backup datacenter Redis cluster. This switching process usually relies on manual execution by operations and maintenance personnel, which is time-consuming and prone to errors, causing the business system to be unable to access the Redis service normally during the failure period, affecting business continuity. In addition, some existing automated solutions lack effective judgment on the service status of the target cluster during the switching execution process, and service unavailability may still occur after the switch. Summary of the Invention

[0004] This application provides a method and apparatus for switching Redis clusters, which can ensure the effectiveness of cluster switching and avoid prolonged business interruption due to switching to an unavailable cluster.

[0005] The first aspect of this application provides a method for switching Redis clusters, applied to a switching control subsystem in a Redis dual-active switching system. The Redis dual-active switching system further includes an availability detection subsystem, a first data center, a second data center, and a proxy node. The first data center deploys a first Redis cluster, and the second data center deploys a second Redis cluster. The proxy node is configured as a unified entry point for business systems to access Redis services, providing access proxies for either the first or second Redis cluster to the business systems, and is initially configured to point the backend service to the first Redis cluster. The method includes: upon receiving a fault trigger signal from the availability detection subsystem, determining the service availability of the second Redis cluster, wherein the fault trigger signal is generated and sent by the availability detection subsystem upon determining a fault in the first Redis cluster; and if the service availability of the second Redis cluster is available, modifying the backend service address configuration of the proxy node to switch the backend service from the first Redis cluster to the second Redis cluster, wherein the modification of the backend service address configuration is transparent to the business systems, and the business systems continue to access Redis services through the proxy node.

[0006] In the technical solution of this application, the service availability of the backup cluster is determined before the switch is executed, and the configuration modification is only performed after the availability is confirmed, thereby ensuring the effectiveness of the switch and avoiding the extension of business interruption time due to the switch to an unavailable cluster.

[0007] Optionally, in one possible implementation of the first aspect, the aforementioned fault trigger signal is generated and sent by the availability detection subsystem in the following manner: performing multi-dimensional health detection on the first Redis cluster, wherein the multi-dimensional health detection includes at least one of process liveness detection, port connectivity detection, read / write availability detection, and data synchronization status detection; if the number of consecutive failures in any dimension of health detection reaches a preset threshold, the first Redis cluster is determined to be faulty, a fault trigger signal is generated, and sent. Thus, by combining multi-dimensional health detection with a consecutive failure threshold mechanism to generate the fault trigger signal, the accuracy of fault determination is improved, and the possibility of false positives or false negatives is reduced.

[0008] Optionally, in another possible implementation of the first aspect, determining the service availability of the second Redis cluster includes: sending read / write commands to the second Redis cluster; determining the service availability of the second Redis cluster as available if a correct response to the read / write command is received within a preset timeout period; and determining the service availability of the second Redis cluster as unavailable if a correct response to the read / write command is not received within the preset timeout period. Thus, by sending read / write commands to the backup cluster and determining its service availability based on whether a correct response is received, service availability is determined in a concrete and verifiable manner, improving the accuracy of the determination results.

[0009] Optionally, in another possible implementation of the first aspect, after modifying the backend service address configuration of the proxy node, the method further includes: if the proxy node supports dynamic loading, making the modified backend service address configuration effective through dynamic loading; if the proxy node does not support dynamic loading, restarting the proxy node to make the modified backend service address configuration effective. Thus, by using either dynamic loading or restarting to make the configuration modification effective depending on whether the proxy node supports dynamic loading, it adapts to proxy nodes with different characteristics, ensuring that the switching operation can be completed in a timely manner.

[0010] Optionally, in another possible implementation of the first aspect, before modifying the backend service address configuration of the proxy node, the method further includes: backing up the current configuration file of the proxy node to obtain a backup configuration file; after modifying the backend service address configuration of the proxy node to switch the backend service from the first Redis cluster to the second Redis cluster, the method further includes: determining the service availability of the second Redis cluster through the proxy node; and restoring the backend service address configuration of the proxy node using the backup configuration file if the service availability of the second Redis cluster is determined to be unavailable through the proxy node. Therefore, by backing up the configuration before modification and restoring it using the backup configuration when the service availability is determined to be unavailable after the switch, a quick rollback to the original configuration can be achieved in case of a switch failure, reducing the risks associated with the switch operation.

[0011] Optionally, in another possible implementation of the first aspect, after modifying the backend service address configuration of the proxy node to switch the backend service from the first Redis cluster to the second Redis cluster, the method further includes: sending a switch result notification to a preset notification recipient based on the switch result, wherein the switch result notification includes at least one of the following: faulty data center identifier, switch result, and switch time. Thus, by automatically sending a notification containing information such as the faulty data center, switch result, and time to the preset notification recipient after the switch is completed, maintenance personnel can promptly grasp the system status, reducing manual monitoring costs.

[0012] Optionally, in another possible implementation of the first aspect, the method further includes: upon receiving a fault trigger signal, if it is determined that the service availability of the second Redis cluster is unavailable, terminating the switchover process and sending a dual-datacenter fault alarm notification to a pre-defined notification recipient. Thus, by terminating the switchover and sending an alarm notification when the backup cluster is determined to be unavailable, invalid switchover operations are avoided when both datacenters are unavailable, and relevant personnel are promptly informed of the emergency situation.

[0013] Optionally, in another possible implementation of the first aspect, the method further includes: upon receiving a recovery trigger signal from the availability detection subsystem, determining the service availability of the first Redis cluster, wherein the recovery trigger signal is sent when the availability detection subsystem determines that the first Redis cluster has recovered and is available; and, if the service availability of the first Redis cluster is available, modifying the backend service address configuration of the proxy node to switch the backend service from the second Redis cluster back to the first Redis cluster. Thus, by automatically executing a switchback operation upon receiving the recovery trigger signal, the backend service is restored to the original cluster, thereby restoring the original deployment architecture without manual intervention after fault repair, achieving a fully automated closed-loop process.

[0014] Optionally, in another possible implementation of the first aspect, before switching the backend service from the second Redis cluster back to the first Redis cluster, the method further includes: obtaining the data synchronization status between the first and second Redis clusters; and, if the data synchronization status indicates that the data is consistent, performing the operation of switching the backend service from the second Redis cluster back to the first Redis cluster. Thus, by obtaining the data synchronization status between the two data centers before the switchback and performing the switchback after confirming data consistency, data inconsistency during the switchback process can be avoided from causing business data anomalies or loss.

[0015] A second aspect of this application provides a Redis cluster switching device applied to a switching control subsystem in a Redis dual-active switching system. The Redis dual-active switching system further includes an availability detection subsystem, a first data center, a second data center, and a proxy node. The first data center deploys a first Redis cluster, and the second data center deploys a second Redis cluster. The proxy node is configured as a unified entry point for business systems to access Redis services, providing access proxies for either the first or second Redis cluster to the business systems, and is initially configured to point backend services to the first Redis cluster. The device includes: The availability determination module is used to determine the service availability of the second Redis cluster upon receiving a fault trigger signal from the availability detection subsystem. The fault trigger signal is generated and sent by the availability detection subsystem upon determining that the first Redis cluster is faulty.

[0016] The switching control module is used to modify the backend service address configuration of the proxy node when the service availability of the second Redis cluster is available, so as to switch the backend service from the first Redis cluster to the second Redis cluster. The modification of the backend service address configuration is transparent to the business system, and the business system continues to access the Redis service through the proxy node.

[0017] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the Redis cluster switching method of the first aspect described above.

[0018] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the Redis cluster switching method described in the first aspect.

[0019] The fifth aspect of this application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the Redis cluster switching method described in the first aspect.

[0020] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, 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 some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram of the architecture of a Redis active-active failover system provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a Redis cluster switching method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a switching device for a Redis cluster provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0023] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0024] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0025] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0026] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0027] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0028] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0029] It should be understood that the sequence number of each step in this embodiment does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of this application embodiment.

[0030] In related technologies, in a dual-datacenter deployment scenario, when the primary datacenter Redis cluster fails, the access traffic of the business system needs to be switched from the primary datacenter Redis cluster to the backup datacenter Redis cluster. This switching process usually relies on manual execution by operations and maintenance personnel, which is time-consuming and prone to errors, causing the business system to be unable to access the Redis service normally during the failure period, affecting business continuity. In addition, some existing automated solutions lack effective judgment on the service status of the target cluster during the switching execution process, and service unavailability may still occur after the switch.

[0031] In view of this, embodiments of this application provide a method and apparatus for switching Redis clusters, applied to the switching control subsystem of a Redis dual-active switching system. The Redis dual-active switching system also includes an availability detection subsystem, a first data center, a second data center, and a proxy node. The first data center deploys a first Redis cluster, and the second data center deploys a second Redis cluster. The proxy node is configured as a unified entry point for business systems to access Redis services, providing access proxies for either the first or second Redis cluster to the business systems, and is initially configured to point the backend service to the first Redis cluster. The method first determines the service availability of the second Redis cluster upon receiving a fault trigger signal sent by the availability detection subsystem. The fault trigger signal is generated and sent by the availability detection subsystem when it determines that the first Redis cluster is faulty. Then, if the service availability of the second Redis cluster is available, the backend service address configuration of the proxy node is modified to switch the backend service from the first Redis cluster to the second Redis cluster. The modification of the backend service address configuration is transparent to the business systems, and the business systems continue to access Redis services through the proxy node. Therefore, by determining the service availability of the backup cluster before the switchover is executed, and only performing configuration modifications after confirming availability, the effectiveness of the switchover is ensured, and the extended service interruption time caused by switching to an unavailable cluster is avoided.

[0032] The following example illustrates the application scenario of the Redis cluster switching method provided in this application. Taking a dual-datacenter Redis deployment of an e-commerce platform as an example, the platform deploys Redis clusters in datacenter A and datacenter B respectively, and provides a unified Redis access entry point for order services through proxy nodes. During normal operation, the proxy nodes point the backend service to the Redis cluster in datacenter A. When the Redis cluster in datacenter A becomes unavailable due to hardware failure, if the traditional manual switching method is used, the operation and maintenance personnel need to first confirm the fault and then modify the proxy configuration. The whole process usually takes several minutes, during which the order service will experience a large number of timeout errors because it cannot access the Redis cache. After adopting the solution of this application, the availability detection subsystem automatically detects the failure of the Redis cluster in datacenter A and sends a fault trigger signal. After receiving the signal, the switching control subsystem first confirms that the Redis cluster service in datacenter B is available, and then automatically modifies the backend service address configuration of the proxy node to switch traffic to the Redis cluster in datacenter B. The whole process does not require manual intervention, and the switching time is greatly reduced to the second level, thereby effectively ensuring the continuous availability of order services.

[0033] To illustrate the technical solution of this application, specific embodiments are described below.

[0034] Reference Figure 1 This diagram illustrates the architecture of a Redis active-active failover system provided in an embodiment of this application. Figure 1 As shown, the system adopts at least a dual-data center deployment architecture.

[0035] The first data center houses the first Redis cluster, and the second data center houses the second Redis cluster. The two Redis clusters in the two data centers can maintain real-time data synchronization through a data synchronization component to ensure data consistency between the two data centers.

[0036] The proxy node is deployed between the business system and the Redis cluster, serving as a unified entry point for the business system to access the Redis service. This proxy node is configured to provide the business system with access to either the first or second Redis cluster, and is initially configured to point the backend service to the first Redis cluster. The business system accesses the Redis cluster through this proxy node without needing to know the specific deployment location of the backend Redis cluster.

[0037] The availability detection subsystem is used to perform health probes on the first Redis cluster and generate a fault trigger signal when the first Redis cluster is determined to be faulty, and send the fault trigger signal to the switchover control subsystem.

[0038] The switching control subsystem establishes communication connections with both the availability detection subsystem and the proxy node. It receives fault trigger signals sent by the availability detection subsystem and performs modification operations on the backend service address configuration of the proxy node based on the signal, switching the backend service from the first Redis cluster to the second Redis cluster.

[0039] The specific implementation methods and interaction processes of the above components will be described in detail in subsequent embodiments using examples.

[0040] exist Figure 1 Based on the system architecture shown, Figure 2 The diagram illustrates a flowchart of a Redis cluster failover method provided in an embodiment of this application. This method can be executed by the failover control subsystem in a Redis active-active failover system.

[0041] like Figure 2 As shown, the switching method for this Redis cluster may include the following steps: Step 201: Upon receiving a fault trigger signal from the availability detection subsystem, determine the service availability of the second Redis cluster.

[0042] The fault trigger signal is generated and sent by the availability detection subsystem when the first Redis cluster fails.

[0043] In this embodiment, the switching control subsystem establishes a communication connection with the availability detection subsystem in advance to detect and receive signals sent by the availability detection subsystem. The availability detection subsystem, as an independent health detection component, is deployed on the operations and maintenance server and maintains communication with the first Redis cluster, the second Redis cluster, and the switching control subsystem.

[0044] In one embodiment, the availability detection subsystem can continuously perform multi-dimensional health probes on the first Redis cluster at preset probe intervals to perceive the real-time operating status of the first Redis cluster. Multi-dimensional health probes refer to a comprehensive health check of the Redis cluster from multiple different dimensions, rather than relying solely on a single connectivity test. When the availability detection subsystem determines that the first Redis cluster has failed based on the probe results, it generates a fault trigger signal and sends this signal to the switchover control subsystem through a preset communication interface. The fault trigger signal includes at least the fault type, the fault occurrence time, and the identification information of the first Redis cluster. The fault type may include process interruption, read / write unavailability, data synchronization interruption, etc. Upon receiving the fault trigger signal, the switchover control subsystem does not directly perform configuration modifications. Instead, it first determines the service availability of the second Redis cluster to verify whether the cluster has the ability to take over the service, thereby avoiding switching to a cluster that is also in an unavailable state and ensuring the effectiveness of the switchover operation.

[0045] In one embodiment, the fault trigger signal is generated and sent by the availability detection subsystem in the following manner: First, a multi-dimensional health probe is performed on the first Redis cluster, wherein the multi-dimensional health probe includes at least one of process liveness detection, port connectivity detection, read / write availability detection, and data synchronization status detection; then, if the number of consecutive failures in any dimension of the health probe reaches a preset threshold, the first Redis cluster is determined to be faulty, a fault trigger signal is generated, and sent. Therefore, by combining multi-dimensional health probes with a consecutive failure threshold mechanism to generate the fault trigger signal, the accuracy of fault determination is improved, and the possibility of false positives or false negatives is reduced.

[0046] It should be noted that the availability detection subsystem can flexibly configure the specific detection dimensions enabled when performing multi-dimensional health probes, based on the reliability requirements of the actual deployment environment. Process liveness detection checks whether the Redis service process is running; port connectivity detection checks whether the Redis service port is connectable; read / write availability detection sends read / write commands to the Redis cluster to check whether the Redis cluster can perform data read / write operations normally; and data synchronization status detection checks whether data synchronization between the first and second Redis clusters is normal. In business scenarios with high fault sensitivity requirements, all four detection dimensions can be enabled simultaneously to comprehensively assess the health status of the first Redis cluster from multiple dimensions. In scenarios more sensitive to probe overhead, only read / write availability detection can be enabled to reduce the additional load on the Redis cluster from probe operations.

[0047] The availability detection subsystem records the detection results after each detection. To reduce false positives caused by occasional network fluctuations or instantaneous load jitter, a fault determination threshold is pre-set in the availability detection subsystem. When the number of consecutive failures of a health probe in a certain dimension reaches this preset threshold (e.g., three consecutive failed probes), the availability detection subsystem determines that the first Redis cluster has failed. After triggering the fault determination, the availability detection subsystem generates a fault trigger signal, which includes the fault type (corresponding to the detection dimension that triggered the fault determination), the time of the fault occurrence, and the identification information of the first Redis cluster, and sends the fault trigger signal to the failover control subsystem.

[0048] In one embodiment, the specific implementation of read / write availability detection may include: an availability detection subsystem sending a setting command (e.g., a SET command) and a getting command (e.g., a GET command) to the first Redis cluster, and detecting whether a correct response is received within a preset timeout period. For example, the availability detection subsystem sends the "SET test_key 1" command to the first Redis cluster. If an "OK" response is received within the preset timeout period (e.g., 1 second), it continues to send the "GET test_key" command. If the obtained value is "1", the read / write availability detection is considered successful. The read / write availability detection is considered to have failed if any of the following occurs: failure to establish a Transmission Control Protocol (TCP) connection, connection actively disconnected by the Redis server, authentication failure, no response received within the preset timeout period after sending the command, the Redis server returning an error response (e.g., LOADING, BUSY, MASTERDOWN, OOM, etc.), or the connection is normal but the command execution is stuck in a blocked state.

[0049] In one embodiment, the specific implementation of data synchronization status detection may include: an availability detection subsystem sending a query request to the Hypertext Transfer Protocol (HTTP) status port exposed by the data synchronization component to obtain the synchronization status data returned by the data synchronization component. This synchronization status data can be described using a lightweight data exchange format (JavaScript Object Notation, JSON), including global status fields, reader status fields, and writer status fields. Specifically, the "consistent" field in the global status field indicates whether the data in the first Redis cluster and the second Redis cluster are completely consistent; the "status" field in the reader status field indicates the working status of the data synchronization component's reader (e.g., "syncing aof" indicates normal incremental synchronization), the "aof_received_offset" field indicates the offset received by the reader, and the "aof_sent_offset" field indicates the offset sent to the writer; the "unanswered_entries" field in the writer status field indicates the number of commands not yet written to the target, and the "unanswered_bytes" field indicates the number of bytes not yet written to the target. The availability detection subsystem analyzes the above fields to determine whether data synchronization has been interrupted and whether the synchronization delay exceeds a preset threshold. If data synchronization is interrupted and cannot be automatically resumed, or if the synchronization delay continues to exceed the preset threshold (e.g., 100 milliseconds), the data synchronization status is determined to be abnormal.

[0050] Through the aforementioned multi-dimensional health detection and continuous failure threshold mechanism, the availability detection subsystem can accurately and promptly detect Redis cluster failures, providing a reliable basis for switching triggers for the switching control subsystem.

[0051] In one embodiment, determining the service availability of the second Redis cluster may specifically include: sending read / write commands to the second Redis cluster; if a correct response to the read / write command is received within a preset timeout period, determining that the service availability of the second Redis cluster is available; if a correct response to the read / write command is not received within the preset timeout period, determining that the service availability of the second Redis cluster is unavailable. Therefore, by sending read / write commands to the standby cluster and determining its service availability based on whether a correct response is received, service availability is determined in a concrete and verifiable manner, improving the accuracy of the determination results.

[0052] It should be noted that after receiving a fault trigger signal, the switchover control subsystem performs a service availability determination operation on the second Redis cluster. The switchover control subsystem directly sends read / write commands to the second Redis cluster (e.g., sending a "SET check_key 1" command followed by a "GET check_key" command), and checks whether a correct response is received within a preset timeout period. If a correct response is received within the preset timeout period, the service availability of the second Redis cluster is determined to be available, indicating that the cluster has normal data read / write service capabilities and can take over business traffic. If no correct response is received within the preset timeout period (including situations such as inability to establish a connection, connection timeout, or receiving an error response), the service availability of the second Redis cluster is determined to be unavailable, indicating that the cluster is currently unable to provide normal service.

[0053] By using the above method, the switching control subsystem first confirms the service availability status of the second Redis cluster before executing the agent configuration modification, thereby ensuring the validity of the switching target and avoiding switching business traffic to a cluster that is also unable to provide services.

[0054] For example, consider the order service of an e-commerce platform. The platform deploys Redis clusters in data center A (data center 1) and data center B (data center 2), and provides a unified Redis access point for the order service through proxy nodes. The availability detection subsystem continuously performs multi-dimensional health checks on the Redis cluster in data center A at 1-second intervals. When the Redis cluster in data center A terminates abnormally due to hardware failure, and the availability detection subsystem detects three consecutive failures (process not alive, port unreachable, read / write command execution failed), reaching a preset fault judgment threshold, the availability detection subsystem determines that the Redis cluster in data center A has experienced a process interruption fault, generates a fault trigger signal, and sends it to the switchover control subsystem. Upon receiving the fault trigger signal, the switchover control subsystem sends read / write commands to the Redis cluster in data center B. If the Redis cluster in data center B returns a correct response within the preset timeout period, the switchover control subsystem determines that the Redis cluster service in data center B is available and continues with the subsequent proxy configuration modification steps. If the Redis cluster in data center B also fails to respond normally (e.g., data center B experiences a network failure), the switchover control subsystem determines that the Redis cluster service in data center B is unavailable, terminates the switchover process, and triggers corresponding alarm handling. By determining service availability before the switchover, the effectiveness of the switchover operation is ensured, avoiding meaningless switching to an unavailable cluster.

[0055] Step 202: If the service availability of the second Redis cluster is available, modify the backend service address configuration of the proxy node to switch the backend service from the first Redis cluster to the second Redis cluster.

[0056] The modification of the backend service address configuration is transparent to the business system, which continues to access the Redis service through the proxy node.

[0057] In this embodiment, after determining that the service availability of the second Redis cluster is available, the switching control subsystem modifies the backend service address configuration of the proxy node. The backend service address configuration of the proxy node refers to the node address information recorded in the proxy node's configuration file, used to specify the target Redis cluster for forwarding business traffic. This typically includes the Internet Protocol (IP) address and port number of each node in the Redis cluster. In the initial deployment state, the backend service address configuration of the proxy node points to the addresses of each node in the first Redis cluster. The switching control subsystem modifies the proxy node's configuration file, replacing the recorded backend service addresses from the node addresses of the first Redis cluster to the node addresses of the second Redis cluster, thereby switching business traffic from the first Redis cluster to the second Redis cluster. The business system does not need to modify its own Redis connection configuration and still accesses the Redis service through the original access address of the proxy node; the switching process is transparent to the business system.

[0058] In one embodiment, after modifying the backend service address configuration of the proxy node, if the proxy node supports dynamic loading, the modified backend service address configuration can be applied dynamically; if the proxy node does not support dynamic loading, the proxy node can be restarted to apply the modified backend service address configuration. Therefore, by using either dynamic loading or restarting depending on whether the proxy node supports dynamic loading to apply the configuration changes, it adapts to proxy nodes with different characteristics, ensuring that the switching operation can be completed promptly.

[0059] It's important to note that after modifying the proxy node configuration file, the changes need to take effect during actual operation. Different proxy node products support different methods for configuration activation: some proxy nodes (such as Predixy proxy) support dynamic loading, meaning that without interrupting existing service connections, they can dynamically load and apply the modified configuration file, making backend service address changes effective immediately without restarting the proxy node process; other proxy nodes do not support dynamic loading, requiring a restart of the proxy node process to reload the configuration file for the changes to take effect.

[0060] For proxy nodes that support dynamic loading, after the switching control subsystem completes the configuration file modification, it triggers the proxy node to reread the configuration file and update its backend service address through the dynamic loading interface provided by the proxy node (e.g., sending a specific configuration reload command to the management port of the proxy node). The configuration modification takes effect immediately, and existing business connections are not affected.

[0061] For proxy nodes that do not support dynamic loading, the switchover control subsystem automatically performs a proxy node restart operation after modifying the configuration file. Specifically, the switchover control subsystem first terminates the currently running proxy node process (e.g., by executing the `kill` command), and then calls the proxy node's built-in startup command to restart the proxy node process (e.g., by executing the command `src / predixy conf / predixy.conf`). When the proxy node starts, it reads the modified configuration file to make the new backend service address configuration take effect. The restart operation is usually controlled within 1 second to minimize service interruption time during the switchover process.

[0062] By flexibly selecting the configuration activation method based on the characteristics of the proxy node, the configuration changes are made effective in a timely manner while minimizing the impact on the business system.

[0063] In one embodiment, before modifying the backend service address configuration of the proxy node, the current configuration file of the proxy node can be backed up to obtain a backup configuration file. Correspondingly, after switching the backend service from the first Redis cluster to the second Redis cluster, the service availability of the second Redis cluster can be determined through the proxy node. Then, if the service availability of the second Redis cluster is determined to be unavailable through the proxy node, the backend service address configuration of the proxy node can be restored using the backup configuration file. Therefore, by backing up the configuration before modification and restoring it using the backup configuration when service availability is determined to be unavailable after the switch, a rapid rollback to the original configuration can be achieved in the event of a switch failure, reducing the risks associated with the switch operation.

[0064] It should be noted that, to ensure the security of the switchover operation, the switchover control subsystem backs up the current configuration file of the proxy node before executing configuration modifications. Specifically, the switchover control subsystem uses the operating system's copy command to copy the current configuration file of the proxy node as a backup configuration file, which is then stored in a preset backup path. This backup configuration file fully preserves the backend service address configuration information before the modification, that is, the node address pointing to the first Redis cluster.

[0065] After the configuration changes are completed and taken effect, the switchover control subsystem re-determines the service availability of the second Redis cluster through the proxy node. This determination differs from the determination in step 201: in step 201, the switchover control subsystem directly sends read and write commands to the second Redis cluster to confirm its service status; however, here the determination is performed by the switchover control subsystem sending read and write commands to the second Redis cluster through the proxy node to verify whether the entire business link from the proxy node to the second Redis cluster has been successfully established, i.e., confirming whether the configuration changes have been correctly taken effect and whether business traffic can access the second Redis cluster normally through the proxy node.

[0066] Furthermore, if the proxy node determines that the service availability of the second Redis cluster is available, the switchover is successful, and the business system can now access the second Redis cluster normally through the proxy node. If the proxy node determines that the service availability of the second Redis cluster is unavailable, it indicates that the business link failed to be established normally after the switchover. Possible reasons include incorrect configuration file modifications, changes in the state of the second Redis cluster during the switchover execution, or abnormal configuration loading on the proxy node. In this case, the switchover control subsystem restores the backend service address configuration of the proxy node using a pre-backed-up backup configuration file. Specifically, the switchover control subsystem overwrites the backup configuration file path on the proxy node's configuration file and, based on the characteristics of the proxy node, makes the restored configuration effective through dynamic loading or restart, thereby reverting the backend service to the first Redis cluster.

[0067] The aforementioned backup and rollback mechanisms ensure the recoverability of the switching operation in abnormal situations and reduce the risks associated with the switching operation.

[0068] In one embodiment, the switching control subsystem can also use service query commands provided by the proxy node to detect the information of the backend Redis services currently being proxied by the proxy node, in order to verify whether the configuration changes have actually taken effect. For example, when the proxy node uses the Predixy proxy framework, the switching control subsystem can send the "info servers" command to the proxy node to obtain a list of backend Redis services currently connected to the proxy node. If the returned service list contains the node IP address and port information of the second Redis cluster, it indicates that the backend service address of the proxy node has been successfully switched to the second Redis cluster.

[0069] For example, let's continue with the order service of the aforementioned e-commerce platform. After the Redis cluster in data center A (the first data center) fails, the switchover control subsystem determines in step 201 that the Redis cluster service in data center B (the second data center) is available, and then executes the configuration modification operation in step 202. The switchover control subsystem first backs up the proxy node configuration file " / etc / predixy / predixy.conf" to a preset path by executing the operating system copy command, obtaining the backup configuration file. Subsequently, the switchover control subsystem reads this configuration file, changes the backend Redis node address from the node address in data center A (192.168.2.10-15:6379) to the node address in data center B (192.168.3.10-15:6379), and saves the modified configuration file. Since the proxy node uses the Predixy proxy framework and has enabled dynamic loading, the switching control subsystem sends configuration reload commands to the proxy node, so that the modified configuration file takes effect immediately without restarting the proxy node process. The entire configuration modification and activation process takes only seconds.

[0070] Furthermore, after the configuration takes effect, the switchover control subsystem sends read and write commands to the Redis cluster in data center B through the proxy node to determine service availability. For example, the switchover control subsystem sends a "GET check_key" command through the proxy node. If a correct response is received within the preset timeout period, the switchover is confirmed to be successful, and the order service can now access the Redis cluster in data center B normally through the proxy node. If a correct response is not received, the switchover control subsystem restores the backend service address configuration of the proxy node using the backup configuration file, rolls back the backend service to the Redis cluster node address in data center A, and triggers the corresponding alarm processing.

[0071] In one embodiment, after step 202, a handover result notification can be sent to a preset notification recipient based on the handover result. The handover result notification includes at least one of the following: faulty data center identifier, handover result, and handover time. Therefore, by automatically sending a notification containing information such as the faulty data center, handover result, and handover time to a preset notification recipient after the handover is completed, maintenance personnel can promptly grasp the system status, reducing manual monitoring costs.

[0072] It should be noted that after completing the agent configuration modification operation, the handover control subsystem generates a handover result notification based on the actual handover result, regardless of whether the handover is successful or not, and sends this notification to the preset notification recipients. The preset notification recipients refer to pre-configured maintenance terminals or instant messaging accounts used to receive handover-related notifications, such as the list of maintenance personnel accounts corresponding to the instant messaging application interface. The handover control subsystem integrates a notification module, which establishes a communication connection with the preset notification recipients through an Application Programming Interface (API).

[0073] The switchover result notification should include at least the faulty data center identifier (i.e., information about the first data center where the fault occurred), the switchover result (e.g., switchover successful or switchover failed), and the switchover time (the total time from receiving the fault trigger signal to completing the configuration modification and confirming the switchover result). In the case of a successful switchover, the notification should also include the identifier of the second Redis cluster currently providing services and the current Redis service status. In the case of a failed switchover, the notification should also include troubleshooting suggestions, such as prompting operations personnel to check the running status of the second Redis cluster and whether the proxy node configuration file permissions and paths are correct.

[0074] By automatically sending a switchover result notification after the switchover is completed, operations and maintenance personnel can promptly obtain the switchover result and current service status without continuously monitoring the system status, which significantly reduces the cost of manual on-call and supports operations and maintenance personnel to quickly carry out troubleshooting and recovery work when switchover anomalies occur.

[0075] In one embodiment, upon receiving a fault trigger signal, if the service availability of the second Redis cluster is determined to be unavailable, the switchover process is terminated, and a dual-datacenter fault alarm notification is sent to a pre-defined notification recipient. Thus, by terminating the switchover and sending an alarm notification when the backup cluster is determined to be unavailable, invalid switchover operations are avoided when both datacenters are unavailable, and relevant personnel are promptly informed of the emergency situation.

[0076] It should be noted that when the switchover control subsystem determines in step 201 that the service availability of the second Redis cluster is unavailable, it indicates that the first Redis cluster has failed, and the second Redis cluster is also currently unable to provide Redis services normally. At this point, continuing the switchover operation is meaningless, as the switched-backend cluster will still be unable to respond to access requests from the business system. In this situation, the switchover control subsystem terminates the switchover process, that is, it no longer executes the step of modifying the backend service address configuration of the proxy node, and sends a dual-datacenter failure alarm notification to the preset notification recipients through the built-in notification module.

[0077] The dual-datacenter fault alarm notification is used to inform operations and maintenance personnel that both the first and second Redis clusters are unavailable, and the business system can no longer access the Redis service normally, requiring immediate manual troubleshooting and recovery. This alarm notification includes the fault type and time of the first Redis cluster, a description of the unavailability status of the second Redis cluster, and suggested troubleshooting directions (e.g., checking network connectivity between the two datacenters, checking the process status of the second Redis cluster, checking the running status of the data synchronization components, etc.).

[0078] The above-mentioned dual-data center fault handling mechanism avoids the need to perform invalid switchover operations when both data centers are unavailable, and enables maintenance personnel to be informed of emergency situations and intervene in a timely manner.

[0079] In one embodiment, upon receiving a recovery trigger signal from the availability detection subsystem, the service availability of the first Redis cluster can be determined. The recovery trigger signal is sent when the availability detection subsystem determines that the first Redis cluster has recovered and is available. If the service availability of the first Redis cluster is confirmed, the backend service address configuration of the proxy node is modified to switch the backend service from the second Redis cluster back to the first Redis cluster. Thus, by automatically executing the switchback operation upon receiving the recovery trigger signal, the backend service is restored to the original cluster, allowing for the restoration of the original deployment architecture without manual intervention after fault repair, achieving a fully automated closed-loop process.

[0080] It should be noted that after the failure of the first Redis cluster is repaired (e.g., the operations and maintenance personnel restart all processes of the first Redis cluster and complete data synchronization through the data synchronization component), the availability detection subsystem continues to perform multi-dimensional health probes on the first Redis cluster according to the preset probe interval. When the availability detection subsystem confirms that the service availability of the first Redis cluster has returned to normal after multiple consecutive probes (e.g., three consecutive successful probes), it determines that the first Redis cluster has recovered and is available, generates a recovery trigger signal, and sends the recovery trigger signal to the switchover control subsystem. The recovery trigger signal includes at least the cluster identifier that has been recovered, the recovery time, and the current service status information.

[0081] Upon receiving the recovery trigger signal, the switchover control subsystem performs a determination operation similar to step 201, sending read and write commands to the first Redis cluster to determine its service availability. If a correct response is received within a preset timeout period, the service availability of the first Redis cluster is determined to be available; if no correct response is received, the service availability of the first Redis cluster is determined to be unavailable, the switchback operation is temporarily suspended, and the system continues to wait for the next recovery trigger signal.

[0082] Furthermore, after confirming the service availability of the first Redis cluster, the switchover control subsystem modifies the backend service address configuration of the proxy node, switching the backend service from the second Redis cluster back to the first Redis cluster. The specific execution method of this rollback operation is the same as the switchover operation: the switchover control subsystem reads the proxy node configuration file, changes the backend service address from the node address of the second Redis cluster back to the node address of the first Redis cluster, saves the configuration file, and then applies the configuration through dynamic loading or process restart, depending on the characteristics of the proxy node. After the rollback is complete, the business system reverts to its original deployment architecture of accessing the first Redis cluster through the proxy node.

[0083] In one embodiment, the rollback operation supports two strategies: automatic rollback and manual triggering rollback, which can be pre-configured in the switchover control subsystem. Under the automatic rollback strategy, the switchover control subsystem automatically executes the rollback operation after determining that the first Redis cluster service is available. Under the manual triggering rollback strategy, after determining that the first Redis cluster service is available, the switchover control subsystem first sends a rollback suggestion notification to a preset notification recipient. The operations and maintenance personnel then manually confirm this notification through the interface provided by the switchover control subsystem before executing the rollback operation. Through this rollback mechanism, the system can automatically or semi-automatically restore to the original deployment architecture after fault repair, forming a fully automated closed loop of "probe-switch-notification-rollback".

[0084] In one embodiment, before switching the backend service from the second Redis cluster back to the first Redis cluster, the data synchronization status between the first and second Redis clusters can be obtained. Then, if the data synchronization status indicates that the data is consistent, the operation of switching the backend service from the second Redis cluster back to the first Redis cluster is performed. Therefore, by obtaining the data synchronization status between the two data centers before the switchback and performing the switchback after confirming data consistency, business data anomalies or loss due to data inconsistency during the switchback process can be avoided.

[0085] It should be noted that before the rollback operation is executed, the switchover control subsystem first obtains the data synchronization status between the first and second Redis clusters to confirm whether the data on both sides is consistent. If some of the data written to the first Redis cluster during the failure has not yet been synchronized back from the second Redis cluster, a direct rollback may cause the data in the first Redis cluster to lag behind the data that the business system has already written to the second Redis cluster, resulting in data inconsistency or data loss.

[0086] Specifically, the switching control subsystem sends a query request to the HTTP status port exposed by the data synchronization component to obtain the synchronization status data returned by the component. This synchronization status data is described in JSON format. The switching control subsystem parses the key fields in the synchronization status data: if the "consistent" field in the global status field is true, it indicates that the data in the first Redis cluster and the second Redis cluster are completely consistent; if the "unanswered_entries" field and the "unanswered_bytes" field in the write-end status field are both 0, it indicates that all data to be synchronized has been written to the target end, and there is no data residue.

[0087] Specifically, if the data synchronization status indicates that the data is consistent, the switchover control subsystem will perform a rollback operation, switching the backend service from the second Redis cluster back to the first Redis cluster. If the data synchronization status indicates that the data is not yet consistent (e.g., the "consistent" field value is false, or the "unanswered_entries" field value is greater than 0), the switchover control subsystem will not perform the rollback temporarily. It will wait for the data synchronization to complete and then check the synchronization status again, or send a notification indicating that the data synchronization is not complete to the preset notification recipient. The operations and maintenance personnel will then determine whether to force the rollback or wait for the data synchronization to complete.

[0088] By introducing a data consistency verification mechanism before the rollback, data anomalies or data loss caused by the rollback operation are effectively avoided, ensuring the consistency and integrity of business data after the rollback.

[0089] For example, let's continue with the order service of the aforementioned e-commerce platform. After the Redis cluster in data center A was repaired, the operations and maintenance personnel restarted all Redis processes in data center A and performed data completion synchronization through the data synchronization component (redis-shake). The availability detection subsystem successfully detected the Redis cluster in data center A three times consecutively, determining that it had recovered and become available. It then generated a recovery trigger signal and sent it to the switchover control subsystem. After receiving the signal, the switchover control subsystem sent read and write commands to the Redis cluster in data center A to confirm that its service availability was available. Subsequently, the switchover control subsystem sent a query request to the HTTP status port of the data synchronization component to obtain the synchronization status data. After parsing, it confirmed that the "consistent" field value was true and the "unanswered_entries" field value was 0, indicating that the data was completely consistent. The switchover control subsystem then modifies the proxy node configuration file, changing the backend service address from the Redis cluster node address in data center B (192.168.3.10-15:6379) back to the Redis cluster node address in data center A (192.168.2.10-15:6379), and dynamically loads the configuration to make it effective. After the switchback is complete, the switchover control subsystem sends a switchback result notification to the operations and maintenance personnel through the notification module, informing them that the Redis cluster in data center A has returned to normal, the backend service has been switched back to data center A, and the current Redis service is normal.

[0090] The Redis cluster switching method disclosed in the above embodiments of this application first determines the service availability of the second Redis cluster upon receiving a fault trigger signal from the availability detection subsystem. The fault trigger signal is generated and sent by the availability detection subsystem upon determining that the first Redis cluster is faulty. Then, if the service availability of the second Redis cluster is available, the backend service address configuration of the proxy node is modified to switch the backend service from the first Redis cluster to the second Redis cluster. The modification of the backend service address configuration is transparent to the business system, which continues to access the Redis service through the proxy node. Therefore, by determining the service availability of the backup cluster before the switchover, and only performing configuration modifications after confirmation of availability, the effectiveness of the switchover is ensured, avoiding prolonged business interruption due to switching to an unavailable cluster. Simultaneously, automated modification of the proxy configuration is achieved without manual intervention, significantly shortening the switchover time and improving the availability of the Redis service.

[0091] See Figure 3 The diagram shows a structural schematic of a Redis cluster switching device provided in an embodiment of this application. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0092] The failover mechanism for a Redis cluster can specifically include the following modules: The availability determination module 301 is used to determine the service availability of the second Redis cluster upon receiving a fault trigger signal sent by the availability detection subsystem. The fault trigger signal is generated and sent by the availability detection subsystem upon determining that the first Redis cluster is faulty.

[0093] The switching control module 302 is used to modify the backend service address configuration of the proxy node when the service availability of the second Redis cluster is available, so as to switch the backend service from the first Redis cluster to the second Redis cluster. The modification of the backend service address configuration is transparent to the business system, and the business system continues to access the Redis service through the proxy node.

[0094] The Redis cluster switching device disclosed in the above embodiments of this application first determines the service availability of the second Redis cluster upon receiving a fault trigger signal from the availability detection subsystem. The fault trigger signal is generated and sent by the availability detection subsystem when the first Redis cluster is determined to be faulty. Then, if the service availability of the second Redis cluster is available, the backend service address configuration of the proxy node is modified to switch the backend service from the first Redis cluster to the second Redis cluster. The modification of the backend service address configuration is transparent to the business system, which continues to access the Redis service through the proxy node. Therefore, by determining the service availability of the backup cluster before the switchover, and only performing configuration modifications after confirmation of availability, the effectiveness of the switchover is ensured, avoiding prolonged business interruption due to switching to an unavailable cluster. Simultaneously, automated modification of the proxy configuration is achieved without manual intervention, significantly shortening the switchover time and improving the availability of the Redis service.

[0095] Furthermore, in one possible implementation of this application embodiment, the above-mentioned fault trigger signal is generated and sent by the availability detection subsystem in the following manner: performing multi-dimensional health detection on the first Redis cluster, wherein the multi-dimensional health detection includes at least one of process liveness detection, port connectivity detection, read / write availability detection and data synchronization status detection; if the number of consecutive failures of health detection in any dimension reaches a preset threshold, the first Redis cluster is determined to be faulty, a fault trigger signal is generated and sent.

[0096] Therefore, by combining multidimensional health detection with a continuous failure threshold mechanism to generate fault trigger signals, the accuracy of fault determination is improved and the possibility of misjudgment or missed judgment is reduced.

[0097] Furthermore, in another possible implementation of this application embodiment, the availability determination module 301 may specifically include the following units: The first sending unit is used to send read and write commands to the second Redis cluster.

[0098] The first determining unit is used to determine the service availability of the second Redis cluster as available if a correct response to a read / write command is received within a preset timeout period.

[0099] The second determining unit is used to determine that the service availability of the second Redis cluster is unavailable if no correct response to the read / write command is received within a preset timeout period.

[0100] Therefore, by sending read and write commands to the backup cluster and determining whether a correct response is received, the availability of services can be determined in a concrete and verifiable way, thereby improving the accuracy of the determination results.

[0101] Furthermore, in another possible implementation of this application embodiment, the switching device for the Redis cluster may further include the following modules: The loading processing module is used to dynamically load the modified backend service address configuration of the proxy node after modification, if the proxy node supports dynamic loading, to make the modified backend service address configuration take effect; if the proxy node does not support dynamic loading, it restarts the proxy node to make the modified backend service address configuration take effect.

[0102] Therefore, by using dynamic loading or restarting depending on whether the proxy node supports dynamic loading, the configuration changes can be made effective, thus adapting to proxy nodes with different characteristics and ensuring that the switching operation can be completed in a timely manner.

[0103] Furthermore, in another possible implementation of this application embodiment, the switching device for the Redis cluster may further include the following modules: The backup processing module is used to back up the current configuration file of the proxy node before modifying the backend service address configuration of the proxy node, and obtain the backup configuration file. The configuration recovery module is used to determine the service availability of the second Redis cluster through the proxy node after modifying the backend service address configuration of the proxy node to switch the backend service from the first Redis cluster to the second Redis cluster; if the proxy node determines that the service availability of the second Redis cluster is unavailable, it restores the backend service address configuration of the proxy node using the backup configuration file.

[0104] Therefore, by backing up the configuration before modification and restoring it using the backup configuration when the service availability is determined to be unavailable after the switch, the system can quickly revert to the original configuration in case of a switch failure, reducing the risks associated with the switch operation.

[0105] Furthermore, in another possible implementation of this application embodiment, the aforementioned Redis cluster switching device may further include the following modules: The result notification module is used to send a switch result notification to a preset notification recipient after the backend service address configuration of the proxy node is modified to switch the backend service from the first Redis cluster to the second Redis cluster. The switch result notification includes at least one of the following: faulty data center identifier, switch result, and switch time.

[0106] Therefore, by automatically sending a notification containing information such as the faulty data center, the switching result, and the time taken to the preset notification recipient after the switch is completed, the operation and maintenance personnel can keep abreast of the system status and reduce the cost of manual on-call.

[0107] Furthermore, in another possible implementation of this application embodiment, the switching device for the Redis cluster may further include the following modules: The fault alarm module is used to terminate the switchover process and send a dual-datacenter fault alarm notification to the preset notification recipients if it determines that the service availability of the second Redis cluster is unavailable after receiving a fault trigger signal.

[0108] Therefore, by terminating the switchover and sending an alarm notification when the backup cluster is determined to be unavailable, invalid switchover operations can be avoided when both data centers are unavailable, and relevant personnel can be informed of the emergency situation in a timely manner.

[0109] Furthermore, in another possible implementation of this application embodiment, the switching device for the Redis cluster may further include the following modules: The automatic failback module is used to determine the service availability of the first Redis cluster upon receiving a recovery trigger signal from the availability detection subsystem. The recovery trigger signal is sent when the availability detection subsystem determines that the first Redis cluster has recovered and is available. If the service availability of the first Redis cluster is available, the module modifies the backend service address configuration of the proxy node to switch the backend service from the second Redis cluster back to the first Redis cluster.

[0110] Therefore, by automatically executing a switchback operation after receiving a recovery trigger signal, the backend services are restored to the original cluster, thus restoring the original deployment architecture without manual intervention after the fault is repaired, achieving a fully automated closed loop.

[0111] Furthermore, in another possible implementation of this application embodiment, the aforementioned Redis cluster switching device may further include the following modules: The data verification module is used to obtain the data synchronization status between the first and second Redis clusters before switching the backend service from the second Redis cluster back to the first Redis cluster; if the data synchronization status indicates that the data is consistent, the module will perform the operation of switching the backend service from the second Redis cluster back to the first Redis cluster.

[0112] Therefore, by obtaining the data synchronization status between the two data centers before the rollback and performing the rollback after confirming that the data is consistent, business data abnormalities or loss due to data inconsistency can be avoided during the rollback process.

[0113] The Redis cluster switching device provided in this application embodiment can be applied in the foregoing method embodiments. For details, please refer to the description of the above method embodiments, which will not be repeated here.

[0114] Figure 4 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 4 As shown, the electronic device 400 of this embodiment includes: at least one processor 410 ( Figure 4 The diagram shows only one processor, a memory 420, and a computer program 421 stored in the memory 420 and executable on the at least one processor 410. When the processor 410 executes the computer program 421, it implements the steps in the above-described Redis cluster switching method embodiment.

[0115] The electronic device 400 can be a desktop computer, laptop, handheld computer, cloud server, or other computing device. This electronic device may include, but is not limited to, a processor 410 and a memory 420. Those skilled in the art will understand that... Figure 4 This is merely an example of electronic device 400 and does not constitute a limitation on electronic device 400. It may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, it may also include input / output devices, network access devices, etc.

[0116] The processor 410 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0117] In some embodiments, the memory 420 may be an internal storage unit of the electronic device 400, such as a hard disk or memory of the electronic device 400. In other embodiments, the memory 420 may be an external storage device of the electronic device 400, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 400. Furthermore, the memory 420 may include both internal and external storage units of the electronic device 400. The memory 420 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 420 can also be used to temporarily store data that has been output or will be output.

[0118] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0119] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0120] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0121] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0122] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0123] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0124] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0125] The implementation of all or part of the processes in the methods of the above embodiments can also be accomplished by a computer program product. When the computer program product is run on an electronic device, the electronic device can implement the steps in the various method embodiments described above.

[0126] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for switching Redis clusters, characterized in that, A switching control subsystem is applied to a Redis dual-active failover system. The Redis dual-active failover system further includes an availability detection subsystem, a first data center, a second data center, and proxy nodes. The first data center deploys a first Redis cluster, and the second data center deploys a second Redis cluster. The proxy nodes are configured as a unified entry point for business systems to access Redis services, providing access proxies for either the first or second Redis cluster to the business systems, and are initially configured to point backend services to the first Redis cluster. The method includes: Upon receiving a fault trigger signal from the availability detection subsystem, the service availability of the second Redis cluster is determined, wherein the fault trigger signal is generated and sent by the availability detection subsystem upon determining that the first Redis cluster is faulty; If the service availability of the second Redis cluster is available, modify the backend service address configuration of the proxy node to switch the backend service from the first Redis cluster to the second Redis cluster. The modification of the backend service address configuration is transparent to the business system, and the business system continues to access the Redis service through the proxy node.

2. The method according to claim 1, characterized in that, The fault trigger signal is generated and sent by the availability detection subsystem in the following manner: Perform multidimensional health probes on the first Redis cluster, wherein the multidimensional health probes include at least one of process liveness probes, port connectivity probes, read / write availability probes, and data synchronization status probes; If the number of consecutive health probe failures in any dimension reaches a preset threshold, the first Redis cluster is determined to be faulty, and the fault trigger signal is generated and sent.

3. The method according to claim 1, characterized in that, Determining the service availability of the second Redis cluster includes: Send read and write commands to the second Redis cluster; If a correct response to the read / write command is received within the preset timeout period, the service availability of the second Redis cluster is determined to be available. If no correct response to the read / write command is received within the preset timeout period, the service availability of the second Redis cluster is determined to be unavailable.

4. The method according to claim 1, characterized in that, After modifying the backend service address configuration of the proxy node, the method further includes: If the proxy node supports dynamic loading, the modified backend service address configuration will take effect through dynamic loading. If the proxy node does not support dynamic loading, restart the proxy node to make the modified backend service address configuration take effect.

5. The method according to claim 1, characterized in that, Before modifying the backend service address configuration of the proxy node, the method further includes: Back up the current configuration file of the proxy node to obtain the backup configuration file; After modifying the backend service address configuration of the proxy node to switch the backend service from the first Redis cluster to the second Redis cluster, the method further includes: The service availability of the second Redis cluster is determined through the proxy node; If the service availability of the second Redis cluster is determined to be unavailable through the proxy node, the backend service address configuration of the proxy node is restored using the backup configuration file.

6. The method according to claim 1, characterized in that, After modifying the backend service address configuration of the proxy node to switch the backend service from the first Redis cluster to the second Redis cluster, the method further includes: Based on the switching result, a switching result notification is sent to a preset notification recipient, wherein the switching result notification includes at least one of the following: faulty computer room identifier, switching result, and switching time.

7. The method according to claim 1, characterized in that, The method further includes: Upon receiving the fault trigger signal, if it is determined that the service availability of the second Redis cluster is unavailable, the switchover process is terminated, and a dual-datacenter fault alarm notification is sent to the preset notification recipient.

8. The method according to claim 1, characterized in that, The method further includes: Upon receiving a recovery trigger signal from the availability detection subsystem, the service availability of the first Redis cluster is determined, wherein the recovery trigger signal is sent when the availability detection subsystem determines that the first Redis cluster has recovered and is available. If the service availability of the first Redis cluster is available, modify the backend service address configuration of the proxy node to switch the backend service from the second Redis cluster back to the first Redis cluster.

9. The method according to claim 8, characterized in that, Before switching the backend service from the second Redis cluster back to the first Redis cluster, the method further includes: Obtain the data synchronization status between the first Redis cluster and the second Redis cluster; If the data synchronization status indicates that the data is consistent, the operation of switching the backend service from the second Redis cluster back to the first Redis cluster is performed.

10. A switching device for a Redis cluster, characterized in that, A switching control subsystem is applied to a Redis dual-active failover system. The Redis dual-active failover system further includes an availability detection subsystem, a first data center, a second data center, and proxy nodes. The first data center deploys a first Redis cluster, and the second data center deploys a second Redis cluster. The proxy nodes are configured as a unified entry point for business systems to access Redis services, providing access proxies for either the first or second Redis cluster to the business systems, and are initially configured to point backend services to the first Redis cluster. The device includes: The availability determination module is used to determine the service availability of the second Redis cluster upon receiving a fault trigger signal sent by the availability detection subsystem, wherein the fault trigger signal is generated and sent by the availability detection subsystem upon determining that the first Redis cluster is faulty; The switching control module is used to modify the backend service address configuration of the proxy node when the service availability of the second Redis cluster is available, so as to switch the backend service from the first Redis cluster to the second Redis cluster. The modification of the backend service address configuration is transparent to the business system, and the business system continues to access the Redis service through the proxy node.

Images