Method for realizing disaster recovery of core network equipment by using redis backup method

Abstract

The invention discloses a method for realizing disaster tolerance of core network equipment by using a redis backup method, which relates to the field of communication and the technical field of databases, and comprises the following steps of: S1, cluster deployment: configuring three redis servers and constructing a cluster structure in a core network system deployment stage, one server is designated as a master node, two servers are configured as slave nodes, and master-slave replication and a high-reliability strategy are started; and S2, a connection establishment step: sequentially creating a write thread, a read thread and a subscription thread in a starting stage of the core network equipment. Three asynchronous connection channels of the write thread, the read thread and the subscription thread are constructed in the core network equipment, and a read-write separation and key value change subscription mechanism between the master node and the slave node of the redis cluster is matched; reliable backup of user data in a redis cluster, real-time updating of a local memory of a core network and local and remote disaster recovery after equipment failure are realized.

Description

Technical Field

[0001] This invention relates to the field of database technology, specifically to a method for disaster recovery of core network equipment using Redis backup. Background Technology

[0002] In core network systems, to ensure service continuity and high equipment reliability, a redundant architecture of primary and backup equipment is commonly adopted, with the backup equipment taking over services in the event of a primary equipment failure. User-related data is critical data within core network equipment. Traditionally, the primary equipment continuously synchronizes data to the backup equipment, with the equipment itself ensuring data consistency between the two sides. With the development of distributed database technology, core networks have begun to introduce third-party databases. The database used by the primary network element acts as the master database, and the database used by the backup network element acts as the slave database, achieving data consistency through incremental log synchronization.

[0003] After introducing a third-party database, core network devices need to perform high-frequency data interactions with an independently deployed database cluster, which brings several challenges: First, how can core network devices reliably write massive amounts of user data to the database cluster, ensuring no data loss and that the data can be successfully read by backup devices after the primary device fails? Second, to improve business processing performance, core network devices need to synchronize some frequently used data to local memory, and maintaining real-time consistency between local memory data and database data presents a challenge. Third, the database cluster has a master-slave structure; how can a read-write separation strategy be designed to reduce the pressure on the master node while also incorporating a subscription notification mechanism to ensure that each load-sharing device can promptly receive data changes and update its local memory, thus supporting both local and remote disaster recovery scenarios? To address these issues, a backup and disaster recovery method that deeply integrates with a Redis cluster is needed to improve read-write performance and enhance disaster recovery capabilities while ensuring data consistency. Summary of the Invention

[0004] The purpose of this invention is to provide a method for disaster recovery of core network devices using Redis backup, so as to solve the problems mentioned in the background art.

[0005] To address the aforementioned technical problems, this invention provides the following technical solution: a method for implementing disaster recovery for core network devices using Redis backup, comprising the following steps: S1. Cluster deployment steps: During the core network system deployment phase, configure three Redis servers and build a cluster structure, designate one server as the master node and configure two servers as slave nodes, and enable master-slave replication and high reliability strategies. S2. Connection establishment steps: During the startup phase of the core network device, write threads, read threads, and subscription threads are created sequentially. Write connections, read connections, and subscription connections are established with the master node and slave node respectively through Redis asynchronous connection operations. Authentication processing is completed in the callback function to ensure the connection is safe and reliable. S3. Write synchronization step: During the operation of core network services, the primary device writes the data write operation requests generated by each service thread into the write queue. When the timer is triggered, the write thread retrieves the write command from the write queue and submits it to the Redis master node through the write connection for execution, so as to store the user data in the Redis cluster. S4. Reading and Subscription Steps: During business operation, each business thread writes read requests to the read queue. When the timer is triggered, the read thread retrieves the read command from the read queue, obtains the business request data from the slave node through the read connection, and synchronizes it to the local memory. At the same time, the subscription thread receives key-value change messages through the subscription connection and writes them to the subscription queue. The data synchronization and disaster recovery control module updates the local memory based on the subscription messages. S5. Disaster recovery steps: When a core network device fails and restarts, this device reads backup data in batches from the Redis cluster through a read thread to restore local memory. When the entire set of core network devices fails in a certain location, the remote core network device establishes a connection with the Redis cluster to read the corresponding user data and loads the user data into the local memory of the remote core network device to complete the remote disaster recovery takeover.

[0006] According to the above technical solution, S1 specifically includes: S1-1. During the core network deployment phase, select three servers to deploy Redis instances, add the three instances to the same logical cluster, and configure the internal communication address and port of the cluster so that the three instances can perform state synchronization and fault detection. S1-2. Designate one instance as the master node among the three instances, configure the persistence policy and access authentication parameters for the master node, so that the master node has the ability to receive external write commands and distribute replicated data to slave nodes, and record the connection information of the master node for use by the core network write thread. S1-3. Configure the remaining two instances as slave nodes, set the replication source of the slave nodes as the master node and enable the automatic reconnection policy, so that the slave nodes can automatically resume replication to the master node after network fluctuations or node restarts. When the replication status is abnormal, the cluster health monitoring submodule will report an alarm and trigger manual or automatic failover.

[0007] According to the above technical solution, S2 specifically includes: S2-1. During the startup process, the core network device creates a write thread, initiates a connection request to the master node through the Redis asynchronous connection function, sends an authentication message to the master node in the callback of successful connection establishment, marks the connection as a write connection after successful authentication and adds it to the event loop of the write thread. The write thread is responsible for maintaining the connection and re-initiating the connection in case of an exception. S2-2. The core network device simultaneously creates a read thread and initiates a connection request to at least one slave node through the Redis asynchronous connection function. In the callback of successful connection establishment, an authentication message is sent and the connection is marked as a read connection after successful authentication. All read operations are sent through the read connection, thereby concentrating the read load on the slave node. S2-3. The core network equipment also creates a subscription thread, which initiates a connection request to the master node through the Redis asynchronous connection function. After successful authentication, it sends wildcard subscription commands related to key-value addition and key-value deletion to the master node through the subscription connection, and pushes key space events to the subscription thread. S2-4. While creating write threads, read threads, and subscription threads, the core network device also creates write queues, read queues, and subscription queues, respectively, and configures timers for write threads and read threads. The timers trigger queue data retrieval operations at preset periods, and the subscription thread writes the message to the subscription queue when it receives the subscription message.

[0008] According to the above technical solution, S3 specifically includes: S3-1, When processing user services, the core network service processing module encapsulates structured data related to user sessions, user parameters, and billing information into a write request object, generates corresponding key names and field names according to pre-planned key naming rules, and pushes the write request object into the write queue. S3-2: When the timer is triggered, the write thread retrieves a batch of write requests to be processed from the write queue, converts each write request into a general Redis write command, and uses a hash data type command for multi-field data. The user data is written to the master node's in-memory database by key name and field name, and timeout attributes are configured when necessary. S3-3: After receiving the write result returned by the master node, the write thread checks the write result and records the execution status. When a write failure is found, it re-enqueues or resends the write command according to the preset retry strategy to ensure that the critical user data is eventually written successfully, so as to ensure that all user data generated by the master device during operation is stored in the Redis cluster. S3-4. When the primary core network device undergoes a planned or abnormal restart, the write thread processes the write queue before exiting, prioritizing the sending of uncommitted write requests to the primary node for execution, thus avoiding data loss due to an empty queue.

[0009] According to the above technical solution, S4 specifically includes: S4-1, When the core network service processing module needs to access user data, it encapsulates the read request into a read request object and writes it into the read queue. The read request object carries the target key name and field name information, and indicates whether the read result needs to be written to the local memory cache. S4-2. When the timer is triggered, the read thread retrieves read requests in batches from the read queue, sends the corresponding Redis read command to the slave node through the read connection, receives the data results returned by the slave node, and writes the successfully read user data into the memory structure inside the core network device so that subsequent accesses can directly return results from local memory. S4-3. The subscription thread receives key-value addition and deletion messages pushed by the master node through the subscription connection and writes each message to the subscription queue. The data synchronization and disaster recovery control module reads the message from the subscription queue, parses out the affected key name and field name, and performs the add, update or delete operation in local memory according to the message type to keep the data state in local memory consistent with the Redis cluster. S4-4 When the read thread finds that the data is in the local memory, it can return the result directly from the local memory according to the configuration and selectively initiate background asynchronous verification, thereby reducing the number of accesses to the slave node while ensuring data consistency.

[0010] According to the above technical solution, S5 specifically includes: S5-1. When a single core network device exits and restarts due to a fault, the local disaster recovery submodule will first access the Redis cluster through the read thread after the device starts up. It will then traverse the key space related to the device according to the predefined key naming rules, read user session data and parameter data in batches, and rebuild the corresponding structure in local memory. S5-2. When the entire core network equipment in a certain location cannot be restored due to power failure or hardware failure, after receiving the scheduling instruction, the remote core network equipment establishes a connection with the same Redis cluster through its own write thread, read thread and subscription thread, reads the target user data from the Redis cluster and builds a local memory view in accordance with the steps S3 and S4, and then starts the corresponding signaling processing module and business processing module to continue to provide business services to the original users. S5-3. During local disaster recovery and off-site disaster recovery takeover, the data synchronization and disaster recovery control module performs integrity verification on all data read during the recovery process. If missing data is recorded as abnormal and an alarm is triggered, the operation and maintenance personnel will repair it in conjunction with the backup strategy and the upper-layer business, thereby ensuring the data reliability and business continuity during the disaster recovery process.

[0011] A system for disaster recovery of core network devices using Redis backup methods includes: The Redis cluster deployment module is used to configure three Redis servers outside the core network system to form a cluster and enable master-slave replication and sentinel mode, so that the cluster has high reliability and high availability. The core network and Redis connection management module is used to create write threads, read threads and subscription threads respectively during the startup phase of the core network device, and establish corresponding asynchronous connection channels with the master node and slave node of the Redis cluster, thus separating the write connection, read connection and subscription connection from each other. The data synchronization and disaster recovery control module is used to write user data through write connections during business operations, synchronize frequently used data to the core network local memory through read connections, receive key-value change notifications and drive local memory updates through subscription connections, and perform local recovery and off-site disaster recovery takeover based on Redis backup data when core network equipment fails.

[0012] According to the above technical solution, the Redis cluster deployment module includes: a master node configuration submodule, which is used to specify one of the three Redis servers as the master node and configure the authentication parameters and persistence strategy of the master node, so that the master node assumes the responsibility of writing operation entry and key value change publication. The slave node configuration submodule is used to configure the other two servers as slave nodes and establish a replication relationship with the master node, so that the slave nodes maintain a consistent data view with the master node and provide read services. The cluster health monitoring submodule is used to monitor the connectivity and role status between the three servers, and to trigger alarms and switchover strategies when replication is interrupted or a node is unavailable. The core network and Redis connection management module includes: a write thread management submodule, which is used to create a write thread when the core network device starts up, establish a write connection with the Redis cluster master node through Redis asynchronous connection operation, set a callback function after the asynchronous connection is successfully established to send authentication messages and maintain the liveness of the write connection; The read thread management submodule is used to create read threads, establish read connections with at least one slave node through Redis asynchronous connection operations, complete authentication processing through callback functions, and execute all read operations in the read connection to reduce the pressure on the master node; The subscription thread management submodule is used to create subscription threads, establish subscription connections with the master node through Redis asynchronous connection operations, and send wildcard subscription requests for key-value addition and deletion to the Redis server after successful authentication to obtain key-value change messages. The write queue and timer submodule is used to configure write queues for write threads within the core network device. It enqueues write operation requests from other business threads and periodically retrieves write commands from the write queue using a timer to submit them to the Redis master node for execution. After a write command is successfully executed, it publishes a data change command to Redis so that Redis can publish the data change message to the threads that subscribe to that data.

[0013] The Read Queue and Timer submodule is used to configure the read queue for the read thread, enqueue read operation requests from other business threads, and periodically retrieve read commands from the read queue through the timer and submit them to the Redis slave node for execution. The subscription queue submodule is used to receive key-value change notifications from the subscription connection and write the notification messages into the queue in order. The subscription thread then retrieves the messages in order and distributes them to the data synchronization and disaster recovery control module for processing. The data synchronization and disaster recovery control module includes: a data storage processing submodule, which is used to organize key data related to users into a hash structure or other key-value structure according to the core network business logic and encapsulate it into a Redis command through a write thread to write it to the master node, so as to realize the persistent backup of user data of the master device in the Redis cluster; The data reading and processing submodule is used to read business request data from slave nodes through a read thread according to business access requests. At the same time, the reading results are updated and written to the local memory of the core network device, and data is returned from the local memory first in subsequent accesses to shorten access latency. The subscription message processing submodule is used to parse key-value addition and deletion messages in the subscription queue, determine the affected user data records, and perform addition, update or deletion operations in local memory to keep the local memory data consistent with the Redis cluster data. The local disaster recovery submodule is used to access the Redis cluster through a read thread when the core network device restarts due to a fault. It reads user data related to the device in batches according to predefined key space rules and rebuilds the local memory state, so that the device can be restored to the service level before the fault after restarting. The off-site disaster recovery takeover submodule is used to control the off-site core network equipment to establish a connection with the Redis cluster and read the corresponding user data when the entire set of core network equipment in a certain location becomes unrecoverable. The read data is then loaded into the local memory of the off-site equipment and the session resources are rebuilt, thereby completing the takeover of off-site user services.

[0014] Compared with the prior art, the beneficial effects achieved by the present invention are as follows: The present invention uses a cluster composed of three Redis servers as a unified storage medium for core network user data. The core network device asynchronously writes key data to the Redis cluster master node through the write thread, efficiently reads business request data from the slave node and synchronizes it to local memory through the read thread, and subscribes to key-value increment and decrement messages through the subscription thread to perceive data changes in real time. Thus, under the premise of read-write separation, the load on the master node is significantly reduced and the overall processing performance is improved.

[0015] When the primary core network device fails and restarts, local memory data can be directly restored from the Redis database to complete local disaster recovery. When an entire core network device in one location fails, a remote core network device can access the same Redis cluster to read backup data and take over user services, achieving off-site disaster recovery backup. This method solves the problem of efficient interaction between core network devices and third-party databases, while building a reliable and unified data backup and recovery channel, significantly improving the high availability and high reliability capabilities of the core network system. Attached Figure Description

[0016] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a schematic diagram of the overall modular structure of the present invention; Figure 2 This is a flowchart illustrating the present invention. Detailed Implementation

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

[0018] Please see Figure 1 and Figure 2 This invention provides a technical solution: a method for disaster recovery of core network equipment using Redis backup, comprising the following steps: S1. Cluster deployment steps: During the core network system deployment phase, configure three Redis servers and build a cluster structure, designate one server as the master node and configure two servers as slave nodes, and enable master-slave replication and high reliability strategies. S2. Connection establishment steps: During the startup phase of the core network device, write threads, read threads, and subscription threads are created sequentially. Write connections, read connections, and subscription connections are established with the master node and slave node respectively through Redis asynchronous connection operations. Authentication processing is completed in the callback function to ensure the connection is safe and reliable. S3. Write synchronization step: During the operation of core network services, the primary device writes the data write operation requests generated by each service thread into the write queue. When the timer is triggered, the write thread retrieves the write command from the write queue and submits it to the Redis master node through the write connection for execution, so as to store the user data in the Redis cluster. S4. Reading and Subscription Steps: During business operation, each business thread writes read requests to the read queue. When the timer is triggered, the read thread retrieves the read command from the read queue, obtains frequently used data from the slave node through the read connection, and synchronizes it to the local memory. At the same time, the subscription thread receives key-value change messages through the subscription connection and writes them to the subscription queue. The data synchronization and disaster recovery control module updates the local memory based on the subscription messages. S5. Disaster recovery steps: When a core network device fails and restarts, this device reads backup data in batches from the Redis cluster through a read thread to restore local memory. When the entire set of core network devices fails in a certain location, the remote core network device establishes a connection with the Redis cluster to read the corresponding user data and loads the user data into the local memory of the remote core network device to complete the remote disaster recovery takeover. S1 specifically includes: S1-1. During the core network deployment phase, select three servers to deploy Redis instances, add the three instances to the same logical cluster, and configure the internal communication address and port of the cluster so that the three instances can perform state synchronization and fault detection. S1-2. Designate one instance as the master node among the three instances, configure the persistence policy and access authentication parameters for the master node, so that the master node has the ability to receive external write commands and distribute replicated data to slave nodes, and record the connection information of the master node for use by the core network write thread. S1-3. Configure the remaining two instances as slave nodes, set the replication source of the slave nodes as the master node and enable the automatic reconnection policy, so that the slave nodes can automatically resume replication to the master node after network fluctuations or node restarts. When the replication status is abnormal, the cluster health monitoring submodule will report an alarm and trigger manual or automatic switchover. S2 specifically includes: S2-1. During the startup process, the core network device creates a write thread, initiates a connection request to the master node through the Redis asynchronous connection function, sends an authentication message to the master node in the callback of successful connection establishment, marks the connection as a write connection after successful authentication and adds it to the event loop of the write thread. The write thread is responsible for maintaining the connection and re-initiating the connection in case of an exception. S2-2. The core network device simultaneously creates a read thread and initiates a connection request to at least one slave node through the Redis asynchronous connection function. In the callback of successful connection establishment, an authentication message is sent and the connection is marked as a read connection after successful authentication. All read operations are sent through the read connection, thereby concentrating the read load on the slave node. S2-3. The core network equipment also creates a subscription thread, which initiates a connection request to the master node through the Redis asynchronous connection function. After successful authentication, it sends wildcard subscription commands related to key-value addition and key-value deletion to the master node through the subscription connection, and pushes key space events to the subscription thread. S2-4. While creating write threads, read threads, and subscription threads, the core network device creates write queues, read queues, and subscription queues respectively, and configures timers for write threads and read threads. The timers trigger queue data retrieval operations at preset periods, and the subscription thread writes the message to the subscription queue when it receives the subscription message. S3 specifically includes: S3-1, When processing user services, the core network service processing module encapsulates structured data related to user sessions, user parameters, and billing information into a write request object, generates corresponding key names and field names according to pre-planned key naming rules, and pushes the write request object into the write queue. S3-2: When the timer is triggered, the write thread retrieves a batch of write requests to be processed from the write queue, converts each write request into a general Redis write command, and uses a hash data type command for multi-field data. The user data is written to the master node's in-memory database by key name and field name, and timeout attributes are configured when necessary. S3-3: After receiving the write result returned by the master node, the write thread checks the write result and records the execution status. When a write failure is found, it re-enqueues or resends the write command according to the preset retry strategy to ensure that the critical user data is eventually written successfully, so as to ensure that all user data generated by the master device during operation is stored in the Redis cluster. S3-4. When the primary core network device undergoes a planned or abnormal restart, the write thread processes the write queue before exiting, prioritizing the sending of uncommitted write requests to the primary node for execution, thus avoiding data loss due to an empty queue. S4 specifically includes: S4-1, When the core network service processing module needs to access user data, it encapsulates the read request into a read request object and writes it into the read queue. The read request object carries the target key name and field name information, and indicates whether the read result needs to be written to the local memory cache. S4-2. When the timer is triggered, the read thread retrieves read requests in batches from the read queue, sends the corresponding Redis read command to the slave node through the read connection, receives the data results returned by the slave node, and writes the successfully read user data into the memory structure inside the core network device so that subsequent accesses can directly return results from local memory. S4-3. The subscription thread receives key-value addition and deletion messages pushed by the master node through the subscription connection and writes each message to the subscription queue. The data synchronization and disaster recovery control module reads the message from the subscription queue, parses out the affected key name and field name, and performs the add, update or delete operation in local memory according to the message type to keep the data state in local memory consistent with the Redis cluster. S4-4. When the read thread finds that there is a hit in the local memory, it can return the result directly from the local memory according to the configuration and selectively initiate background asynchronous verification, thereby reducing the number of accesses to the slave node while ensuring data consistency. S5 specifically includes: S5-1. When a single core network device exits and restarts due to a fault, the local disaster recovery submodule will first access the Redis cluster through the read thread after the device starts up. It will then traverse the key space related to the device according to the predefined key naming rules, read user session data and parameter data in batches, and rebuild the corresponding structure in local memory. S5-2. When the entire core network equipment in a certain location cannot be restored due to power failure or hardware failure, after receiving the scheduling instruction, the remote core network equipment establishes a connection with the same Redis cluster through its own write thread, read thread and subscription thread, reads the target user data from the Redis cluster and builds a local memory view in accordance with the steps S3 and S4, and then starts the corresponding signaling processing module and business processing module to continue to provide business services to the original users. S5-3. During local disaster recovery and off-site disaster recovery takeover, the data synchronization and disaster recovery control module performs integrity verification on all data read during the recovery process. For missing data, an anomaly is recorded and an alarm is triggered. The operation and maintenance personnel then repair the data in conjunction with the backup strategy and the upper-layer business, thereby ensuring the data reliability and business continuity during the disaster recovery process. A system for disaster recovery of core network devices using Redis backup methods includes: The Redis cluster deployment module is used to configure three Redis servers outside the core network system to form a cluster and enable master-slave replication mechanism, so that the cluster has high reliability and high availability. The core network and Redis connection management module is used to create write threads, read threads and subscription threads respectively during the startup phase of the core network device, and establish corresponding asynchronous connection channels with the master node and slave node of the Redis cluster, thus separating the write connection, read connection and subscription connection from each other. The data synchronization and disaster recovery control module is used to write user data through write connections during business operations, synchronize frequently used data to the core network local memory through read connections, receive key-value change notifications and drive local memory updates through subscription connections, and perform local recovery and off-site disaster recovery takeover based on Redis backup data when core network equipment fails. The Redis cluster deployment module includes: a master node configuration submodule, which is used to specify one of the three Redis servers as the master node and configure the master node's authentication parameters and persistence strategy, so that the master node is responsible for the entry point of write operations and the publication of key-value changes; The slave node configuration submodule is used to configure the other two servers as slave nodes and establish a replication relationship with the master node, so that the slave nodes maintain a consistent data view with the master node and provide read services. The cluster health monitoring submodule is used to monitor the connectivity and role status between the three servers, and to trigger alarms and switchover strategies when replication is interrupted or a node is unavailable. The core network and Redis connection management module includes: a write thread management submodule, which is used to create write threads when the core network device starts up, establish write connections with the Redis cluster master node through Redis asynchronous connection operations, set a callback function after successful asynchronous connection establishment to send authentication messages and maintain the liveness of the write connection; The read thread management submodule is used to create read threads, establish read connections with at least one slave node through Redis asynchronous connection operations, complete authentication processing through callback functions, and execute all read operations in the read connection to reduce the pressure on the master node; The subscription thread management submodule is used to create subscription threads, establish subscription connections with the master node through Redis asynchronous connection operations, and send wildcard subscription requests for key-value addition and deletion to the Redis server after successful authentication to obtain key-value change messages. The write queue and timer submodule is used to configure write queues for write threads within the core network device. It enqueues write operation requests from other business threads and periodically retrieves write commands from the write queue using a timer to submit them to the Redis master node for execution. After a write command is successfully executed, it publishes a data change command to Redis so that Redis can publish the data change message to the threads that subscribe to that data.

[0019] The Read Queue and Timer submodule is used to configure the read queue for the read thread, enqueue read operation requests from other business threads, and periodically retrieve read commands from the read queue through the timer and submit them to the Redis slave node for execution. The subscription queue submodule is used to receive key-value change notifications from the subscription connection and write the notification messages into the queue in order. The subscription thread then retrieves the messages in order and distributes them to the data synchronization and disaster recovery control module for processing. The data synchronization and disaster recovery control module includes: a data storage processing submodule, which organizes key user-related data into a hash structure or other key-value structure according to the core network business logic and encapsulates it into Redis commands through a write thread to write it to the master node, so as to achieve persistent backup of user data of the master device in the Redis cluster; The data reading and processing submodule is used to read commonly used data from slave nodes through a read thread according to business access requests, write the reading results into the local memory of the core network device, and return data from the local memory first in subsequent accesses to shorten access latency. The subscription message processing submodule is used to parse key-value addition and deletion messages in the subscription queue, determine the affected user data records, and perform addition, update or deletion operations in local memory to keep the local memory data consistent with the Redis cluster data. The local disaster recovery submodule is used to access the Redis cluster through a read thread when the core network device restarts due to a fault. It reads user data related to the device in batches according to predefined key space rules and rebuilds the local memory state, so that the device can be restored to the service level before the fault after restarting. The off-site disaster recovery takeover submodule is used to control the off-site core network equipment to establish a connection with the Redis cluster and read the corresponding user data when the entire set of core network equipment in a certain location becomes unrecoverable. The read data is then loaded into the local memory of the off-site equipment and the session resources are rebuilt, thereby completing the takeover of off-site user services.

[0020] To achieve high reliability, three Redis servers were configured as a cluster, employing master-slave replication to ensure high availability. Core network devices only need to store data on the Redis servers; Redis is responsible for reliability. The following section mainly describes how core network devices synchronize data to Redis and how to retrieve data from Redis.

[0021] First, during core network startup, three threads are created to establish three connections with the Redis master and slave nodes. These three connections are for reading, writing, and subscribing to Redis, respectively. Data is written via the write connection, and data is read via the read connection. Subscribed messages are transmitted through the subscription connection. This separation of read, write, and subscription improves read and write efficiency. Because the data on the master and slave nodes is consistent, establishing the read connection on the slave node further reduces the load on the master node, thereby enhancing its business processing capabilities.

[0022] To synchronize backup data, core network elements need to complete three operations with the Redis cluster: Firstly, data storage. To prevent data loss and ensure that backup devices can access the data when switching to primary mode, the primary device of a network element needs to store the data on the cluster server. This is data storage, which is essentially a write operation. Secondly, there's data reading. To quickly read frequently used data, core network elements need to synchronize the data to their local memory for convenient and rapid operation. This is the data reading operation. Thirdly, data subscription allows data to be synchronized from the cluster server to the core network element devices whenever data changes.

[0023] The above operations are performed by the core network elements using Redis's asynchronous operation functions and hash data type commands.

[0024] First, the core network creates a write thread to establish a connection with the Redis cluster master node using asynchronous Redis connection operations. Then, a callback function is set up to execute upon successful asynchronous operation. For example, in the asynchronous connection establishment operation, if the connection is established successfully, an authentication message is sent to the Redis cluster. If authentication fails, the connection establishment fails. After successful authentication, subsequent write operations will be performed within the connection. Simultaneously, a write queue is set up, and write operations from other threads are added to this queue. A timer is then set to periodically retrieve commands from the queue that require write operations.

[0025] Simultaneously, read threads are created. To reduce the load on the primary node, asynchronous Redis connection operations are used to establish connections with the Redis cluster backup nodes. A callback function is set up, which is executed upon successful asynchronous operation. For example, in the asynchronous connection establishment operation, if the connection is established successfully, an authentication message is sent to the Redis cluster. If authentication fails, the connection establishment fails. After successful authentication, subsequent read operations will be performed within this connection. A read queue is also set up, and read operations from other threads are added to this queue. A timer is then set up to periodically retrieve commands from the queue that require read operations.

[0026] To promptly detect changes in key figures, a subscription thread needs to be created. This thread establishes a connection with the Redis cluster master node using asynchronous connection operations, and then executes a callback function upon successful asynchronous operation. For example, in an asynchronous chain establishment operation, if the connection is established successfully, an authentication message is sent to the Redis cluster. If authentication fails, the connection establishment fails. After successful authentication, a wildcard subscription for key-value increments or deletions is published to the Redis server.

[0027] After the three types of threads are successfully created, the core network device elements send relevant write or query operations to Redis by calling the interface when they need to read or write data. These operations all use general Redis commands. When a key-value pair changes, Redis also sends a message back to the core network device. These messages are placed into the queues of the corresponding read / write threads described above. The timer in this queue continuously retrieves data to be processed, processes the data, converts it into Redis commands, and sends them to Redis for execution. After Redis completes the execution, it returns the result regardless of success or failure. The core network device processes the returned result and stores the results that need to be saved in memory.

[0028] When a core network device fails and restarts, it can directly access the Redis database and restore the data to its local memory, thus completing the device's disaster recovery mechanism. Alternatively, if an entire core network system fails in one location, a remote core network device can retrieve data from the Redis database and take over the remote users, completing the remote disaster recovery backup function.

[0029] II. Product Structure This invention proposes a method for disaster recovery backup using Redis. User data for core network devices is backed up in a Redis cluster. When a core network device fails and becomes unrecoverable, user data can be restored by reading the backup data from Redis on other backup devices, continuing to serve users and increasing device reliability. The Redis cluster can be configured with 2-3 servers as needed to increase reliability and availability. The core network establishes two connections, one with the primary device and one with a backup device in the cluster, for separate read and write operations, reducing the load on individual devices and improving processing speed.

[0030] It should be noted that, in this document, relational terms such as "first" and "second" are used only 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 process, method, article, or apparatus.

[0031] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for implementing disaster recovery for core network devices using Redis backup, characterized in that: Includes the following steps: S1. Cluster deployment steps: During the core network system deployment phase, configure three Redis servers and build a cluster structure, designate one server as the master node and configure two servers as slave nodes, and enable master-slave replication and high reliability strategies. S2. Connection establishment steps: During the startup phase of the core network device, write threads, read threads, and subscription threads are created sequentially. Write connections, read connections, and subscription connections are established with the master node and slave node respectively through Redis asynchronous connection operations. Authentication processing is completed in the callback function to ensure the connection is safe and reliable. S3. Write synchronization step: During the operation of core network services, the primary device writes the data write operation requests generated by each service thread into the write queue. When the timer is triggered, the write thread retrieves the write command from the write queue and submits it to the Redis master node through the write connection for execution, so as to store the user data in the Redis cluster. S4. Reading and Subscription Steps: During business operation, each business thread writes read requests to the read queue. When the timer is triggered, the read thread retrieves the read command from the read queue, obtains frequently used data from the slave node through the read connection, and synchronizes it to the local memory. At the same time, the subscription thread receives key-value change messages through the subscription connection and writes them to the subscription queue. The data synchronization and disaster recovery control module updates the local memory based on the subscription messages. S5. Disaster recovery steps: When a core network device fails and restarts, this device reads backup data in batches from the Redis cluster through a read thread to restore local memory. When the entire set of core network devices fails in a certain location, the remote core network device establishes a connection with the Redis cluster to read the corresponding user data and loads the user data into the local memory of the remote core network device to complete the remote disaster recovery takeover.

2. The method for implementing core network equipment disaster recovery using Redis backup as described in claim 1, characterized in that: S1 specifically includes: S1-1. During the core network deployment phase, select three servers to deploy Redis instances, add the three instances to the same logical cluster, and configure the internal communication address and port of the cluster so that the three instances can perform state synchronization and fault detection. S1-2. Designate one instance as the master node among the three instances, configure the persistence policy and access authentication parameters for the master node, so that the master node has the ability to receive external write commands and distribute replicated data to slave nodes, and record the connection information of the master node for use by the core network write thread. S1-3. Configure the remaining two instances as slave nodes, set the replication source of the slave nodes as the master node and enable the automatic reconnection policy, so that the slave nodes can automatically resume replication to the master node after network fluctuations or node restarts. When the replication status is abnormal, the cluster health monitoring submodule will report an alarm and trigger manual or automatic failover.

3. A method for implementing core network equipment disaster recovery using Redis backup as described in claim 2, characterized in that: S2 specifically includes: S2-1. During the startup process, the core network device creates a write thread, initiates a connection request to the master node through the Redis asynchronous connection function, sends an authentication message to the master node in the callback of successful connection establishment, marks the connection as a write connection after successful authentication and adds it to the event loop of the write thread. The write thread is responsible for maintaining the connection and re-initiating the connection in case of an exception. S2-2. The core network device simultaneously creates a read thread and initiates a connection request to at least one slave node through the Redis asynchronous connection function. In the callback of successful connection establishment, an authentication message is sent and the connection is marked as a read connection after successful authentication. All read operations are sent through the read connection, thereby concentrating the read load on the slave node. S2-3. The core network equipment also creates a subscription thread, which initiates a connection request to the master node through the Redis asynchronous connection function. After successful authentication, it sends wildcard subscription commands related to key-value addition and key-value deletion to the master node through the subscription connection, and pushes key space events to the subscription thread. S2-4. While creating write threads, read threads, and subscription threads, the core network device creates write queues, read queues, and subscription queues respectively, and configures timers for write threads and read threads. The timers trigger queue data retrieval operations at preset periods, and the subscription thread writes the message to the subscription queue when it receives the subscription message.

4. A method for implementing core network equipment disaster recovery using Redis backup as described in claim 3, characterized in that: S3 specifically includes: S3-1, When processing user services, the core network service processing module encapsulates structured data related to user sessions, user parameters, and billing information into a write request object, generates corresponding key names and field names according to pre-planned key naming rules, and pushes the write request object into the write queue. S3-2: When the timer is triggered, the write thread retrieves a batch of write requests to be processed from the write queue, converts each write request into a general Redis write command, and uses a hash data type command for multi-field data. The user data is written to the master node's in-memory database by key name and field name, and timeout attributes are configured when necessary. S3-3: After receiving the write result returned by the master node, the write thread checks the write result and records the execution status. When a write failure is found, it re-enqueues or resends the write command according to the preset retry strategy to ensure that the critical user data is eventually written successfully, so as to ensure that all user data generated by the master device during operation is stored in the Redis cluster. S3-4. When the primary core network device undergoes a planned or abnormal restart, the write thread processes the write queue before exiting, prioritizing the sending of uncommitted write requests to the primary node for execution, thus avoiding data loss due to an empty queue.

5. A method for implementing core network equipment disaster recovery using Redis backup as described in claim 4, characterized in that: S4 specifically includes: S4-1, When the core network service processing module needs to access user data, it encapsulates the read request into a read request object and writes it into the read queue. The read request object carries the target key name and field name information, and indicates whether the read result needs to be written to the local memory cache. S4-2. When the timer is triggered, the read thread retrieves read requests in batches from the read queue, sends the corresponding Redis read command to the slave node through the read connection, receives the data results returned by the slave node, and writes the successfully read user data into the memory structure inside the core network device so that subsequent accesses can directly return results from local memory. S4-3. The subscription thread receives key-value addition and deletion messages pushed by the master node through the subscription connection and writes each message to the subscription queue. The data synchronization and disaster recovery control module reads the message from the subscription queue, parses out the affected key name and field name, and performs the add, update or delete operation in local memory according to the message type to keep the data state in local memory consistent with the Redis cluster. S4-4. When the read thread finds that there is a hit in the local memory, it can return the result directly from the local memory according to the configuration and selectively initiate background asynchronous verification, thereby reducing the number of accesses to the slave node while ensuring data consistency. S4-5. Local memory cache only stores frequently used data; less frequently accessed data is cleared to free up memory space. This is determined based on the number of accesses. When there is a large amount of data stored locally, data with fewer accesses can be cleared based on the statistical access count, and the space can be used to store newly read data.

6. A method for implementing core network equipment disaster recovery using Redis backup as described in claim 5, characterized in that: S5 specifically includes: S5-1 When a single core network device exits and restarts due to a fault, the local disaster recovery submodule notifies the backup core network device to take over the service. The backup core network device then accesses the Redis cluster through a read thread, traverses the key space associated with the device according to the predefined key naming rules, reads user session data and parameter data in batches, and reconstructs the corresponding structure in local memory. S5-2. When the entire core network equipment in a certain location cannot be restored due to power failure or hardware failure, after receiving the scheduling instruction, the remote core network equipment establishes a connection with the same Redis cluster through its own write thread, read thread and subscription thread, reads the target user data from the Redis cluster and builds a local memory view in accordance with the steps S3 and S4, and then starts the corresponding signaling processing module and business processing module to continue to provide business services to the original users. S5-3. During local disaster recovery and off-site disaster recovery takeover, the data synchronization and disaster recovery control module performs integrity verification on all data read during the recovery process. If missing data is recorded as abnormal and an alarm is triggered, the operation and maintenance personnel will repair it in conjunction with the backup strategy and the upper-layer business, thereby ensuring the data reliability and business continuity during the disaster recovery process.

7. A system for implementing core network equipment disaster recovery using the Redis backup method according to any one of claims 1-6, characterized in that: include: The Redis cluster deployment module is used to configure three Redis servers outside the core network system to form a cluster master-slave replication and enable sentinel mode, so that the cluster has high reliability and high availability. The core network and Redis connection management module is used to create write threads, read threads and subscription threads respectively during the startup phase of the core network device, and establish corresponding asynchronous connection channels with the master node and slave node of the Redis cluster, thus separating the write connection, read connection and subscription connection from each other. The data synchronization and disaster recovery control module is used to write user data through write connections during business operations, synchronize frequently used data to the core network local memory through read connections, receive key-value change notifications and drive local memory updates through subscription connections, and perform local recovery and off-site disaster recovery takeover based on Redis backup data when core network equipment fails.

8. A system for disaster recovery of core network equipment using Redis backup method according to claim 7, characterized in that: The Redis cluster deployment module includes a master node configuration submodule, which is used to designate one of the three Redis servers as the master node and configure the authentication parameters and persistence strategy of the master node, so that the master node is responsible for the entry point of write operations and the publication of key-value changes. The slave node configuration submodule is used to configure the other two servers as slave nodes and establish a replication relationship with the master node, so that the slave nodes maintain a consistent data view with the master node and provide read services. The cluster health monitoring submodule is used to monitor the connectivity and role status between the three servers, and to trigger alarms and switchover strategies when replication is interrupted or a node is unavailable. The core network and Redis connection management module includes: a write thread management submodule, which is used to create a write thread when the core network device starts up, establish a write connection with the Redis cluster master node through Redis asynchronous connection operation, set a callback function after successful asynchronous connection establishment to send authentication messages and maintain the liveness of the write connection; The read thread management submodule is used to create read threads, establish read connections with at least one slave node through Redis asynchronous connection operations, complete authentication processing through callback functions, and execute all read operations in the read connection to reduce the pressure on the master node; The subscription thread management submodule is used to create subscription threads, establish subscription connections with the master node through Redis asynchronous connection operations, and send wildcard subscription requests for key-value addition and deletion to the Redis server after successful authentication to obtain key-value change messages. The write queue and timer submodule is used to configure write queues for write threads within the core network device. It enqueues write operation requests from other business threads and periodically retrieves write commands from the write queue through a timer and submits them to the Redis master node for execution. After the write command is successfully executed, it publishes a data change command to Redis so that Redis can publish the data change message to the threads that subscribe to the data. The Read Queue and Timer submodule is used to configure the read queue for the read thread, enqueue read operation requests from other business threads, and periodically retrieve read commands from the read queue through the timer and submit them to the Redis slave node for execution. The subscription queue submodule is used to receive key-value change notifications from the subscription connection and write the notification messages into the queue in order. The subscription thread then retrieves the messages in order and distributes them to the data synchronization and disaster recovery control module for processing. The data synchronization and disaster recovery control module includes: a data storage processing submodule, which is used to organize key data related to users into a hash structure or other key-value structure according to the core network business logic and encapsulate it into a Redis command through a write thread to write it to the master node, so as to realize the persistent backup of user data of the master device in the Redis cluster; The data reading and processing submodule is used to read the data requested by the business module from the slave node through the read thread according to the business access request. At the same time, it writes the reading result to the local memory of the core network device. If the data already exists, it updates the data and records the access count of the data. This is used to prioritize returning data from the local memory in subsequent accesses to shorten the access latency. The subscription message processing submodule is used to parse key-value addition and deletion messages in the subscription queue, determine the affected user data records, and perform addition, update or deletion operations in local memory to keep the local memory data consistent with the Redis cluster data. The local disaster recovery submodule is used to access the Redis cluster through a read thread when the core network device restarts due to a fault. It reads user data related to the device in batches according to predefined key space rules and rebuilds the local memory state, so that the device can be restored to the service level before the fault after restarting. The off-site disaster recovery takeover submodule is used to control the off-site core network equipment to establish a connection with the Redis cluster and read the corresponding user data when the entire set of core network equipment in a certain location becomes unrecoverable. The read data is then loaded into the local memory of the off-site equipment and the session resources are rebuilt, thereby completing the takeover of off-site user services.

Images