Redis-based upf high availability method, device, equipment and medium

Abstract

The application relates to the technical field of high-availability storage, and discloses a Redis-based UPF high-availability method, device, equipment and medium, the method comprising the following steps: determining a lock acquisition strategy; the lock acquisition strategy comprises a lock period, a lock competition rule and a preset number of locks; obtaining the locks corresponding to various service instances from a Redis server according to the lock competition rule; marking the service instances with the preset number of obtained locks as active instances, assigning corresponding service processing tasks to the active instances, and marking the service instances with the preset number of unobtained locks as standby instances; each active instance updates the lock state to the Redis server at a specified period; and if the active instances exceed the lock period, switching the standby instances to new active instances. The application can improve the efficiency and reliability of the UPF.

Description

Technical Field

[0001] This invention relates to the field of high availability storage technology, specifically to a Redis-based UPF high availability method, apparatus, device, and medium. Background Technology

[0002] With the development of 5G networks, the requirements for critical infrastructure such as User Plane Functions (UPFs) are becoming increasingly stringent. UPFs, defined in the 3GPP standard, are a key component of the 5G core network architecture. They are primarily responsible for handling user data transmission, routing, and the execution of related policies, ensuring that the mobile network can efficiently provide users with internet connectivity and other data services. Especially when facing sudden traffic surges or hardware / software failures, ensuring high system availability and rapid service recovery has become a major challenge. Currently, the most common deployment method for UPFs is a "one primary, one backup" configuration. Normally, only the primary node is active, while the backup node is idle. Using traditional relational databases to store session information makes it difficult to handle large-scale concurrent requests, impacting overall performance. Summary of the Invention

[0003] In view of this, the present invention provides a Redis-based UPF high availability method, apparatus, device and medium to improve the efficiency and reliability of UPF.

[0004] In a first aspect, the present invention provides a high availability method for implementing UPF based on Redis. The method includes: determining a lock acquisition strategy; the lock acquisition strategy includes a lock expiration period, lock contention rules, and a preset number of locks; acquiring locks corresponding to each service instance from the Redis server according to the lock contention rules; marking service instances that have acquired the preset number of locks as active instances and assigning them corresponding business processing tasks, and marking service instances that have not acquired locks as backup instances; each active instance updating its lock status to the Redis server at a specified period; if an active instance exceeds its lock expiration period, switching a backup instance to a new active instance.

[0005] The present invention provides a method for achieving high availability of UPF based on Redis. This method achieves high availability of services by defining lock acquisition strategies, allowing service instances to compete for locks, and switching between active and standby instances based on lock status, thereby improving the efficiency and reliability of UPF.

[0006] In one alternative implementation, the lock acquisition strategy further includes a lock name, and the method further includes: assigning a unique identifier to the lock of the Redis server based on the lock name.

[0007] In one optional implementation, the locks corresponding to each service instance are obtained from the Redis server according to the lock contention rules, including: setting a preset acquisition time for lock acquisition; if a service instance fails to successfully acquire the lock corresponding to a candidate service instance within the preset acquisition time, the operation of acquiring the lock corresponding to the candidate service instance is stopped.

[0008] In one optional implementation, after allocating the corresponding business processing task, the method further includes: serializing the session data of the business processing task and sending it to the Redis server.

[0009] In one alternative implementation, the method further includes: a standby instance subscribing to a specific channel of the Redis server; and, based on the specific channel, the standby instance receiving and storing deserialized session data.

[0010] In one optional implementation, if the active instance exceeds the lock period, the standby instance is switched to the new active instance, including: if the active instance fails to send a refresh request within the lock period, the lock corresponding to the active instance is released and downgraded to a new standby instance; a target instance is selected in the standby instance, and the lock corresponding to the target instance is obtained from the Redis server to switch the target instance to the new active instance.

[0011] In one alternative implementation, the method further includes: if the active instance is marked as an internal abnormal state, restarting the active instance and downgrading the active instance to a new standby instance; if the active instance stops after receiving an external instruction, downgrading the active instance to a new standby instance.

[0012] Secondly, this invention provides a high-availability device for implementing UPF based on Redis. The device includes: a strategy determination module for determining a lock acquisition strategy; the lock acquisition strategy includes a lock expiration period, lock contention rules, and a preset number of locks; a lock acquisition module for acquiring locks corresponding to each service instance from the Redis server according to the lock contention rules; an instance marking module for marking service instances that have acquired a preset number of locks as active instances and assigning them corresponding business processing tasks, and marking a preset number of service instances that have not acquired locks as standby instances; each active instance updates its lock status to the Redis server at a specified period; and an instance switching module for switching standby instances to new active instances if an active instance exceeds its lock expiration period.

[0013] Thirdly, the present invention provides a computer device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the high availability method for implementing UPF based on Redis as described in the first aspect or any corresponding embodiment above.

[0014] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the Redis-based high availability method for implementing UPF as described in the first aspect or any corresponding embodiment thereof.

[0015] Fifthly, the present invention provides a computer program product, including computer instructions for causing a computer to execute the Redis-based high availability method for implementing UPF as described in the first aspect or any corresponding embodiment thereof. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating a method for implementing UPF based on Redis according to an embodiment of the present invention.

[0018] Figure 2 This is a flowchart illustrating a Redis-based serialization / deserialization method according to an optional embodiment of the present invention.

[0019] Figure 3 This is a schematic diagram of the service instance contention lock process according to an optional embodiment of the present invention;

[0020] Figure 4 This is a schematic diagram of the switching process for a single UPF service instance according to an optional embodiment of the present invention;

[0021] Figure 5 This is a structural block diagram of a high-availability device for implementing UPF based on Redis according to an embodiment of the present invention;

[0022] Figure 6 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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, 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.

[0024] Redis (Remote Dictionary Server) is an open-source, in-memory data structure storage system widely used in databases, caching, and message queues. Redis distributed locks are a mechanism for implementing mutual exclusion in distributed systems. Through specific Redis commands (such as SETNX), mutual exclusion is achieved, ensuring that only one client can acquire the lock at a time. The lock value typically contains a unique identifier for the client, ensuring that only the client holding the lock can release it. To avoid deadlocks, locks usually have an automatic expiration time; after the timeout, Redis automatically deletes the lock and releases the resources. In UPF, Redis distributed locks can be applied in various scenarios to ensure data consistency and service reliability.

[0025] According to an embodiment of the present invention, a method embodiment for implementing UPF based on Redis is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0026] This embodiment provides a method for achieving high availability of UPF based on Redis. Figure 1 This is a flowchart illustrating a high-availability method for implementing UPF based on Redis according to an embodiment of the present invention, as shown below. Figure 1 As shown, the process includes the following steps:

[0027] Step S101: Determine the lock acquisition strategy; the lock acquisition strategy includes the lock duration, lock contention rules, and preset lock quantity.

[0028] Optionally, the lock acquisition strategy may also include the lock name, which assigns a unique identifier to the lock on the Redis server based on the lock name.

[0029] The lock expiration period is the valid time of the lock. During the lock expiration period, the service instance holding the lock is considered active and has the right to process business requests. Once the lock expires, it will be released if it is not refreshed. Define the rules for how service instances compete to acquire the lock, including timestamp-based priority ordering, random selection, or other strategies. The number of locks pre-set on the Redis server matches the number of active service instances required by the business. The lock name is a unique name or identifier assigned to each lock, allowing service instances to explicitly specify their target when attempting to acquire the lock.

[0030] Step S102: Obtain the locks corresponding to each service instance from the Redis server according to the lock contention rules.

[0031] After a service instance starts, it will attempt to acquire a lock according to the lock contention rules. If the service instance successfully acquires the lock, it will hold the lock until it expires. If the service instance fails to acquire the lock, it will enter a standby state and wait for an opportunity to try to acquire the lock again.

[0032] In step S103, the service instances that have acquired a preset number of locks are marked as active instances and assigned corresponding business processing tasks, and the service instances that have not acquired a preset number of locks are marked as standby instances; each active instance updates the lock status to the Redis server according to a specified period.

[0033] The preset number of locks is denoted as N. The first N service instances to successfully acquire a lock are marked as active instances and are responsible for handling business requests. Service instances that fail to acquire a lock are marked as standby instances and are in a standby state. Active instances need to send lock refresh requests to the Redis server at specified intervals to extend the lock's validity period and confirm their own status.

[0034] In step S104, if the active instance exceeds the lock period, the standby instance is switched to the new active instance.

[0035] If the active instance fails to send a refresh request within the lock's expiration period, the lock will automatically expire and be released. Once the lock is released, the standby instance will have the opportunity to attempt to acquire it. The standby instance that successfully acquires the lock will become the new active instance and take over the business processing tasks that were originally handled by the failed instance.

[0036] The high availability method for implementing UPF based on Redis provided in this embodiment achieves high availability of services by defining lock acquisition strategies, service instances competing to acquire locks, and switching between active and standby instances based on lock status, thereby improving the efficiency and reliability of UPF.

[0037] In an optional implementation, the process of step S102 above includes the following steps:

[0038] Step S1021: Set the preset acquisition time for lock acquisition.

[0039] The preset acquisition time limits the time a service instance spends attempting to acquire a lock. If a service instance fails to acquire the lock within the preset time, it will stop trying, thus avoiding indefinitely consuming system resources. The preset acquisition time can be fixed (e.g., 30 seconds, 1 minute) or dynamic (adjusted based on factors such as system load and network conditions).

[0040] Step S1022: If the service instance fails to acquire the lock corresponding to the candidate service instance within the preset acquisition time, the operation of acquiring the lock corresponding to the candidate service instance is stopped.

[0041] When a service instance begins attempting to acquire a lock, a timer starts. If the service instance fails to acquire the lock within the preset acquisition time (i.e., the lock has been acquired by another instance or the acquisition failed for other reasons), the lock acquisition operation for that service instance will be stopped. After stopping, the service instance can enter a standby state, waiting for an opportunity to try to acquire the lock again, or perform other tasks.

[0042] This implementation improves the overall performance and efficiency of the system by stopping invalid lock acquisition attempts, releasing system resources, and allowing other service instances or processes to acquire locks.

[0043] In an optional implementation, after the above step S103 assigns the corresponding business processing tasks, Figure 2 This is a flowchart illustrating a Redis-based serialization / deserialization method according to an optional embodiment of the present invention, as shown below. Figure 2 As shown, the process includes the following steps:

[0044] Step S201: Serialize the session data of the business processing task and send it to the Redis server.

[0045] When an active service instance processes a business request, it generates corresponding session data. This session data is serialized in a specific format for transmission and storage over the network. For example, protobuf (Protocol Buffers) can be used for serialization. After each session-related operation request (such as create, modify, or delete) is processed, the service instance sends its latest session data, serialized in protobuf format, to Redis.

[0046] Protobuf is a high-efficiency binary serialization format that can significantly reduce data size, thereby speeding up data transfer and reducing storage space usage. Active service instances generate session data when processing business requests. The protobuf library is used to serialize this session data into binary format. The serialized data is then sent to the Redis server for storage.

[0047] Step S202: The standby instance subscribes to a specific channel of the Redis server.

[0048] The standby service instance subscribes to a specific channel on the Redis server to receive session data update messages from the active service instance in real time. After starting up, the standby instance connects to the Redis server and subscribes to a specific channel. This channel is where the active instance publishes session data update messages. After subscribing to the channel, the standby instance will be able to receive session data sent by the active instance in real time.

[0049] Step S203: Based on a specific channel, the backup instance receives and saves the deserialized session data.

[0050] These binary-formatted session data are deserialized back to their original format using a deserialization technique corresponding to the serialization technique. The deserialized data is then saved to local memory for quick service recovery when needed.

[0051] This implementation method, by subscribing to specific channels and deserializing session data, enables the standby instance to receive session data update messages sent by the active instance in real time and to quickly restore service when taking over the tasks of the active instance, thereby ensuring data consistency and synchronization.

[0052] In an optional implementation, the process of step S104 above includes the following steps:

[0053] In step S1041, if the active instance fails to send a refresh request within the lock period, the lock corresponding to the active instance is released and it is downgraded to a new standby instance.

[0054] Monitor whether each active instance sends a refresh request to Redis within the lock period. If an active instance fails to send a refresh request within the specified time, it is considered that the instance has failed or malfunctioned.

[0055] By releasing the lock corresponding to the failed active instance, a standby instance has the opportunity to acquire the lock and take over the business processing tasks originally handled by the failed instance. The failed active instance is then downgraded to a new standby instance, which may become active again after the fault is resolved.

[0056] Step S1042: Select the target instance from the standby instances and obtain the lock corresponding to the target instance from the Redis server to switch the target instance to the new active instance.

[0057] Select a target instance from the standby instances and attempt to acquire the lock corresponding to that target instance from the Redis server. If successful, the target instance will become the new active instance and take over the business processing tasks originally handled by the failed active instance.

[0058] Figure 3This is a schematic diagram of the service instance lock contention process according to an optional embodiment of the present invention. N service instances successfully acquire the lock and periodically send refresh requests to refresh the expiration time. M standby instances periodically attempt to acquire the lock. Whenever a standby instance successfully acquires the lock that originally belonged to a certain service instance, it means that the standby instance has been officially promoted to the new service instance, recovers the session-related data of the previous service instance from Redis, and begins to assume the workload. At the same time, the service instance that originally held the lock but encountered problems will automatically be downgraded to a standby instance after restarting and continue to wait for the next opportunity to take over.

[0059] This implementation method acquires the lock corresponding to the failed active instance, allowing the standby instance to take over its tasks and ensuring service stability.

[0060] In one alternative implementation, if the active instance is marked as having an internal abnormal state, the active instance is restarted and downgraded to a new standby instance.

[0061] If an active instance stops after receiving an external instruction, it will be downgraded to a new standby instance.

[0062] The system monitors the running status of active instances in real time through a self-diagnostic mechanism.

[0063] If an active instance is found to have an internal abnormal state (such as memory overflow, routing errors, DPDK MBUF errors, etc.), it is marked as abnormal. Upon detecting an internal abnormal state in an active instance, a restart mechanism is immediately triggered. During the restart process, the active instance is marked as a new standby instance. After the restart is complete, the instance will remain as a standby instance, waiting for an opportunity to re-acquire the lock and become the active instance.

[0064] An active instance may receive a stop command from a system administrator or an external system. A stop command indicates that the service instance has terminated abnormally due to external reasons (such as a system crash), and the locks held by the active instance in Redis will expire naturally because they have not been refreshed in time. Upon receiving a stop command, the active instance immediately stops processing business requests and is marked as a new standby instance.

[0065] This implementation prevents abnormal instances from continuing to process business requests, thereby avoiding potential data corruption or service interruption and ensuring the stability and reliability of the system.

[0066] Figure 4 This is a schematic diagram of the switching process for a single UPF service instance according to an optional embodiment of the present invention, such as... Figure 4As shown, during the initial system startup, UPF starts N+M instances, where N represents the number of active service instances configured, and M represents the number of additional standby instances. All these instances connect to the same Redis instance for coordinating and managing lock states and backing up session data. Each instance attempts to acquire one of the locks (a total of N locks are set), and each lock has an expiration time. The first N instances to successfully acquire the lock are designated as active service instances, while the remaining M instances serve as standby. To maintain its "active" state, each service instance needs to periodically send lock refresh requests to Redis to extend the validity of its held locks. This process not only proves that the instance is still running normally but also serves as a confirmation of its own health status. If a service instance fails to update its lock in time, it is considered invalid or has malfunctioned, and the lock will automatically expire. If a malfunction is detected, the system will take appropriate measures, such as releasing the lock or retrying to acquire the lock, to restore the normal service state.

[0067] Optionally, administrators can be proactively notified in real time of UPF instance status switching via email, SMS, and various mobile apps, making it easier for relevant personnel to locate and analyze the cause of the instance switching and resolve the problem in a timely manner.

[0068] In summary, this invention ensures rapid service recovery when an active instance fails through backup instances and an automatic failover mechanism. By competitively acquiring locks, business processing tasks are rationally allocated, preventing some instances from being overloaded while others remain idle. Regularly updating lock states and employing a fault detection mechanism allows for timely detection and handling of instance failures, effectively achieving dynamic management and failover of service instances. This significantly improves system reliability and response speed, ensuring system stability and reliability.

[0069] This embodiment also provides a high-availability device for implementing UPF based on Redis. This device is used to implement the above embodiments and preferred embodiments, and details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0070] This embodiment provides a high-availability device for implementing UPF based on Redis, such as... Figure 5 As shown, it includes:

[0071] The strategy determination module 501 is used to determine the lock acquisition strategy; the lock acquisition strategy includes the lock duration, lock contention rules, and preset number of locks.

[0072] The lock acquisition module 502 is used to acquire the locks corresponding to each service instance from the Redis server according to the lock contention rules.

[0073] The instance marking module 503 is used to mark a preset number of service instances that have acquired locks as active instances and assign corresponding business processing tasks, and to mark a preset number of service instances that have not acquired locks as standby instances; each active instance updates the lock status to the Redis server according to a specified period.

[0074] The instance switching module 504 is used to switch the standby instance to the new active instance if the active instance exceeds the lock period.

[0075] In one alternative implementation, the strategy determination module 501 is used to:

[0076] The lock acquisition strategy also includes the lock name; based on the lock name, a unique identifier is assigned to the lock on the Redis server.

[0077] In one optional implementation, the lock acquisition module 502 includes:

[0078] The first lock acquisition unit is used to set the preset acquisition time for lock acquisition;

[0079] The second lock acquisition unit is used to stop the operation of acquiring the lock corresponding to the candidate service instance if the service instance fails to acquire the lock corresponding to the candidate service instance within a preset acquisition time.

[0080] In one alternative implementation, the instance tagging module 503 is used to:

[0081] The session data of the business processing task is serialized and sent to the Redis server.

[0082] In one optional embodiment, the apparatus further includes a deserialization module, which includes:

[0083] The first deserialization unit is used for the standby instance to subscribe to a specific channel of the Redis server;

[0084] The second deserialization unit is used to receive and save deserialized session data from a backup instance based on a specific channel.

[0085] In one alternative implementation, the instance switching module 504 includes:

[0086] The first instance switching unit is used to release the lock corresponding to the active instance and downgrade it to a new standby instance if the active instance fails to send a refresh request within the lock period.

[0087] The second instance switching unit is used to select a target instance from the standby instances and obtain the lock corresponding to the target instance from the Redis server to switch the target instance to the new active instance.

[0088] In an optional implementation, the instance switching module 504 further includes:

[0089] The instance restart unit is used to restart the active instance and downgrade it to a new standby instance if the active instance is marked as an internal abnormal state.

[0090] The instance degradation unit is used to downgrade an active instance to a new standby instance if the active instance stops after receiving an external instruction.

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

[0092] In this embodiment, the high availability device for implementing UPF based on Redis is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0093] This invention also provides a computer device having the above-described features. Figure 5 The diagram shows a high-availability device for implementing UPF based on Redis.

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

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

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

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

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

[0099] The computer device also includes an input device 30 and an output device 40. The processor 10, memory 20, input device 30, and output device 40 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

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

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

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

[0103] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for implementing high availability of UPF based on Redis, characterized in that, The method includes: Determine the lock acquisition strategy; the lock acquisition strategy includes the lock duration, lock contention rules, and preset lock quantity; According to the lock contention rules, obtain the locks corresponding to each service instance from the Redis server; The service instances that have acquired a preset number of locks are marked as active instances and assigned corresponding business processing tasks, while the service instances that have not acquired locks are marked as backup instances; each active instance updates the lock status to the Redis server according to a specified period. If the active instance exceeds the lock period, then the standby instance is switched to the new active instance; The process of allocating the corresponding business processing tasks further includes: The session data of the business processing task is serialized and sent to the Redis server; The method further includes: The standby instance subscribes to a specific channel of the Redis server; Based on the specific channel, the backup instance receives and saves the deserialized session data.

2. The method according to claim 1, characterized in that, The lock acquisition strategy also includes the lock name, and the method further includes: Based on the lock name, assign a unique identifier to the lock on the Redis server.

3. The method according to claim 1 or 2, characterized in that, The step of obtaining the locks corresponding to each service instance from the Redis server according to the lock contention rules includes: Set the preset acquisition time for lock acquisition; If a service instance fails to acquire the lock corresponding to a candidate service instance within the preset acquisition time, the operation of acquiring the lock corresponding to the candidate service instance will be stopped.

4. The method according to claim 1, characterized in that, If the active instance exceeds the lock period, then switching the backup instance to the new active instance includes: If the active instance fails to send a refresh request within the lock period, the lock corresponding to the active instance is released and it is downgraded to a new standby instance. Select a target instance from the standby instance and obtain the lock corresponding to the target instance from the Redis server to switch the target instance to a new active instance.

5. The method according to claim 4, characterized in that, The method further includes: If the active instance is marked as an internal abnormal state, restart the active instance and downgrade it to a new standby instance; If the active instance stops after receiving an external instruction, the active instance will be downgraded to a new standby instance.

6. A high-availability device for implementing UPF based on Redis, characterized in that, The device includes: The strategy determination module is used to determine the lock acquisition strategy; the lock acquisition strategy includes the lock duration, lock contention rules, and preset lock quantity; The lock acquisition module is used to acquire the locks corresponding to each service instance from the Redis server according to the lock contention rules. The instance marking module is used to mark a preset number of service instances that have acquired locks as active instances and assign corresponding business processing tasks, and to mark a preset number of service instances that have not acquired locks as standby instances; each active instance updates the lock status to the Redis server according to a specified period; The instance switching module is used to switch the backup instance to a new active instance if the active instance exceeds the lock period. The instance tagging module is used to serialize the session data of the business processing task and send it to the Redis server. The device further includes a deserialization module, which includes: The first deserialization unit is used for the standby instance to subscribe to a specific channel of the Redis server; The second deserialization unit is used to receive and save deserialized session data from a backup instance based on a specific channel.

7. A computer device, characterized in that, include: A memory and a processor are interconnected, the memory stores computer instructions, and the processor executes the computer instructions to perform the high availability method for implementing UPF based on Redis as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the high availability method for implementing UPF based on Redis as described in any one of claims 1 to 5.

Images