Main and standby fault switching quota management method based on distributed storage cluster

Abstract

The invention provides a main and standby fault switching quota management method based on a distributed storage cluster. According to the main and standby fault switching quota management method based on the distributed storage cluster, zero-error statistics and global consistency of quota data in the main and standby fault switching process can be achieved, and the high availability of a distributed storage system and the reliability of resource management are effectively guaranteed.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of master-slave fault switching and quota consistency guarantee of distributed storage clusters, and particularly relates to a master-slave fault switching quota management method based on a distributed storage cluster. BACKGROUND

[0002] As a core mechanism of resource scheduling of distributed storage systems, quota management is widely used in enterprise-level data centers, cloud computing platforms and large-scale file systems. Its main function is to guarantee the resource fairness and system stability in multi-user and multi-task scenarios. In related technologies, a basic quota control system is constructed through the collaborative work of centralized management, master-slave switching mechanism and heartbeat monitoring. Specifically, this system covers the whole process from quota allocation, usage monitoring to fault recovery, including key links such as quota node state mapping, client incremental reporting, master node election and data consistency guarantee. With the continuous expansion of the scale of storage systems and the continuous improvement of business continuity requirements, the traditional solution gradually exposes the coordination problem between high availability and data consistency, and a new quota management architecture that integrates load awareness, logical clock synchronization and lightweight deduplication mechanism is urgently needed.

[0003] However, in the existing quota management method, centralized control or simple distributed synchronization mechanism is directly used, and the incremental data persistence and message duplicate processing problems in the master-slave switching process are not fully considered, which may cause quota statistical errors, data inconsistency, or introduce a large number of redundant operations in the fault recovery phase, thereby affecting the availability of the system and the accuracy of resource allocation. Specifically, the existing technology usually relies on a single master node for quota decision, which has the risk of single point failure; during switching, the incremental operations that are not persisted may be lost, leading to quota overrun or misjudgment; at the same time, after the recovery of the fault node, a large amount of data needs to be synchronized again, which easily causes state conflicts and statistical deviations, limiting the stable operation ability of the system in high concurrency and high dynamic environment. SUMMARY

[0004] The present application aims to at least partially solve one of the technical problems in the related art.

[0005] To this end, a first object of the present application is to propose a master-slave fault switching quota management method based on a distributed storage cluster.

[0006] A second object of the present application is to propose a master-slave fault switching quota management device based on a distributed storage cluster.

[0007] A third object of the present application is to propose an electronic device.

[0008] A fourth object of the present application is to propose a computer-readable storage medium.

[0009] A fifth object of the present application is to propose a computer program product.

[0010] To achieve the above object, the first aspect of the present application proposes a method for managing quota switching between primary and backup faults based on a distributed storage cluster, comprising: S1, a client records quota increment and pre-application amount in memory according to logical clock, and after reporting the increment data, waits for a response confirmation from the primary quota node, and accumulates the increment to the local logical clock statistical value; S2, when the primary quota node fails, the monitoring node selects the backup node with the lowest load as the new primary node according to the quota node state mapping table, and notifies the client to update the quota server mapping relationship; S3, the new primary quota node sends a state query request to all normal clients, collects the increment data and the maximum reporting serial number of the current logical clock of the client; S4, the new primary quota node merges and replays the operation according to the increment data and the maximum reporting serial number returned by the client according to the logical clock order, and generates a globally consistent quota state.

[0011] In an embodiment of the present application, the client records quota increment and pre-application amount in memory according to logical clock, and after reporting the increment data, waits for a response confirmation from the primary quota node, and accumulates the increment to the local logical clock statistical value, and further comprises: S11, the client generates an incremental logical clock serial number according to the operation timestamp and the client identifier at each quota operation, and caches the serial number together with the quota increment and the pre-application amount in the memory; S12, after receiving the confirmation response of the primary quota node to the increment data, the client marks the logical clock serial number corresponding to the increment data as having been persisted, and carries the maximum persisted logical clock serial number in the subsequent heartbeat response, so that the primary quota node judges the data synchronization state of the client.

[0012] In an embodiment of the present application, when the primary quota node fails, the monitoring node selects the backup node with the lowest load as the new primary node according to the quota node state mapping table, and notifies the client to update the quota server mapping relationship, further comprising: S21, when selecting the new primary node, the monitoring node performs weighted scoring based on the CPU usage, memory usage and network bandwidth in the quota node state mapping table, and selects the backup node with the lowest score as the new primary node; S22, when notifying the client to update the quota server mapping relationship, the monitoring node sends the update instruction in a broadcast manner, and after the client receives the update instruction, caches the IP address and port information of the new primary node locally for subsequent routing selection of quota operation.

[0013] In one embodiment of the present application, the new master quota node sends a state query request to all normal clients, collects the increment data of the current logical clock of the clients and the maximum reporting sequence number, and further comprises: S31, before sending the state query request, the new master quota node first obtains the IP address and state information of all normal clients from the monitoring node to ensure that the query request is sent only to the clients in the active state; S32, when collecting the client data, the new master quota node sets a response timeout mechanism, and if the client does not return a response within a preset time, the client is marked as abnormal and its data is ignored in the subsequent merging operation.

[0014] In one embodiment of the present application, further comprising: S5, after the old master quota node is restored, the old master quota node sends a version number query request to the monitoring node, and the monitoring node compares the version number of the current master node with the version number of the old master node, and if the version number of the old master node is lower than that of the current master node, the old master node is notified to automatically downgrade to a backup node, and the local cached quota state information of the old master node is cleared.

[0015] To achieve the above purpose, the second aspect embodiment of the present application provides a master and backup fault switching quota management device based on a distributed storage cluster, comprising: a logical clock recording module, configured to record quota increments and pre-application amounts in the memory of the client according to the logical clock, and after reporting the increment data, waiting for the response confirmation of the master quota node, and accumulating the increments to the local logical clock statistical value; a master node switching control module, configured to select the backup node with the lowest load as the new master node when the master quota node fails, and notify the client to update the quota server mapping relationship according to the quota node state mapping table; a state query sending module, configured to send a state query request to all normal clients by the new master quota node, and collect the increment data of the current logical clock of the clients and the maximum reporting sequence number; and a quota state merging module, configured to merge and replay the operation according to the increment data and the maximum reporting sequence number returned by the client in the order of the logical clock by the new master quota node, and generate a globally consistent quota state.

[0016] In one embodiment of the present application, the logical clock recording module is further configured to: generate an incremental logical clock sequence number according to the operation timestamp and the client identifier at each quota operation of the client, and cache the sequence number together with the quota increments and the pre-application amounts in the memory; and after receiving the confirmation response of the master quota node to the increment data, mark the logical clock sequence number corresponding to the increment data as having been persisted, and carry the maximum persisted logical clock sequence number in the subsequent heartbeat response, so that the master quota node can judge the data synchronization state of the client.

[0017] To achieve the above purpose, the third aspect embodiment of the present application provides an electronic device, comprising: a processor, and a memory connected with the processor in communication;

[0018] The memory stores computer-executable instructions;

[0019] The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of the first aspect.

[0020] To achieve the above object, the fourth aspect of the present application provides a computer readable storage medium, the computer readable storage medium stores computer-executable instructions, the computer-executable instructions are executed by a processor to implement the method according to any one of the first aspect.

[0021] To achieve the above object, the fifth aspect of the present application provides a computer program product, the computer program is executed by a processor to implement the method according to any one of the first aspect.

[0022] The embodiments of the present application provide at least the following beneficial effects: the quota data in the master-slave fault switching process is zero-error statistical and globally consistent, and the high availability and reliability of the distributed storage system are improved.

[0023] Additional aspects and advantages of the application will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following and / or can be learned by practice of the application. BRIEF DESCRIPTION OF DRAWINGS

[0024] In order to more clearly illustrate the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0025] Figure 1 is a flow chart of a master-slave fault switching quota management method based on a distributed storage cluster according to an embodiment of the present application;

[0026] Figure 2 is a structural schematic diagram of a master-slave fault switching quota management device based on a distributed storage cluster according to an embodiment of the present application. DETAILED DESCRIPTION

[0027] The embodiments of the present application will be described in detail below, and examples of the embodiments are shown in the drawings, wherein the same or similar notations represent the same or similar elements or elements with the same or similar functions throughout. The embodiments described below by referring to the drawings are exemplary and are intended to explain the present application, and cannot be understood as a limitation of the present application.

[0028] Furthermore, the terms "first", "second", etc. are used herein only to describe different steps in a process, and do not connote relative importance or an ordering among the steps. Thus, a step that is described as "first" can in some embodiments be performed before or after a step that is described as "second". The meaning of "a", "an", and "the" includes singular and plural referents unless the context clearly dictates otherwise.

[0029] Any process or method described in a flowchart or otherwise described herein can be understood as representing code modules, segments, or portions of code that include one or more executable instructions for implementing specific logic functions (or steps) in the process, and the various embodiments of the application can include additional or fewer steps performing the same or equivalent functions. In some embodiments, the steps can be performed in the order shown or discussed, including in an iterative manner, in reverse order or in substantially simultaneous order.

[0030] Figure 1 is a flowchart of a method for managing quotas based on master-slave fault switching of a distributed storage cluster according to an embodiment of the application.

[0031] As shown in Figure 1 , the method for managing quotas based on master-slave fault switching of a distributed storage cluster includes the following steps:

[0032] S1, the client records the quota increment and pre-application amount in the memory according to the logical clock, and after reporting the increment data, waits for the master quota node to respond and confirm, and accumulates the increment to the local logical clock statistical value.

[0033] Specifically, in the technical solution of the application, the client records the quota increment and pre-application amount in the memory according to the logical clock, and after reporting the increment data, waits for the master quota node to respond and confirm, and accumulates the increment to the local logical clock statistical value, which is one of the key steps to realize high availability and high consistency quota management in a distributed storage system. Based on the logical clock mechanism, combined with the asynchronous communication and confirmation process between the client and the master quota node, this step ensures that the quota operation of the client will not be lost or repeated during the master node fault switching process, thereby ensuring the accuracy of the quota statistics.

[0034] In terms of technical implementation, the client generates an incremental logical clock sequence number each time it performs a quota operation (such as file writing, directory creation, etc.), and records the corresponding quota increment or pre-application amount in the operation log structure in memory, such as using a ring buffer or linked list structure for efficient storage. The client then sends the increment data to the current master quota node through RPC or message queue mechanism, and enters a waiting response state. After receiving the increment data, the master quota node first performs legality verification, including quota total limit, client identity verification, etc. If the verification is passed, the operation is persisted to a distributed storage system (such as a persistent log based on Raft or Paxos protocol), and a confirmation response is sent to the client, including the LCN corresponding to the operation and the persistence state.

[0035] In terms of parameter indicators, the logical clock sequence number (LCN) is usually a 64-bit integer to support unique identification under large-scale concurrent operations. The client carries the maximum LCN completed in the heartbeat response, which is used to clean up the records in memory that have been written to disk, reducing memory usage. After receiving the increment data reported by the client, the master quota node needs to return a confirmation response within a set timeout (such as 2 seconds), otherwise the client will trigger a retry mechanism. In addition, the client also needs to carry the maximum reporting sequence number in each heartbeat, which is used for message deduplication processing by the new master node after failure switching, to avoid repeated statistics.

[0036] In terms of application scenarios, this step is widely applicable to quota management scenarios in distributed storage systems, especially in high-availability operations such as master backup switching and node failure recovery. For example, in a cluster composed of multiple storage nodes, when the master quota node fails, the standby node needs to quickly take over and restore the quota state. The operation data recorded by the client through the logical clock can be merged by the new master node according to the sequence number, thereby generating a globally consistent quota state, avoiding quota over-limit or misjudgment caused by switching.

[0037] The technical effect of this step is to realize the ordered operation synchronization between the client and the master quota node through the logical clock mechanism, ensuring the integrity and consistency of the quota data during the failure switching process. At the same time, combined with the confirmation response mechanism, it effectively prevents data loss and repeated processing, improving the reliability and fault tolerance of the system. Further, this design reduces the synchronization overhead during master backup switching, improves the response efficiency and stability of the system, and is one of the core supporting technologies for realizing "zero error" quota management in distributed systems.

[0038] Further, S1 comprises:

[0039] S11, the client generates an incremental logical clock sequence number according to the operation timestamp and the client identifier at each quota operation, and caches the sequence number together with the quota increment and the pre-application amount in the memory.

[0040] Specifically, in the distributed storage system of the application, the client generates an incremental logical clock sequence number according to the operation timestamp and the client identifier at each quota operation, and caches the sequence number together with the quota increment and the pre-application amount in the memory, which is one of the key steps to realize high availability and high consistency quota management. The technical implementation of this step is based on the logical clock mechanism, combined with the client local cache strategy, to ensure the orderliness and integrity of the quota data during the master-slave switching process.

[0041] In terms of technical implementation, the client first obtains the timestamp of the current operation and generates an incremental logical clock sequence number in combination with the client unique identifier when initiating a quota operation (such as file writing, space application, etc.). The sequence number follows the logical clock algorithm to ensure the orderliness of local operations. A mapping structure (such as a hash table or a queue) is maintained in the client memory to cache the logical clock sequence number, the quota increment, and the pre-application amount. After each operation, the client inserts these data into the cache structure in sequence order for subsequent persistent processing.

[0042] In terms of parameter indicators, the generation of the logical clock sequence number needs to meet the monotonic increasing property, and a 64-bit integer is usually used to support large-scale concurrent operations. The timestamp can be generated based on the system time (such as Unix timestamp) or the logical clock algorithm to ensure the order comparability of cross-client operations. The memory structure cached by the client needs to support high-concurrency read and write, and a thread-safe queue structure is usually used with a cache size upper limit (such as 1000 records) to prevent memory overflow. In addition, the client carries the maximum logical clock sequence number of the completed persistent in the heartbeat response to clean up the cached records that have been written to disk, improving the memory usage efficiency.

[0043] In terms of application scenarios, this step is widely used in distributed storage systems, especially in scenarios such as master-slave switching and node fault recovery. When the client communicates with the master quota node, if the master node fails, the backup node can merge the operations in sequence after becoming the master by using the logical clock sequence number and increment data reported by the client, avoiding data loss or repeated processing. At the same time, this mechanism supports message deduplication by comparing the maximum sequence number reported by the client with the sequence number already processed by the new master node, filtering out repeated or processed messages, thereby ensuring the accuracy of quota statistics.

[0044] At the technical effect level, this step realizes the ordered recording and persistence control of client operations by introducing logical clock sequence numbers, effectively solving the problems of data loss and statistical errors in the process of master-slave switching. The innovation lies in the combination of logical clock mechanism and quota management, which improves the reliability and consistency of the system in the fault switching scenario. At the same time, through memory caching and sequence number management, the real-time dependence on the master node is reduced, and the fault tolerance and response efficiency of the system are enhanced.

[0045] S12, after receiving the confirmation response of the master quota node to the incremental data, the client marks the logical clock sequence number corresponding to the incremental data as having been persisted, and carries the maximum persisted logical clock sequence number in the subsequent heartbeat response, so that the master quota node judges the client data synchronization state.

[0046] Specifically, in a distributed storage system, after receiving the confirmation response of the master quota node to the incremental data, the client marks the logical clock sequence number corresponding to the incremental data as having been persisted, and carries the maximum persisted logical clock sequence number in the subsequent heartbeat response, which is one of the key steps to realize quota state consistency and fault tolerance capability in switching. Based on the logical clock (Logical Clock) mechanism, combined with the asynchronous communication model between the client and the master quota node, it ensures that the new master node can accurately obtain the quota incremental information that has not been persisted by the client when the master node fails to switch, thereby avoiding the quota statistical error caused by data loss or repeated processing.

[0047] Technical implementation level: the client maintains a quota operation queue in memory that increases by logical clock. Each operation (such as quota increment, pre-application) is accompanied by a unique logical clock sequence number. When the client sends incremental data to the master quota node and receives an acknowledgment (ACK), it indicates that the increment has been persisted by the master node to the storage medium (such as NVM, SSD or log file). At this time, the client marks the logical clock sequence number as "persisted" and updates the "maximum persisted logical clock sequence number" maintained locally. In the subsequent heartbeat response, the client reports the maximum persisted logical clock sequence number as metadata, and the master quota node judges the synchronization state of the client according to it, identifies the incremental operation that has not been persisted, and thus accurately replays the data in the event of a fault switch.

[0048] Parameter index level: the logical clock sequence number is usually a 64-bit integer, supporting monotonic increase to ensure operation order. The heartbeat period between the client and the master quota node is set to 5 seconds, and the master node can record the Max Persisted LSN of the client after receiving the heartbeat response, and use it as the basis for data synchronization in the event of a fault switch. In addition, the master node needs to collect the LSN information of all clients after switching to determine the global latest quota state and ensure consistency.

[0049] Application scenario level: This step is widely used in distributed storage systems, especially in scenarios such as failure of the master quota node, network partition, or active offline. When the master node abnormally exits, the monitoring node triggers the master selection process, and the new master node identifies and merges the incremental operations that have not been persisted by querying the Max Persisted LSN of the client, thereby quickly recovering the quota state and ensuring the continuity and data consistency of the system during the fault switching process.

[0050] Technical effect level: By carrying the maximum persisted logical clock sequence number in the heartbeat response, the client can assist the master quota node to achieve accurate synchronization and deduplication of incremental data, effectively avoiding the problems of repeated reporting or data loss caused by network delay or node failure. This mechanism significantly improves the accuracy of quota statistics during the fault switching process of the system, reduces the complexity and time overhead of data recovery, and is an important guarantee means for high-availability and high-reliability quota management.

[0051] S2, when the master quota node fails, the monitoring node selects the backup node with the lowest load as the new master node according to the quota node state mapping table, and notifies the client to update the quota server mapping relationship.

[0052] Specifically, when the master quota node fails, the monitoring node selects the backup node with the lowest load as the new master node according to the quota node state mapping table maintained by the cluster, and notifies the client to update the quota server mapping relationship. This step is one of the core mechanisms for implementing high-availability quota management in the present application, and its technical implementation is based on the cooperative mechanism of node state monitoring, load evaluation, and client mapping update in a distributed system.

[0053] In terms of technical implementation, the monitoring node monitors the running state of each quota node through a periodic heartbeat detection mechanism (sending a heartbeat packet every 5 seconds). When the master quota node does not respond for 3 consecutive heartbeat periods (i.e. within 15 seconds), the monitoring node determines it as a failed node and triggers the master node switching process. During the switching process, the monitoring node first filters all backup quota nodes in the "up" state from the state mapping table, and scores them based on their load indicators (including CPU usage, memory usage, network bandwidth, etc.), and selects the node with the lowest score (i.e. the lightest load) as the new master node. This process ensures that the new master node has sufficient resources to handle subsequent quota requests, thereby improving the overall stability of the system.

[0054] In terms of parameter indicators, the heartbeat detection period is set to 5 seconds, and the fault determination threshold is 3 consecutive non-responses, i.e., no heartbeat response received within 15 seconds. The load scoring algorithm optionally uses a weighted average method, such as a CPU usage weight of 40%, a memory usage of 30%, and a network bandwidth of 30%, to comprehensively evaluate the idle degree of the node. After the new master node is elected, the monitoring node sends the updated quota server map to all clients through the message broadcast mechanism (such as gRPC or message queue) within the cluster, and the clients update the local cached master node address accordingly to ensure correct routing of subsequent quota requests.

[0055] In application scenarios, this step is applicable to scenarios such as main quota node downtime, network interruption, or process abnormal exit in a distributed storage system. For example, in a three-node cluster, if the master node stops responding due to hardware failure, the monitoring node will immediately start the switching process, select the backup node with the lightest load to take over the master node responsibilities, and ensure business continuity through client mapping update mechanism.

[0056] The technical effect of this step is that through dynamic load evaluation and client mapping update, seamless switching of master and backup nodes is achieved, avoiding quota service interruption or data inconsistency problems caused by master node failure. At the same time, by preferentially selecting the node with the lowest load as the new master node, the performance and stability of the system after fault switching are effectively improved, providing an efficient and reliable quota management mechanism for distributed storage systems.

[0057] Further, S2 comprises:

[0058] S21, when selecting a new master node, the monitoring node performs weighted scoring based on the CPU usage, memory usage, and network bandwidth in the quota node state mapping table, and selects the backup node with the lowest score as the new master node.

[0059] Specifically, in a distributed storage cluster, when the main quota node fails, the monitoring node needs to select one of the backup nodes as the new master node. This step performs weighted scoring based on the three key indicators in the quota node state mapping table—CPU usage, memory usage, and network bandwidth—and selects the backup node with the lowest score as the new master node. The core of this mechanism is to ensure that the new master node has the best resource availability through dynamic load evaluation, thereby improving the stability and response efficiency of the system during the fault switching process.

[0060] In terms of technical implementation, the monitoring node periodically (e.g., every 5 seconds) collects real-time load information of each quota node and records it in a quota node state mapping table. The table is a globally shared data structure that contains the primary and backup roles of each node, resource usage status, and the latest heartbeat timestamp. After the fault switching trigger, the monitoring node first filters out the backup nodes currently in the "up" state, and then scores each node according to the pre-set weighted algorithm.

[0061] In application scenarios, this step is suitable for distributed storage systems with a large number of cluster nodes and frequent load fluctuations. For example, in a cluster containing 5 quota nodes, when the primary node is marked as "down" due to high load or failure, the monitoring node will quickly select the backup node with the least resource occupation based on the above scoring mechanism to minimize switching delay and ensure the continuity of quota service. After taking over the service, the new primary node will broadcast map change information to the client and synchronize the client's quota increment data to ensure global consistency.

[0062] The technical effect of this step is that by introducing a weighted scoring mechanism, it realizes load-sensitive election of the primary node, effectively avoiding the situation where a resource-starved node is mistakenly selected as the primary node, thereby improving the overall availability and fault tolerance of the system. At the same time, the configurability of the scoring parameters enhances the adaptability of the system in different deployment environments, providing key support for high-precision, low-latency fault switching.

[0063] S22, when notifying the client to update the quota server mapping relationship, the monitoring node sends an update instruction in a broadcast manner, and after the client receives the update instruction, caches the IP address and port information of the new primary node to the local for subsequent routing selection of quota operations.

[0064] Specifically, in a distributed storage system, when the monitoring node detects the failure of the primary quota node and completes the election of the new primary node, it needs to ensure that the client can timely perceive and update its routing relationship with the quota server to guarantee the continuity and consistency of subsequent quota operations. To this end, when notifying the client to update the quota server mapping relationship, the present application sends an update instruction in a broadcast manner, and after the client receives the instruction, caches the IP address and port information of the new primary node to the local for subsequent routing selection of quota operations.

[0065] In some implementations, the monitoring node sends quota server mapping relationship update instructions to all registered clients through a communication protocol inside the cluster, such as a TCP / UDP-based multicast or broadcast mechanism. The instructions contain the IP address, port number of the new master node, and version number of the current quota server state mapping table (Map). After receiving the broadcast instructions, the client first verifies whether the version number is higher than the locally cached version. If the verification is passed, the local quota server Map cache is updated, and the IP and port information of the new master node is written into the routing table structure (such as a hash table or a linked list) in the local memory for subsequent routing decisions of quota requests.

[0066] Further, after updating the local cache, the client will preferentially route quota operation requests (such as quota application, usage reporting, etc.) to the new master node to ensure the continuity of the operation. At the same time, after establishing a connection with the new master node, the client will re-synchronize its logical clock state to ensure the consistency of the quota data. In this step, the use of the broadcast mechanism effectively reduces communication overhead and delay, ensuring that all clients complete mapping updates in the shortest time, thereby improving the overall availability and fault tolerance of the system.

[0067] Optionally, the sending period of the broadcast instructions can be set to once every 5 seconds, consistent with the client heartbeat period, to ensure that the client can respond in time. The IP address and port information of the new master node need to comply with the IPv4 / IPv6 standard and support port range configuration (such as default port 9000-9999) to adapt to deployment requirements in different network environments.

[0068] This step plays a key role in routing switching and state synchronization in the entire technical solution. By combining the broadcast mechanism with local cache updates, it effectively solves the problem of quota operation failure or data inconsistency caused by the lag of client routing information during master-backup switching, improving the high availability and stability of the system.

[0069] S3, the new master quota node sends a state query request to all normal clients, collecting the current logical clock increment data and maximum reporting sequence number of the clients.

[0070] Specifically, in a distributed storage system, when the master quota node fails and the backup node is promoted to master, the new master quota node needs to ensure that the quota status of all clients in the system is consistent with itself to avoid quota statistical errors caused by switching. To this end, the new master quota node sends a state query request to all normal clients, collecting the current logical clock increment data and maximum reporting sequence number of the clients. This process is a key step to achieve global quota consistency guarantee.

[0071] In terms of technical implementation, the new master quota node first obtains the current active client identifiers (such as client ID or IP address) through the client list and constructs a state query request message. This message is usually transmitted using a lightweight protocol (such as gRPC or a custom TCP protocol) to reduce network latency. The request includes the identification information and current version number of the new master node. Upon receiving the request, the client extracts the logical clock record quota increment data (such as cumulative values of file creation, deletion, write size, etc.) and the maximum reported sequence number from local memory, and encapsulates these data in a response message to return to the new master node. The logical clock usually uses the Lamport timestamp mechanism to ensure the causal order consistency of operations between the client and the quota node.

[0072] In terms of parameter indicators, the update period of the logical clock is usually consistent with the client heartbeat period, i.e., updated every 5 seconds to ensure the real-time nature of state synchronization. The maximum reported sequence number is used to identify the last quota operation record that the client has successfully persisted to the master node. By comparing this sequence number with its own persisted records, the new master node can identify and filter duplicate or non-disk operations, thereby achieving message deduplication. In addition, the new master node will be in a temporary lock state before all client responses are collected, and will return a "retry" error code to any new quota reporting or pre-application request, preventing the processing of new requests before the data is fully synchronized, and ensuring the accuracy of quota statistics.

[0073] In application scenarios, this step mainly occurs in the quota state recovery phase after the master-slave switchover. For example, in a three-node distributed storage cluster, when the master node is determined to be faulty due to three consecutive heartbeat timeouts (15 seconds), the standby node becomes the master and immediately initiates a state query request to quickly rebuild the global quota state. The increment data and sequence number carried in the client's response will be used by the new master node to replay operations in logical clock order, generating a consistent quota snapshot.

[0074] The technical value of this step lies in the logical clock-driven increment data collection and sequence number comparison mechanism, which effectively avoids the quota inconsistency problem caused by data loss or duplication in traditional master-slave switchover, improving the reliability and consistency guarantee capability of the system during the fault switching process. It is the core link to achieve "zero error" quota management.

[0075] Further, S3 includes:

[0076] S31, before sending the state query request, the new master quota node first obtains the IP addresses and state information of all normal clients from the monitoring node to ensure that the query request is sent only to active clients.

[0077] Specifically, after the new primary quota node completes the primary-backup switchover and takes over the quota service, before sending the state query request, it first obtains the IP addresses and state information of all current normal clients from the monitoring node. The technical implementation of this step is based on the state synchronization mechanism in distributed systems, aiming to ensure that the new primary node only initiates queries to clients in the active state, thereby avoiding invalid communication, resource waste, and quota statistical errors caused by inconsistent client states.

[0078] At the technical implementation level, the monitoring node, as the global manager of the cluster state, maintains a client state mapping table that records the IP address, connection state, last heartbeat timestamp, and other key information of each client. After taking over the service, the new primary quota node initiates a state query request through the communication interface (such as gRPC or REST API) with the monitoring node to obtain the latest snapshot of the mapping table. Upon receiving the request, the monitoring node filters out clients in the "active" state based on the pre-set heartbeat detection mechanism (such as a heartbeat every 5 seconds, and 3 consecutive non-responses are considered abnormal) and returns the IP addresses and state information of these clients to the new primary node.

[0079] In terms of parameter indicators, this step involves multiple key parameters, including the heartbeat detection period (5 seconds), the heartbeat timeout threshold (3 consecutive non-responses, i.e., 15 seconds without response is considered abnormal), the definition of the client state field, and the QoS (Quality of Service) requirements of the communication protocol, ensuring the real-time and reliability of the state information. In addition, after receiving the client state information, the new primary node will build a local client connection whitelist for subsequent routing control of state query requests.

[0080] In application scenarios, this step usually occurs in the switchover process after the primary quota node fails and the standby node is elected as the new primary node. The new primary node needs to quickly synchronize the quota states of the clients to ensure that the system can maintain the accuracy and consistency of quota statistics after the switchover. By sending query requests only to active clients, network load and response delay can be effectively reduced, improving the overall availability and response efficiency of the system.

[0081] The technical effect of this step is that by introducing a client state filtering mechanism, the new primary node can accurately identify currently communicable clients, avoiding sending invalid requests to disconnected or abnormal clients, thereby improving the data synchronization efficiency and accuracy during the system switchover process. At the same time, this mechanism, combined with the quota merging process driven by the logical clock, provides a reliable data source for subsequent consistency recovery, and is one of the key links to achieve "zero-error" quota statistics in the fault switchover process.

[0082] S32, the new master quota node sets a response timeout mechanism when collecting client data, and if the client does not return a response within a preset time, the client is marked as abnormal and its data is ignored in subsequent merging operations.

[0083] Specifically, after the new master quota node completes the master-standby switchover, its primary task is to collect the quota increment and pre-application amount of the client to ensure that the system can quickly recover and maintain the consistency of the quota state after switchover. To this end, the application introduces a response timeout mechanism in the communication between the new master quota node and the client to deal with the situation of delayed response or disconnection of the client, thereby improving the fault tolerance and data integrity of the system.

[0084] In terms of technical implementation, the new master quota node sends a state query request to all normally connected clients, requiring the clients to report the quota increment and pre-application amount recorded by their current logical clock. After receiving the request, the client needs to return a response within a preset time. If the client fails to return a valid response within the time, the new master node will mark it as an abnormal client and ignore its data in subsequent quota data merging operations. This mechanism sets a timeout threshold to avoid blocking problems caused by abnormal client communication, ensuring that the new master node can complete data collection and state reconstruction in a timely manner.

[0085] In terms of specific parameter settings, the client response timeout time can be configured according to the actual network environment and system load, with typical values ranging from 5 seconds to 10 seconds. This parameter needs to be defined in the system configuration file and loaded when the new master node starts. In addition, the client needs to carry the maximum reporting sequence number in the response, which is used for message deduplication processing by the new master node to prevent errors caused by repeated operations.

[0086] In application scenarios, this step is mainly applied to the fast recovery process after the master quota node fails in a distributed storage system. When the master node abnormally exits, the new master node needs to complete the collection and merging of client data in the shortest time to ensure the continuity of system services. If some clients fail to respond in a timely manner due to network delay or their own failure, they will be excluded through the timeout mechanism to avoid affecting the overall recovery efficiency due to the abnormality of individual clients.

[0087] From a technical effect point of view, this response timeout mechanism effectively improves the robustness and recovery efficiency of the system during the fault switchover process. By setting a reasonable timeout threshold, the system can quickly identify and isolate abnormal clients while ensuring data consistency, thereby ensuring that the new master node only processes valid information when merging data, avoiding quota calculation errors or system delays caused by invalid responses. Further, this mechanism, combined with the merging strategy driven by the logical clock, provides a key guarantee for achieving zero-error quota statistics.

[0088] S4, the new master quota node merges and replays the operations according to the incremental data returned by the client and the maximum reporting sequence number in logical clock order to generate a globally consistent quota state.

[0089] Specifically, after the new master quota node completes the master-standby switchover, one of its core tasks is to merge and replay the operations according to the incremental data returned by the client and the maximum reporting sequence number in logical clock order to generate a globally consistent quota state. This step is a key technical link for achieving the consistency and accuracy of quota data during the switchover process.

[0090] From a technical implementation perspective, after taking over the quota service, the new master quota node first sends a state query request to all clients in the "normal" state, requiring them to return the quota incremental data recorded in the current memory and the corresponding maximum reporting sequence number. After receiving the request, the client organizes its local incremental operation records in logical clock order, including the increase of quota usage and the submission of pre-application amount. Each operation record is attached with an increasing logical clock sequence number to identify the time sequence of the operation. After receiving the responses from all clients, the new master node sorts the incremental operations according to the logical clock sequence number to ensure that the causal relationship and time sequence of the operations are not destroyed. Subsequently, the new master node replays these operations one by one to update its local quota state, including the total amount of quota, the used amount, and the remaining usage of the key indicators.

[0091] From a parameter index perspective, the logical clock sequence number is a 64-bit integer with an initial value of 0, which is incremented each time the client performs a quota operation. The maximum reporting sequence number is used to identify the latest operation sequence number that the client has successfully persisted to the master node, and the new master node filters out the old data that has been persisted to avoid duplicate processing. In the switchover process, the new master node needs to complete the collection and merging of incremental data from all clients within 15 seconds to ensure that the system recovery time objective (RTO) is controlled within an acceptable range. The client reports the data within the heartbeat period (5 seconds) to ensure the real-time and completeness of the incremental data.

[0092] From an application scenario perspective, this step is applicable to the fast recovery scenario after the master quota node fails in a distributed storage system. For example, in a three-node cluster, when the master node is determined to be faulty due to heartbeat timeout (3 consecutive non-responses, i.e., 15 seconds), the standby node is elected as the new master node and immediately starts the incremental data collection process. After receiving the query from the new master node, the client returns the quota operations that have not been persisted in its memory, and the new master node rebuilds the global quota state to ensure that the system can still provide accurate quota control services after the switchover.

[0093] On the technical effect level, through the ordered merging and replay of the logical clock sequence number, the new master node can accurately restore the operation record of the client during the fault switching, avoiding the quota statistical error caused by operation disorder or loss. Meanwhile, combined with the message deduplication mechanism of the maximum reporting sequence number, the redundant processing is effectively reduced, and the switching efficiency is improved. This step guarantees the strong consistency of the quota state in the distributed system, and is a key technical support for realizing high availability and zero-error quota management.

[0094] The master / standby fault switching quota management method based on the distributed storage cluster in the embodiment of the application realizes zero-error statistics of quota data in the master / standby fault switching process, and guarantees the high availability and consistency of the distributed storage cluster.

[0095] In addition, in the embodiment of the application, after the old master quota node is restored, the old master quota node sends a version number query request to the monitoring node, the monitoring node compares the version number of the current master node with the version number of the old master node, if the version number of the old master node is lower than the version number of the current master node, the old master node is notified to automatically downgrade to a standby node, and the local cached quota state information of the old master node is cleared.

[0096] Specifically, in the distributed storage cluster, after the old master quota node is restored, the old master quota node sends a version number query request to the monitoring node, which is a key step to realize the consistency of the master / standby node state and avoid the conflict of the double master. The technical implementation of this step is based on the version number comparison mechanism, combined with the heartbeat detection and the update logic of the state mapping table (Map), to ensure that the system can still maintain the global consistency of the quota state after the fault recovery.

[0097] On the technical implementation level, after the old master node is restored, the old master node first sends a version number query request to the monitoring node through a predefined communication protocol (such as gRPC or a custom TCP protocol). The version number is usually an incremental integer sequence number (such as a 64-bit unsigned integer), which is automatically incremented and persistently stored by the monitoring node each time the master node switches. After receiving the request, the monitoring node extracts the version number of the current master node from the quota node state mapping table it maintains, and compares it with the version number carried by the old master node. If the version number of the old master node is lower than the version number of the current master node, the monitoring node will trigger the downgrade process and notify the old master node to automatically switch to a standby node through a control message.

[0098] On the parameter index level, the version number comparison mechanism needs to meet the following conditions: the length of the version number field should support at least 10 years of incremental demand (such as 64 bits), the version number update needs to be strictly bound to the master node switching event to ensure the uniqueness and monotonicity of the version number. In addition, the monitoring node needs to maintain the mapping relationship between the version number and the master node identity to support fast query and comparison. This mechanism usually works in coordination with the heartbeat detection mechanism, and the heartbeat period is 5 seconds. If it is timed out for 3 times (15 seconds) in succession, it is determined that the node is faulty, thereby ensuring the timeliness of the version number update.

[0099] At the application level, this step is suitable for state synchronization scenarios after a master node failure in a distributed storage system. For example, in a three-node cluster, if the original master node is temporarily offline due to network interruption or hardware failure, the standby node takes over the master node's responsibilities through an election mechanism and generates a new version number. When the original master node recovers, if its version number has not been updated, it indicates that its state is lagging behind and it needs to be automatically downgraded to a standby node to prevent it from continuing to process quota requests and causing data inconsistency.

[0100] From a technical perspective, this step effectively avoids the "dual-master" conflict caused by the old master node recovering and simultaneously processing quota requests with the new master node, ensuring that only one master node is always responsible for quota decisions in the system. Simultaneously, by clearing the quota status information cached locally on the old master node, it prevents it from making incorrect judgments based on expired data, thereby ensuring the accuracy and consistency of quota statistics across the entire cluster. This mechanism, combining logical clock and version number control, achieves lightweight and highly reliable state synchronization, representing a significant innovation of this invention in terms of high availability and data consistency.

[0101] The primary / standby fault failover quota management method based on distributed storage clusters in this invention achieves automatic synchronization between the old primary quota node and the current primary node status through a version number comparison mechanism after the old primary quota node recovers. This ensures that the old primary node is accurately downgraded and expired quota status information is cleared, thereby further improving the data consistency and system stability of the distributed storage cluster after primary / standby failover.

[0102] To implement the above embodiments, the present invention also proposes a primary / backup failover quota management device based on a distributed storage cluster. Figure 2 This is a schematic diagram of the structure of a primary / standby fault-failure switching quota management device based on a distributed storage cluster, provided in an embodiment of the present invention. Figure 2 As shown, the device includes:

[0103] The logical clock recording module 100 is used to record quota increments and pre-request amounts in the client's memory according to the logical clock, and after reporting the incremental data, wait for the main quota node to respond and confirm, and then accumulate the increment to the local logical clock statistics.

[0104] The master node switching control module 200 is used to select the standby node with the lowest load as the new master node according to the quota node status mapping table when the master quota node fails, and to notify the client to update the quota server mapping relationship.

[0105] The status query sending module 300 is used by the new primary quota node to send status query requests to all normal clients, and to collect the incremental data of the current logical clock of the client and the maximum reporting sequence number.

[0106] The quota state merging module 400 is configured to merge and replay operations in the logical clock order according to the incremental data and the maximum reporting sequence number returned by the client, and generate a globally consistent quota state.

[0107] As to the apparatus in the above-mentioned embodiments, the specific manners in which various modules perform operations have been described in detail in the embodiments of the method, and thus will not be described in detail here.

[0108] In order to implement the above-mentioned embodiments, the present application further provides an electronic device, comprising a processor and a memory connected with the processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to implement the method provided by the foregoing embodiments.

[0109] In order to implement the above-mentioned embodiments, the present application further provides a computer readable storage medium, wherein the computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by a processor to implement the method provided by the foregoing embodiments.

[0110] In order to implement the above-mentioned embodiments, the present application further provides a computer program product, comprising a computer program, wherein the computer program is executed by a processor to implement the method provided by the foregoing embodiments.

[0111] The collection, storage, use, processing, transmission, provision and disclosure of the personal information of the user involved in the present application comply with the relevant laws and regulations and do not violate public order and good customs.

[0112] It should be noted that the personal information from the user should be collected for legal and reasonable purposes, and should not be shared or sold outside these legal uses. In addition, such collection / sharing should be carried out after the user's informed consent is received, including but not limited to informing the user to read the user agreement / user notice before the user uses the function, and signing the agreement / authorization including authorization of relevant user information. In addition, any necessary steps should be taken to protect and ensure access to such personal information data, and to ensure that other people with access to personal information data comply with their privacy policy and processes.

[0113] The present application is expected to provide embodiments in which the user can selectively prevent the use or access of personal information data. That is, the present disclosure is expected to provide hardware and / or software to prevent or block access to such personal information data. Once the personal information data is no longer needed, the risk is minimized by limiting data collection and deleting data. In addition, such personal information is de-identified, if applicable, to protect the privacy of the user.

[0114] In the foregoing detailed description of embodiments of the application, reference is made to the drawings, which form a part hereof, and in which are shown by way of illustration embodiments in which the subject matter of the application can be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the application, and it is to be understood that other embodiments can be utilized and that changes can be made without departing from the scope of the present application. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present application is defined only by the appended claims.

[0115] Furthermore, the terms "first", "second", or the like, are used herein only to describe various steps or operations in a circuit, process, or the like, and do not imply a relative importance or a specific order of the steps or operations. Thus, the features defined by the terms "first", "second", etc. can include at least one of the features, explicitly or implicitly. In the description of the application, the meaning of "a plurality" is at least two, such as two, three, etc., unless otherwise expressly specified.

[0116] Any process or method descriptions or blocks in flow charts described herein and elsewhere can be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of the preferred embodiments of the present application in which additional functionality can be added or some functionality can be removed, by adding, removing or modifying operations in the modules, and each of the variations of these are also contained within the scope of the application. The processes depicted in the flow charts can also be performed in an alternative order, or in parallel, unless otherwise specifically stated.

[0117] The logic and / or steps represented in flow diagrams or otherwise described herein, for example, can be considered as a sequence of instructions to implement logic functions, and can be embodied in any computer-readable medium for use by an instruction execution system, apparatus, or device, such as a computer-based system, processor- containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this specification, a "computer-readable medium" can be any means that can contain, store, communicate, propagate or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-readable medium can be a machine-readable storage device (e.g., magnetic, optical or other) a machine-readable storage diskette (e.g., floppy disk, optical disk, CD- ROM, etc.), a machine- readable storage card (e.g., PCMCIA card, etc.), a machine-readable storage tape (e.g., magnetic tape, optical tape, etc.), a machine-readable storage medium (e.g., RAM, ROM, etc.), a machine-readable signal (e.g., electrical, optical, etc.), a machine-readable medium (e.g., carrier wave, etc.) or any other suitable medium or means of embodying the program. More specific examples (a non-exhaustive list) of the computer-readable medium include the following: an electrical connection having one or more wires (e.g., a bus that has thin film resistors for

[0118] It should be understood that aspects of the application can be implemented in hardware, software, firmware or combinations thereof. In the embodiments described above, various steps or methods can be implemented in software or firmware that is stored in memory and executed by suitable instruction execution systems. As such, in some embodiments, memory (including computer-readable media) can store software, firmware or programs of instructions that can be executed by the instruction execution system to implement the methods and carry out the steps involved. For example, if implemented in hardware, as in another embodiment, any of the following techniques, which are well known in the art of making integrated circuits, can be used to implement the various techniques and / or functions: a discrete logic circuit(s) having logic gates for implementing logic functions upon data signals, an application specific integrated circuit having appropriate combinational logic gates, a programmable gate array(s) (PGA), a field programmable gate array (FPGA), etc.

[0119] Those of skill in the art would understand that information and signals can be represented using any of a variety of technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that can be referenced throughout the above description can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0120] In addition, each function unit in each embodiment of the present application can be integrated in one processing module, or each unit can be physically present separately, or two or more units can be integrated in one module. The integrated module can be realized in the form of hardware or in the form of a software function module. When the integrated module is realized in the form of a software function module and sold or used as an independent product, it can also be stored in a computer readable storage medium.

[0121] The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it should be understood that the above embodiments are exemplary and should not be construed as limiting the present application, and those skilled in the art can make changes, modifications, replacements and variations to the above embodiments within the scope of the present application.

[0122] It should be understood that various forms of flow shown above can be reordered, added or deleted. For example, each step described in the present application can be executed in parallel, sequentially or in different order, as long as the desired results of the technical solutions of the present application can be achieved, which is not limited herein.

[0123] The above detailed description does not constitute a limitation on the scope of protection of the present application. Those skilled in the art should understand that various modifications, combinations, sub-combinations and replacements can be made according to design requirements and other factors. Any modifications, equivalent replacements and improvements within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A method for managing primary / standby failover quotas based on a distributed storage cluster, characterized in that, include: S1, the client records the quota increment and pre-request amount in memory according to the logical clock, and waits for the main quota node to respond and confirm after reporting the incremental data, and then adds the increment to the local logical clock statistics. S2, When the primary quota node fails, the monitoring node selects the standby node with the lowest load as the new primary node according to the quota node status mapping table, and notifies the client to update the quota server mapping relationship. S3, the new primary quota node sends a status query request to all normal clients to collect the incremental data of the current logical clock of the clients and the maximum reporting sequence number; S4, the new primary quota node merges and replays the operations according to the incremental data returned by the client and the maximum reporting sequence number in logical clock order to generate a globally consistent quota status.

2. The method as described in claim 1, characterized in that, The client records quota increments and pre-request amounts in memory according to the logical clock, and waits for confirmation from the primary quota node after reporting the incremental data. It also accumulates the increments to the local logical clock statistics. S11, each time the client performs a quota operation, it generates an incrementing logical clock sequence number based on the operation timestamp and the client identifier, and caches this sequence number, along with the quota increment and the pre-request amount, in memory; S12, after receiving the confirmation response from the primary quota node for the incremental data, the client marks the logical clock sequence number corresponding to the incremental data as persisted, and carries the maximum persisted logical clock sequence number in the subsequent heartbeat response so that the primary quota node can determine the client's data synchronization status.

3. The method as described in claim 1, characterized in that, When the primary quota node fails, the monitoring node selects the standby node with the lowest load as the new primary node based on the quota node status mapping table, and notifies the client to update the quota server mapping relationship. This also includes: S21, When selecting a new master node, the monitoring node performs a weighted score based on three indicators in the quota node status mapping table: CPU utilization, memory utilization, and network bandwidth, and selects the backup node with the lowest score as the new master node. S22. When the monitoring node notifies the client to update the quota server mapping relationship, it sends the update command via broadcast. After the client receives the update command, it caches the IP address and port information of the new master node locally for routing selection in subsequent quota operations.

4. The method as described in claim 1, characterized in that, The new primary quota node sends status query requests to all normal clients, collects incremental data of the client's current logical clock and the maximum reported sequence number, and also includes: S31. Before sending a status query request, the new primary quota node first obtains the IP addresses and status information of all currently active clients from the monitoring node to ensure that the query request is only sent to clients that are active. S32, when the new primary quota node collects client data, it sets a response timeout mechanism. If the client does not return a response within a preset time, the client is marked as abnormal and its data is ignored in subsequent merge operations.

5. The method as described in claim 1, characterized in that, Also includes: After the old primary quota node recovers, it sends a version number query request to the monitoring node. The monitoring node compares the version number of the current primary node with the version number of the old primary node. If the version number of the old primary node is lower than that of the current primary node, it notifies the old primary node to automatically downgrade to a backup node and clears its locally cached quota status information.

6. A primary / backup failover quota management device based on a distributed storage cluster, characterized in that, include: The logical clock recording module is used to record quota increments and pre-request amounts in the client's memory according to the logical clock, and after reporting the incremental data, wait for the main quota node to respond and confirm, and then accumulate the increment to the local logical clock statistics. The master node switching control module is used to select the standby node with the lowest load as the new master node according to the quota node status mapping table when the master quota node fails, and to notify the client to update the quota server mapping relationship. The status query sending module is used by the new primary quota node to send status query requests to all normal clients, and to collect the incremental data of the current logical clock of the client and the maximum reporting sequence number. The quota status merging module is used by the new primary quota node to merge and replay the operations according to the incremental data returned by the client and the maximum reporting sequence number in logical clock order, thereby generating a globally consistent quota status.

7. The apparatus as claimed in claim 6, characterized in that, The logic clock recording module is also used for: Each time the client performs a quota operation, it generates an incrementing logical clock sequence number based on the operation timestamp and the client identifier, and caches this sequence number, along with the quota increment and the pre-request amount, in memory. After receiving the confirmation response from the primary quota node for incremental data, the client marks the logical clock sequence number corresponding to the incremental data as persisted and carries the maximum persisted logical clock sequence number in the subsequent heartbeat response so that the primary quota node can determine the client's data synchronization status.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-5.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-5.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-5.

Images