Message processing system, proxy server deployment method, electronic device, and medium

Abstract

Provided in the present disclosure are a message processing system, a proxy server deployment method, an electronic device, and a medium. The system comprises: a first primary proxy server, which is deployed in a first data center; a first standby proxy server, which is a message replica of the first primary proxy server and is deployed in a second data center, wherein the first data center and the second data center are located in a first service region, and the first primary proxy server and the first standby proxy server belong to a first message service cluster; a second proxy server, which is deployed in a third data center and belongs to a second message service cluster, wherein the third data center is located in a second service area; and a client, which is used for generating and consuming messages on the basis of the first primary proxy server in a normal service mode, generating and consuming messages on the basis of the first standby proxy server in an intra-city disaster recovery mode, and generating and consuming messages on the basis of the second proxy server in a remote disaster recovery mode, so that high flexibility, executability and scalability can be achieved while high availability and high reliability are ensured.

Description

[0001] This disclosure claims priority to Chinese patent application number 202410063204.3, filed with the China Patent Office on January 16, 2024, entitled "Message Processing System, Proxy Server Deployment Method, Electronic Device, and Medium," the entire contents of which are incorporated herein by reference. Technical Field: This disclosure relates to the field of data center technology, and more particularly to a message processing system, a proxy server deployment method, an electronic device, and a storage medium. Background: In recent years, with the continuous improvement of digital infrastructure and the increasing emphasis on data availability and reliability, multi-computer room, multi-region, and multi-data center deployments have increasingly become popular among users. By deploying applications in different regions or computer rooms, users achieve disaster recovery, data redundancy, and data isolation. Therefore, providing highly available message services based on multi-data center deployments is particularly important. SUMMARY: Embodiments of the present disclosure provide a message processing system, a proxy server deployment method, an electronic device, and a storage medium to alleviate or resolve one or more technical issues existing in the prior art. In a first aspect, an embodiment of the present disclosure provides a message processing system, comprising: a first primary proxy server, deployed in a first data center; a first backup proxy server, which is a message replica of the first primary proxy server and is deployed in a second data center, wherein the first data center and the second data center are both located in a first service area, and the first primary proxy server and the first backup proxy server belong to a first message service cluster; a second proxy server, deployed in a third data center and belonging to a second message service cluster, wherein the third data center is located in a second service area; and a client, wherein when the message processing system is in normal service mode, the client produces and consumes messages based on the first primary proxy server; when the message processing system is in intra-city disaster recovery mode, the client produces and consumes messages based on the first backup proxy server; and when the message processing system is in remote disaster recovery mode, the client produces and consumes messages based on the second proxy server.In a second aspect, embodiments of the present disclosure provide a proxy server deployment method, comprising: obtaining a deployment state, wherein the deployment state includes a first deployment state and a second deployment state, wherein the first deployment state indicates that a primary proxy server and a backup proxy server in an active-standby topology are both deployed in a first data center, and the second deployment state indicates that the primary proxy server and the backup proxy server in an active-standby topology are respectively deployed in the first data center and the second data center; in response to a change request for the first deployment state to change to the second deployment state, updating the primary proxy server and the backup proxy server in the first data center to be first primary proxy servers, and running multiple proxy servers in the second data center as first backup proxy servers; wherein the first backup proxy server is a message replica of the first primary proxy server, the first data center and the second data center are both located in a first service area, and the first primary proxy server and the first backup proxy server belong to a first message service cluster; in a normal service mode, a client produces and consumes messages based on the first primary proxy server, and in a same-city disaster recovery mode, the client produces and consumes messages based on the first backup proxy server. In a third aspect, embodiments of the present disclosure provide an electronic device, comprising a memory, a processor, and a computer program stored in the memory, wherein the processor implements the method provided in any embodiment of the present disclosure when executing the computer program. In a fourth aspect, embodiments of the present disclosure provide a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the method provided in any embodiment of the present disclosure. In a fifth aspect, embodiments of the present disclosure provide a computer program product, including a computer program. When executed by a processor, the computer program implements the method provided in any embodiment of the present disclosure. According to the message processing system of the embodiments of the present disclosure, a first message service cluster (Cluster 1) is deployed in two in-city centers, namely a first data center and a second data center. The first data center deploys a primary proxy server to provide normal services, while the second data center deploys a backup proxy server, serving as the in-city disaster recovery center. The third data center, serving as the remote disaster recovery center, deploys a second message service cluster (Cluster 2). This allows the first message service cluster (Cluster 1) to be established first, followed by the gradual deployment of the second message service cluster (Cluster 2). This ensures uninterrupted message services and eliminates the need for pre-planning and layout of all components. This system offers excellent feasibility and scalability in practical implementation.Furthermore, to address the large failure blast radius caused by all components being in the same message service cluster, the off-site disaster recovery center and the dual centers in the same city in the embodiments of the present disclosure are two completely independent message service clusters that do not affect each other, thereby effectively reducing the failure blast radius. The above overview is for illustrative purposes only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features of the present disclosure will become readily apparent by reference to the accompanying drawings and the following detailed description. In the accompanying drawings, unless otherwise specified, identical reference numerals throughout the various figures denote identical or similar components or elements. The figures are not necessarily drawn to scale. It should be understood that these figures depict only some embodiments of the present disclosure and should not be construed as limiting the scope of the present disclosure. Figure 1 illustrates an architectural diagram of a distributed message processing system; Figure 2 illustrates an architectural diagram of another distributed message processing system; Figure 3 illustrates an architectural diagram of a message processing system provided by an embodiment of the present disclosure; Figure 4 illustrates an architectural diagram of another message processing system provided by an embodiment of the present disclosure; Figure 5 illustrates a schematic diagram of state transitions recorded by a replica replication state machine; Figure 6 illustrates a schematic diagram of the operating states of a message queue replication component; Figure 7 illustrates a schematic diagram of remote disaster recovery switching performed by a message processing system according to an embodiment of the present disclosure; Figure 8 illustrates a flow chart of a proxy server deployment method provided by an embodiment of the present disclosure; Figure 9 illustrates a schematic diagram of deployment state changes according to an embodiment of the present disclosure; Figure 10 illustrates an architectural diagram of a deployment system provided by an embodiment of the present disclosure; Figure 11 illustrates an example diagram of a first active-standby topology information table; Figure 12 illustrates an example diagram of a second active-standby topology information table; and Figure 13 illustrates a block diagram of an electronic device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE EMBODIMENTS The following description briefly describes only certain exemplary embodiments. As will be appreciated by those skilled in the art, the described embodiments may be modified in various ways without departing from the spirit or scope of the present disclosure. Therefore, the drawings and description are to be regarded as illustrative in nature and not restrictive. To facilitate understanding of the technical solutions of the embodiments of the present disclosure, the related technologies of the embodiments of the present disclosure are described below. The following related technologies are optional solutions that can be arbitrarily combined with the technical solutions of the embodiments of the present disclosure, and they all fall within the protection scope of the embodiments of the present disclosure.A distributed message processing system is a system that enables asynchronous communication in a distributed environment. It utilizes middleware technology to allow different components of a distributed system or application to exchange information through messages without requiring direct connection or knowledge of each other. This decouples different components and improves the system's scalability, resilience, and maintainability. The following describes the terminology used in the embodiments of this disclosure, using the distributed message processing system shown in Figure 1. Message: A message is a unit of data passed between different components. It can contain text, binary data, or other information formats. Messages are typically used for communication between different components of a distributed system or application. They primarily consist of a combination of data and (optional) attributes that a producer sends to a topic and ultimately delivers to consumers. Topic: A topic is a logical classification or namespace for messages. Messages are published to a specific topic, and receivers (consumers) who subscribe to that topic will receive messages related to the topic. Topics provide a way to organize and filter messages, enabling different components to independently send and receive messages of specific types. Produce Message: Producing a message refers to the process of creating and sending a message. Producer: The producer and sender of messages, also known as a message publisher. Producers publish messages to one or more topics so that other components (consumers) can receive and process them. In a distributed messaging system, producers randomly establish a persistent connection with a name server to obtain routing information for the broker server containing the topic to be published. They then establish a persistent connection with the broker server to publish the message. Message Consumption: Message consumption refers to the process of receiving and processing messages. Consumer: The consumer of messages, used for synchronous or asynchronous message processing. Consumers are the receivers of messages, subscribing to one or more topics and receiving messages from them. In a distributed messaging system, consumers also randomly establish a persistent connection with a name server to obtain routing information for the broker server containing the subscribed topics. They then establish a persistent connection with the broker server. Once a new message is published to the subscribed topic, the consumer receives the message and performs the corresponding action. Source Topic: The topic of the message queue from which the data in a synchronization task originates. Producers publish messages to source topics, and message queues route these messages to other places based on some rules and configurations.Target Topic: The target message queue for data synchronization tasks. Consumers subscribe to target topics to receive messages from source topics. The target topic determines where messages are ultimately delivered. Source Message Queue: The source message queue is the queue to which messages are sent from the source topic. In a distributed messaging system, messages typically first enter a queue and are then routed from there to the corresponding topic. Queues can be used to buffer messages, provide in-order delivery, or serve as an intermediate step in routing. Target Message Queue: The target message queue is the queue to which the messaging system routes messages. Once a message arrives at a target topic, the system may place it in one or more target message queues to await processing by consumers. Name Server: A routing discovery server in a distributed messaging system, providing producers and consumers with routing information about the broker servers where topics reside. Broker Server: Exposes message sending and consuming interfaces. Message producers and consumers interact with it to implement the core message sending and receiving logic. Master Broker: Responsible for providing external message services under normal circumstances. Slave Broker: In a distributed message processing system, a slave broker serves as a replica of the master broker's messages and possesses all of the master broker's data. Recovery Time Objective (RTO): Measured in time, it defines the time required for the information system or service to be restored after a disaster. Recovery Point Objective (RPO): A point in the past to which data can be recovered in the event of a disaster or emergency. It represents the amount of data loss the system can tolerate. Cluster: A group of independent computers connected by a high-speed computer network, forming a group and managed as a single system. Computers or servers in a cluster are typically connected by a high-speed network and share storage, software, and other resources. A cluster can exist within a single data center or span multiple data centers. In a cluster, various computing resources can share workloads, improving overall performance and scalability.Proxy servers are typically deployed in clusters. A proxy server cluster consists of at least one master broker and at least one slave broker. A master and slave broker in a master-slave topology are considered a proxy server group. In a distributed message processing system, the slave broker serves as a replica of the master broker's messages and possesses all of the master broker's data. In recent years, with the continuous improvement of digital infrastructure and the increasing emphasis on data availability and reliability, multi-data center, multi-region, and multi-data center deployments have become increasingly popular. By deploying applications in different regions or data centers, users can achieve disaster recovery, data redundancy, latency reduction, and data isolation. Disaster recovery ensures that if a failure occurs in one region, failover can be performed to another region, reducing recovery time and data loss. Data redundancy ensures that multiple copies of data are distributed across different regions, further ensuring data security. Latency reduction reduces latency by deploying data closer to users. Data isolation capabilities ensure that data between different regions is isolated from each other. For example, some data must be stored in a specific region or encrypted before transmission, while some data can be synchronized to other regions. A two-site, three-center deployment is a common disaster recovery deployment approach with high data availability and reliability. A two-site, three-center deployment typically consists of three data centers, two of which are physically close together and deployed in the same service area, forming a single-city dual-center deployment. The other data center is physically farther away from the other two data centers and deployed in a different service area, serving as a remote disaster recovery center. It should be noted that in the disclosed embodiments, "region" refers to a physical area, i.e., a geographically divided area. For example, different computer rooms (different data centers) are deployed in different regions. "Service area" refers to an area with the same or similar management of infrastructure, such as power systems or network systems, such as within the same city or adjacent cities. If a natural disaster causes a power system or network system failure in a service area, multiple computer rooms (or data centers) within that service area may also experience failures. For example, in a two-site, three-center deployment, dual centers in the same city are two data centers established in the same service area (such as the same city or a neighboring city) that can independently operate key systems. The dual centers have basically equivalent data processing capabilities and synchronize data in real time via high-speed links. Under normal circumstances, they can simultaneously share the operation of services and management systems and can switch operations.An off-site disaster recovery center establishes a backup disaster recovery center in another service area (such as a remote city) to back up data between the two centers. If a failure occurs in either of the two centers due to a natural disaster or other reasons, the off-site disaster recovery center can restore services using the backup data. In one specific implementation, a two-site, three-center architecture can be implemented based on a cluster's internal replica synchronization mechanism. Figure 2 shows the architecture of a two-site, three-center message processing system implemented based on a cluster's internal replica synchronization mechanism. In the message processing system shown in Figure 2, Data Centers 1 and 2 are physically close and serve the same service area. Data Center 3 is in another service area and is physically farther away from the other two centers. Data Center 1 deploys a primary proxy server, which provides external message services under normal circumstances. Data Center 2 deploys a backup proxy server. After a replication state machine transition, the primary proxy server in Data Center 1 and the backup proxy server in Data Center 2 enter a synchronized replication state. If a failure occurs in Data Center 1, the backup proxy server in Data Center 2 is elected as the new primary proxy server to provide message services. Data Center 3, as an off-site disaster recovery center, also deploys a backup proxy server. It is always in an asynchronous replication state as a backup proxy server, that is, it will not enter the state machine to become the primary proxy server and will not participate in the election. This ensures data redundancy and does not affect the delay of application message sending. The above-mentioned two-site three-center architecture based on the cluster internal copy synchronization mechanism has the following disadvantages: (1) Once the two centers in the same city fail at the same time, even if the backup proxy server of the off-site disaster recovery center is promoted to provide services to the primary proxy server through manual intervention, the message replicas synchronized within the cluster are the commit logs of the proxy servers.

[0002] (commitlog), that is, the message log that has been successfully sent by the producer. Once external data flows into data center 3, the commit logs of the proxy servers of data center 1 and data center 2 will be forked (off-site disaster recovery is asynchronous replication, and its own RPO>0). Moreover, due to the strict consistency requirements of the commit log data, it is almost impossible to complete the data re-recording after the failure recovery; (2) Since the three data centers are all in the same cluster, the actual construction process basically needs to be completed in one step. However, in the actual construction process, many construction processes are expanded according to the actual disaster recovery needs. The system is expanded from a single computer room to two computer rooms, and finally to two locations and three centers, rather than in one step;

[0003] (3) Since the components of the three data centers are all in the same cluster, any problem with a component in any data center will expand the explosion radius of the failure; (4) Due to the internal replica synchronization mechanism of the cluster, all data will be fully replicated, and selective replication (such as selecting topics that need disaster recovery for replication) cannot be performed. Therefore, if the bandwidth is limited or the inflow traffic is large, the gap in asynchronous replication is relatively large, and the RPO of the remote disaster recovery center (data center 3) and the dual centers in the same city (data center 1 and data center 2) will also be larger. Figure 3 shows the architecture diagram of the message processing system provided by the embodiment of the present disclosure. As shown in Figure 3, the message processing system includes: a first primary proxy server 311, a first backup proxy server 312, a second proxy server 320 and a client 303. Among them, the first primary proxy server 311 and the first backup proxy server 312 belong to the first message service cluster.

[0004] (Cluster 1) o There can be multiple first primary proxy servers 311 and first backup proxy servers 312. The first primary proxy servers and first backup proxy servers in a master-slave topology are in the same proxy server group. Within the same proxy server group, the first backup proxy server 312 is a message replica of the first primary proxy server 311, receiving data synchronized from the first primary proxy server 311 and thus having the same data as the first primary proxy server 311. The first primary proxy server 311 is deployed in the first data center (Region 1), and the first backup proxy server 312 is deployed in the second data center (Region 2). Both the first and second data centers are located in the first service region. The second proxy server 320 is deployed in the third data center (Region 3) and belongs to the second message service cluster (Cluster 2). The third data center is located in the second service region. For example, the first service region can be the same city or a neighboring city, so that the first data center

[0005] The first data center (Region 1) and the second data center (Region 2) have the same service infrastructure (such as power facilities or network facilities). The second service area is located in a different place from the first service area, so the second service area and the first service area have different service infrastructure (such as power facilities or network facilities). In other words, the first data center

[0006] The physical distance between Region 1 and the second data center (Region 2) is relatively close, while the physical distance between Region 3 and both the first and second data centers is relatively far. Therefore, if a failure occurs in the first service region, the probability of failure in the second service region is relatively low. That is, failures in the first and second service regions typically do not occur simultaneously. Client 303 can be either a producer or a consumer. Producers produce messages by interacting with proxy servers (first primary proxy server 311, first backup proxy server 312, or second proxy server 320), while consumers consume messages by interacting with proxy servers. Specifically, when the message processing system is in normal service mode, client 303 produces and consumes messages based on first primary proxy server 311. When the message processing system is in intra-city disaster recovery mode, client 303 produces and consumes messages based on first backup proxy server 312. When the message processing system is in remote disaster recovery mode, client 303 produces and consumes messages based on second proxy server 320. In normal service mode, the first data center is operating normally and has not experienced any failures. In intra-city disaster recovery mode, the first data center experiences a failure, while the second data center does not. In remote disaster recovery mode, both the first and second data centers experience failures. For example, the message processing system of this embodiment of the present disclosure further includes: at least one first name server 301, deployed in a first message service cluster (Cluster 1); and at least one second name server 302, deployed in a second message service cluster (Cluster 2). In normal service mode, a producer (client 303) randomly establishes a persistent connection with a first name server 301, obtains routing information for the first primary proxy server 311 containing the topic to be published, and then establishes a persistent connection with the server to publish the message, thereby producing the message. A consumer (client 303) also randomly establishes a persistent connection with a first name server 301, obtains routing information for the first primary proxy server 311 containing the topic to be subscribed to, and then establishes a persistent connection with the server. Once a new message is published to the subscribed topic, the consumer receives the message and performs corresponding operations.In the same-city disaster recovery mode, the producer (client 303) obtains the routing information of the first backup proxy server 312, where the topic of the message to be published is located, from the first name server 301, and then produces the message from the first backup proxy server 312. The consumer (client 303) obtains the routing information of the first backup proxy server 312, where the topic to be subscribed is located, from the first name server 301, and then consumes the message from the first backup proxy server 312. In the remote disaster recovery mode, the producer or consumer (client 303) obtains the routing information of the second proxy server 320 from the first name server 301, and then produces or consumes the message from the second proxy server 320. Compared to the two-site, three-center message processing system based on the cluster internal replica synchronization mechanism shown in Figure 2, which has the disadvantage of requiring advance planning and layout of components for deployment within the same cluster and is not scalable, in the message processing system of the embodiment of the present disclosure, the two centers in the same city are the first data center and the second data center, where the first message service cluster (Cluster 1) is deployed, and the remote disaster recovery center is the third data center, where the second message service cluster (Cluster 2) is deployed. The first message service cluster (Cluster 1) can be built first, and then the second message service cluster can be implemented.

[0007] The progressive deployment of Cluster 2 ensures uninterrupted intermediate message services and eliminates the need for pre-planning and layout of all components. This provides excellent scalability and feasibility in actual implementation. Furthermore, to address the large failure radius associated with all components being in the same message service cluster, the remote disaster recovery center and the dual centers in the same city are two completely independent message service clusters that do not affect each other, effectively reducing the failure radius. In one embodiment, as shown in Figure 4 , the second proxy server 320 includes a second primary proxy server 321 and a second backup proxy server 322 that serves as a message replica of the second primary proxy server 321. When the message processing system is in remote disaster recovery mode, the client 303 produces and consumes messages based on the second primary proxy server 321 or the second backup proxy server 321. In other words, during the deployment of the second message service cluster, data from the first message service cluster can be replicated, and the primary and backup topology relationships within the second message service cluster can be synchronized. This allows for rapid deployment without interrupting the services of the first message service cluster, resulting in improved feasibility and scalability. The following details the implementation of the same-city disaster recovery model. Within the same message service cluster, data consistency between the primary and backup proxy servers can be achieved through the message service cluster's internal replica synchronization mechanism (also known as the message replica replication mechanism) to achieve high availability. In one embodiment, as shown in Figure 4 , the first, second, and third data centers are each deployed with a state switch control component (Controller). Each state switch control component (Controller) controls the switching of message replica replication states for proxy servers within the first or second message service cluster based on a majority consensus protocol among multiple state switch control components. The state switch control component (Controller), also known as the master election component, can initiate multiple replica replication state machines. Each replica replication state machine corresponds to a group of proxy servers (e.g., the first primary proxy server 311 and the first backup proxy server 312 in a primary-backup topology, or the second primary proxy server 321 and the second backup proxy server 322 in a primary-backup topology), controlling the state switching of message replication between the two proxy servers in the group.Within the first message service cluster, after the replication state machine transitions, the first primary proxy server 311 and the first backup proxy server 312 ultimately enter the synchronous replication state. Within the second message service cluster, after the replication state machine transitions, the second primary proxy server 321 and the second backup proxy server 322 ultimately enter the synchronous replication state. The message processing system of this disclosed embodiment fully utilizes the close proximity of the dual centers (the first data center and the second data center) within the same city. Disaster recovery within the same city can be achieved through the internal replica synchronization mechanism within the message service cluster. High-availability disaster recovery failover is achieved through replica state machine transitions, achieving an RPO of 0 and ensuring high reliability and low latency for the dual centers within the same city. Figure 5 illustrates the state transitions of a primary proxy server (shown as Master in Figure 5) and a backup proxy server (shown as Slave in Figure 5) within a group of proxy servers, as recorded by a replication state machine. When the first proxy server (shown as a broker in Figure 5) starts up, the proxy server group switches from its initial state to a single-master state, with the newly started broker acting as the master. When the second broker starts up, the proxy server group switches from a single-master state to an asynchronous replication state, with the second broker acting as a slave and initiating asynchronous replication of master-slave data with the master. While asynchronous replication is in progress, the proxy server group switches to a semi-synchronous state. When the slave point (the slave's message synchronization point) catches up with the master, the proxy server group switches to a synchronous replication state. If the master fails during this period, the system issues an alarm, prompting operations personnel to address the issue. As can be seen, the metadata or state transitions of each proxy server group do not affect each other. Therefore, the metadata and state transitions of the first message service cluster (Cluster 1) and the second message service cluster (Cluster 2) do not affect each other, thus enabling data management to be isolated by message service cluster. In disaster recovery scenarios, the Controller determines whether a proxy server is the primary or backup by computing the replica state machine and relying on a majority consensus protocol. Raft, a consensus algorithm widely used in engineering, is a strongly consistent, decentralized, and highly available distributed protocol. It can be used for leader election, specifically, selecting the primary proxy server that provides external message services. Specifically, when the replica state machine controls message replication state transitions between a group of proxy servers, each state transition requires a majority consensus protocol. This means that each state transition must meet the majority consensus of multiple replica state machines.Because the first, second, and third data centers are all deployed with controllers—two in the same city (first service region) and one in a different location (second service region)—even if any data center fails, the other two can still reach a majority consensus and complete a primary / backup switchover without manual intervention. The RTO (Reserve Time) is the election time plus the route discovery time, which can be less than one minute. Consequently, if any data center (either the first or second data center) in the same city (first service region) fails, it can immediately enter disaster recovery mode, achieving an RPO of 0. The replica state machine also ensures that if the first primary proxy server 311 in the first data center fails, the first backup proxy server 312 in the second data center, serving as the same-city disaster recovery center, can be elected as the primary proxy server, entering the same-city disaster recovery mode. Client 303 can then produce and consume messages based on the first backup proxy server 312. The following details the implementation of the remote disaster recovery mode. In one embodiment, as shown in FIG4 , the message processing system of the disclosed embodiment further includes a message queue replication component (MQ Replicator) 304 for configuring a first replication link for message replication from a first message service cluster to a second message service cluster. Specifically, based on the first replication link configured by the message queue replication component 304, asynchronous message replication can be implemented between dual centers in the same city (the first data center and the second data center) and a remote disaster recovery center (the third data center), enabling real-time data backup of the cluster (the first message service cluster Cluster 1) in the dual centers in the same city to the cluster (the second message service cluster Cluster 2) in the remote disaster recovery center. For example, as shown in FIG6 , the message queue replication component 304 consumes messages from a target topic from the first message service cluster (Cluster 1) based on the first replication link and sends messages from the target topic to the second message service cluster (Cluster 2). For example, the target topic can be determined based on the topic level according to actual disaster recovery requirements. The message queue replication component 304 can then establish a synchronization link (the first replication link) that consumes messages from the source topic and sends them to the target topic to achieve data synchronization. In other words, data can be selectively replicated between the remote disaster recovery center and the dual centers in the same city based on topic level, eliminating the need for full replication. This reduces the risk of excessive RPO caused by bandwidth limitations or excessive full data volume. Figure 7 shows a schematic diagram of remote disaster recovery switching in a message processing system according to an embodiment of the present disclosure.As shown in Figure 7, before disaster recovery occurs, the message processing system is in normal service mode. The first message service cluster (Cluster 1) is in the active state, and the second message service cluster (Cluster 2) is in the standby state. Specifically, client 303 produces and consumes messages based on Cluster 1, and all service requests are fulfilled by Cluster 1. Cluster 2 does not provide external message services. Based on the first replication link configured by the message queue replication component 304, data from the dual centers in the same city (the first and second data centers) is backed up (message replication) in real time to a remote disaster recovery center (the third data center). Here, target topics can be selected for data synchronization based on the topic level according to actual disaster recovery requirements. If a disaster occurs in either of the dual centers in the same city, and remote disaster recovery is implemented, the message processing system switches to remote disaster recovery mode. In remote disaster recovery mode, Cluster 1 enters the standby state, Cluster 2 remains in the active state, and the message service logic switches to Cluster 20. Specifically, client 303 produces and consumes messages based on Cluster 2, and all service requests are fulfilled by Cluster 2. As can be seen, the uplink (the consumption link of client 303) can be seamlessly switched. In one embodiment, the message queue replication component 304 synchronizes the message consumption location of Cluster 1 to Cluster 2 according to preset time conditions. For example, the message queue replication component 304 can periodically synchronize the message consumption locations (timestamps) of the dual centers in the same city to the off-site disaster recovery center. When the message processing system switches to off-site disaster recovery mode, the downlink (the production link of client 303) needs to reset the message consumption location after switching to Cluster 2 to minimize message loss. Specifically, client 303 can query the last message consumption location submitted by client 303 before off-site disaster recovery occurred through the application programming interface (API) and continue consuming from this location. When the message processing system switches from normal service mode to remote disaster recovery mode, due to the asynchronous replication feature of message queue replication component 304, the RPO is greater than 00. When the dual centers in the same city recover, the data that has not yet been synchronized to the remote disaster recovery center will continue to be synchronized to the remote disaster recovery center and will also process this data. If breakpoint-resume transmission of this data is not required, the replication task of message queue replication component 304 can be stopped.If Cluster 1 needs to be restored to the Active state at this time, data re-recording can be performed as needed. This re-records the new data generated in Cluster 2 after the disaster recovery occurred. Specifically, in response to the message processing system switching from remote disaster recovery mode to normal service mode, the message queue replication component 304 configures a second replication link for message replication from Cluster 2 to Cluster 1. The starting point of the message replication for the second replication link corresponds to the time when the message processing system switched to remote disaster recovery mode. In other words, the message queue replication component 304 initiates a unidirectional synchronization link (the second replication link) from Cluster 2 to Cluster 1, and the synchronization starts at the time when the disaster recovery occurred. In the message processing system shown in Figure 2, commitlog-level replication makes it difficult to complete data re-recording after a fork-induced switchover. In the technical solution of the present embodiment, topic-level data synchronization is achieved between the remote disaster recovery center and the dual centers in the same city, relying on the message queue replication component 304. This essentially establishes a synchronization link (the first replication link) that consumes messages from the source topic and sends them to the target topic. Therefore, when the dual centers in the same city recover, once the first replication link is re-established, any data that has not yet been synchronized to the remote disaster recovery center due to an RPO greater than 0 will continue to be synchronized to the remote disaster recovery center. Furthermore, data can also be synchronized on demand by establishing a reverse synchronization link (the second replication link), with the synchronization starting at the time of the disaster recovery event. Therefore, the technical solution of the present embodiment can effectively complete data re-recording. The following describes the progressive deployment solution for the message processing system of the present embodiment. This progressive deployment solution expands from a single computer room (single data center) phase to a dual computer room (dual data center) phase, and then to a final state of two locations and three centers. The single-datacenter phase corresponds to the first deployment state of the message processing system, where both the primary and backup proxy servers are deployed in the first data center, in a master-slave topology. The dual-datacenter phase corresponds to the second deployment state, where both the primary and backup proxy servers are deployed in the first and second data centers, respectively, in a master-slave topology. Since name servers are stateless, scaling from the first to the second deployment state is straightforward. Proxy servers are stateful applications that need to transition from a single-datacenter master-slave state (the first deployment state) to two replicas across two data centers (the second deployment state). This means that the primary and backup proxy servers within a group are deployed in each data center, with one each. Therefore, a transition plan is required, which is described in detail below.FIG8 illustrates a flowchart of a proxy server deployment method provided by an embodiment of the present disclosure. As shown in FIG8 , the method includes: Step S801: Obtaining a deployment state, wherein the deployment state includes a first deployment state and a second deployment state, wherein the first deployment state indicates that a primary proxy server and a backup proxy server having an active-standby topology are both deployed in the first data center, and the second deployment state indicates that the primary proxy server and the backup proxy server having an active-standby topology are respectively deployed in the first data center and the second data center; Step S802: In response to a change request for changing the first deployment state to the second deployment state, updating the primary proxy server and the backup proxy server in the first data center to be the first primary proxy server, and running multiple proxy servers in the second data center as first backup proxy servers; wherein the first backup proxy server is a message replica of the first primary proxy server, the first data center and the second data center are both located in a first service area, and the first primary proxy server and the first backup proxy server belong to a first message service cluster; in normal service mode, the client produces and consumes messages based on the first primary proxy server, and in intra-city disaster recovery mode, the client produces and consumes messages based on the first backup proxy server. Taking computer room A as an example of the first data center and computer room B as an example of the second data center, as shown in Figure 9, in the first deployment state, multiple groups of proxy servers are deployed in computer room A. Each group of proxy servers includes a primary proxy server and a backup proxy server, and the two have a primary-backup topology relationship, that is, the backup proxy server can serve as a message replica of the primary proxy server.In the second deployment state, the primary proxy server and the backup proxy server in computer room A both operate as primary proxy servers, that is, they can serve as the first primary proxy server 311, and the proxy server in computer room B operates as the backup proxy server, that is, it can serve as the first backup proxy server 312. Specifically, in response to the change request for changing the first deployment state to the second deployment state, the primary proxy server and the backup proxy server in computer room A are updated to the first primary proxy server 311, and multiple proxy servers are operated in computer room B as the first backup proxy servers 312. In one embodiment, in step S802, updating the primary proxy server and the backup proxy server in the first data center to the first primary proxy server and operating multiple proxy servers in the second data center as the first backup proxy servers includes: deleting a first primary-backup topology information table, wherein the first primary-backup topology information table is used to record identification information and a primary-backup topology relationship of the primary proxy server and the backup proxy server in the first data center in the first deployment state; updating the operating states of the primary proxy server and the backup proxy server in the first data center to the primary proxy server operating state, and operating multiple proxy servers in the second data center as the first backup proxy servers. A second active-standby topology information table is generated. The second active-standby topology information table includes information for recording the identification information of the first active proxy server, the identification information of the first standby proxy server, and the active-standby topology relationship between the first active proxy server and the first standby proxy server. For example, to implement deployment from a single computer room to a dual computer room, that is, to change the first deployment state to the second deployment state, an embodiment of the present disclosure provides a deployment system architecture. As shown in FIG10 , the deployment system includes a control center, a topology relationship storage center, and agents deployed on each proxy server. Each proxy server is deployed with an agent that communicates with the control center and the topology relationship storage center. The computer room transition control center can be implemented using a distributed coordination component to control the progress of deployment state transitions. The agents on the proxy servers monitor the deployment state information from the control center. Once the deployment state changes, such as from the first deployment state to the second deployment state, the active-standby topology relationship transition begins. The topology relationship storage center stores the active-standby topology relationship and can be implemented using a database. Progressive deployment mainly includes three stages: single computer room (SINGLE) state, which is the first deployment state; transition (TRANSITION) state, which is the intermediate stage of transition from the first deployment state to the second deployment state; dual computer room (DUAL) state, which is the second deployment state.In a single data center (SINGLE) state, when the first data center (for example, Data Center A) is established, each proxy server automatically requests unique identification information from the topology storage center upon startup and establishes a primary / backup topology relationship with other proxies. This generates a first primary / backup topology information table, along with corresponding configuration information and metadata for storage as an application metadata table. The server is then brought online, completing the automated deployment of the single data center. Figure 11 shows an example of the first primary / backup topology information table. Upon startup, each proxy server inserts a record into the topology storage center through its proxy. Each record contains the proxy server's identification information (ID) and server information (e.g., IP address). The ID increments with each insertion, and the primary / backup topology relationship is represented by a sequence of IDs. For example, adjacent even-numbered servers are paired together to form an active-standby topology, while adjacent odd-numbered servers are paired together to form an active-standby topology. For each even-numbered server ID, if it is an odd number, the server searches upwards for the first adjacent ID to form an active-standby topology; if it is an even number, the server searches downwards for the first adjacent ID to form an active-standby topology. For each odd-numbered server ID, if it is an odd number, the server searches upwards for the first adjacent ID to form an active-standby topology; if it is an even number, the server searches downwards for the first adjacent ID to form an active-standby topology. As shown in Figure 11, proxy servers with IDs 0 and 2 form an active-standby topology, 1 and 3 form an active-standby topology, 4 and 6 form an active-standby topology, 5 and 7 form an active-standby topology, and so on. In the TRANSITION state, proxy servers (including primary and backup proxy servers) monitor information from the control center indicating that the first deployment state has changed to the second deployment state. Specifically, the primary proxy server inserts its own record (including ID and IP) into the topology relationship table of Computer Room A and downgrades the replica operation mechanism to single-copy operation. Upon completion, the stage information (stage) in its record in the topology relationship table of Computer Room A is set to 1. The backup proxy server will first go offline, clean up stored data, and then re-apply for a new server name. It will also insert its own record (including ID and IP) into the topology relationship table of Computer Room A and enter the primary proxy server operation state. Upon completion, the stage information in its record in the topology relationship table of Computer Room A is set to 1, thereby achieving the automatic deployment of the first primary proxy server, the automatic deletion of the first primary-backup topology information table, and the automatic generation of a subtable (the topology relationship table of Computer Room A) in the second primary-backup topology information table.Furthermore, in the TRANSITION state, multiple proxy servers are run in the second data center (for example, computer room B) as first backup proxy servers, and another subtable (computer room B topology relationship table) in the second primary-backup topology information table is automatically generated. For example, once the TRANSITION state is entered, the first primary-backup topology information table is automatically deleted, and the proxy server in each computer room inserts a record into its own computer room's topology relationship table. Each record has an ID, which increments with each insertion. Finally, proxy servers with the same ID in the topology relationship tables of the two computer rooms form a primary-backup topology relationship, i.e., the same group of proxy servers. Specifically, the proxy server in computer room B inserts its own record (including its ID and IP address) into the computer room B topology relationship table, and establishes a primary-backup topology relationship with the proxy server in computer room A based on the ID. For example, proxy servers with the same ID in the computer room A and computer room B topology relationship tables form a primary-backup topology relationship. The proxy server in computer room B polls until the stage of its paired proxy server (in a master-slave topology relationship) reaches 1. It then goes online. After completion, its stage in the topology table of computer room A is set to 1. The control center then checks whether the topology table of computer room B contains all planned proxy servers and that all have stage 1. If so, the control center sets the current deployment state to DUAL, the second deployment state, thereby automatically generating a second master-slave topology information table and automatically deploying dual centers in the same city. The second master-slave topology information table includes the topology table of the first data center (e.g., computer room A) and the topology table of the second data center (e.g., computer room B), as shown in Figure 12. Furthermore, the method of this embodiment of the present disclosure may also include: running a second proxy server in a third data center, where the third data center is located in the second service area and belongs to the second message service cluster. In remote disaster recovery mode, clients produce and consume messages based on the second proxy server; and replicating messages from the first message service cluster to the second message service cluster based on the message queue replication component. In other words, to move from dual centers (dual computer rooms) in the same city to three centers in two locations, you only need to deploy an additional message service cluster in the off-site disaster recovery center (third data center) and use the message queue replication component to establish a data synchronization link (first replication link) for message replication. This process will not affect the service progress of the dual centers in the same city at all.Furthermore, the deployment and expansion of a Controller cluster can utilize Raft's membership change solution. After the network is established, a single Controller can be expanded to a remote disaster recovery center (third data center), without impacting service processes. According to the deployment solution of the disclosed embodiment, a gradual transition from a single computer room (one data center) to a dual computer room (two centers in the same city) is achieved, followed by expansion of the first message service cluster in the two centers (the first and second data centers) to the second message service cluster in the remote disaster recovery center. This progressive deployment ensures uninterrupted service processes and eliminates the need for pre-planned layout and planning of all components. Therefore, this solution offers excellent feasibility and scalability. It should be noted that the disclosed embodiment does not specifically limit the application scenarios of the technical solution. In addition, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant regions, and corresponding operation portals are provided for users to select or edit authorization or rejection. An embodiment of the present disclosure further provides a proxy server deployment device, comprising: a deployment status acquisition module, configured to acquire a deployment status, wherein the deployment status includes a first deployment status and a second deployment status, wherein the first deployment status is that a primary proxy server and a backup proxy server having a primary-backup topology relationship are both deployed in a first data center, and the second deployment status is that the primary proxy server and the backup proxy server having a primary-backup topology relationship are respectively deployed in the first data center and the second data center; an update module, configured to, in response to a change request for changing the first deployment status to the second deployment status, update the primary proxy server and the backup proxy server in the first data center to be first primary proxy servers, and run multiple proxy servers in the second data center as first backup proxy servers; wherein the first backup proxy server is a message replica of the first primary proxy server, the first data center and the second data center are both located in a first service area, and the first primary proxy server and the first backup proxy server belong to a first message service cluster; in a normal service mode, a client produces and consumes messages based on the first primary proxy server, and in a same-city disaster recovery mode, the client produces and consumes messages based on the first backup proxy server.In one embodiment, the update module is specifically configured to: delete a first master-slave topology information table, wherein the first master-slave topology information table is configured to record identification information and a master-slave topology relationship of a primary proxy server and a backup proxy server in the first data center in the first deployment state; update the operational status of the primary proxy server and the backup proxy server in the first data center to the operational status of the primary proxy server; operate multiple proxy servers in the second data center as the first backup proxy servers; and generate a second master-slave topology information table, wherein the second master-slave topology information table includes identification information for recording the first primary proxy server, identification information for the first backup proxy server, and the master-slave topology relationship between the first primary proxy server and the first backup proxy server. In one embodiment, the proxy server deployment apparatus further includes an operation module configured to operate a second proxy server in a third data center, wherein the third data center is located in a second service area, the second proxy server belongs to a second message service cluster, and in remote disaster recovery mode, the client produces and consumes messages based on the second proxy server; and replicate messages from the first message service cluster to the second message service cluster based on a message queue replication component. The functions of each module in each device of the embodiments of the present disclosure can be found in the corresponding descriptions of the above-mentioned methods, and they have corresponding beneficial effects, so they will not be repeated here. Figure 13 is a block diagram of an electronic device used to implement the embodiments of the present disclosure. As shown in Figure 13, the electronic device includes a memory 1301 and a processor 1302. The memory 1301 stores a computer program executable on the processor 1302. When the processor 1302 executes the computer program, the method of the above-mentioned embodiment is implemented. The number of memories 1301 and processors 1302 can be one or more. The electronic device also includes a communication interface 1303 for communicating with external devices and exchanging data. If the memory 1301, processor 1302, and communication interface 1303 are implemented independently, the memory 1301, processor 1302, and communication interface 1303 can be interconnected via a bus to enable communication between them. The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus.This bus can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, Figure 13 shows only one thick line, but this does not mean that there is only one bus or only one type of bus. Optionally, in a specific implementation, if the memory 1301, the processor 1302, and the communication interface 1303 are integrated on a single chip, the memory 1301, the processor 1302, and the communication interface 1303 can communicate with each other through an internal interface. An embodiment of the present disclosure provides a computer-readable storage medium storing a computer program. When executed by a processor, the program implements the method provided in any embodiment of the present disclosure. An embodiment of the present disclosure also provides a chip comprising a processor configured to retrieve and execute instructions stored in a memory, so that a communication device equipped with the chip performs the method provided in any embodiment of the present disclosure. An embodiment of the present disclosure also provides a chip comprising an input interface, an output interface, a processor, and a memory. The input interface, the output interface, the processor, and the memory are connected via an internal connection path. The processor is configured to execute code in the memory. When the code is executed, the processor performs the method provided in any embodiment of the present disclosure. It should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), 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. It is worth noting that the processor may be a processor supporting the Advanced RISC Machines (ARM) architecture. Optionally, the memory may include read-only memory and random access memory, and may also include non-volatile random access memory. The memory may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), and synchronous dynamic random access memory.

[0008] Synchronous DRAM (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDR SDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), Sync Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The above embodiments can be implemented in whole or in part via software, hardware, firmware, or any combination thereof. When implemented using software, they can be implemented in whole or in part in the form of a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, they fully or partially produce the processes or functions according to the present disclosure. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. The present disclosure also provides a computer program product including a computer program that, when executed by a processor, implements the method provided in any embodiment of the present disclosure. Throughout this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples" indicate that a specific feature, structure, material, or characteristic described in conjunction with that embodiment or example is included in at least one embodiment or example of the present disclosure. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate different embodiments or examples, as well as features from different embodiments or examples, as long as they are not mutually inconsistent. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features being referred to. Therefore, features specified as "first" or "second" may explicitly or implicitly include at least one of those features. Throughout this disclosure, "multiple" means two or more, unless otherwise specifically defined. Any process or method description in the flowchart or otherwise described herein may be understood to represent a module, segment, or portion of code that includes one or more executable instructions for implementing the specified logical function or process steps.Furthermore, the scope of the preferred embodiments of the present disclosure includes alternative implementations in which functions may be performed out of the order shown or discussed, including performing functions substantially simultaneously or in reverse order depending on the functions involved. The logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing the logical functions and can be embodied in any computer-readable medium for use by an instruction execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device), or in conjunction with such an instruction execution system, apparatus, or device. It should be understood that various aspects of the present disclosure may be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods may be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the above-described method embodiments may be performed by a program that instructs the relevant hardware. The program may be stored in a computer-readable storage medium. When executed, the program includes one or a combination of the steps of the method embodiments. Furthermore, the functional units in the various embodiments of the present disclosure may be integrated into a single processing module, each unit may exist physically separately, or two or more units may be integrated into a single module. These integrated modules may be implemented in either hardware or software functional modules. If these integrated modules are implemented as software functional modules and sold or used as standalone products, they may also be stored in a computer-readable storage medium. This storage medium may be a read-only memory, a magnetic disk, or an optical disk. The foregoing description is merely a specific embodiment of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Any person skilled in the art will readily conceive of various variations and substitutions within the technical scope of this disclosure, and such variations and substitutions are intended to be encompassed by the scope of protection of this disclosure. Therefore, the scope of protection of the present disclosure shall be subject to the scope of protection of the claims.

Claims

Claims 1. A message processing system, comprising: A first main proxy server is deployed in a first data center; a first backup proxy server, which is a message copy of the first main proxy server and is deployed in a second data center, wherein the first data center and the second data center are both located in a first service area, and the first main proxy server and the first backup proxy server belong to a first message service cluster; a second proxy server, which is deployed in a third data center and belongs to a second message service cluster, wherein the third data center is located in a second service area; a client, when the message processing system is in a normal service mode, the client produces and consumes messages based on the first main proxy server; when the message processing system is in a same-city disaster recovery mode, the client produces and consumes messages based on the first backup proxy server; when the message processing system is in a remote disaster recovery mode, the client produces and consumes messages based on the second proxy server.

2. The message processing system according to claim 1, wherein The second proxy server includes a second primary proxy server and a second backup proxy server as a message copy of the second primary proxy server. When the message processing system is in the remote disaster recovery mode, the client produces and consumes messages based on the second primary proxy server or the second backup proxy server.

3. The message processing system according to claim 1 or 2, wherein The first data center, the second data center, and the third data center are all deployed with a state switching control component, and the state switching control component controls the switching of the message copy replication state of the proxy server in the first message service cluster or the second message service cluster based on the majority consensus protocol among the multiple state switching control components.

4. The message processing system according to any one of claims 1 to 3, further comprising a message queue replication component, configured to configure a first replication link for performing message replication from the first message service cluster to the second message service cluster.

5. The message processing system according to claim 4, wherein The message queue replication component consumes messages of a target topic from the first message service cluster based on the first replication link, and sends messages of the target topic to the second message service cluster.

6. The message processing system according to claim 4, wherein, The message queue replication component synchronizes the message consumption site of the first message service cluster to the second message service cluster according to a preset time condition.

7. The message processing system according to claim 4, wherein, In response to the message processing system switching from the off-site disaster recovery mode to the normal service mode, the message queue replication component configures a second replication link for message replication from the second message service cluster to the first message service cluster, and the starting point of the second replication link for message replication corresponds to the time when the message processing system switches to the off-site disaster recovery mode.

8. A proxy server deployment method, comprising: Get the deployment status, wherein the deployment status includes a first deployment status and a second deployment status, the first deployment status is that the primary proxy server and the backup proxy server having a primary-backup topology relationship are both deployed in the first data The invention relates to a method for providing a message service cluster in which a primary proxy server and a backup proxy server having a primary-backup topology relationship are respectively deployed in the first data center and the second data center in the second deployment state; in response to a change request for changing the first deployment state to the second deployment state, updating the primary proxy server and the backup proxy server in the first data center to be the first primary proxy server, and running a plurality of proxy servers in the second data center as the first backup proxy server; wherein the first backup proxy server is a message copy of the first primary proxy server, the first data center and the second data center are both located in a first service area, and the first primary proxy server and the first backup proxy server belong to a first message service cluster; in a normal service mode, a client produces and consumes messages based on the first primary proxy server, and in a same-city disaster recovery mode, the client produces and consumes messages based on the first backup proxy server.

9. The method according to claim 8, wherein Updating the primary proxy server and the standby proxy server in the first data center to be the first primary proxy server, and running multiple proxy servers in the second data center as the first standby proxy servers, including: deleting a first primary-standby topology information table, wherein the first primary-standby topology information table is used to record the identification information and the primary-standby topology relationship of the primary proxy server and the standby proxy server in the first data center under the first deployment state; updating the running state of the primary proxy server and the standby proxy server in the first data center to be the running state of the primary proxy server, running multiple proxy servers in the second data center as the first standby proxy server, and generating a second primary-standby topology information table, wherein the second primary-standby topology information table includes information for recording the identification information of the first primary proxy server, the identification information of the first standby proxy server, and the primary-standby topology relationship between the first primary proxy server and the first standby proxy server.

10. The method according to claim 8 or 9 further comprises: A second proxy server is run in a third data center, wherein the third data center is located in a second service area, the second proxy server belongs to a second message service cluster, and in a remote disaster recovery mode, the client produces and consumes messages based on the second proxy server; based on a message queue replication component, messages are replicated from the first message service cluster to the second message service cluster.

11. An electronic device, comprising a memory, a processor and a computer program stored in the memory, wherein the processor implements the method according to any one of claims 8 to 10 when executing the computer program.

12. A computer-readable storage medium storing a computer program, where the computer program, when executed by a processor, implements the method according to any one of claims 8 to 10.

13. A computer program product including a computer program, where the computer program, when executed by a processor, implements the method according to any one of claims 8 to 10.

Images