Current limiting methods and devices

Abstract

This application provides a rate limiting method, apparatus, computer device, computer-readable storage medium, and computer program product, belonging to the field of data processing. The rate limiting method includes: receiving rate limiting parameters broadcast by a master node of a distributed system, the rate limiting parameters including at least a global start time; determining the current warming-up phase of the node based on the global start time and the current time, the warming-up phase corresponding to several phases with different request rates, where each subsequent phase has a higher request rate than the previous phase, the request rate being the rate at which a target service is called, and the node being any execution node of the distributed system; and dynamically adjusting the request rate of the node calling the target service based on the warming-up phase. The technical solution of this application embodiment can achieve a gradual warming-up of the QPS (Queries Per Second) of a distributed system calling a target service, improving the stability of the target service calls and the overall success rate of the task.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a current limiting method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] In business scenarios such as brand operation, recommendation, and advertising, there is often a need for automated analysis of massive amounts of text data, such as sentiment recognition, brand relevance recognition, and industry relevance judgment. With the development of Large Language Model (LLM) capabilities, more and more distributed computing clusters are calling external LLM services in batches through HTTP interfaces to perform inference on each piece of text, and then storing the results in a data warehouse for use by downstream products.

[0003] To avoid traffic surges from external calls to the large language model service, rate limiting is typically required. Currently, the common approach is to reduce the impact by limiting the absolute access volume over a period of time, such as QPS (queries per second) and TPS (requests per second). However, when the required resources or peak values ​​are extremely high, this will impact all the resources of the large language model service provider. Even if the QPS and TPS are within the allowable range of the large language model service provider, it will trigger the provider's sudden flow control policy, causing a concentrated burst of request failures and retry requests, thus reducing the overall success rate of the task.

[0004] It should be noted that the above content is not necessarily prior art, nor is it intended to limit the scope of patent protection of this application. Summary of the Invention

[0005] This application provides a current limiting method, apparatus, computer device, computer-readable storage medium, and computer program product to solve or alleviate one or more of the technical problems mentioned above.

[0006] One aspect of this application provides a rate limiting method, the method comprising:

[0007] Receive rate limiting parameters broadcast by the master node of the distributed system, wherein the rate limiting parameters include at least the global start time; The current warming phase of this node is determined based on the global start time and the current time. The warming phase corresponds to several phases with different request rates, and the request rate of the later phase is greater than that of the previous phase. The request rate is the rate at which the target service is called. This node is any execution node of the distributed system. The request rate for this node to call the target service is dynamically adjusted based on the heating phase.

[0008] Optionally, the current limiting parameters may also include the number of heating stages, the duration of each heating stage, and the request rate corresponding to each heating stage.

[0009] Optionally, the rate limiting parameter also includes the node maximum rate quota. The request rate of each stage in the warm-up phase is obtained based on the node maximum rate quota, which is obtained by the master node based on the number of execution nodes and the global maximum request rate.

[0010] Optionally, after receiving the rate limiting parameters broadcast by the distributed system master node, the method further includes: Obtain the partition identifier of the current data partition of the current node, and determine the target delay time of the current data partition based on the partition identifier; Determine whether the target delay time has been reached based on the global start time and the current time; If the target delay time is reached, the current data partition begins to call the target service based on the control of the request rate during the warm-up phase.

[0011] Optionally, before determining the current heating stage of the node based on the global start time and the current time, the method further includes: Receive the serialized rate limiter class definition sent by the master node, wherein the rate limiter class definition removes the lock object during serialization; The rate limiter class definition is deserialized and the lock field in the rate limiter class definition is initialized to an uncreated state, resulting in the deserialization result of the rate limiter class definition. Based on the result of deserialization of the current limiter class definition, a current limiter instance is created on this node. The current limiter instance is used to execute the steps of determining the current heating stage of this node and subsequent steps based on the global start time and the current time. If the rate limiter instance is used and it is determined that the lock has not been created, a target lock object is created on the local node. The target lock object is used to control the contention of multiple threads on the local node calling the target service.

[0012] Optionally, the creation of a rate limiter instance on this node based on the deserialization result of the rate limiter class definition includes: In the case of processing the first data partition of the current node, a rate limiter instance is created on the current node based on the result of deserialization of the rate limiter instance class and the rate limiter parameters; The rate limiter instance is cached or stored as a static variable in this node for reuse by all data partitions of this node.

[0013] Optionally, the method further includes: Obtain the target data obtained after the local node calls the target service and processes it; The target data is returned to the master node so that the master node can write the target data into the target storage module according to a preset format.

[0014] Another aspect of this application provides a current limiting device, the device comprising: A receiving module is used to receive rate limiting parameters broadcast by the master node of the distributed system, wherein the rate limiting parameters include at least the global start time; The determination module is used to determine the current warming stage of the node based on the global start time and the current time. The warming stage corresponds to several stages with different request rates, and the request rate of the later stage is greater than that of the previous stage. The request rate is the rate at which the target service is called. The node is any execution node of the distributed system. The rate limiting module is used to dynamically adjust the request rate of the local node calling the target service based on the heating phase.

[0015] Another aspect of this application provides a computer device, including: At least one processor; and A memory that is communicatively connected to the at least one processor; Wherein: the memory stores instructions that can be executed by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method as described above.

[0016] Another aspect of this application provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the method described above.

[0017] Another aspect of this application provides a computer program product including a computer program that, when executed by a processor, implements the method described above.

[0018] The embodiments of this application employing the above-described technical solution may have the following advantages: By receiving rate-limiting parameters broadcast by the distributed system's master node, which include at least a global start time, the current warming-up phase of the node is determined based on the global start time and the current time. Each warming-up phase corresponds to several stages with different request rates, with each subsequent stage having a higher request rate than the previous one. The request rate of the node calling the target service is dynamically adjusted based on the warming-up phase. Rate limiting can be implemented by broadcasting rate-limiting parameters from the master node, allowing for unified global control of QPS. This also avoids issues such as memory overflow and extended task execution time caused by pulling large amounts of data back to the master node, thus improving task execution efficiency. Furthermore, controlling the request rate through different warming-up phases allows QPS to gradually increase, improving the stability of target service calls and the overall task success rate. Additionally, the global start time allows all execution nodes to share the same time scale, helping to maintain a consistent rate-limiting warming-up rhythm. Attached Figure Description

[0019] The accompanying drawings exemplify embodiments and form part of the specification, serving together with the textual description to explain exemplary implementations of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of the claims. Throughout the drawings, the same reference numerals refer to similar but not necessarily identical elements.

[0020] Figure 1 A flowchart illustrating the current limiting method according to Embodiment 1 of this application is shown schematically; Figure 2 The illustration shows a new process in the rate limiting method according to Embodiment 1 of this application; Figure 3 This illustration schematically shows another additional process of the flow limiting method according to Embodiment 1 of this application; Figure 4 Schematic illustration Figure 3 Flowchart of the sub-steps in step S404; Figure 5 This illustration schematically shows another additional process of the flow limiting method according to Embodiment 1 of this application; Figure 6 This diagram illustrates the system architecture of the rate limiting method according to Embodiment 1 of this application in a Spark scenario. Figure 7 Schematic illustration Figure 6 Corresponding modules and processes; Figure 8 This illustration schematically shows a flowchart of the rate limiting method according to Embodiment 1 of this application in a Spark scenario; Figure 9 A block diagram of a current limiting device according to Embodiment 2 of this application is schematically shown; and Figure 10A schematic diagram of the hardware architecture of a computer device according to Embodiment 3 of this application is shown. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0022] It should be noted that the descriptions involving "first," "second," etc., in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0023] It should be noted that, in any stage of this application involving the collection, storage, use, transmission, and processing of data, each stage strictly adheres to the laws, regulations, industry standards, and regulatory requirements of the data source, usage location, and relevant countries and regions to ensure the legality and compliance of data activities. In the collection stage, the purpose, method, and scope of collection are clearly communicated to the data subject in a prominent manner. Collection is conducted only after obtaining the data subject's legal authorization, ensuring that the collection process follows the "minimum necessary" principle and does not exceed the scope of data collection. In the storage stage, storage periods are limited, and data is promptly deleted or anonymized / encrypted after the storage purpose is achieved. In the usage stage, a strict data security protection mechanism is implemented, using field-level desensitization technology and processing the original data according to preset desensitization rules. For different types of data, multiple desensitization strategies, such as data generalization, data anonymization, and data encryption, are employed to effectively mitigate the risk of sensitive information leakage and ensure that all data used is securely processed and desensitized, comprehensively protecting the rights and interests of data subjects and data security. In the transmission and processing stages, the confidentiality and security of data are ensured during transmission and processing.

[0024] In the description of this application, it should be understood that the numerical labels before the steps do not indicate the order of the steps, but are only used to facilitate the description of this application and to distinguish each step, and therefore should not be construed as a limitation of this application.

[0025] First, a definition of the terminology used in this application is provided: Queries per second (QPS) describes the number of requests a system can process per unit of time (per second). It is an important indicator for measuring the load capacity and call intensity of external services and is also a core configuration parameter for rate limiting control.

[0026] Transactions Per Second (TPS) refers to the number of requests a system successfully processes and responds to per unit of time (per second). In large-scale model scenarios, TPS typically refers to the number of inference requests the system can successfully process per unit of time (how many model calls are completed per second). It is one of the core performance indicators for measuring the throughput of large-scale model services, reflecting the service's processing capacity and stability under high-concurrency scenarios.

[0027] The Driver node in Spark is responsible for building job logic, managing task scheduling, and maintaining the overall state of the job. It is typically responsible for reading configurations, creating RDDs / DataFrames, and distributing broadcast variables.

[0028] Executor nodes are worker processes in Spark responsible for actually executing tasks. They typically run on worker nodes in the cluster, executing operator logic such as map, reduce, and map partitions, and caching intermediate data.

[0029] Data partitioning refers to the process of dividing a large dataset into several smaller, independent subsets of data according to certain rules (strategies).

[0030] RDD (Resilient Distributed Dataset) is Spark's core data abstraction, representing a read-only, partitioned collection of records with lineage information and fault tolerance, which can be distributed and computed in parallel across different Executors.

[0031] Repartitioning refers to the operation in Spark that changes the parallelism and load distribution of data by adjusting the number or distribution of partitions, and is used to control the number of parallel tasks and the amount of data on the Executor side.

[0032] Secondly, to facilitate understanding of the technical solutions provided in the embodiments of this application by those skilled in the art, the relevant technologies are described below: Among the relevant technologies, the following methods for rate limiting are available: 1. Calling external interfaces using a standalone script / standalone service: Write Python / Java scripts or microservices on a single server to pull data to be processed from the data warehouse; call external APIs concurrently within a single machine using multithreading or coroutines; use local rate limiting algorithms such as token bucket, leaky bucket, and fixed time window to control the call rate within a single machine process.

[0033] 2. The “Driver + Single Point Call” approach based on a distributed computing framework: In Spark, first try to preprocess the data using distributed operators (such as cleaning, aggregation, etc.), and then pull all the processed data back to the Driver process through interfaces such as collect() and toPandas(); use multi-threading on the Driver to call external large language model interfaces in batches, and then write the results back to the database or Hive.

[0034] 3. Simple mapPartition + local rate limiting method based on Spark: The HTTP call logic is directly written into mapPartitions or map functions. Each Executor calls the external interface one by one when processing its own partition data. Simple sleep intervals are used within each Task or each thread to control the call frequency, or some local RateLimiter classes are used to implement fixed QPS control.

[0035] 4. Distributed rate limiting solutions that rely on external centralized counters / caching systems: Use Redis, ZooKeeper, or a database to maintain a global counter shared across processes and nodes. Before each request, access the counter via the network to obtain a token or update the technology. In order to reduce network access pressure, it is usually necessary to implement complex logic such as batch token issuance and time window alignment.

[0036] However, the above method has the following drawbacks: 1. The "Driver + single-point call" approach based on a distributed computing framework requires pulling a large amount of data back to the Driver via collect() or toPandas() in order to control QPS uniformly on the Driver. This can easily lead to a sharp increase in Driver memory usage, triggering memory overflow or frequent garbage collection. In addition, a large amount of data will generate significant overhead during network transmission and serialization / deserialization, extending the overall task execution time. All external API calls are concentrated on a single machine, and the parallelism of the calls is limited by the CPU and network of a single machine. It is impossible to fully utilize the computing resources of the entire cluster, making it difficult to simultaneously achieve "fine-grained control of global QPS" and "large-scale parallel processing using the cluster".

[0037] 2. The simple mapPartition + local rate limiting method based on Spark only controls the local QPS through the local RateLimiter or sleep function within each Executor / Task, without global coordination. When the number of Executors or the parallelism of tasks in the cluster increases, the actual global QPS will increase exponentially. For example, if each Executor has a local rate limit of 10 QPS, when the number of Executors increases from 50 to 150, the global QPS will increase from 500 to 1500, which can easily exceed the allowable limit of external services. In addition, the task startup time of each Executor is inconsistent, and there will be scheduling jitter. Sometimes, there will be obvious request peaks at certain times, which cannot reliably guarantee that the global QPS does not exceed the limit, which can easily cause external interface errors, blocking, or risk control.

[0038] 3. Simple rate limiting implementations typically only set a constant target QPS, without a gradual increase mechanism from low to high QPS. This leads to interface instability. External large language models or cloud services are subjected to high QPS concurrent requests from the beginning, which can easily trigger the burst flow control policies of external large language models or cloud services. Failure and retry requests will burst in one go, reducing the overall success rate of the task and end-to-end efficiency.

[0039] 4. Distributed rate limiting schemes that rely on external centralized counters / caching systems will increase network round-trip latency and reduce the efficiency of a single request because the centralized counter needs to be accessed before each request or batch of requests. This will make the centralized counter itself a performance bottleneck or even a single point of failure. For scenarios like Spark with a large number of tasks, short lifecycles, and high concurrency, the coordination logic of the call process is relatively complex. It is difficult to strike a balance between rate limiting accuracy, availability, and implementation complexity. The engineering implementation cost is high and it is not conducive to the rapid integration of existing Spark jobs.

[0040] 5. Serialization and thread safety issues in multi-threaded execution environments: In Spark, functions and objects need to be serialized from the Driver and sent to various Executors for execution. If the RateLimiter class instance with its internal lock object is directly serialized from the Driver to the Executor, the lock object information may only exist within the Executor and cannot be passed between multiple Executors; the sharing or isolation behavior of locks between different Tasks may not meet expectations, resulting in thread safety issues; some implementations have not been specifically adapted to Spark's serialization and multi-threaded execution characteristics of Executors, leading to concurrency bugs or rate limiting anomalies that are difficult to reproduce during actual deployment.

[0041] Therefore, this application provides a current limiting technical solution. In this technical solution: 1. Implement a unified, gradually increasing QPS control mechanism in a distributed system. This allows the QPS to gradually transition from a lower to a higher level when a task starts, reducing request surges and external interface jitter, and minimizing the impact on the target service's resources. After the increase is complete, the QPS can be stabilized near the configured maximum QPS, thereby ensuring the timely completion of the task.

[0042] 2. By using simple and configurable parameters and broadcast variables, rate limiting is performed locally on each execution node. Global rate limiting is achieved while maintaining fully distributed data processing. All data is processed in a distributed manner within the distributed system cluster, eliminating the need to centralize large amounts of data to the master node. This reduces resource consumption, ensures data privacy and security, reduces master node memory usage and network transmission pressure, and improves cluster resource utilization and task throughput.

[0043] 3. Ensure that the lock object is not directly serialized during the process of the rate limiter being passed from the master node to the execution node, and delay the initialization of the local lock in the correct way within the execution node. Multiple tasks using the same execution node can share the same rate limiter instance, control QPS at the execution node level, and avoid thread safety issues and deadlock risks.

[0044] 4. Introduce a staggered startup strategy at the data partition level to stagger the actual startup times of each data partition, further reducing peak request times.

[0045] The details of the above plan are provided below.

[0046] The technical solutions of this application are described below through several embodiments. It should be understood that these embodiments can be implemented in many different forms and should not be construed as being limited to the embodiments set forth herein.

[0047] Example 1 Figure 1 A flowchart illustrating a rate limiting method according to Embodiment 1 of this application is shown. It should be noted that the executing entity of the rate limiting method in this embodiment can be a distributed system, and more specifically, an execution node within the distributed system. The following description uses an execution node as an example.

[0048] like Figure 1 As shown, the current limiting method may include steps S200~S204, wherein: Step S200: Receive the rate limiting parameters broadcast by the master node of the distributed system. The rate limiting parameters include at least the global start time.

[0049] Step S202: Determine the current warming phase of this node based on the global start time and the current time. The warming phase corresponds to several phases with different request rates, and the request rate of the later phase is greater than that of the previous phase. The request rate is the rate at which the target service is called. This node is any execution node in the distributed system.

[0050] Step S204: Dynamically adjust the request rate of this node to call the target service based on the heating stage.

[0051] The rate limiting method provided in this embodiment receives rate limiting parameters broadcast by the master node of the distributed system. These parameters include at least a global start time. Based on the global start time and the current time, the current warming-up stage of the node is determined. Each warming-up stage corresponds to several stages with different request rates, and the request rate of each subsequent stage is higher than that of the previous stage. The request rate of the node calling the target service is dynamically adjusted based on the warming-up stage. Rate limiting can be achieved by broadcasting rate limiting parameters by the master node, thereby controlling QPS globally and avoiding problems such as memory overflow and extended task execution time caused by pulling a large amount of data back to the master node, thus improving task execution efficiency. At the same time, controlling the request rate through different warming-up stages allows QPS to gradually increase, improving the stability of target service calls and the overall success rate of tasks. Furthermore, the global start time allows all execution nodes to share the same time scale, which helps maintain a consistent rhythm of rate limiting warming-up.

[0052] The following combination Figure 1 The steps in steps S200 to S204, as well as other optional steps, are described in detail.

[0053] Step S200 It receives rate limiting parameters broadcast by the master node of the distributed system. The rate limiting parameters include at least the global start time.

[0054] Specifically, the master node can record a timestamp when a task starts, using this timestamp as the global start time. For example, the timestamp corresponding to the task's start time can be used as the global start time, or the timestamp corresponding to the task's start time plus a numerical value can be used as the global start time. Besides the global start time, rate limiting parameters can also include other basic rate limiting parameters, such as the global maximum request rate, time window parameters, and maximum number of retries. Except for the global start time, other rate limiting parameters can be obtained through configuration. The master node can obtain the specific rate limiting parameters by reading the rate limiting parameter configuration file, then generate broadcast variables based on these parameters and the global start time, and then broadcast them to each execution node.

[0055] To precisely control the warm-up phase of each execution node, the rate limiting parameters may also include parameters corresponding to the warm-up phase. In optional embodiments, the rate limiting parameters may also include the number of warm-up phases, the duration of each warm-up phase, and the request rate corresponding to each warm-up phase. It is understood that by including the parameters corresponding to the warm-up phases, the master node can control the request rate corresponding to each warm-up phase of each execution node, facilitating global QPS control while improving the accuracy of QPS and warm-up phase control for each execution node.

[0056] In some possible embodiments, the parameters corresponding to the heating phase are not broadcast through the master node, but are configured by the execution node according to a preset configuration. For example, the number of heating phases can be a preset number, the duration of each heating phase can be a preset duration, and the request rate corresponding to each heating phase can be a preset request rate or a request rate calculated based on the maximum QPS allocated by the master node. For example, the maximum QPS allocated by the master node can be included in the rate limiting parameters, and the request rate corresponding to each phase can be obtained by multiplying the maximum QPS by the corresponding ratio.

[0057] In optional embodiments, the rate limiting parameters also include node maximum rate quotas. The request rate for each stage in the warm-up phase is obtained based on the node maximum rate quota, which is determined by the master node based on the number of execution nodes and the global maximum request rate. The number of execution nodes can be estimated by the master node based on task parameters or cluster configuration. During operation, if the number of execution nodes is relatively stable, the master node can also directly obtain the actual number of execution nodes. The global maximum request rate can be determined based on the maximum allowed rate of the target service. The node maximum rate quota can be obtained by evenly distributing the global maximum request rate according to the number of execution nodes. For example, if the global maximum request rate is 1000 QPS and there are 100 execution nodes, then the node maximum rate quota for each execution node is 10 QPS. Based on the node maximum rate quota, the request rate for each stage in the warm-up phase can be obtained by multiplying the node maximum rate quota by a certain proportion. For example, if there are three warm-up phases, the proportions for the three phases can be 50%, 80%, and 100%, respectively. Of course, 100% represents a completed state and can be excluded from the warm-up phase. Alternatively, the node's maximum rate quota can be used as the request rate for the final stage, with the request rate of the previous stage equal to the request rate of the next stage minus a certain value. Understandably, the node's maximum rate quota is determined by the master node based on the number of execution nodes and the global maximum request rate, and then broadcast to all execution nodes. This allows the master node to perform global QPS control while avoiding issues such as pulling large amounts of data back to the master node that could cause memory overflow.

[0058] Step S202 The current warming phase of this node is determined based on the global start time and the current time. The warming phase corresponds to several phases with different request rates, and the request rate of the later phase is greater than that of the previous phase. The request rate is the rate at which the target service is called. This node is any execution node in the distributed system.

[0059] The target service can be an external service, such as a large language model or other artificial intelligence services, or an internal service, such as a model training task scheduling service or a file transcoding service.

[0060] During the warming phase, the duration of each phase can be the same or different. For example, there may be three warming phases, with durations of 5 minutes, 10 minutes, and 10 minutes respectively. This node can obtain the current time and then calculate the difference between the current time and the global start time. Based on this difference, it can determine which warming phase it is currently in. With the three phases lasting 5 minutes, 10 minutes, and 10 minutes respectively, the corresponding warming phases are: Warming Phase 1 (0 minutes - 5 minutes), Warming Phase 2 (5 minutes to 15 minutes), and Warming Phase 3 (15 minutes to 25 minutes). If the difference is 5 minutes, it can be determined that it has entered Warming Phase 2; if the difference is 15 minutes, it can be determined that it has entered Warming Phase 3.

[0061] Step S204 The request rate for calling the target service by this node is dynamically adjusted based on the temperature rise phase.

[0062] Specifically, after determining the warming-up phase, this node can obtain the request rate corresponding to the current warming-up phase and call the target service according to the request rate corresponding to the current warming-up phase. For example, if there are three warming-up phases, with corresponding request rates of 5 QPS, 10 QPS and 20 QPS respectively, and the current warming-up phase is the second warming-up phase, then the target service will be called at a request rate of 10 QPS.

[0063] In an optional embodiment, after step S200, i.e., after receiving the rate limiting parameters broadcast by the distributed system master node, such as Figure 2 As shown, the current limiting method in this application embodiment may further include: Step S300: Obtain the partition identifier of the current data partition of this node, and determine the target delay time of the current data partition based on the partition identifier.

[0064] Step S302: Determine whether the target delay time has been reached based on the global start time and the current time.

[0065] Step S304: If the target delay time is reached, the current data partition starts calling the target service based on the control of the request rate during the warm-up phase.

[0066] Specifically, the partition identifier of the current data partition on this node can be obtained through relevant interfaces (such as Spark's TaskContext interface). Then, a hash algorithm can be used to calculate the target latency time of the current data partition based on the partition identifier. For example, the partition identifier can be moduloed and multiplied by a base number of seconds to calculate the target latency time, so that different data partitions have different latency times, thus achieving the effect of staggered startup. After determining the target latency time, the difference between the current time and the global start time can be used to determine whether the target latency time has been reached. If the target latency time has not been reached, the node can sleep and wait for the corresponding time. If the target latency time is reached, the warm-up phase calculation will begin, and the current data partition will start calling the target service according to the request rate control of the warm-up phase.

[0067] In this embodiment, by obtaining the partition identifier of the current data partition of this node, the target latency time of the current data partition is determined based on the partition identifier. Based on the global start time and the current time, it is determined whether the target latency time has been reached. If the target latency time has been reached, the current data partition starts calling the target service based on the control of the request rate during the warm-up phase. The partition identifier can make each data partition have a different latency time, avoiding all data partitions from starting at the same time point, reducing instantaneous concurrency peaks. Combined with the gradual warm-up mechanism, the control of global QPS is made smoother, reducing the risk of the target service being overwhelmed at a certain time.

[0068] In an optional embodiment, before step S202, that is, before determining the current heating stage of this node based on the global start time and the current time, such as Figure 3 As shown, the current limiting method in this application embodiment may further include: Step S400: Receive the serialized rate limiter class definition sent by the master node. The lock object is removed during the serialization of the rate limiter class definition.

[0069] Step S402: Deserialize the rate limiter class definition and initialize the lock field in the rate limiter class definition to an uncreated state to obtain the result of the rate limiter class definition deserialization.

[0070] Step S404: Based on the result of deserialization of the current limiter class definition, a current limiter instance is created on this node. The current limiter instance is used to execute the steps of determining the current heating stage of this node and subsequent steps based on the global start time and the current time.

[0071] Step S406: If a rate limiter instance is used and it is determined that the lock has not been created, a target lock object is created on this node. The target lock object is used to control the contention of multiple threads on this node calling the target service.

[0072] Specifically, a GradualRateLimiter class can be defined on the master node. This class definition contains an instance-level lock object used to control the request interval of execution nodes in a multi-threaded environment. The class definition can include a global start time. To ensure that the lock object does not produce unpredictable states or behavioral anomalies due to serialization and deserialization during cross-process transmission, the lock object is excluded when serializing the class definition. Then, the serialized class definition can be distributed to all execution nodes in the distributed system.

[0073] After receiving the serialized rate limiter definition, this node can deserialize the rate limiter class definition and initialize the lock field in the rate limiter class definition to an uncreated state, thus obtaining the result of the rate limiter class definition deserialization. Then, this node can create a rate limiter instance, namely a GradualRateLimiter instance, in this node based on the result of the rate limiter class definition deserialization. This rate limiter instance can carry the rate limiting parameters and rate limiting logic issued by the master node to implement steps S202 and thereafter. Specifically, it can include the maximum QPS (i.e., the highest request rate allowed after the warm-up is completed), the initial QPS (i.e., the request rate at the beginning of the task startup), the number of warm-up stages, the stage duration, the log printing interval, the instance-level lock, the last request time, the cumulative number of requests, the last report time, etc. At this point, the rate limiter instance is logically ready, but the lock object has not yet been created.

[0074] When any task thread on this node calls the rate limiter instance, it checks whether the target lock object has been created. If the target lock object has not been created, it is created on this node. Threads on this node can call the rate limiter instance by calling `acquire()`. The rate limiter instance calculates the minimum time interval between two requests based on the request rate corresponding to the current stage. If the time between the current call and the previous request is insufficient, the thread making the current request within `acquire()` waits for the remaining time before returning. Inside `acquire()`, the "time calculation and waiting" logic is wrapped with the target lock object to prevent multiple threads from modifying time-related states simultaneously. If waiting is required, methods such as `sleep` are used to block the current thread for a period of time. Each time a request is successfully allowed, the time of the previous request and the cumulative number of requests are updated. If multiple threads concurrently call the target service within this node, all threads call the same rate limiter instance's `acquire()` before making a request. Multiple threads will queue up to ensure that the time interval logic is executed correctly and that the QPS is not amplified due to multi-threading.

[0075] In this embodiment, by removing the lock object when defining the rate limiter class during serialization and initializing the lock field to an uncreated state during deserialization, the target lock object is created on the local node when the rate limiter instance is called subsequently. This ensures that the lock object is created and used only locally, avoiding unknown behaviors caused by cross-process serialization, ensuring that the lock object can play its concurrency control role normally, effectively avoiding deadlock and data competition, and improving the stability of the system.

[0076] In an optional embodiment, in step S404, i.e., the result of deserialization based on the current limiter definition is used to create a current limiter instance on this node, such as... Figure 4 As shown, it may further include: Step S500: In the case of processing the first data partition of this node, a rate limiter instance is created on this node based on the result of deserialization of the rate limiter instance class and the rate limiter parameters.

[0077] Step S502: Cache the rate limiter instance in this node or save it as a static variable so that it can be reused by all data partitions of this node.

[0078] When processing the first data partition of this node, it can be checked whether a valid rate limiter instance already exists in the current process of this node. If it is detected that it has not yet been created, a rate limiter instance is created on this node based on the deserialization result of the rate limiter instance class and the rate limiting parameters. The created instance is saved on this node through static variables or local caching. When subsequent data partitions of this node call the rate limiter instance, they can check and find that the rate limiter instance has been created, so they can directly reuse the rate limiter instance without creating it again.

[0079] In this embodiment, when processing the first data partition of this node, a rate limiter instance is created on this node based on the result of deserialization of the rate limiter instance class and the rate limiter parameters. The rate limiter instance is cached on this node or saved as a static variable for reuse by all data partitions of this node. This allows multiple tasks and threads on this node to share a single rate limiter instance, thereby achieving node-level QPS control, ensuring that the request rate of this node always matches the preset configuration, and reducing the resource overhead caused by repeated object initialization.

[0080] In optional embodiments, such as Figure 5 As shown, the current limiting method in this application embodiment may further include: Step S600: Obtain the target data obtained after the target service is called by this node.

[0081] Step S602: Return the target data to the master node so that the master node can write the target data into the target storage module according to the preset format.

[0082] Specifically, after invoking the target service, this node can process the obtained results and transform them into structured target data. Then, this node can encapsulate the target data into a data structure that the master node can recognize (such as an RDD in a Spark scenario) and return it to the master node. After receiving the target data, the master node writes it to the target storage module according to a preset format. The preset format varies depending on the distributed system. Taking Spark as an example, the target data can be returned to the master node in RDD form. The master node then merges the RDDs into a unified RDD, converts it into a structured DataFrame according to the output schema (field names, types, and order), and then writes it to the target storage module (such as a Hive table, HDFS target, etc.).

[0083] By obtaining the target data obtained after the local node calls the target service and processes it, the target data is returned to the master node so that the master node can write the target data into the target storage module according to the preset format. Only the result after calling the target service needs to be returned to the master node, without transferring all the data back to the master node, which significantly reduces the memory occupied by the master node. This allows for better utilization of the cluster's parallel capabilities, improves the overall processing scale and throughput, and ensures the consistency of the final written data format.

[0084] To make this application easier to understand, the following is combined with... Figure 6-8 An example application is provided.

[0085] Figure 6 The system architecture diagram of the rate limiting method in the Spark scenario of this application embodiment may include the following: 1. Data storage layer: The first data table stores the raw text data to be processed (such as user comments and post content), which can be a Hive table or other distributed storage.

[0086] The second data table stores the structured results after processing by external interfaces (such as sentiment tags, brand relevance, and industry relevance).

[0087] 2. Distributed computing layer: The Driver node is responsible for reading task configurations (such as QPS parameters, number of retries, etc.); calculating global QPS-related parameters (such as maximum QPS per Executor); generating corresponding broadcast variables; building and submitting Spark job plans; and distributing data to be processed to Executors by partition.

[0088] Multiple Executor nodes: receive the data partitions assigned to them; initialize or acquire a local rate limiter instance when processing a partition for the first time; and control the call rhythm to external interfaces within their respective processes.

[0089] 3. Current limiting control layer: Gradual RateLimiter module: Controls local QPS at the Executor level; determines the target QPS for the current stage based on the global start time and the current time; supports secure serialization and thread-safe access.

[0090] Broadcast Parameters Module: Used to broadcast the global start time; used to broadcast configurations such as the maximum QPS and initial QPS per Executor.

[0091] 4. External service layer: External interface services: These can be large language model APIs or other HTTP / gRPC services; responsible for semantic understanding or classification of input text and returning results.

[0092] 5. Results Output and Monitoring Layer: The result writing module writes each input record and its corresponding external interface result to a second data table; it supports partitioned storage by fields such as date and business line.

[0093] Monitoring and logging module: The rate limiter and calling logic periodically output information such as estimated QPS, cumulative request count, and error rate for the current stage; it can be integrated into existing monitoring systems for visualization.

[0094] At runtime, the Driver loads data from the first data table and creates broadcast variables. Each Executor uses a rate limiter to control the call rhythm when processing partitioned data, and then writes the processing results to the second data table.

[0095] Figure 7 for Figure 6 The corresponding modules and process diagrams can generally include the following: 1. Parameter configuration and job entry module: Reads global maximum QPS, global initial QPS, number of warm-up stages, duration of each stage, estimated number of Executors, maximum number of retries and retry interval from the configuration center, command line parameters or configuration files; creates Spark sessions and starts jobs.

[0096] 2. Global Time and QPS Broadcast Module: Record the current time on the Driver side as the global start time of this job; convert the global initial QPS and maximum QPS into "initial QPS per Executor" and "maximum QPS per Executor" based on the estimated number of Executors; and send the global start time and QPS parameters per Executor to all Executors through Spark broadcasting.

[0097] 3. Executor-side rate limiter management module: When the Executor processes a partition for the first time, it reads the global start time and per-Executor QPS configuration from the broadcast variable; creates or obtains a GradualRateLimiter instance according to the configuration; caches the rate limiter instance in the Executor process so that subsequent Tasks can share the same instance; and provides a thread-safe acquire() method for partition processing logic to call.

[0098] 4. Partition Processing and Peak Shaving Control Module: Use mapPartitions or a similar interface to process the data of each partition separately; before partition processing begins, obtain the current partitionId through TaskContext; calculate the peak shaving delay time based on the partition number (e.g., take the partition number modulo a constant and then multiply by a fixed number of seconds); call sleep to make the partition wait for a certain period of time before starting to send requests; during partition processing, for each piece of data or a batch of data, call the rate limiter acquire() before accessing external interfaces.

[0099] 5. External Interface Call and Result Parsing Module: Extracts text and related business fields from input records; constructs HTTP / gRPC request parameters; calls GradualRateLimiter.acquire() to throttle the request and waits for an appropriate time to initiate the request; after sending the request, obtains the returned string; performs necessary repairs and parsing on the response content (e.g., repairing JSON format and extracting tag fields); and encapsulates it into a unified result object for return.

[0100] 6. Result Writing and Persistence Module: Returns the processing results of each partition to the Driver in RDD form; creates a DataFrame on the Driver side according to the result format; writes the results to the second data table according to the defined table structure, which can be done by appending or partition overwriting; supports setting the output partition key and storage path according to task parameters.

[0101] Figure 8 This is an example of the method flow for the rate limiting method in the Spark scenario, as described in this application embodiment. The flow can generally include the following: 1. Loading data to be processed: The Driver loads the text records to be processed from the first data table according to specified conditions (such as date, business line, etc.) to form an input DataFrame.

[0102] 2. Read rate limiting configuration parameters: The parameter configuration module reads the following key parameters from external or local sources: global maximum QPS, global initial QPS, number of warm-up stages, duration of each stage, estimated number of Executors, maximum number of retries, etc.

[0103] 3. Calculate and broadcast global rate limiting parameters: In the Driver, calculate the "initial QPS per Executor" and "maximum QPS per Executor" based on the parameters in the previous step; record the current time as the global start time; generate broadcast variables from the global start time and the QPS parameters per Executor, and send them to all Executors.

[0104] 4. Repartition and distribution of input data: The Driver repartitions the input DataFrame based on the task size and cluster resources; the partitioned data is then distributed to each Executor as RDD shards.

[0105] 5. Executor initializes the rate limiter: When an Executor processes a partition for the first time, it reads the global start time and the per-Executor QPS parameter from the broadcast variable; if the GradualRateLimiter instance has not yet been created in this Executor, it creates the rate limiter; the rate limiter object is cached in the Executor for reuse in subsequent partitions.

[0106] 6. Staggered Startup by Partition: For each partition, obtain the current partitionId at the beginning of the processing logic; calculate the staggered delay time according to preset rules (such as multiplying the partitionId by a base number of seconds after taking the modulo); call sleep to wait for the corresponding duration before starting to process the data of this partition.

[0107] 7. Call the rate limiter and send external requests: When traversing records within a partition, perform the following steps for each record or each small batch of records: Extract text and other business fields to construct the parameters required for external service calls; Call GradualRateLimiter.acquire(): If the time interval between the previous request and the current stage is too short, the sending interval will be automatically waited internally; Return after the time is up, indicating that it is safe to send the next request; Send an HTTP / gRPC request to the external service and wait for the return result.

[0108] 8. Response Result Parsing and Structuring: Perform the following on the strings returned by external services: necessary repairs (such as JSON completion); parse the repaired content into structured objects; extract the required fields (such as sentiment type, brand association, industry tags, etc.); merge the parsing results with the original record identification information to form a unified output record.

[0109] 9. Result Collection and DataFrame Construction: Each Executor records the results obtained from its partition into RDD shards and returns them; the Driver aggregates all shards and constructs the resulting DataFrame according to a predefined schema; caching or materialization can be performed if necessary.

[0110] 10. Result Writing and Task Completion: Write the result DataFrame to the second data table by appending or overwriting; after the task is completed, evaluate the QPS trend and external interface stability of this task based on the logs and monitoring information output by the rate limiter and the calling logic.

[0111] In this exemplary application, a gradually increasing QPS control mechanism can reduce the resource impact on the target service; by configuring parameters and broadcast variables, rate limiting control is performed on each Executor, eliminating the need to centralize large amounts of data to the Driver, reducing Driver memory usage and network transmission pressure, and improving cluster resource utilization and task throughput; by having multiple tasks on the same Executor share a single rate limiter instance, Executor-level QPS control can be achieved; and by employing a staggered startup strategy, the actual startup times of each data partition are staggered, further reducing request peaks.

[0112] Example 2 Figure 9 The diagram schematically illustrates a current limiting device according to Embodiment 2 of this application. This device can be divided into one or more program modules. One or more program modules are stored in a storage medium and executed by one or more processors to complete the embodiment of this application. The program module referred to in this embodiment is a series of computer program instruction segments capable of performing a specific function. The following description will specifically introduce the function of each program module in this embodiment. For example... Figure 9 As shown, the device 700 may include: a receiving module 710, a determining module 720, and a current limiting module 730, wherein: The receiving module 710 is used to receive rate limiting parameters broadcast by the master node of the distributed system, wherein the rate limiting parameters include at least the global start time; The determination module 720 is used to determine the current warming stage of the node based on the global start time and the current time. The warming stage corresponds to several stages with different request rates, and the request rate of the later stage is greater than that of the previous stage. The request rate is the rate at which the target service is called. The node is any execution node of the distributed system. The rate limiting module 730 is used to dynamically adjust the request rate of the local node calling the target service based on the heating phase.

[0113] In an optional embodiment, the current limiting parameters may further include the number of heating stages, the duration of each heating stage, and the request rate corresponding to each heating stage.

[0114] In an optional embodiment, the rate limiting parameter further includes a node maximum rate quota, and the request rate of each stage in the warm-up phase is obtained based on the node maximum rate quota, which is obtained by the master node based on the number of execution nodes and the global maximum request rate.

[0115] In an optional embodiment, the device 700 is further used for: Obtain the partition identifier of the current data partition of the current node, and determine the target delay time of the current data partition based on the partition identifier; Determine whether the target delay time has been reached based on the global start time and the current time; If the target delay time is reached, the current data partition begins to call the target service based on the control of the request rate during the warm-up phase.

[0116] In an optional embodiment, the device 700 is further used for: Receive the serialized rate limiter class definition sent by the master node, wherein the rate limiter class definition removes the lock object during serialization; The rate limiter class definition is deserialized and the lock field in the rate limiter class definition is initialized to an uncreated state, resulting in the deserialization result of the rate limiter class definition. Based on the result of deserialization of the current limiter class definition, a current limiter instance is created on this node. The current limiter instance is used to execute the steps of determining the current heating stage of this node and subsequent steps based on the global start time and the current time. If the rate limiter instance is used and it is determined that the lock has not been created, a target lock object is created on the local node. The target lock object is used to control the contention of multiple threads on the local node calling the target service.

[0117] In an optional embodiment, the device 700 is further used for: In the case of processing the first data partition of the current node, a rate limiter instance is created on the current node based on the result of deserialization of the rate limiter instance class and the rate limiter parameters; The rate limiter instance is cached or stored as a static variable in this node for reuse by all data partitions of this node.

[0118] In an optional embodiment, the device 700 is further used for: Obtain the target data obtained after the local node calls the target service and processes it; The target data is returned to the master node so that the master node can write the target data into the target storage module according to a preset format.

[0119] Example 3 Figure 10 This illustration schematically shows a hardware architecture diagram of a computer device 10000 suitable for implementing a rate limiting method according to Embodiment 3 of this application. In some embodiments, the computer device 10000 may be a terminal device such as a smartphone, wearable device, tablet computer, personal computer, in-vehicle terminal, game console, virtual device, workbench, digital assistant, set-top box, robot, etc. In other embodiments, the computer device 10000 may be a rack server, blade server, tower server, or cabinet server (including independent servers or server clusters composed of multiple servers), etc. Figure 10 As shown, the computer device 10000 includes, but is not limited to: a memory 10010, a processor 10020, and a network interface 10030 that can communicate and be linked with each other via a system bus. Wherein: The memory 10010 includes at least one type of computer-readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 10010 may be an internal storage module of a computer device 10000, such as the hard disk or memory of the computer device 10000. In other embodiments, the memory 10010 may also be an external storage device of the computer device 10000, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 10000. Of course, the memory 10010 may also include both the internal storage module and the external storage device of the computer device 10000. In this embodiment, the memory 10010 is typically used to store the operating system and various application software installed on the computer device 10000, such as the program code for the current limiting method. In addition, the memory 10010 can also be used to temporarily store various types of data that have been output or will be output.

[0120] In some embodiments, processor 10020 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other chip. Processor 10020 is typically used to control the overall operation of computer device 10000, such as performing control and processing related to data interaction or communication with computer device 10000. In this embodiment, processor 10020 is used to run program code stored in memory 10010 or process data.

[0121] Network interface 10030 may include a wireless network interface or a wired network interface, which is typically used to establish a communication link between computer device 10000 and other computer devices. For example, network interface 10030 is used to connect computer device 10000 to an external terminal via a network, establishing a data transmission channel and communication link between computer device 10000 and the external terminal. The network may be an intranet, the Internet, Global System for Mobile Communication (GSM), Wideband Code Division Multiple Access (WCDMA), 4G network, 5G network, Bluetooth, Wi-Fi, or other wireless or wired networks.

[0122] It should be pointed out that, Figure 10 Only computer devices with components 10010-10030 are shown; however, it should be understood that it is not required to implement all of the shown components, and more or fewer components may be implemented instead.

[0123] In this embodiment, the current limiting method stored in memory 10010 can also be divided into one or more program modules and executed by one or more processors (such as processor 10020) to complete the embodiment of this application.

[0124] Example 4 This application also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the rate limiting method in the embodiments.

[0125] In this embodiment, the computer-readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the computer-readable storage medium may be an internal storage unit of a computer device, such as the hard disk or memory of the computer device. In other embodiments, the computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device. Of course, the computer-readable storage medium may include both the internal storage unit and the external storage device of the computer device. In this embodiment, the computer-readable storage medium is typically used to store the operating system and various application software installed on the computer device, such as the program code of the rate limiting method in the embodiment. In addition, the computer-readable storage medium can also be used to temporarily store various types of data that have been output or will be output.

[0126] Example 5 This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods described in the above embodiments.

[0127] Obviously, those skilled in the art should understand that the modules or steps of the embodiments of this application described above can be implemented using general-purpose computer devices. They can be centralized on a single computer device or distributed across a network of multiple computer devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computer device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the embodiments of this application are not limited to any particular combination of hardware and software.

[0128] It should be noted that the above are merely preferred embodiments of this application and do not limit the scope of patent protection of this application. Any equivalent structural or procedural changes made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of this application.

Claims

1. A current limiting method, characterized in that, The method includes: Receive rate limiting parameters broadcast by the master node of the distributed system, wherein the rate limiting parameters include at least the global start time; The current warming phase of this node is determined based on the global start time and the current time. The warming phase corresponds to several phases with different request rates, and the request rate of the later phase is greater than that of the previous phase. The request rate is the rate at which the target service is called. This node is any execution node of the distributed system. The request rate for this node to call the target service is dynamically adjusted based on the heating phase.

2. The method according to claim 1, characterized in that, The rate limiting parameters also include the number of heating stages, the duration of each heating stage, and the request rate corresponding to each heating stage.

3. The method according to claim 1, characterized in that, The rate limiting parameters also include the node maximum rate quota. The request rate of each stage in the warm-up phase is obtained based on the node maximum rate quota, which is obtained by the master node based on the number of execution nodes and the global maximum request rate.

4. The method according to claim 1, characterized in that, After receiving the rate limiting parameters broadcast by the distributed system master node, the method further includes: Obtain the partition identifier of the current data partition of the current node, and determine the target delay time of the current data partition based on the partition identifier; Determine whether the target delay time has been reached based on the global start time and the current time; If the target delay time is reached, the current data partition begins to call the target service based on the control of the request rate during the warm-up phase.

5. The method according to claim 1, characterized in that, Before determining the current heating stage of the node based on the global start time and the current time, the method further includes: Receive the serialized rate limiter class definition sent by the master node, wherein the rate limiter class definition removes the lock object during serialization; The rate limiter class definition is deserialized and the lock field in the rate limiter class definition is initialized to an uncreated state, resulting in the deserialization result of the rate limiter class definition. Based on the result of deserialization of the current limiter class definition, a current limiter instance is created on this node. The current limiter instance is used to execute the steps of determining the current heating stage of this node and subsequent steps based on the global start time and the current time. If the rate limiter instance is used and it is determined that the lock has not been created, a target lock object is created on the local node. The target lock object is used to control the contention of multiple threads on the local node calling the target service.

6. The method according to claim 4, characterized in that, The process of deserializing the result based on the rate limiter class definition to create a rate limiter instance on this node includes: In the case of processing the first data partition of the current node, a rate limiter instance is created on the current node based on the result of deserialization of the rate limiter instance class and the rate limiter parameters; The rate limiter instance is cached or stored as a static variable in this node for reuse by all data partitions of this node.

7. The method according to claim 1, characterized in that, The method further includes: Obtain the target data obtained after the local node calls the target service and processes it; The target data is returned to the master node so that the master node can write the target data into the target storage module according to a preset format.

8. A current limiting device, characterized in that, The device includes: A receiving module is used to receive rate limiting parameters broadcast by the master node of the distributed system, wherein the rate limiting parameters include at least the global start time; The determination module is used to determine the current warming stage of the node based on the global start time and the current time. The warming stage corresponds to several stages with different request rates, and the request rate of the later stage is greater than that of the previous stage. The request rate is the rate at which the target service is called. The node is any execution node of the distributed system. The rate limiting module is used to dynamically adjust the request rate of the local node calling the target service based on the heating phase.

9. A computer device, characterized in that, include: At least one processor; and A memory communicatively connected to the at least one processor; wherein: The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 7.

Images