Method, device and equipment for generating high-availability cache architecture and readable storage medium

Abstract

The invention relates to a high-availability cache architecture generation method and device, equipment and a readable storage medium. The method comprises the steps that first configuration information corresponding to a Redis cluster is created in a container arrangement platform; based on the first configuration information, controlling a container group used for operating each Redis instance in the at least two Redis instances to be started in sequence; determining a starting state of the container group; based on the starting state of the container group, controlling a sentry module to configure a Redis instance operated by the first container group as a master node, and obtaining master-slave configuration information of a Redis cluster to generate a high-availability cache architecture; wherein the first container group is used for operating the first started container group in the at least two Redis instances, and the slave nodes are Redis instances operated by other container groups. According to the method and the device, the master node is automatically set according to the starting sequence of the container group running the Redis instance, so that the setting of the master node and the slave node is automatically completed, and the configuration usability and the deployment convenience of the high-availability cache architecture can be improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method, apparatus, device, and readable storage medium for generating a high-availability cache architecture. Background Technology

[0002] In related technologies, high-availability caching architectures offer high performance and are widely used in production environments. For example, a high-availability caching architecture may include Redis, an open-source, in-memory data structure storage system commonly used as a database, cache, and message broker. If a single point of failure occurs in Redis, the entire high-availability caching architecture system will malfunction, significantly impacting its availability.

[0003] To avoid this single point of failure, a slave node needs to be assigned to each Redis instance, forming a master-slave configuration. When the master node fails, a manual switchover to a slave node is required. However, this approach leads to system service interruption. Therefore, the Sentinel mode is commonly used to solve the automatic failover between master and slave nodes. Sentinel mode refers to deploying a Sentinel instance on top of the master-slave configuration, enabling automatic failover between master and slave nodes. However, Sentinel mode requires more complex configuration. For example, it needs to handle communication between the Redis instance and the Sentinel instance, and the Sentinel instance needs to specify the current master node address and establish a connection accordingly. These operations require manual configuration, and the configuration process involves significant modifications to the existing system, posing a high risk. This results in poor configuration usability and deployment convenience for high-availability caching architectures. Summary of the Invention

[0004] To address the aforementioned technical problems, this disclosure provides a method, apparatus, device, and readable storage medium for generating a high-availability cache architecture, thereby resolving the issues of poor configuration ease of use and poor deployment convenience of high-availability cache architectures in related technologies.

[0005] In a first aspect, embodiments of this disclosure provide a method for generating a highly available cache architecture based on a container orchestration platform. The highly available cache architecture includes a sentinel module, a proxy module, and a Redis cluster, wherein the Redis cluster includes at least two Redis instances. The method includes: Create the first configuration information for the Redis cluster in the container orchestration platform; the first configuration information includes the configuration parameters for running the Redis cluster, the startup script for the Redis instance, the StatefulSet resource for creating at least two Redis instances, and the headless service resource for the Redis instance; Based on the first configuration information, control the container group used to run each of the at least two Redis instances to start sequentially; Determine the startup status of the container group; The Sentinel module, which controls the startup status of container groups, configures the Redis instance running in the first container group as the master node, thereby obtaining the master-slave configuration information of the Redis cluster to generate a highly available caching architecture. The master-slave configuration information is used to indicate at least one of the master and slave nodes included in the Redis cluster. The first container group is the first container group to start up and complete in the container group used to run at least two Redis instances. The slave nodes are the Redis instances running in container groups other than the first container group.

[0006] Secondly, embodiments of this disclosure provide a device for generating a high-availability caching architecture based on a container orchestration platform. The high-availability caching architecture includes a sentinel module, a proxy module, and a Redis cluster. The Redis cluster includes at least two Redis instances. The generation device includes: The module is used to create the first configuration information corresponding to the Redis cluster in the container orchestration platform. The first configuration information includes the configuration parameters for running the Redis cluster, the startup script of the Redis instance, the StatefulSet resource of the stateful application controller for creating at least two Redis instances, and the headless service resource corresponding to the Redis instance. The control module is used to control the container group for running at least two Redis instances to start sequentially, based on the first configuration information; The determination module is used to determine the startup status of the container group; The generation module is used to control the Sentinel module to configure the Redis instance running in the first container group as the master node based on the startup status of the container group, so as to obtain the master-slave configuration information of the Redis cluster and generate a high-availability caching architecture. The master-slave configuration information is used to indicate at least one of the master nodes and slave nodes included in the Redis cluster. The first container group is the first container group that has been started and completed in the container group used to run at least two Redis instances. The slave nodes are the Redis instances running in the container groups other than the first container group.

[0007] Thirdly, embodiments of this disclosure provide an electronic device, including: Memory; Processor; and Computer programs; The computer program is stored in the memory and configured to be executed by the processor to implement the method as described in the first aspect.

[0008] Fourthly, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the method described in the first aspect.

[0009] Fifthly, embodiments of this disclosure also provide a computer program product, which includes a computer program or instructions that, when executed by a processor, implement the method for generating a high-availability cache architecture based on a container orchestration platform as described above.

[0010] The high-availability caching architecture generation method, apparatus, device, and readable storage medium provided in this disclosure leverage the capabilities of a container orchestration platform, eliminating the need for user interaction with the sentinel module for configuration. The sentinel module automatically sets the master node based on the startup order of the container group running the Redis instance, thus automatically completing the master-slave node setup. Since no manual user intervention is required, this improves the ease of configuration and deployment of the high-availability caching architecture. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0012] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 A schematic diagram illustrating an application scenario provided by an embodiment of this disclosure; Figure 2 A flowchart illustrating a method for generating a highly available caching architecture based on a container orchestration platform, as provided in this embodiment of the disclosure. Figure 3 A flowchart illustrating a method for obtaining master-slave configuration information of a Redis cluster, provided in this embodiment of the disclosure; Figure 4 A flowchart illustrating a method for determining the startup state of the container group provided in this embodiment of the disclosure; Figure 5 A schematic diagram of the structure of a device for generating a high-availability cache architecture based on a container orchestration platform provided in an embodiment of this disclosure; Figure 6 This is a structural connection diagram of an electronic device provided in an embodiment of the present disclosure.

[0014] Figure label: 10 High-Availability Caching Architecture, 12 Sentinel Modules, 14 Proxy Modules, 142 Proxy Units, 16 Redis Clusters, 162 Redis Instances. Detailed Implementation

[0015] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0016] Numerous specific details are set forth in the following description to provide a thorough understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.

[0017] Before describing the embodiments of this disclosure in detail, the technical background involved in this disclosure will be described here so that those skilled in the art can have a clearer understanding of the embodiments of this disclosure.

[0018] Some of the nouns or terms that appear in the description of the embodiments of this disclosure shall be interpreted as follows: Container orchestration platform: An open-source container cluster management system used for the automated deployment, scaling, and management of containerized applications. For example, a container orchestration platform may include, but is not limited to, Kubernetes (K8s). This application embodiment uses K8s as an example for description.

[0019] Pod: A deployable and manageable unit of computation in a container orchestration platform. It encapsulates an application; containers are a lightweight, portable software packaging technology that enables applications and their dependencies to run consistently in virtually any computing environment. For example, Docker containers.

[0020] Redis: An open-source, in-memory data structure storage system commonly used as a database, cache, and message broker.

[0021] Sentinel Module: The Sentinel module can include one or more Sentinel instances. A Sentinel instance is a system for managing and monitoring Redis instances, mainly used to provide automatic fault detection and failover functions for the Redis service.

[0022] Predixy: A high-performance, highly available Redis proxy server designed to provide stronger client access support for Redis.

[0023] IP address: IP is an abbreviation for Internet Protocol, which is the Internet Protocol address.

[0024] Service: A service or service provided.

[0025] Headless Service: A special type of service that does not have a cluster IP address.

[0026] Spring Boot: An open-source Java development framework.

[0027] Lua: A programming language.

[0028] ConfigMap is a configuration mapping tool that stores non-confidential configuration data, enabling the separation of configuration from container images.

[0029] StatefulSet is a stateful replica set that manages stateful applications and provides stable network identification, ordered deployment, and persistent storage.

[0030] Cloud-native: A methodology for building and running applications that fully leverages the advantages of cloud computing. At its core, cloud-native relies on a standardized approach, independent of the infrastructure, to develop, deploy, and manage applications, enabling them to efficiently utilize the elasticity, distributed nature, and automated management capabilities offered by the cloud environment.

[0031] In cloud-native environments, highly available caching architectures are widely used due to their high performance. For example, a highly available caching architecture may include Redis, an open-source, in-memory data structure storage system commonly used as a database, cache, and message broker. If a single point of failure occurs in Redis, the entire highly available caching architecture system will fail, significantly impacting its availability. To avoid such single points of failure, the following high-availability solutions currently exist: 1. Master-Slave Mode. Redis allows specifying one or more slave nodes for a single instance, thus forming a master-slave mode. This mode effectively improves read performance and allows for manual switching to a slave node when the master node fails.

[0032] 2. Sentinel Mode. Based on the master-slave mode, a batch of sentinel instances are deployed to monitor the master and slave instances. If the master node fails, failover can be performed automatically, and tasks can be deployed to the slave nodes.

[0033] 3. Proxy mode. Add a proxy layer before the sentinel mode or cluster mode to shield the complex operations.

[0034] In master-slave mode, when the master Redis node fails, the program configuration needs to be modified to switch from the master node's IP address to the slave node's IP address. This will cause service interruption and affect the overall availability of the system.

[0035] Sentinel mode solves the problem of automatic master-slave failover and improves system availability. However, it requires more complex configuration, handling of communication with Sentinel, and determining the current master node address to establish a connection with the Redis master node. Although Spring Boot provides a wrapper around Sentinel, using Sentinel in Lua requires manual execution of these steps, necessitating significant modifications to the existing system and posing a considerable risk.

[0036] In proxy mode, the proxy mode shields Sentinel's processing, which better meets our needs. However, this architecture is relatively complex, and deployment on physical machines is also complex. It requires the deployment and configuration of Redis, Sentinel, and the proxy. Furthermore, if one physical machine fails, redeployment on that machine is necessary when the device is repaired or replaced. Additionally, if high availability is the primary goal, Redis is typically deployed with only one master and one slave. When one device fails, Redis becomes a single point of failure until it is repaired or replaced, posing a significant risk to the entire system.

[0037] The aforementioned issues result in poor configuration ease of use and deployment convenience for highly available caching architectures.

[0038] In view of this, embodiments of this disclosure provide a method for generating a highly available caching architecture based on a container orchestration platform. Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of the present disclosure. For example, as shown... Figure 1 As shown, the high-availability caching architecture 10 includes a sentinel module 12, a proxy module 14, and a Redis cluster 16. The proxy module 13 includes at least two proxy units 142, and the Redis cluster 16 includes at least two Redis instances 162. For example, the sentinel module 12 may also include multiple sentinel instances.

[0039] like Figure 1 As shown, a dashed box represents a combination of a Redis cluster and a proxy module; a high-availability caching architecture can include multiple such combinations. For ease of identification, Figure 1 They are named using the sequence A, B...Z respectively.

[0040] A proxy module can include multiple proxy units. For ease of identification, Figure 1To distinguish them, add 0 or 1 after the name.

[0041] A Redis cluster can include multiple Redis instances. For ease of identification, Figure 1 Add 0 or 1 after the name to distinguish them.

[0042] A sentinel module can include multiple sentinel instances. For ease of identification, Figure 1 To distinguish them, add 0, 1, or 2 after the name.

[0043] Figure 2 A flowchart illustrating the method for generating a highly available caching architecture based on a container orchestration platform, as provided in this disclosure embodiment, is shown below. Figure 2 As shown, the method includes: S201, Create the first configuration information for the Redis cluster in the container orchestration platform.

[0044] The first configuration information includes configuration parameters for running the Redis cluster, startup scripts for the Redis instance, StatefulSet resources for creating at least two Redis instances, and headless service resources corresponding to the Redis instance.

[0045] In this embodiment of the disclosure, the first configuration information is used to control the startup of the Redis cluster. Exemplarily, the first configuration information includes configuration parameters for running the Redis cluster. In this step, a Redis configuration file (ConfigMap) is created.

[0046] For example, the first configuration information also includes the startup script for the Redis instance. In this step, a ConfigMap for the startup script of the Redis instance is created.

[0047] For example, the first configuration information also includes a StatefulSet resource for a stateful application controller used to create at least two Redis instances. In this step, a StatefulSet instance for creating Redis is created; for example, this StatefulSet has two replicas.

[0048] For example, the first configuration information also includes the headless service resource corresponding to the Redis instance. In this step, a Redis Service of type Headless is created.

[0049] For example, the container orchestration platform is Kubernetes (K8s). K8s has the ability to evict and rebuild Pods. The eviction capability releases resources and removes Pods when a node is under excessive pressure or fails. The rebuild capability is achieved through collaboration between the controller and scheduler, which restarts the application on a healthy node based on the desired state.

[0050] By leveraging Kubernetes' eviction and rebuild capabilities, the system can self-heal and restore the original topology based on the StatefulSet sequence number and Sentinel state when any component fails.

[0051] S202, based on the first configuration information, controls the container group used to run each of the at least two Redis instances to start sequentially.

[0052] In this embodiment of the disclosure, after creating a StatefulSet resource containing at least two Redis instances, the Pods controlling the StatefulSet are started in a predefined order, where each Pod is used to run one Redis instance. In this step, each Redis instance in the Redis cluster is started sequentially.

[0053] S203, Determine the startup status of the container group.

[0054] In this embodiment of the disclosure, the control program cyclically checks whether each container group has started successfully, thereby determining the startup status of each container group.

[0055] For example, the control program breaks out of the loop when it detects that the container group has started successfully.

[0056] For example, if the number of loops checking whether each container group has started successfully exceeds a certain threshold, the control program determines that the container group has failed to start and exits the loop. For example, the number of loops threshold ranges from 50 to 500. For example, the number of loops threshold is 100.

[0057] S204, the Sentinel module, which controls the startup status of the container group, configures the Redis instance running in the first container group as the master node, obtains the master-slave configuration information of the Redis cluster, and generates a highly available caching architecture.

[0058] The master-slave configuration information is used to indicate at least one of the master nodes and slave nodes included in the Redis cluster. The first container group is the first container group to start up and complete in the container group used to run each of the at least two Redis instances. The slave node is the Redis instance running in the container group other than the first container group.

[0059] In this embodiment, a Redis master-slave dynamic election mechanism based on StatefulSet is designed. The startup order of Pods is configured in StatefulSet, for example, Pod-0 is set to start first, and then the container groups are started in the order of Pod-1, Pod-2...Pod-n. The sentinel module is controlled to configure the Redis instance running in the first container group that has just started as the master node in the current Redis cluster, thereby obtaining the master-slave configuration information of the Redis cluster.

[0060] By configuring the startup order of Pods in a StatefulSet, multiple container groups used to host Redis instances in a Redis cluster are started sequentially. The Redis instance running in the first Pod to start is automatically configured as the master node, ensuring that the Redis instances running in subsequent Pods are automatically configured as slave nodes. This achieves fully automated dynamic allocation of master and slave roles without manual intervention, resolving the master-slave allocation timing issue for Redis instances in Kubernetes.

[0061] Optionally, in a Redis cluster, there is 1 master node and 1 or n slave nodes, where n is an integer greater than or equal to 2.

[0062] In some embodiments, the master-slave configuration information of a Redis cluster can at least indicate the master node of the Redis cluster.

[0063] In some embodiments, the master-slave configuration information of a Redis cluster can indicate the master node and at least one slave node of the Redis cluster.

[0064] In some embodiments, the master-slave configuration information of a Redis cluster can indicate the master node and all slave nodes of the Redis cluster.

[0065] Once you have the master-slave configuration information for the Redis cluster, you can generate a highly available caching architecture.

[0066] In this embodiment, by leveraging the capabilities of a container orchestration platform, users do not need to interact with the Sentinel module for configuration. The Sentinel module can automatically set the master node according to the startup order of the container group running the Redis instance, thereby automatically completing the master-slave node setup. No manual user intervention is required during this process, thus improving the ease of configuration and deployment of the high-availability caching architecture.

[0067] In some embodiments of this disclosure, based on Figure 2The technical solution shown, after obtaining the master-slave configuration information of the Redis cluster, can further include the following steps in generating a high-availability caching architecture based on a container orchestration platform: Create the second configuration information corresponding to the agent module in the container orchestration platform.

[0068] The second configuration information includes configuration parameters for running the proxy module, StatefulSet resources for creating the proxy module, and service resources corresponding to the proxy module.

[0069] In this embodiment of the disclosure, the second configuration information, exemplarily, includes configuration parameters for running the agent module. Exemplarily, in this step, a Predixy configuration file, ConfigMap, is created.

[0070] For example, the second configuration information also includes a StatefulSet resource for creating the proxy module. For example, in this step, an instance of Predixy's StatefulSet is created. For example, the number of replicas of the Predixy instance of StatefulSet is 2.

[0071] For example, the second configuration information also includes service resources corresponding to the proxy module. For example, in this step, a Predixy Service is created, and an IP address is obtained for convenient external use.

[0072] After completing the second configuration step of creating the proxy module, the proxy module starts up. At this point, the proxy module can be used to block any processing related to the sentinel module.

[0073] This disclosed embodiment starts the proxy module only after obtaining the master-slave configuration information of the Redis cluster, i.e., after the Redis master-slave topology is ready. Therefore, it ensures that the proxy module can directly obtain the backend address during its initialization process. By relying on Sentinel's real-time topology data, the problem of starting the proxy module with no configuration is solved. This achieves decoupling of the proxy layer and data layer startup, eliminating the need for manual backend address configuration after the proxy module has started. This further improves the deployment convenience of the high-availability caching architecture.

[0074] In some embodiments of this disclosure, based on Figure 2 The technical solution shown, after the Sentinel module for controlling the startup status of the container group configures the Redis instance running in the first container group as the master node, can further include the following steps in generating a high-availability caching architecture based on a container orchestration platform: Based on the first configuration information, control the startup of the second container group used to run the Redis instance; if it is determined that the master-slave configuration information has been obtained, and the master-slave configuration information indicates that the Redis instance running in the first container group is configured as the master node, start the Redis instance running in the second container group as the slave node.

[0075] In this embodiment of the disclosure, multiple container groups used to run Redis instances in the Redis cluster are started sequentially. Specifically, when one container group starts, the Redis instance running in that container group starts.

[0076] When each Redis instance starts, it checks if a master node already exists in the Redis cluster. If no master node exists, it starts as the first Redis instance to start in the cluster and functions as the master. If a master node already exists, it starts as a slave, thus automatically configuring the master and slave nodes in the Redis cluster.

[0077] For example, suppose a Redis cluster includes two container groups for running Redis instances, namely the first container group and the second container group. The first container group starts before the second container group.

[0078] After the first container group starts, the second container group starts sequentially. Since the first container group has already started and its Redis instance is configured as the master node, when the second container group starts, its Redis instance will be able to obtain the master-slave configuration information from the sentinel module. This configuration information will already set the Redis instance from the first container group as the master node. Therefore, the Redis instance from the second container group will automatically start as a slave node.

[0079] This embodiment of the disclosure controls the startup order of multiple Redis instances in a Redis cluster by controlling the startup order of multiple Pods in Kubernetes. By controlling the first Redis instance to start as the master node, and subsequent Redis instances to start as slave nodes, fully automated allocation of master and slave nodes is achieved.

[0080] In some embodiments of this disclosure, based on Figure 2 In the illustrated embodiment, after the Sentinel module, which controls the startup status of the container group, configures the Redis instance running in the first container group as the master node and obtains the master-slave configuration information of the Redis cluster, the method for generating a high-availability caching architecture based on the container orchestration platform may further include the following steps: Based on the master-slave configuration information, update the third configuration information corresponding to the sentinel module.

[0081] The third configuration information is used to run the sentinel module, and the updated third configuration information includes master-slave configuration information.

[0082] This disclosure presents a zero-disruption hot update process for the sentinel module configuration. When generating a high-availability caching architecture, the Redis instance running on the first started Pod is first determined as the master node. Then, after determining the master node, it is dynamically added via commands from the sentinel module. The master-slave configuration information, including the master node's configuration, is then persisted to a third configuration file, and the third configuration file is updated.

[0083] For example, after the master node is determined, the master-slave configuration information, including the master node information, is written into the system's RAM (Random Access Memory). Since RAM is a volatile storage medium, the master-slave configuration information may be lost when the sentinel module experiences a power outage or restart.

[0084] Therefore, after obtaining the master-slave configuration information of the Redis cluster, the system updates its own third configuration information based on this information, thereby writing and solidifying the determined master-slave configuration information into the third configuration information. For example, the control program first dynamically adds the master node using the Sentine command, and then writes it back to the ConfigMap for configuration solidification.

[0085] This embodiment of the disclosure achieves reverse synchronization of master-slave configuration information and third-party configuration information from memory storage to persistent storage by designing a zero-disruption hot update process for sentinel module configuration information. This avoids the problem of configuration information loss due to sentinel module restart. Throughout the process, the sentinel module service does not need to be restarted, ensuring the continuity of the sentinel module's monitoring of the high-availability caching architecture and eliminating service downtime.

[0086] In some embodiments of this disclosure, Figure 3 A flowchart illustrating a method for obtaining master-slave configuration information of a Redis cluster, as provided in an embodiment of this disclosure.

[0087] based on Figure 2 In the embodiment shown, S204, the step of configuring the Redis instance running in the first container group as the master node based on the startup status control sentinel module of the container group to obtain the master-slave configuration information of the Redis cluster can specifically include, as follows: Figure 3 The following steps are shown: S301, configure the Redis instance running in the first container group as the master node, and obtain the address information of the master node.

[0088] The first container group is the first container group to be started. After configuring the Redis instance running in the first container group as the master node, the control program can obtain the address information of the master node. For example, the address information includes the IP address of the master node.

[0089] For example, the control program continuously retrieves the address information of Redis instances. The first Redis instance address retrieved by the control program is the first Redis instance that has completed startup and been configured with an IP address, i.e., the master node.

[0090] S302, the control sentinel module queries the master node for the address information of the slave nodes in the first container group.

[0091] After the first running Redis instance is configured as the master node, all other Redis instances start as slave nodes. Each Redis instance started as a slave node sends its own address information to the master node.

[0092] After identifying the master node, the sentinel module establishes a communication connection with it based on its address information. At this point, the sentinel module can query the address information of each slave node from the master node, thus enabling the configuration of slave nodes in the Redis cluster.

[0093] S303, based on the address information of the master node and the address information of the slave node, obtains the master-slave configuration information of the Redis cluster.

[0094] After obtaining the master node's address information, the master node's address information is written into the Redis cluster's master-slave configuration information. Then, whenever the sentinel module queries a slave node through the master node, it writes the queried slave node's address information into and updates the Redis cluster's master-slave configuration information. This process continues until the address information of all slave nodes has been collected, at which point the master-slave configuration information collection is considered complete.

[0095] For example, suppose a Redis cluster includes one master node and three slave nodes, namely Redis-1, Redis-2, and Redis-3. After the master node is determined, master-slave configuration information is generated based on the master node's address information. After Redis-1 starts as a slave node, the sentinel module queries the address information of Redis-1 through the master node and updates it in the master-slave configuration information.

[0096] Similarly, after Redis-2 and Redis-3 start as slave nodes, the sentinel module queries the address information of Redis-2 and Redis-3 through the master node and updates it in the master-slave configuration information. After writing the address information of Redis-3 into the master-slave configuration information, the master-slave configuration information of the Redis cluster is confirmed.

[0097] This embodiment determines the master-slave configuration information of the Redis cluster by identifying the first Redis instance to be started as the master node and querying the address information of subsequent slave nodes through the master node. No manual intervention is required during this process, enabling fully automated master-slave topology construction.

[0098] In some embodiments of this disclosure, Figure 4 A flowchart illustrating a method for determining the startup state of a container group, provided in an embodiment of this disclosure.

[0099] based on Figure 2 In the embodiment shown, the step of determining the startup state of the container group in S203 may specifically include, as follows: Figure 4 The following steps are shown: S401 polls the Internet Protocol (IP) addresses of the container group to determine the IP address configuration status of the container group.

[0100] In this embodiment of the disclosure, the Internet Protocol address configuration status includes "configured successfully" and "pending configuration". After creating the first configuration information corresponding to the Redis cluster, the control program polls the Internet Protocol address, i.e., the IP address, of each container group corresponding to the Redis cluster to determine whether the Internet Protocol address configuration status of each container group is "configured successfully" or "pending configuration".

[0101] S402, if the Internet Protocol address configuration status of the container group is determined to be successfully configured, the startup status of the container group is determined to be startup completed.

[0102] It's understandable that whenever a container group finishes starting, its internet protocol address is successfully configured. At this point, the container group's internet protocol address configuration status is recognized as successful. Therefore, once a container group's internet protocol address configuration status is determined to be successful, the container group can be considered to have finished starting.

[0103] based on Figure 2 In the illustrated embodiment, this disclosure configures the first Redis instance in a Redis cluster that is successfully configured with an Internet Protocol address as the master node. All other Redis instances in the same Redis cluster will be configured as slave nodes.

[0104] This embodiment of the disclosure achieves fully automated configuration of master and slave nodes by polling the IP addresses of container groups and determining the Redis instance running in the container group with the first successfully configured IP address as the master node. This simplifies the operation steps for deploying a high-availability caching architecture and improves deployment efficiency.

[0105] In some embodiments of this disclosure, based on Figure 1 The application scenarios shown and Figure 2 In the embodiment shown, the high-availability caching architecture based on the container orchestration platform of this disclosure includes multiple Redis clusters and multiple proxy modules, with each proxy module corresponding to one of the multiple Redis clusters. Each proxy module includes at least two proxy units, and each of the at least two proxy units corresponds to at least two Redis instances.

[0106] In this embodiment of the disclosure, the high-availability caching architecture based on the container orchestration platform includes multiple Redis clusters.

[0107] In some implementations, when generating a highly available caching architecture based on a container orchestration platform, the configuration of each of the multiple Redis clusters is completed sequentially. Once all Redis clusters are configured, the highly available caching architecture based on the container orchestration platform is generated.

[0108] In other implementations, multiple Redis clusters are configured in parallel when generating a highly available cache architecture based on a container orchestration platform, thereby improving the generation efficiency of the highly available cache architecture based on the container orchestration platform.

[0109] Each Redis cluster corresponds to a proxy module.

[0110] In some implementations, the number of proxy modules is the same as the number of Redis clusters.

[0111] In some other implementations, the number of proxy modules may be greater than or equal to the number of Redis clusters. The extra proxy modules are configured redundantly.

[0112] Each proxy module includes at least two proxy units. Each of the at least two proxy units in a proxy module corresponds one-to-one with at least two Redis instances in the Redis cluster corresponding to that proxy module.

[0113] For example, assume that proxy module 1 corresponds to Redis cluster 1. Redis cluster 1 includes two Redis instances, Redis-0 and Redis-1. Proxy module 1 includes two proxy units, Predixy-0 and Predixy-1. Predixy-0 corresponds to Redis-0 and is responsible for providing the external IP address of Redis-0. Predixy-1 corresponds to Redis-1 and is responsible for providing the external IP address of Redis-1.

[0114] For example, a sentinel module may include one sentinel instance or multiple sentinel instances. When there are multiple sentinel instances, the multiple sentinel instances perform heartbeats / monitoring with each other.

[0115] For example, when there are multiple Redis clusters, the Sentinel module can perform heartbeat / monitoring on multiple Redis clusters simultaneously.

[0116] The high-availability caching architecture based on a container orchestration platform in this embodiment may include multiple Redis clusters, each corresponding to a proxy module. Each Redis instance in a Redis cluster corresponds to a proxy unit, thus forming a sentinel module-proxy module-Redis cluster architecture. This architecture features high availability, automatically migrating service instances when a single Redis instance fails, reducing the risk of single point of failure. After the failed device recovers, it only needs to be rejoined to the Kubernetes cluster; there is no need to redeploy Redis, thus improving deployment efficiency.

[0117] The following describes the solution provided by the embodiments of this application with reference to a specific example.

[0118] by Figure 1 Taking the application scenario shown as an example, when generating a highly available caching architecture based on a container orchestration platform, the following steps are executed in sequence: Step 1: Create the configuration file ConfigMap for the Redis cluster.

[0119] Step 2: Create the startup script ConfigMap for the Redis instance in the Redis cluster.

[0120] Step 3: Create a StatefulSet resource for the Redis instance in the Redis cluster. For example, this StatefulSet resource indicates that the number of replicas of the Redis instance is 2, that is, two Redis instances are created.

[0121] Step 4: Create a Headless Service resource for the Redis instance.

[0122] Steps 1 to 4 above describe the configuration information for creating a Redis cluster. For detailed information on steps 1 to 4, please refer to the above description.

[0123] Step 5: Wait for the Pod that runs the first Redis instance to be assigned an IP address.

[0124] The purpose of step 5 is to ensure that the Pod running the first Redis instance is assigned an IP address, thereby avoiding errors when adding a master node in the master-slave configuration information for subsequent Sentinel instances.

[0125] Step 6: Connect to a Sentinel instance and execute the command to set the master node in the Redis cluster.

[0126] Step 7: Update the third configuration information of the sentinel instance.

[0127] The purpose of steps 6 and 7 is to ensure that the third configuration information is correct and to avoid losing the configuration after the sentinel instance is unexpectedly restarted.

[0128] Step 8: After correctly setting the master node in this Redis cluster in the Sentinel instance, the startup script of the first Redis instance in the Redis cluster can be executed normally.

[0129] Step 9: After the first Pod running the Redis instance starts, the second Pod running the Redis instance determines that it is not the master node, so it starts as a slave node.

[0130] Step 10: The Sentinel instance queries the address information of other slave nodes in the Redis cluster from the master node in the Redis cluster.

[0131] Steps 8 to 10 above constitute the construction of the master-slave topology in the Redis cluster. For detailed information on steps 8 to 10, please refer to the above description.

[0132] Step 11: Create the ConfigMap for the proxy module.

[0133] Step 12: Create a StatefulSet resource for creating the proxy unit. For example, this StatefulSet resource indicates that the number of replicas for the proxy unit is 2, meaning two proxy units are created. Since the master-slave nodes in the Redis cluster have been correctly configured in the Sentinel instance, the proxy unit will receive the master-slave configuration information upon startup and can normally proxy the corresponding Redis instance, thus avoiding proxy module issues. Lili Although the ad starts up, the Server information is empty when using the info command.

[0134] 13. Create the service resources corresponding to the proxy module.

[0135] Steps 11 to 13 above describe the configuration information for creating the proxy module. For detailed information on steps 11 to 13, please refer to the above description.

[0136] It is understandable that steps 1 to 13 above are all executed in the container orchestration platform.

[0137] This disclosure presents a Redis cluster on Kubernetes. This Redis cluster is not a traditional Redis cluster, but rather a Kubernetes cluster on which multiple Redis clusters can be created as needed for external applications.

[0138] As a container orchestration platform, this disclosure utilizes the containerized management and automatic failover features of Kubernetes to deploy Redis, Sentinel, and Proxy on Kubernetes, thereby improving the overall availability, usability, and deployment convenience of the system.

[0139] Optionally, for the Proxy, Predixy can be used as the proxy unit corresponding to the Redis instance.

[0140] Deploy a master-slave architecture in Kubernetes (K8s) with Redis instances monitored by Sentinel and transparent proxying via Predixy. This architecture deeply integrates K8s' fault healing mechanisms, such as Pod eviction / rebuild mechanisms, while also ensuring the high availability of Redis instances and the elasticity of the underlying infrastructure, thereby achieving end-to-end automated recovery from nodes to services.

[0141] This disclosure also provides a generation apparatus for a high-availability caching architecture based on a container orchestration platform. This apparatus is used to implement the above embodiments and optional implementations, and 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.

[0142] In some embodiments of this disclosure, a device for generating a high-availability cache architecture based on a container orchestration platform is provided. The high-availability cache architecture includes a sentinel module, a proxy module, and a Redis cluster, wherein the Redis cluster includes at least two Redis instances.

[0143] Figure 5 This is a schematic diagram of the structure of the device for generating a high-availability caching architecture based on a container orchestration platform provided in an embodiment of this disclosure, as shown below. Figure 5As shown, the generation device 50 includes: a creation module 51, a control module 52, a determination module 53, and a generation module 54.

[0144] The creation module 51 is used to create the first configuration information corresponding to the Redis cluster in the container orchestration platform. The first configuration information includes configuration parameters for running the Redis cluster, startup scripts for the Redis instance, StatefulSet resources for creating at least two Redis instances, and headless service resources corresponding to the Redis instance.

[0145] The control module 52 is used to control the container group for running at least two Redis instances to start sequentially, based on the first configuration information.

[0146] The determination module 53 is used to determine the startup status of the container group.

[0147] The generation module 54 is used to control the startup status of the container group. The sentinel module configures the Redis instance running in the first container group as the master node, and obtains the master-slave configuration information of the Redis cluster to generate a high-availability cache architecture. The master-slave configuration information is used to indicate at least one of the master node and slave node included in the Redis cluster. The first container group is the first container group to start up and complete in the container group used to run at least two Redis instances. The slave node is the Redis instance running in the container group other than the first container group.

[0148] In this embodiment, by leveraging the capabilities of a container orchestration platform, users do not need to interact with the Sentinel module for configuration. The Sentinel module can automatically set the master node according to the startup order of the container group running the Redis instance, thereby automatically completing the master-slave node setup. No manual user intervention is required during this process, thus improving the ease of configuration and deployment of the high-availability caching architecture.

[0149] Optionally, the creation module 51 is also used to create second configuration information corresponding to the proxy module in the container orchestration platform; wherein, the second configuration information includes configuration parameters for running the proxy module, StatefulSet resources for creating the proxy module, and service resources corresponding to the proxy module.

[0150] Optionally, the control module 52 is further configured to control the startup of a second container group for running Redis instances based on the first configuration information. Additionally, if it is determined that master-slave configuration information has been obtained, and the master-slave configuration information indicates that the Redis instance running in the first container group is configured as the master node, the control module 52 starts the Redis instance running in the second container group as a slave node.

[0151] Optionally, the generation device further includes an update module, which is used to update the master-slave configuration information and the third configuration information corresponding to the sentinel module; wherein the third configuration information is used to run the sentinel module, and the updated third configuration information includes the master-slave configuration information.

[0152] Optionally, the control module 52 is also used to configure the Redis instance running in the first container group as the master node and obtain the address information of the master node.

[0153] The generation device also includes a query module, which controls the sentinel module to query the address information of the slave nodes in the first container group from the master node; The determination module 53 is also used to obtain the master-slave configuration information of the Redis cluster based on the address information of the master node and the address information of the slave node.

[0154] Optionally, the determining module 53 is further configured to poll the Internet Protocol address of the container group to determine the Internet Protocol address configuration status of the container group. And, if the Internet Protocol address configuration status of the container group is determined to be successfully configured, the startup status of the container group is determined to be startup complete.

[0155] Optionally, there may be multiple Redis clusters and multiple proxy modules, with each proxy module corresponding to one of the multiple Redis clusters. Each proxy module includes at least two proxy units, and each of the at least two proxy units corresponds to at least two Redis instances.

[0156] 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.

[0157] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. The electronic device provided in an embodiment of this disclosure can execute the processing flow provided in the request processing method embodiment, such as... Figure 6 As shown, the electronic device 60 includes: a memory 61, a processor 62, a computer program, and a communication interface 63; wherein the computer program is stored in the memory 61 and is configured to be executed by the processor 62 to generate a high-availability cache architecture based on a container orchestration platform as described above.

[0158] In addition, this disclosure also provides a computer-readable storage medium storing a computer program thereon, the computer program being executed by a processor to implement the method for generating a high-availability cache architecture based on a container orchestration platform as described in the above embodiments.

[0159] Furthermore, this disclosure also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, implement the method for generating a high-availability cache architecture based on a container orchestration platform as described above.

[0160] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0161] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for generating a highly available caching architecture based on a container orchestration platform, characterized in that, The high-availability caching architecture includes a sentinel module, a proxy module, and a Redis cluster, wherein the Redis cluster includes at least two Redis instances, and the method includes: In the container orchestration platform, first configuration information corresponding to the Redis cluster is created; wherein, the first configuration information includes configuration parameters for running the Redis cluster, startup script of the Redis instance, StatefulSet resource for creating at least two Redis instances, and headless service resource corresponding to the Redis instance; Based on the first configuration information, the container group used to run each of the at least two Redis instances is started sequentially; Determine the startup status of the container group; Based on the startup status of the container group, the sentinel module is controlled to configure the Redis instance running in the first container group as the master node, thereby obtaining the master-slave configuration information of the Redis cluster to generate the high-availability cache architecture; wherein, the master-slave configuration information is used to indicate at least one of the master node and slave node included in the Redis cluster, the first container group is the first container group to start and complete among the container groups used to run each of the at least two Redis instances, and the slave node is the Redis instance running in the container group other than the first container group.

2. The method according to claim 1, characterized in that, After obtaining the master-slave configuration information of the Redis cluster, the method further includes: In the container orchestration platform, a second configuration information corresponding to the proxy module is created; wherein, the second configuration information includes configuration parameters for running the proxy module, StatefulSet resources for creating the proxy module, and service resources corresponding to the proxy module.

3. The method according to claim 1, characterized in that, After the sentinel module configures the Redis instance running in the first container group as the master node based on the startup status of the container group, the method further includes: Based on the first configuration information, control the startup of the second container group used to run the Redis instance; If the master-slave configuration information is obtained and the master-slave configuration information indicates that the Redis instance running in the first container group is configured as the master node, the Redis instance running in the second container group is started as the slave node.

4. The method according to claim 1, characterized in that, After the sentinel module configures the Redis instance running in the first container group as the master node based on the startup status of the container group, and obtains the master-slave configuration information of the Redis cluster, the method further includes: Based on the master-slave configuration information, the third configuration information corresponding to the sentinel module is updated; wherein, the third configuration information is used to run the sentinel module, and the updated third configuration information includes the master-slave configuration information.

5. The method according to any one of claims 1 to 4, characterized in that, The process of controlling the sentinel module based on the startup status of the container group to configure the Redis instance running in the first container group as the master node, thereby obtaining the master-slave configuration information of the Redis cluster, including: Configure the Redis instance running in the first container group as the master node and obtain the address information of the master node; The sentinel module is controlled to query the address information of the slave nodes in the first container group from the master node; Based on the address information of the master node and the address information of the slave node, the master-slave configuration information of the Redis cluster is obtained.

6. The method according to any one of claims 1 to 4, characterized in that, Determining the startup status of the container group includes: Poll the Internet Protocol (IP) addresses of the container group to determine the IP address configuration status of the container group; If the Internet Protocol address configuration status of the container group is determined to be successfully configured, the startup status of the container group is determined to be startup completed.

7. The method according to any one of claims 1 to 4, characterized in that, There are multiple Redis clusters and multiple proxy modules, with each proxy module corresponding to one of the multiple Redis clusters. The proxy module includes at least two proxy units, each corresponding to one of the at least two Redis instances.

8. A device for generating a highly available caching architecture based on a container orchestration platform, characterized in that, The high-availability caching architecture includes a sentinel module, a proxy module, and a Redis cluster, wherein the Redis cluster includes at least two Redis instances, and the generation device includes: A creation module is used to create first configuration information corresponding to the Redis cluster in the container orchestration platform; wherein, the first configuration information includes configuration parameters for running the Redis cluster, startup script of the Redis instance, StatefulSet resource for creating the at least two Redis instances, and headless service resource corresponding to the Redis instance; The control module is configured to control the container group used to run each of the at least two Redis instances to start sequentially, based on the first configuration information. A determination module is used to determine the startup status of the container group; A generation module is used to control the sentinel module to configure the Redis instance running in the first container group as the master node based on the startup status of the container group, thereby obtaining the master-slave configuration information of the Redis cluster to generate the high-availability cache architecture; wherein, the master-slave configuration information is used to indicate at least one of the master node and slave node included in the Redis cluster, the first container group is the first container group to start and complete startup among the container groups used to run each of the at least two Redis instances, and the slave node is the Redis instance running in the container group other than the first container group.

9. An electronic device, characterized in that, include: Memory; processor; as well as Computer programs; The computer program is stored in the memory and configured to be executed by the processor to implement the method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-7.

Images