Flow control method of media interface and related device

Abstract

The invention provides a flow control method of a media interface and a related device. The method comprises the following steps: under the condition that an access request of a first thread for a media interface is received, determining an access limit corresponding to an item scene to which the first thread belongs; wherein the item scenes are categories divided according to functions realized by calling the media interface; under the condition that the remaining access quota of the item scene to which the first thread belongs cannot meet the access request, dividing a dynamic quota to the item scene based on a dynamic quota pool, and taking the dynamic quota as the added access quota of the item scene; wherein the sum of the access quotas of the different item scenes for the media interface is not greater than the upper limit value of the access quotas of the media interface; and calling a media interface to send an access request according to the remaining access quota after the dynamic quota is added to the item scene to which the first thread belongs. The flow control method and the related device can improve the utilization rate of a media interface to a certain extent.

Description

Technical Field

[0001] One or more embodiments of this application relate to the field of e-commerce technology, and in particular to a flow control method and related apparatus for a media interface. Background Technology

[0002] In related technologies, media platforms in internet applications typically support functions such as ad placement, data synchronization, and status query through externally provided application programming interfaces (APIs). Because these media APIs need to serve a large number of advertisers and third-party systems simultaneously, media providers usually set access frequency limits for API calls, i.e., an upper limit on the access quota within a specified time window.

[0003] However, the related technologies suffer from low utilization of media interfaces. Summary of the Invention

[0004] In view of this, one or more embodiments of this application provide a flow control method and related apparatus for a media interface, which can improve the utilization rate of the media interface to a certain extent.

[0005] In a first aspect, one or more embodiments of this application propose a flow control method for a media interface, comprising: upon receiving an access request from a first thread for the media interface, determining the access quota corresponding to the event scenario to which the first thread belongs; wherein the event scenario is a category divided according to the function implemented by calling the media interface; different event scenarios each correspond to an access quota; the access quota is used to represent the number of threads in the corresponding event scenario allowed to call the media interface within a specified time window; the media interface has an upper limit value of the access quota within the specified time window; if the remaining access quota of the event scenario to which the first thread belongs cannot satisfy the access request, allocating a dynamic quota to the event scenario based on a dynamic quota pool, the dynamic quota being used as an additional access quota for the event scenario; wherein the sum of the access quotas for the media interface for different event scenarios is not greater than the upper limit value of the access quota for the media interface; and calling the media interface to send the access request based on the remaining access quota after adding the dynamic quota to the event scenario to which the first thread belongs.

[0006] Secondly, one or more embodiments of this application provide a computer device including a memory and a processor, wherein the memory stores at least one computer program, which is loaded and executed by the processor to implement the method as described above.

[0007] Thirdly, one or more embodiments of this application provide a computer program product including computer instructions that, when executed by a processor, implement the method as described above.

[0008] As can be seen from the above embodiments, in the multiple embodiments provided in this application, by distinguishing different event scenarios for access requests to the media interface and setting access quotas for each event scenario, the frequency of thread calls to the media interface can be accurately controlled according to the scenario dimension within a specified time window, avoiding resource allocation imbalance caused by competition for quotas between different scenarios. Furthermore, by introducing a dynamic quota pool mechanism, when the remaining access quota for a certain event scenario is insufficient, a dynamic quota can be temporarily allocated to that event scenario. This allows each event scenario to obtain additional call quotas according to actual needs, while ensuring that the upper limit of the media interface access quota is not exceeded, achieving flexible allocation of limited access resources. Through the above methods, the overall utilization rate of the media interface can be improved while ensuring the call needs of event scenarios are met. Attached Figure Description

[0009] Figure 1 This is an example diagram illustrating an application scenario of an access system, provided in the scenario example section of this manual.

[0010] Figure 2 This is a flowchart illustrating a flow control method for a media interface provided in one embodiment of this specification.

[0011] Figure 3 This is a schematic diagram of an access system provided in one embodiment of this specification.

[0012] Figure 4 This is a schematic diagram of a computer device provided in one embodiment of this specification. Detailed Implementation

[0013] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0014] In the description of the embodiments of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0015] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0016] In related technologies, media platforms typically support functions such as ad delivery, data synchronization, and status queries through publicly accessible Application Programming Interfaces (APIs). These media interfaces need to serve multiple access systems simultaneously. To ensure the stability of the interfaces under high concurrency, media platforms employ access frequency-based limiting measures, i.e., setting an upper limit on access quotas within a specified time window. In this way, each access system is assigned a corresponding upper limit for calling the media interfaces, ensuring the smooth operation of the entire media platform.

[0017] Access requests for different scenarios exhibit significant differences in traffic characteristics. For example, scheduled tasks often trigger a large number of access requests to media interfaces in a short period of time, while real-time triggered requests show a continuous and dispersed calling pattern. During the execution of scheduled tasks, the access quota of the access system is approached, making it difficult to respond promptly to real-time triggered requests. Therefore, the access system allocates a certain access quota for each scenario, so that when a media access request occurs in a scenario, the media interface is invoked based on the corresponding access quota.

[0018] However, not every scenario will continuously occupy the full access quota. In some cases, a certain scenario may generate a large number of access requests to the media interface, but the allocated access quota is insufficient and needs to be queued, while other scenarios may only have a small number of access requests, and the access quota will be idle.

[0019] Therefore, it is necessary to propose a new technical solution that can improve the utilization rate of media interfaces in order to improve the overall resource utilization efficiency of the access system.

[0020] In several embodiments provided in this application, the flow control method for the media interface can be applied to electronic devices with certain computing and network access capabilities. This electronic device can be a desktop computer, laptop computer, tablet computer, smartphone, or a server. Specifically, the electronic device includes a processor, memory, and a network access module for network communication. The server can be an electronic device with strong data processing capabilities; of course, a server can also refer to a server cluster formed by multiple electronic devices, or a quantum server built using a quantum computer.

[0021] Please see Figure 1 One embodiment of this application provides an example application scenario of a flow control method for a media interface. This flow control method can be applied when a third-party advertising delivery system calls the media interface of a media platform to avoid wasting or conflicting media interface access quotas due to concurrent triggering of different access requests. In this example scenario, the third-party advertising delivery system sends an access request to the media platform by calling the media interface. This access request may involve different scenarios such as real-time synchronization of advertising data, batch creation of advertising plans, and status queries of advertising performance.

[0022] For example, during ad delivery, advertisers might trigger multiple access requests simultaneously through a third-party ad delivery system. The first thread might be a "batch ad creation" scenario, which generates a concentrated and large number of access requests within a short period. The third thread might be a "desktop ad data query" scenario, which calls media interfaces in a distributed and continuous manner. When the access system receives an access request from the first thread, it can first determine the corresponding scenario and deduct a quota from the corresponding access limit. Each scenario has a pre-allocated static access quota to ensure that different types of function calls are guaranteed within a specified time window.

[0023] At certain times, the static access quota allocated to the task scenario belonging to the first thread may be exhausted due to concentrated calls. In this case, the access system can allocate dynamic quotas based on the dynamic quota pool, thereby temporarily increasing the available quotas for that task scenario. The dynamic quota pool is maintained uniformly by the access system and can allocate additional access quotas for frequently called task scenarios while ensuring that the total access quota for different task scenarios does not exceed the upper limit of the media interface access quota. If there are still reserves in the dynamic quota pool, the first thread can continue to call the media interface to complete the batch creation requests for advertising plans. Furthermore, the "batch creation of advertisements" task scenario may generate a second thread that needs to call the media interface. After the first thread triggers the allocation of dynamic quotas, if there are quotas available for that task scenario, the second thread can directly use the quotas from the increased dynamic quota to call the media interface.

[0024] In some examples, each event scenario can be configured with a minimum threshold to ensure it still gets basic access to services even under high concurrency. For instance, the "Advertising Data Query" event scenario can continue to complete status query requests even when overall traffic is tight, relying on the minimum threshold to maintain the continuity of ad delivery monitoring. When the dynamic quota pool is unallocated, the access system ensures that the sum of the minimum thresholds for all event scenarios does not exceed the interface's upper limit.

[0025] In a further example, when the first thread is the only active thread in its event scenario, the access system can allocate an access quota equal to the minimum threshold from the global quota pool to support the basic call requirements when the event scenario transitions from an idle state to an active state. This avoids call blocking when the event scenario is first launched.

[0026] To prevent a single scenario from consuming excessive dynamic quotas for an extended period, the access system can set an upper limit threshold for dynamic quotas for each scenario. For example, in the "Batch Create Ads" scenario, when the dynamic quota reaches the upper limit, no new dynamic quotas can be acquired. In this case, the access system can either abandon the access request for that thread or place the request in a delayed response queue, waiting for the quota to be restored before calling the media interface, thereby ensuring the fairness and sustainability of system operation.

[0027] In concurrent scenarios, once the first and second threads release their allocated quotas, the access system can return the allocated dynamic quota to the dynamic quota pool for use in other scenarios.

[0028] In implementation, the access system can also implement dual control over quota usage and request submission using quota locks and access locks. Quota locks indicate that an access quota is occupied, preventing multiple threads from competing for the same quota simultaneously. Access locks indicate whether a thread is eligible to submit an access request, thus preventing unordered requests from flowing in before quota allocation is confirmed. In a distributed deployment scenario, quota locks and access locks can be implemented using a distributed lock mechanism to ensure consistency in quota occupancy and release across multiple nodes globally.

[0029] In some cases, different task scenarios can have different priorities. For example, the "ad data query" task scenario has a higher priority than the "batch ad creation" task scenario. When the dynamic quota pool is insufficient, the system will prioritize allocating dynamic quotas to high-priority task scenarios to ensure the stable operation of critical functions such as ad placement monitoring and real-time data acquisition.

[0030] Please see Figure 2 One embodiment of this application provides a flow control method for a media interface. The flow control method can be applied to a media interface access system, which can be applied to the aforementioned electronic device possessing certain computing and network access capabilities. Of course, in some embodiments, the access system can also be software running on the electronic device. The flow control method for the media interface may include the following steps.

[0031] Step S110: Upon receiving an access request from the first thread for the media interface, determine the access quota corresponding to the event scenario to which the first thread belongs; wherein, the event scenario is a category divided according to the function implemented by calling the media interface; different event scenarios correspond to different access quotas; the access quota is used to represent the number of threads in the corresponding event scenario allowed to call the media interface within a specified time window; the media interface has an upper limit value of the access quota within the specified time window.

[0032] Step S120: If the remaining access quota of the event scenario to which the first thread belongs cannot meet the access request, a dynamic quota is allocated to the event scenario based on the dynamic quota pool, and the dynamic quota is used as the access quota added to the event scenario; wherein, the sum of the access quotas of different event scenarios for the media interface is not greater than the upper limit of the access quota of the media interface.

[0033] Step S130: Based on the event scenario to which the first thread belongs, use the remaining access quota after increasing the dynamic quota, and call the media interface to send the access request.

[0034] In this embodiment, the media interface refers to the application programming interface (API) provided by the media platform. The functions implemented by the media platform include, but are not limited to, ad delivery, data synchronization, and status query. The media interface can simultaneously respond to concurrent calls from multiple access systems. In this embodiment, the flow control method refers to controlling the access to the media interface by allocating, dynamically adjusting, and reclaiming access quotas when access systems call the media interface, thereby improving the overall utilization rate of the media interface.

[0035] In this implementation, when the access system receives an access request for the media interface from the first thread, it can first determine the event scenario to which the first thread belongs. An event scenario refers to the classification of access requests based on the function implemented by calling the media interface, such as a scheduled task synchronization scenario, a real-time triggered synchronization scenario, or a status query scenario. Different event scenarios correspond to different access quotas, which represent the number of times a thread in the corresponding event scenario is allowed to call the media interface within a specified time window.

[0036] In this embodiment, the access system has an upper limit on the access quota for the corresponding media interface within a specified time window, which limits the total number of calls made by the access system within that time window. In this embodiment, the access system can allocate a static access quota for each event scenario, ensuring that each event scenario has an appropriate number of slots. When the remaining access quota for the event scenario to which the first thread belongs cannot meet the current access requests, the access system will allocate a dynamic quota to that event scenario based on a dynamic quota pool. A dynamic quota refers to the incremental quota temporarily allocated to a specific event scenario from the dynamic quota pool, used to provide temporary support when the number of access requests exceeds the static access quota. The allocation process of the dynamic quota must adhere to a total limit constraint, meaning that the sum of the access quotas for all event scenarios within the specified time window does not exceed the upper limit of the media interface's access quota, thereby ensuring the overall stability of the media platform's operation.

[0037] In this implementation, after obtaining the remaining access quota for its respective event scenario, the first thread can call the media interface to complete the access request. In this way, different event scenarios can retain their own static access quota while dynamically acquiring additional call quota based on actual needs, avoiding resource waste due to idle quotas in some event scenarios, and improving the overall utilization rate of the media interface across different event scenarios.

[0038] In some implementations, each event scenario corresponds to a minimum access limit threshold; wherein, when the dynamic limit pool is not allocated a dynamic limit, the sum of the access limits included in the dynamic limit pool and the minimum access limit thresholds corresponding to all event scenarios is less than or equal to the upper limit of the access limit of the media interface.

[0039] In this implementation, to ensure that different event scenarios have basic access capabilities when calling media interfaces, the access system can configure a minimum access threshold for each event scenario. The minimum threshold can refer to the minimum number of available slots allocated to a specific event scenario within a specified time window. This ensures that the event scenario still receives basic calling opportunities under high concurrency or intense competition, thereby preventing the event scenario from being blocked due to resource constraints. In this implementation, the number of slots constrained by the minimum threshold can be a static access quota for each event scenario.

[0040] In this implementation, the access system needs to incorporate the minimum threshold corresponding to each event scenario into the overall quota constraint when maintaining the dynamic quota pool. When the dynamic quota pool has not allocated any dynamic quota, the sum of the access quota included in the dynamic quota pool and the minimum threshold of all event scenarios is less than or equal to the upper limit of the media interface's access quota within a specified time window. In this way, the overall allocation of access quota will not exceed the media interface's carrying capacity, avoiding interface access exceeding limits due to unreasonable configuration.

[0041] In this implementation, by setting a minimum threshold, not only is a basic guarantee provided for each scenario, but a baseline is also provided for the subsequent allocation of dynamic quotas. The access system can balance fairness and flexibility under the condition of limited overall access quotas, ensuring that in actual operation, each scenario will not have its access quota idle for a long time due to low-frequency calls, nor will it have its access quota completely occupied by high-frequency calls, thereby improving the overall rational utilization of media interface access resources.

[0042] In some implementations, when the first thread is the only active thread in the event scenario to which it belongs, the access system allocates an access quota for the event scenario from the global quota pool; wherein, the access quota allocated from the global quota pool for the event scenario is equal to the minimum threshold corresponding to the event scenario; the access quota of the global quota pool is equal to the upper limit of the access quota of the media interface; based on the access quota of the event scenario, the media interface is invoked to send the access request.

[0043] In this implementation, to ensure that the access system can reasonably utilize access quotas when different event scenarios are initiated, the access system can maintain a global quota pool. The global quota pool refers to the access quota source centrally managed by the access system within a specified time window, used to allocate a basic access quota for an event scenario when it is first activated.

[0044] In this implementation, when the first thread arrives as the only active thread in its respective task scenario—that is, when the task scenario transitions from an idle state to an active state—the access system can trigger a quota allocation operation, allocating an access quota for the task scenario from the global quota pool. The allocated access quota is equal to the minimum threshold corresponding to the task scenario, ensuring that the task scenario has the necessary call slots during the initial running phase, thereby avoiding situations where access requests cannot be executed.

[0045] In this implementation, based on the access quota allocated from the global quota pool, the first thread can call the media interface to send an access request. In this way, the access system can allocate an access quota equal to the minimum threshold at the critical moment when a task transitions from an inactive to an active state. This ensures the basic calling capabilities of the task while avoiding uncertainty and resource waste in quota allocation, thereby further improving the stability of the media interface access process.

[0046] In some implementations, each event scenario has a corresponding upper limit threshold for dynamic quotas; the access system may allocate dynamic quotas from the dynamic quota pool to the event scenario if the remaining access quota of the event scenario to which the first thread belongs cannot satisfy the access request, and if the dynamic quota obtained by the event scenario is not greater than the corresponding upper limit threshold, and the total amount of dynamic quotas obtained by the event scenario is not greater than the corresponding upper limit threshold.

[0047] In this implementation, to prevent a particular scenario from consuming excessive resources during the dynamic quota allocation process, the access system can configure an upper limit threshold for the dynamic quota for each scenario. The upper limit threshold refers to the maximum total dynamic quota that a particular scenario can obtain from the dynamic quota pool within a specified time window. This threshold constrains the dynamic expansion capability of the scenario and prevents it from restricting access to other scenarios due to frequent requests.

[0048] In this implementation, when the remaining access quota for the task scenario to which the first thread belongs is insufficient to meet the access requests, the access system will determine whether the dynamic quota already obtained by the task scenario has not exceeded its corresponding upper limit threshold. If this condition is met, the access system can continue to allocate dynamic quota from the dynamic quota pool to the task scenario as additional available slots for the task scenario within a specified time window.

[0049] In this implementation, the total dynamic quota obtained by a transaction scenario throughout the entire invocation process must be less than or equal to its corresponding upper limit threshold. This ensures that even if there is remaining capacity in the dynamic quota pool, a transaction scenario will not expand indefinitely. Thus, the access system can maintain flexibility without exceeding the media interface access quota limit, making the allocation of dynamic quotas highly controllable.

[0050] In some implementations, if the remaining access quota of the event scenario to which the first thread belongs cannot satisfy the access request, and the dynamic quota obtained by the event scenario is equal to the corresponding upper limit threshold, the access request of the first thread is abandoned, or the access request of the first thread is placed in a delayed response queue so that when the remaining access quota of the event scenario to which the first thread belongs can satisfy the access request, the media interface is called to send the access request.

[0051] In this implementation, when the remaining access quota for the event scenario to which the first thread belongs is insufficient, and the dynamic quota already acquired for that event scenario has reached its corresponding upper limit threshold, the access system will be unable to continue allocating dynamic quota for that event scenario. At this time, the access system can take two approaches: first, directly abandon the access request of the first thread to avoid exceeding the access quota constraint; second, place the access request in a delayed response queue. The delayed response queue is a data structure used to temporarily store access requests that cannot be executed immediately. When the event scenario subsequently releases quotas or the remaining access quota becomes available again, the media interface will be called sequentially to send the access request.

[0052] In this implementation, by setting a delayed response mechanism when the dynamic quota has reached its upper limit, access requests are not dropped in an orderly manner, but instead regain execution opportunities through orderly waiting. This avoids the risk of interface overload caused by unlimited backlog of access requests, and also provides a smooth handling method for high-frequency request scenarios, thereby improving the stability of the access system when facing resource constraints.

[0053] In some implementations, upon receiving an access request for the media interface from a second thread, the access system can use the remaining access quota after increasing the dynamic quota based on the event scenario to call the media interface and send the access request.

[0054] In this embodiment, when the access system receives an access request for the media interface from a second thread, it can decide whether to allow the second thread to call the media interface based on the remaining access quota after dynamic quota allocation for the event scenario to which the second thread belongs. The second thread refers to a concurrent thread different from the first thread, but belonging to the same event scenario. Further, in this embodiment, the dynamic quota allocated to the event scenario to which the first thread belongs can include multiple quotas. When the access system receives the access request for the media interface from the second thread, it can directly utilize the dynamic quota triggered by the first thread to call the media interface and send the access request. Thus, the second thread does not need to repeatedly trigger the dynamic quota application process, but can quickly obtain the permission to call the media interface based on the increased access quota after the dynamic quota is added.

[0055] In some implementations, the dynamic quota is returned to the dynamic quota pool when both the first thread and the second thread release the quota they have occupied.

[0056] In this implementation, when both the first thread and the second thread complete their access requests and release the quotas they have occupied, the access system can return the dynamic quota previously allocated for this scenario to the dynamic quota pool. Releasing the quota means that after a thread completes its call to the media interface, the quota it occupies is no longer retained, thus forming a reclaimable quota resource.

[0057] In this implementation, the dynamic credit limit return process is uniformly managed by the access system to ensure that the dynamic credit limit pool can continuously maintain a reasonable capacity. After receiving the returned credit limit, the dynamic credit limit pool can reallocate quotas for other service scenarios, thereby preventing the dynamic credit limit from being occupied or idle for a long time.

[0058] In this implementation, by promptly returning the dynamic quota after both the first and second threads release their quotas, the access system can maintain the cyclical use of the dynamic quota, enabling efficient transfer of quota resources across multiple scenarios. This not only improves the overall utilization rate of media interface access resources but also ensures the fairness and sustainability of quota allocation in a concurrent call environment.

[0059] In this implementation, "first thread" and "second thread" do not specifically refer to any one thread, but can be used to represent thread instances that need to occupy dynamic quota in the system. It can be understood that after an event scenario acquires dynamic quota, the acquired dynamic quota can be released entirely when no thread is occupying the increased dynamic quota. In some cases, an event scenario may experience a concentrated surge of access requests within a certain period. In this case, the dynamic quota can be reused to meet the event scenario's call requirements for the media interface. When no thread is occupying the dynamic quota, it indicates that the event scenario has passed the peak call phase for the media interface. Thus, when no thread is occupying the dynamic quota, the dynamic quota for that event scenario is released to improve the utilization rate of the media interface.

[0060] In some implementations, when the first thread and the second thread respectively obtain access quotas to the media interface, they respectively obtain quota locks; wherein, the quota locks are used to indicate that the access quotas are occupied; after the first thread and the second thread respectively finish using the media interface, they respectively release the quota locks.

[0061] In this implementation, when the first thread and the second thread respectively acquire access quotas to the media interface, the access system can allocate quota locks to them respectively. A quota lock can be an occupancy identifier corresponding to a single quota within the access quota, indicating that the quota has been occupied by a particular thread. This avoids resource conflicts caused by multiple threads simultaneously competing for the same quota. By allocating an independent quota lock to each thread, the access system can accurately manage the usage of access quotas in a concurrent environment.

[0062] In this implementation, the quota lock can be more than just a logical identifier; it can also be implemented using a distributed lock. When the access system is deployed in a distributed manner, multiple distributed nodes may simultaneously have access requests for the same transaction. In this case, the quota lock can serve as a distributed lock mechanism, coordinated by a centralized lock management service or consensus protocol, ensuring that the same quota is not repeatedly allocated by multiple distributed nodes in a distributed environment. For example, a lease-based distributed lock mechanism can be used, allowing a thread to exclusively hold the quota for its validity period after acquiring it, and to notify the access system to complete the unlocking operation upon release.

[0063] In this implementation, after the first thread and the second thread complete their respective calls to the media interface, they can release their corresponding quota locks. Releasing a quota lock means that after completing the access request, the thread removes the previously occupied quota identifier, making the quota available again so that subsequent threads can acquire and call the media interface again. In a distributed scenario, releasing a quota lock can also be achieved by updating a globally consistent lock state, thereby ensuring that different nodes can perceive that the quota has become available again.

[0064] In this implementation, the first thread and the second thread are not limited to specific thread instances, but rather represent any thread that needs to occupy access quotas in the access system. When multiple threads exist in a scenario, each thread must bind a corresponding quota lock when acquiring access quotas and release the quota lock after completing the call. In this way, the access system can achieve fine-grained control over access quotas through quota locks, ensuring not only the orderly acquisition and release of quotas, but also avoiding contention between different nodes under distributed deployment conditions.

[0065] In some implementations, the access request from the first thread to the media interface is only received after the first thread has acquired the access lock; wherein the access lock is used to indicate that the first thread is allowed to submit an access request; and the access lock is released if it is determined that the remaining access quota for the first thread's corresponding event scenario is sufficient to satisfy the first thread's access request.

[0066] In this implementation, when the first thread attempts to initiate an access request to the media interface, the access system can first allocate an access lock to that first thread. An access lock is a control identifier used to indicate whether a thread is qualified to submit an access request. Unlike a quota lock, an access lock controls the request sending process, rather than occupying an access quota. Access locks can prevent a large number of threads from submitting access requests out of order before their access quotas are confirmed, thereby reducing concurrency conflicts in the access system.

[0067] In this implementation, access locks can be implemented in a distributed environment through a centralized lock management service or based on a consistency protocol. A thread is only qualified to submit its access request to the access system after acquiring the access lock. If a thread fails to acquire the access lock, its access request will not be received or further processed. In this way, the access system can pre-control the inflow of access requests through access locks before determining access limits, improving the orderliness of data processing within the access system.

[0068] In this implementation, when the access system determines that the remaining access quota for the event scenario belonging to the first thread is sufficient to satisfy the access request, it can release the access lock, allowing the first thread to complete the actual call operation with the support of the quota resources. Releasing the access lock means removing the previous restriction on the thread's request submission, enabling the thread to successfully occupy the access quota and execute the media interface call. In a distributed scenario, releasing the access lock can also update the global state, allowing other distributed nodes to perceive that the access lock is no longer occupied, thereby maintaining the consistency of the lock state.

[0069] In this implementation, an access lock is used to control the request submission phase, ensuring that a thread submits an access request only after it has obtained a quota to call the media interface; a quota lock is used to control the quota occupancy phase, ensuring that a thread exclusively holds its quota during the call. Thus, the access system, through the cooperation of these two locking mechanisms, can improve the stability and fairness of the media interface access process in a distributed environment.

[0070] In some implementations, the priorities of at least some different task scenarios are different; when the remaining access quota of the task scenario to which the first thread belongs cannot meet the access request, in the step of allocating dynamic quota to the task scenario based on the dynamic quota pool, dynamic quota is allocated to the task scenario with higher priority.

[0071] In this implementation, the access system can set priorities for different task scenarios. Task priority refers to a control parameter used to differentiate the urgency or importance of each task scenario during resource contention, guiding the access system in determining the order of priority during dynamic quota allocation. For example, task scenarios involving high-response-demand processing can be assigned high priority, while task scenarios involving batch synchronization or low-time-sensitivity tasks can be assigned lower priority. By setting different task priorities, the access system can ensure that access requests for critical tasks are supported first, within the constraints of limited resources.

[0072] In this implementation, when the remaining access quota for the task scenario to which the first thread belongs is insufficient to meet access requests, the access system will trigger the allocation logic of the dynamic quota pool. During this process, the access system first determines whether to allocate dynamic quota to higher-priority task scenarios based on their priority order. When the dynamic quota pool capacity is limited, the access system will prioritize allocating dynamic quota to higher-priority task scenarios to ensure that thread requests in these scenarios receive timely responses.

[0073] In this implementation, the priority determination process is combined with the dynamic quota allocation process. This allows the dynamic quota pool to not only be divided according to the total quota constraint but also to reflect the different adjustments based on the varying needs of different service scenarios. In some cases, if multiple service scenarios trigger dynamic quota requests simultaneously, the access system can sort them based on priority weights, allocating quotas to high-priority service scenarios first. Once their needs are met, quotas are then allocated to other lower-priority service scenarios. In this way, the access system can balance fairness and efficiency in the dynamic quota pool management process, thereby improving the overall utilization rate of the media interface in concurrent call scenarios.

[0074] Please see Figure 3 The embodiments of this application also provide an access system. The access system includes: a determination module, a partitioning module, and a calling module.

[0075] The determining module is used to determine the access quota corresponding to the event scenario to which the first thread belongs when receiving an access request from the first thread for the media interface; wherein, the event scenario is a category divided according to the function implemented by calling the media interface; different event scenarios correspond to different access quotas; the access quota is used to represent the number of threads in the corresponding event scenario allowed to call the media interface within a specified time window; the media interface has an upper limit value of the access quota within the specified time window.

[0076] The allocation module is used to allocate dynamic quotas to the event scenario based on a dynamic quota pool when the remaining access quota of the event scenario to which the first thread belongs cannot meet the access request. The dynamic quotas are used as the access quotas added to the event scenario. The total access quotas for the media interface for different event scenarios are not greater than the upper limit of the access quota of the media interface.

[0077] The calling module is used to call the media interface to send the access request based on the remaining access quota after increasing the dynamic quota according to the event scenario to which the first thread belongs.

[0078] In this embodiment, the functions and effects implemented by the access system can be explained in comparison with the aforementioned embodiments, and will not be repeated here.

[0079] Please see Figure 4 This application also provides a computer device comprising: a memory and a processor, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the method described above.

[0080] The memory, processor, and communication interface in the computer device can communicate with each other via the system bus and network communication.

[0081] In this embodiment, the functions and effects implemented by the computer device can be explained by referring to the foregoing embodiments, and will not be repeated here.

[0082] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, causes the processor to implement the method as described above.

[0083] The functions and effects achieved in this embodiment can be explained by referring to other embodiments, and will not be repeated here.

[0084] This application also provides a computer program product containing instructions, including a computer program / instructions that, when executed by a processor, implement the method as described above.

[0085] The functions and effects achieved in this embodiment can be explained by referring to other embodiments, and will not be repeated here.

[0086] It is understood that the specific examples in this document are only intended to help those skilled in the art better understand the embodiments of this application, and are not intended to limit the scope of the invention.

[0087] It is understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0088] It is understood that the various implementation methods described in this application can be implemented individually or in combination, and the implementation methods in this application are not limited in this respect.

[0089] Unless otherwise stated, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this application includes any and all combinations of one or more of the associated listed items. The singular forms "a," "the," and "the" as used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0090] It is understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0091] It is understood that the memory in the embodiments of this application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Specifically, non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM). It should be noted that the memory in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0092] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0093] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the aforementioned method implementations, and will not be repeated here.

[0094] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0095] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0096] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0097] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0098] The above description is merely a specific embodiment of this application, but the scope of protection of this invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this invention should be determined by the scope of the claims.

Claims

1. A flow control method for a media interface, characterized in that, include: Upon receiving an access request from the first thread for the media interface, the access quota corresponding to the event scenario to which the first thread belongs is determined; wherein, the event scenario is a category divided according to the function implemented by calling the media interface; different event scenarios correspond to different access quotas; the access quota is used to represent the number of threads in the corresponding event scenario allowed to call the media interface within a specified time window; the media interface has an upper limit value of the access quota within the specified time window; If the remaining access quota of the event scenario to which the first thread belongs cannot meet the access request, a dynamic quota is allocated to the event scenario based on the dynamic quota pool, and the dynamic quota is used as the access quota added to the event scenario; wherein, the sum of the access quotas of different event scenarios for the media interface is not greater than the upper limit of the access quota of the media interface. Based on the event scenario to which the first thread belongs, the remaining access quota after increasing the dynamic quota is called to send the access request via the media interface.

2. The method according to claim 1, characterized in that, Each event scenario has a corresponding minimum access limit threshold; wherein, when the dynamic limit pool has not been allocated a dynamic limit, the sum of the access limits included in the dynamic limit pool and the minimum access limit thresholds corresponding to all event scenarios is less than or equal to the upper limit of the access limit of the media interface.

3. The method according to claim 2, characterized in that, The method further includes: If the first thread is the only active thread in the event scenario to which it belongs, the access quota for the event scenario is allocated from the global quota pool; wherein, the access quota allocated from the global quota pool for the event scenario is equal to the minimum threshold corresponding to the event scenario; the access quota of the global quota pool is equal to the upper limit of the access quota of the media interface. Based on the access limit for the aforementioned scenario, the media interface is invoked to send the access request.

4. The method according to claim 1, characterized in that, Each event scenario has a corresponding upper limit threshold for dynamic quotas; if the remaining access quota for the event scenario to which the first thread belongs cannot meet the access request, dynamic quotas are allocated to the event scenario based on the dynamic quota pool, including: If the remaining access quota for the event scenario to which the first thread belongs cannot satisfy the access request, and the dynamic quota obtained by the event scenario is not greater than the corresponding upper limit threshold, dynamic quota shall be allocated from the dynamic quota pool to the event scenario, and the total amount of dynamic quota obtained by the event scenario shall not be greater than the corresponding upper limit threshold.

5. The method according to claim 4, characterized in that, The method further includes: If the remaining access quota for the event scenario to which the first thread belongs is insufficient to satisfy the access request, and the dynamic quota obtained by the event scenario is equal to the corresponding upper limit threshold, the access request of the first thread is abandoned, or the access request of the first thread is placed in a delayed response queue, so that when the remaining access quota for the event scenario to which the first thread belongs can satisfy the access request, the media interface is invoked to send the access request.

6. The method according to claim 1, characterized in that, The method further includes: Upon receiving an access request for the media interface from the second thread, the remaining access quota after increasing the dynamic quota based on the event scenario is used to call the media interface and send the access request.

7. The method according to claim 6, characterized in that, The method further includes: If both the first thread and the second thread release the quota they have occupied, the dynamic quota will be returned to the dynamic quota pool.

8. The method according to claim 7, characterized in that, The method further includes: If the first thread and the second thread respectively obtain access quotas to the media interface, they respectively obtain quota locks; wherein, the quota locks are used to indicate that the access quotas are occupied; After the first thread and the second thread have finished using the media interface, they respectively release the quota lock.

9. The method according to claim 1, characterized in that, The method further includes: Access requests from the first thread to the media interface are only accepted if the first thread acquires the access lock; wherein, the access lock is used to indicate that the first thread is allowed to submit an access request. If it is determined that the remaining access quota for the scenario corresponding to the first thread is sufficient to satisfy the access request of the first thread, the access lock is released.

10. The method according to claim 1, characterized in that, The priorities of items differ in at least some different scenarios; If the remaining access quota for the task scenario to which the first thread belongs cannot meet the access request, in the step of allocating dynamic quotas to the task scenario based on the dynamic quota pool, dynamic quotas are preferentially allocated to task scenarios with higher priority.

11. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to implement the method as described in any one of claims 1 to 10.

12. A computer program product, characterized in that, Includes computer instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 10.

Images