Link resource allocation method and device, computer equipment, storage medium and program product

Abstract

The invention relates to a link resource allocation method and device, computer equipment, a storage medium and a program product, and relates to the technical field of network communication, and the method comprises the steps: determining the message type of each message, needing to be transmitted between at least two corresponding threads, of a to-be-processed service under the condition that the to-be-processed service is received; the two threads corresponding to each message comprise a sender thread and a receiver thread; based on the message type of each message, determining a target interface adapted to each sender thread in the threads; under the condition that a target interface of a sender thread is determined to be a dependency interface, aiming at each message needing to be sent by the sender thread, allocating a corresponding link resource to each message based on a resource allocation priority of each message and pre-configured resource information of the link resource included in the sender thread, and transmitting the corresponding message based on each link resource. By adopting the method, the rationality of resource allocation in a high-concurrency scene can be improved.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a link resource allocation method, apparatus, computer equipment, storage medium, and program product. Background Technology

[0002] Due to limitations in computer hardware, resources cannot be infinitely expanded for software. Therefore, in high-concurrency scenarios, problems such as resource contention and resource dependency deadlocks can occur, potentially leading to system crashes. Specifically, communication between different threads may involve multiple links, each maintaining limited resources. Resources must be requested before communication can begin. If resources cannot be obtained, the thread is blocked and waits until resources become available. Since these links may have dependencies and a specific communication order, prolonged blocking and waiting can lead to resource dependency deadlocks.

[0003] Therefore, how to reasonably allocate link resources in high-concurrency scenarios has become an urgent problem to be solved. Summary of the Invention

[0004] Therefore, it is necessary to provide a link resource allocation method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the rationality of resource allocation in high-concurrency scenarios, in order to address the above-mentioned technical problems.

[0005] Firstly, this application provides a link resource allocation method, including:

[0006] Upon receiving a pending service, the message types of each message that the pending service needs to be transmitted between at least two corresponding threads are determined; the two threads corresponding to each message include a sending thread and a receiving thread.

[0007] Based on the message type of each message, determine the target interface adapted by each sending thread in the thread;

[0008] If the target interface of the sending thread is determined to be a dependency interface, for each message that the sending thread needs to send, based on the resource allocation priority of each message and the pre-configured resource information of the link resources included in the sending thread, the corresponding link resources are allocated to each message, and the corresponding message is transmitted based on each link resource.

[0009] In this embodiment, the message types of each message that the business to be processed needs to be transmitted between at least two corresponding threads are determined. Based on the message types of each message, the target interface adapted by each sending thread in the thread is determined. When the target interface is a dependency interface, for each message that the sending thread needs to send, corresponding link resources are allocated to each message based on the resource allocation priority of each message and the pre-configured resource information of the link resources included in the sending thread. The corresponding message is transmitted based on each link resource. The link resource allocation of each message is finely managed according to different message types and different resource allocation priorities, thereby avoiding the problem of resource dependency deadlock and improving the rationality of resource allocation in high-concurrency scenarios.

[0010] In one embodiment, the message type includes a dependency type and a normal type; the target interface includes a normal interface and a dependency interface;

[0011] Determining the target interface adapted to each sending thread in the thread includes:

[0012] In the case of the message type of each message that the sending thread needs to send, including the dependency type, the target interface adapted by the sending thread is determined to be the dependency interface.

[0013] If the message type of each message that the sending thread needs to send includes the ordinary type but does not include the dependency type, then the target interface adapted by the sending thread is determined to be the ordinary interface.

[0014] In this embodiment, when the messages to be sent by the sending thread include messages of dependency type, it indicates that the current scenario is prone to dependency deadlock. Therefore, the dependency interface is called as the target interface, and the resource allocation logic of the dependency interface that supports dependency type messages is used to allocate link resources, thereby avoiding the dependency deadlock problem caused by dependency type messages. When the messages to be sent by the sending thread only involve ordinary messages, the ordinary interface is called as the target interface, reducing the consumption of interface computing resources. Different interfaces are adapted to different scenarios, realizing fine-grained management of resource allocation and further improving the rationality of resource allocation in high-concurrency scenarios.

[0015] In one embodiment, upon receiving a pending service, determining the message types of each message that the pending service needs to be transmitted between at least two corresponding threads includes:

[0016] Upon receiving the pending service, the message type of the first message with a dependency relationship that the pending service needs to be transmitted between at least two corresponding threads is determined as the dependency type; the dependency relationship includes chained dependency relationship and business association relationship.

[0017] The message type of the second message, excluding the first message, among the messages that need to be transmitted between at least two corresponding threads for the business to be processed is determined to be of the normal type.

[0018] In this embodiment, upon receiving a pending service, the server detects the relationship between the messages and determines the message type of the first message with a dependency relationship that needs to be transmitted between at least two corresponding threads as the dependency type. The message type of the second message among the messages that need to be transmitted between at least two corresponding threads, excluding the first message, is determined as the normal type. This provides a clear priority hierarchy for subsequent resource allocation and transmission control. The classification of message types helps to clarify which messages require strong consistency, ordering, or resource guarantees, and which messages can take a more flexible parallel path, thereby achieving a more reasonable allocation of link resources.

[0019] In one embodiment, after determining the message type of the first message with a dependency relationship that the pending service needs to be transmitted between at least two corresponding threads as a dependency type, the method further includes:

[0020] Based on the message characteristics of the first message and the dependency relationship, the input parameter identifier of the first message is determined.

[0021] In this embodiment, by extracting and quantifying multiple dimensions of message features and dependencies, such as dependency depth, message attributes, and the business module to which they belong, the semantics and transmission constraints of the first message can be represented by structured input parameter identifiers. This structured representation enables the accurate identification of the priority, constraints, and context of the first message during subsequent resource allocation and transmission scheduling, thereby reducing uncertainty and out-of-order risk during transmission and further improving the rationality of message resource allocation in high-concurrency scenarios.

[0022] In one embodiment, the method further includes:

[0023] If the business association relationship is the same in at least two of the first messages, it is determined that the input parameter identifiers of the at least two first messages are the same.

[0024] In this embodiment, the server sets the input parameter identifiers of at least two first messages with the same business relationship to be the same, indicating that these at least two first messages can follow the same rules in link resource allocation, thereby reducing the risk of disagreement. Furthermore, the complexity of resource allocation changes from evaluating each first message individually to batch processing of such first messages of the same nature. Batch processing reduces the overhead of repetitive calculations, lowers the latency when initiating resource allocation, and improves throughput under high concurrency, further enhancing the rationality of resource allocation.

[0025] In one embodiment, the method further includes:

[0026] If at least two of the first messages have the same chain dependency, it is determined that the input parameter identifiers of the at least two first messages are different.

[0027] In this embodiment, when at least two first messages have the same chain dependency relationship, it indicates that in a high-concurrency scenario, these at least two first messages may conflict in the use of link resources, leading to a dependency deadlock problem. Therefore, the server sets different input parameter identifiers for at least two first messages, so that different allocation rules are adopted when allocating link resources to them in the future, thereby avoiding the dependency deadlock problem and further improving the rationality of resource allocation in a high-concurrency scenario.

[0028] In one embodiment, when it is determined that the target interface of the sending thread is a dependency interface, for each message that the sending thread needs to send, based on the resource allocation priority of each message and the pre-configured resource information of the link resources included in the sending thread, the corresponding link resources are allocated to each message, and the corresponding message is transmitted based on each link resource, including:

[0029] If the target interface of the sending thread is determined to be a dependency interface, for each message that the sending thread needs to send, based on the resource allocation priority of the second message and the pre-configured resource information of the link resources included in the sending thread, the corresponding link resources are allocated for the second message, and the corresponding second message is transmitted based on each link resource.

[0030] Based on the resource allocation priority of the first message, the input parameter identifier, and the pre-configured resource information of the link resources included in the sending thread, link resources corresponding to the input parameter identifier are allocated to the first message, and the corresponding first message is transmitted based on each link resource.

[0031] In this embodiment, when the target interface of the sending thread is determined to be a dependency interface, for each message that the sending thread needs to send, according to the resource allocation priority and pre-configured resource information, link resources are allocated first to the second message that does not have a dependency relationship, and then link resources are allocated to the first message that has a dependency relationship. This can improve the efficiency of business processing and resource utilization. Furthermore, when there are insufficient idle link resources, excess first or second messages are scheduled to their respective waiting queues until corresponding idle link resources are released before allocation, thus realizing the orderly allocation of link resources and further improving the rationality of resource allocation in high-concurrency scenarios.

[0032] In one embodiment, before allocating the corresponding link resources to each message based on the resource allocation priority of each message and the pre-configured resource information of the link resources included in the sending thread, the method further includes:

[0033] Obtain the resource type from the pre-configured resource information of the link resources included in each of the sending threads, and the number of resources corresponding to each resource type; the resource types include ordinary type and dependency type.

[0034] In this embodiment, before allocating link resources, the resource types and the number of resources corresponding to each resource type in the pre-configured resource information are first obtained to provide constraints and guarantees for the link resource allocation stage. This ensures that the subsequent link resource allocation can be carried out in an orderly manner by type and layer, reducing the risk of misordering or blocking caused by insufficient resources, thereby further improving the rationality of link resource allocation in high-concurrency scenarios.

[0035] In one embodiment, when it is determined that the target interface of the sending thread is a normal interface, for each message that the sending thread needs to send, a corresponding normal type of link resource is allocated to each message based on the resource allocation priority of each message, and the corresponding message is transmitted based on each link resource.

[0036] In this embodiment, when only ordinary interfaces are used for link resource allocation, the scheduler no longer needs to make mixed decisions between dependency-type resources and ordinary resources, nor does it need to handle cross-type conflicts between multiple types of resources. This reduces the uncertainty caused by path branches, making scheduling decisions faster, increasing scheduling throughput, and making latency more predictable in high-concurrency scenarios. Furthermore, the diversity of interfaces adapts to the diversity of resource allocation scenarios, improving the flexibility of resource allocation in business systems.

[0037] Secondly, this application also provides a link resource allocation device, comprising:

[0038] The message determination module is used to determine the message type of each message that needs to be transmitted between at least two corresponding threads when a pending service is received; the two threads corresponding to each message include a sending thread and a receiving thread;

[0039] An interface determination module is used to determine the target interface adapted to each sending thread in the thread based on the message type of each message.

[0040] The resource allocation module is used to, when it is determined that the target interface of the sending thread is a dependency interface, allocate corresponding link resources for each message to be sent by the sending thread based on the resource allocation priority of each message and the pre-configured resource information of the link resources included by the sending thread, and transmit the corresponding message based on each link resource.

[0041] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0042] Upon receiving a pending service, the message types of each message that the pending service needs to be transmitted between at least two corresponding threads are determined; the two threads corresponding to each message include a sending thread and a receiving thread.

[0043] Based on the message type of each message, determine the target interface adapted by each sending thread in the thread;

[0044] If the target interface of the sending thread is determined to be a dependency interface, for each message that the sending thread needs to send, based on the resource allocation priority of each message and the pre-configured resource information of the link resources included in the sending thread, the corresponding link resources are allocated to each message, and the corresponding message is transmitted based on each link resource.

[0045] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0046] Upon receiving a pending service, the message types of each message that the pending service needs to be transmitted between at least two corresponding threads are determined; the two threads corresponding to each message include a sending thread and a receiving thread.

[0047] Based on the message type of each message, determine the target interface adapted by each sending thread in the thread;

[0048] If the target interface of the sending thread is determined to be a dependency interface, for each message that the sending thread needs to send, based on the resource allocation priority of each message and the pre-configured resource information of the link resources included in the sending thread, the corresponding link resources are allocated to each message, and the corresponding message is transmitted based on each link resource.

[0049] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0050] Upon receiving a pending service, the message types of each message that the pending service needs to be transmitted between at least two corresponding threads are determined; the two threads corresponding to each message include a sending thread and a receiving thread.

[0051] Based on the message type of each message, determine the target interface adapted by each sending thread in the thread;

[0052] If the target interface of the sending thread is determined to be a dependency interface, for each message that the sending thread needs to send, based on the resource allocation priority of each message and the pre-configured resource information of the link resources included in the sending thread, the corresponding link resources are allocated to each message, and the corresponding message is transmitted based on each link resource.

[0053] The aforementioned link resource allocation method, apparatus, computer equipment, computer-readable storage medium, and computer program product, upon receiving a pending service, determine the message type of each message that needs to be transmitted between at least two corresponding threads, laying the groundwork for subsequent interface adaptation and resource allocation by category. Each message corresponds to two threads: a sending thread and a receiving thread. Further, based on the message type of each message, the target interface adapted to each sending thread is determined. Through category-based interface adaptation, in high-concurrency scenarios, the transmission of messages with stronger business constraints can be prioritized. If the target interface of the sending thread is determined to be a dependency interface, for each message to be sent by the sending thread, corresponding link resources are allocated to each message based on the resource allocation priority of each message and the pre-configured resource information of the link resources included in the sending thread, and the corresponding messages are transmitted based on each link resource. Binding the link resource allocation mechanism to the message type improves the predictability and controllability of link resource allocation. It considers not only the resource allocation priority of each message but also the pre-configured resource information, achieving orderly allocation of link resources and thus improving the rationality of resource allocation in high-concurrency scenarios. Attached Figure Description

[0054] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 This is a sequence diagram of multi-threaded interactions in related technologies.

[0056] Figure 2 This is a flowchart illustrating a link resource allocation method in one embodiment;

[0057] Figure 3 This is a flowchart illustrating the link resource allocation steps in one embodiment;

[0058] Figure 4 This is a schematic diagram of link resource allocation with the same input parameter identifier in one embodiment;

[0059] Figure 5 This is a schematic diagram illustrating the link resource allocation principle with different input parameter identifiers in one embodiment;

[0060] Figure 6 This is a structural block diagram of a link resource allocation device in one embodiment;

[0061] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0062] 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.

[0063] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0064] As described in the background section, the network communication methods of related technologies suffer from low resource allocation rationality in high-concurrency scenarios. The inventors have discovered that the reason for this problem lies in, for example... Figure 1The diagram illustrates a sequence diagram of multi-threaded interaction in related technologies, including thread A and thread B. Communication between these two threads is directional; that is, thread A sending requests to thread B and thread B sending requests to thread A use different links. Each link maintains limited resources, requiring resource allocation before communication can begin. If no resources are available, communication is blocked until resources become available. Thread A requests the link resource from thread A to thread B by sending a request `reqA1` to thread B. When thread B receives `reqA1` and processes the message, it needs to request the link resource from thread B to thread A by sending a request `reqB1` to thread A. When thread A receives `reqB1` and processes the message... Then, a request for resources from thread A to thread B is needed, so a reqA2 request is sent to thread B. Thread B receives the reqA2 request, processes it, and after processing, sends an ackA2 response to thread A, thereby releasing the link resources corresponding to the reqA2 request from thread A to thread B. After thread A receives the ackA2, the processing of the reqB1 request ends, and the thread A replies with an ackB1 response to thread B, thereby releasing the link resources corresponding to the reqB1 request from thread B to thread A. After thread B receives the ackB1 response, the processing of the reqA1 request ends, and thread B replies with an ackA1 response to thread A, thus releasing the link resources corresponding to the reqA1 request from thread A to thread B.

[0065] In the above scenario, the link resources are only truly released after the reqA1 request completes. However, the link resources needed to send the reqA2 request may be occupied by the reqA1 request, because the reqA1 and reqA2 requests use the same link and have a sequential order, creating a link resource dependency between them. Assuming a large number of concurrent upstream transactions (i.e., a large number of reqA1 requests sent from thread A to thread B), the link resources from thread A to thread B are largely allocated, potentially exhausting all link resources in extreme cases. At this point, there are no resources available for allocation when processing reaches the reqA2 request stage, causing the reqA2 request to be blocked. The link resources needed for reqA2 can only be released after reqA1 completes, but the reqA1 request depends on the completion of the reqA2 request, thus creating a deadlock. Related technologies mainly address deadlock problems in high-concurrency scenarios by simply expanding hardware resources such as memory. However, this not only fails to fundamentally solve the problem of unreasonable link resource allocation but also increases enterprise costs.

[0066] Based on the above reasons, this application provides a link resource allocation method. This method determines the message types of each message that the business to be processed needs to transmit between at least two corresponding threads. Based on the message types, it determines the target interface adapted to each sending thread within the thread. When the target interface is a dependency interface, for each message that the sending thread needs to send, it allocates corresponding link resources to each message based on the resource allocation priority of each message and the pre-configured resource information of the link resources included in the sending thread. Then, it transmits the corresponding message based on each link resource. This method performs fine-grained management of the link resource allocation for each message according to different message types and different resource allocation priorities, thereby avoiding resource dependency deadlock and improving the rationality of resource allocation in high-concurrency scenarios.

[0067] In one embodiment, such as Figure 2 As shown, a link resource allocation method is provided. This embodiment uses the application of this method to a server as an example for illustration. It can be understood that this method can also be applied to a terminal, and can also be applied to a system including a terminal and a server, and implemented through the interaction between the terminal and the server. The terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, etc.; the server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. This embodiment includes the following steps S202 to S206. Wherein:

[0068] Step S202: Upon receiving a pending service, determine the message type of each message that needs to be transmitted between at least two corresponding threads for the pending service.

[0069] Each message corresponds to two threads: a sending thread and a receiving thread. A thread can be an execution unit that performs a set of related operations in the system, used to realize the transmission and processing of messages between different roles. The sending thread can be an execution unit that is responsible for sending messages to the other end (the receiving thread), and is responsible for transmitting the messages to be sent through the allocated link resources. The receiving thread can be an execution unit that is responsible for receiving messages from the sending thread, and is responsible for subsequent work such as processing, forwarding or storing the received messages.

[0070] Among them, the pending business can be a business task or business unit that needs to be processed by the system and transmits messages between at least two threads, and is the input object that triggers subsequent processes such as resource allocation, message transmission and interface adaptation.

[0071] A message can be a data unit that needs to be transmitted between the sending thread and the receiving thread in a pending business process, and may contain metadata and actual payload (valid data content); the message type can be a classification attribute that describes the message during the transmission process, such as being divided into dependency type and ordinary type.

[0072] For example, when the server receives a business to be processed, the server determines that the business to be processed needs to be processed in at least two corresponding threads, including determining the sending thread and the receiving thread among the at least two threads, and further determining the message type of each message transmitted between the at least two threads; it can be understood that the server determines the role of the thread involved in the business to be processed in a way that can be obtained according to the preset business processing flow of the business to be processed, and the server determines the message type in a way that can be determined according to the data carried by the message.

[0073] Step S204: Based on the message type of each message, determine the target interface that each sending thread in the thread should adapt to.

[0074] The target interface can be the interface adapted by the sending thread when sending messages. The type of the target interface is determined by the message types of all messages that a sending thread corresponding to a certain business to be processed needs to send. As an intermediate adaptation layer between the sending thread and the link resource pool, the target interface is responsible for dynamically allocating link resources for messages based on message attributes (type, resource allocation priority, etc.) and pre-configured resource information, and coordinating the use and release of link resources. For example, multiple sending threads can all adapt to the same target interface.

[0075] For example, different types of interfaces are pre-built in the server. Different interfaces can support different message types and have different message resource allocation logic. The server determines the target interface adapted by each sending thread based on the message type of the message involved in each sending thread, thus laying the groundwork for allocating link resources for each message in the future.

[0076] Step S206: If the target interface of the sending thread is determined to be a dependency interface, for each message that the sending thread needs to send, based on the resource allocation priority of each message and the pre-configured resource information of the link resources included by the sending thread, the corresponding link resources are allocated to each message, and the corresponding message is transmitted based on each link resource.

[0077] Among them, the dependency interface can be an interface that supports the transmission requirements of messages with dependencies (dependency messages); it should be added that the dependency interface can also support the resource allocation of ordinary messages.

[0078] Among them, resource allocation priority can be the relative priority ranking of different messages when allocating link resources, which is used to determine the link resource allocation order.

[0079] Link resources can be physical or logical resources required for actual message transmission, such as link bandwidth, time slots, and channels.

[0080] Among them, the pre-configured resource information can be the configuration of link resources at system startup or a certain stage, including information such as resource type, quantity, upper limit, and purpose, which is used to quickly allocate resources at runtime.

[0081] For example, when the server determines that the target interface of the sending thread is a dependency interface, for each message that the sending thread needs to send, the server will first determine the resource allocation priority of each message and the pre-configured resource information of the link resources included by the sending thread. Specifically, the server needs to combine the resource allocation priority corresponding to different message types and the resource allocation priority of the first-come-first-served messages of the same type to determine the allocation order of link resources. In addition, it also needs to determine the link resources matched by messages of different message types according to the configured resource information, so that the messages with allocated link resources can be transmitted based on their link resources.

[0082] In the aforementioned link resource allocation method, upon receiving a pending service, the message types of each message that needs to be transmitted between at least two corresponding threads are determined, laying the groundwork for subsequent interface adaptation and resource allocation by category. Each message corresponds to two threads: a sending thread and a receiving thread. Further, based on the message type of each message, the target interface adapted to each sending thread is determined. Through category-based interface adaptation, messages with stronger business constraints can be prioritized for transmission in high-concurrency scenarios. If the target interface of the sending thread is determined to be a dependency interface, for each message to be sent by the sending thread, corresponding link resources are allocated to each message based on the resource allocation priority of each message and the pre-configured resource information of the link resources included in the sending thread. The corresponding messages are then transmitted based on these link resources. Binding the link resource allocation mechanism to the message type improves the predictability and controllability of link resource allocation. It considers not only the resource allocation priority of each message but also the pre-configured resource information, achieving orderly allocation of link resources and thus improving the rationality of resource allocation in high-concurrency scenarios.

[0083] In one exemplary embodiment, the message type includes a dependency type and a normal type; the target interface includes a normal interface and a dependency interface.

[0084] The content executed in step S204 is to determine the target interface adapted by each sending thread in the thread. Specifically, it can be executed as follows: if the message type of each message to be sent by the sending thread includes the dependency type, determine that the target interface adapted by the sending thread is the dependency interface; if the message type of each message to be sent by the sending thread includes the normal type but does not include the dependency type, determine that the target interface adapted by the sending thread is the normal interface.

[0085] Among these, a regular interface can be an interface that supports the allocation of link resources for ordinary message types. It should be noted that a regular interface does not support the allocation of link resources for dependency-type messages.

[0086] For example, if the server detects that the message types of the messages to be sent by the sending thread include dependency types (i.e., if the messages to be sent by the sending thread include dependency types), the server determines that the target interface adapted by the current sending thread is the dependency interface of the link resource allocation service that can support dependency type messages. If the server detects that the message types of the messages to be sent by the sending thread include ordinary types but do not include dependency types (i.e., if the messages to be sent by the sending thread are all ordinary types), the server determines that the target interface adapted by the current sending thread is the ordinary interface that supports resource allocation for ordinary type messages.

[0087] In this embodiment, when the messages to be sent by the sending thread include messages of dependency type, it indicates that the current scenario is prone to dependency deadlock. Therefore, the dependency interface is called as the target interface, and the resource allocation logic of the dependency interface that supports dependency type messages is used to allocate link resources, thereby avoiding the dependency deadlock problem caused by dependency type messages. When the messages to be sent by the sending thread only involve ordinary messages, the ordinary interface is called as the target interface, reducing the consumption of interface computing resources. Different interfaces are adapted to different scenarios, realizing fine-grained management of resource allocation and further improving the rationality of resource allocation in high-concurrency scenarios.

[0088] In an exemplary embodiment, step S202, upon receiving a service to be processed, determines the message type of each message that the service to be processed needs to be transmitted between at least two corresponding threads. Specifically, this can be performed as follows: upon receiving a service to be processed, the message type of the first message that has a dependency relationship and needs to be transmitted between at least two corresponding threads is determined as a dependency type; and the message type of the second message, excluding the first message, among the messages that the service to be processed needs to be transmitted between at least two corresponding threads is determined as a normal type.

[0089] The first message can be a message that is explicitly identified as having a dependency relationship in the set of messages with dependencies, that is, the aforementioned dependency message, such as a message that usually has a chain dependency or business relationship. The type of this message is determined as the dependency type.

[0090] The second message can be any other message that needs to be transmitted between at least two threads in the pending business. It can be said to be the remaining message other than the first message, that is, the ordinary message mentioned above, which is usually identified as a normal type.

[0091] Dependencies include chain dependencies and business relationships. Chain dependencies refer to the fact that the processing or transmission of a message depends on the completion or characteristics of other messages. Business relationships can be logical or business-level connections between different messages or messages in the same business unit to be processed, such as the same business context or the same service object, specifically, such as the transmission of heartbeat signals.

[0092] For example, when the server receives a business to be processed, it detects the relationship between the messages to be sent by the sending thread. If the server detects that there is a dependency relationship between at least two messages to be sent, it determines the message type of the first message with a dependency relationship that the business to be processed needs to transmit between the corresponding at least two threads as a dependency type; and the server determines the message type of the second message other than the first message among the messages that the business to be processed needs to transmit between the corresponding at least two threads as a normal type.

[0093] It is understandable that the server may detect the relationship between messages in ways including but not limited to: uniformly carrying relevant identifiers in the message header or message description when the business to be processed is input into the server, or pre-building a business model and having the server perform static analysis on the business to be processed based on the business model to determine which messages have dependencies and which messages can be processed independently in parallel. In addition, it may also analyze the correlation between messages in the same business context in fields such as time, object identity information, and session identity information. No specific limitations are made on this.

[0094] In this embodiment, when receiving a business to be processed, the server detects the relationships between messages, and determines the message type of the first message with a dependency relationship that needs to be transmitted between at least two corresponding threads of the business to be processed as the dependency type, and determines the message type of the second message other than the first message among the messages that need to be transmitted between at least two corresponding threads of the business to be processed as the ordinary type, providing a clear priority hierarchy for subsequent resource allocation and transmission control. The division of message types helps to clarify which messages require strong consistency, orderliness or resource guarantee, and which messages can take a more flexible parallel path, so as to achieve a more reasonable allocation of link resources.

[0095] In an exemplary embodiment, after determining the message type of the first message with a dependency relationship that needs to be transmitted between at least two corresponding threads of the business to be processed as the dependency type in the above embodiment, it further includes: determining the input parameter identifier of the first message according to the message characteristics and dependency relationship of the first message.

[0096] Among them, the message characteristics may be characteristic information used to describe the message, for example, may include information in three dimensions of the dependency depth of the message, message attributes, and the business module to which it belongs; among them, the dependency depth may be the level of the dependency relationship among the messages that have a dependency relationship with this message. For example, if message A depends on the completion of message B to be completed, then the dependency depth of message A is 0, and the dependency depth of message B is 1; among them, the message attributes may be attributes such as the function, format, and data type of the message; among them, the business module to which it belongs may refer to the functional unit to which this message belongs in the business logic, or which functional unit dominates the generation and processing.

[0097] Among them, the input parameter identifier may be a triple identifier, which is a composite identifier composed of three elements, used to distinguish the dependency relationship characteristics of the first message (dependency type message), and is a structured data. The format may be, for example, (A, B, C), where the three elements respectively correspond to different dimensions of the message characteristics and jointly constitute a complete description of the dependency characteristics of the first message.

[0098] Exemplarily, the server determines the dependency depth, message attributes, and the business module to which it belongs of each message according to the messages and dependency relationships in multiple dimensions included in the message characteristics of the first message, and thus constructs the input parameter identifier of the first message in the form of a triple based on the above information. The specific form of the input parameter identifier is such as refkey (reference key) <depidx (dependency depth), subidx (message attributes), modidx (business module to which it belongs)>. The refkeys corresponding to the first messages with different dependency depths, different message attributes, and different business modules are different. Preferably, each refkey can correspond to an application for allocating a link resource.

[0099] In this embodiment, by extracting and quantifying multiple dimensions of message features and dependencies, such as dependency depth, message attributes, and the business module to which they belong, the semantics and transmission constraints of the first message can be represented by structured input parameter identifiers. This structured representation enables the accurate identification of the priority, constraints, and context of the first message during subsequent resource allocation and transmission scheduling, thereby reducing uncertainty and out-of-order risk during transmission and further improving the rationality of message resource allocation in high-concurrency scenarios.

[0100] In an exemplary embodiment, the above link resource allocation method further includes: determining that the input parameter identifiers of at least two first messages are the same when the business association relationship of at least two first messages is the same.

[0101] For example, if the server detects that at least two first messages have the same business relationship, it indicates that the at least two first messages have the same dependency depth, the same message attributes, and belong to the same business module. Therefore, the input parameter identifiers of the at least two first messages are the same. It can be understood that the same business relationship indicates that the at least two messages are within the same business unit to be processed, and there is a logical or business-level relationship between the messages. However, there is no dependency depth relationship in terms of resource consumption; therefore, the dependency depth of the at least two messages is 0.

[0102] In this embodiment, the server sets the input parameter identifiers of at least two first messages with the same business relationship to be the same, indicating that these at least two first messages can follow the same rules in link resource allocation, thereby reducing the risk of disagreement. Furthermore, the complexity of resource allocation changes from evaluating each first message individually to batch processing of such first messages of the same nature. Batch processing reduces the overhead of repetitive calculations, lowers the latency when initiating resource allocation, and improves throughput under high concurrency, further enhancing the rationality of resource allocation.

[0103] In an exemplary embodiment, the above-described link resource allocation method further includes: determining that the input parameter identifiers of at least two first messages are different when the chain dependency relationship of at least two first messages is the same.

[0104] For example, when the server detects that at least two first messages have the same chain dependency relationship, it indicates that the at least two first messages have the same message attributes and belong to the same business module, but have different dependency depths. Therefore, the input parameter identifiers of the at least two first messages are different. It can be understood that the processing or transmission of one of these at least two first messages depends on the completion or characteristics of other messages. According to the chain association order of each message in the chain dependency relationship, the dependency depth of each first message is determined. For example, if message A depends on the completion of message B to complete, then the dependency depth of message A is 0, and the dependency depth of message B is 1.

[0105] In this embodiment, when at least two first messages have the same chain dependency relationship, it indicates that in a high-concurrency scenario, these at least two first messages may conflict in the use of link resources, leading to a dependency deadlock problem. Therefore, the server sets different input parameter identifiers for at least two first messages, so that different allocation rules are adopted when allocating link resources to them in the future, thereby avoiding the dependency deadlock problem and further improving the rationality of resource allocation in a high-concurrency scenario.

[0106] In one exemplary embodiment, such as Figure 3 As shown, step S206, when it is determined that the target interface of the sending thread is a dependency interface, allocates corresponding link resources to each message to be sent by the sending thread based on the resource allocation priority of each message and the pre-configured resource information of the link resources included in the sending thread, and transmits the corresponding message based on each link resource, including the following steps S302 to S304. Wherein:

[0107] Step S302: If the target interface of the sending thread is determined to be the dependency interface, the corresponding link resources are allocated to the second message based on the resource allocation priority of the second message and the pre-configured resource information of the link resources included in the sending thread, and the corresponding second message is transmitted based on each link resource.

[0108] The resource allocation priority of the second message can be a priority identifier for the second message in resource allocation, used to distinguish the priority of resource contention between each second message and with the first message.

[0109] For example, for the second message among the messages to be sent by the sending thread, the server determines the resource allocation order of each second message based on its resource allocation priority. According to this resource allocation order and the pre-configured resource information of the link resources included in the sending thread, the server allocates corresponding link resources to the second message and transmits the corresponding second message based on each link resource. It is understood that the second message does not have an input parameter identifier, and the ordinary type link resources in the pre-configured resource information are universal for the second message. Therefore, as long as the resource allocation order is followed, and if both the first and second messages are among the messages waiting for resource allocation, the second message is allocated first. Among multiple waiting second messages, ordinary type link resources are allocated as needed according to the order in which the second messages are sent.

[0110] It's important to note that among messages awaiting link resource allocation, the dependency interface prioritizes allocating link resources to the second message before allocating them to the first message. This is because the second messages are independent, with no resource dependencies or business connections. Once sent, the sending thread can immediately release the occupied link resources upon receiving the corresponding response. In contrast, the resource occupation time and complexity of the first message are significantly greater than those of the second message. Therefore, prioritizing link resource allocation to the second message improves business processing efficiency and resource utilization.

[0111] In addition, the pre-configured resource information also includes the number of link resources of each type. When allocating link resources, if the number of second messages waiting to be allocated link resources is greater than the number of ordinary type link resources, the second messages that exceed the number of link resources are identified from all the second messages and scheduled to the waiting queue of second messages to wait for the allocation of idle ordinary type link resources.

[0112] Step S304: For each message that the sending thread needs to send, based on the resource allocation priority of the first message, the input parameter identifier, and the pre-configured resource information of the link resources included in the sending thread, allocate link resources corresponding to the input parameter identifier for the first message, and transmit the corresponding first message based on each link resource.

[0113] The resource allocation priority of the first message can be a priority identifier for the first message in resource allocation, used to distinguish the priority of resource contention between each first message and with the second message.

[0114] For example, when the target interface of the sending thread is determined to be a dependency interface, the server determines the resource allocation order of each first message based on the resource allocation priority of the first message for each message to be sent by the sending thread. The server allocates link resources corresponding to the input parameter identifier for each first message according to the resource allocation order, and according to the input parameter identifier of each first message and the pre-configured resource information of the link resources included by the sending thread, and transmits the corresponding first message based on each link resource.

[0115] It should be noted that the server determines the dependency type of link resources from all link resources based on the pre-configured resource information. Each dependency type of link resource also has an identifier. For example, the identifier of the dependency type link resource uses the same format as the input parameter identifier, and there is a one-to-one correspondence between the identifier of each link resource and the input parameter identifier of the first message. Therefore, when the server allocates resources according to the input parameter identifier of the first message, it needs to allocate the link resource corresponding to the input parameter identifier of the first message. In addition, the pre-configured resource information also includes the quantity of each type of link resource. When allocating link resources, if the number of first messages waiting for link resource allocation is greater than the number of dependency type link resources, the first messages exceeding the number of link resources are determined from all first messages and scheduled to the waiting queue of first messages to wait for the allocation of idle dependency type link resources.

[0116] In this embodiment, when the target interface of the sending thread is determined to be a dependency interface, for each message that the sending thread needs to send, according to the resource allocation priority and pre-configured resource information, link resources are allocated first to the second message that does not have a dependency relationship, and then link resources are allocated to the first message that has a dependency relationship. This can improve the efficiency of business processing and resource utilization. Furthermore, when there are insufficient idle link resources, excess first or second messages are scheduled to their respective waiting queues until corresponding idle link resources are released before allocation, thus realizing the orderly allocation of link resources and further improving the rationality of resource allocation in high-concurrency scenarios.

[0117] In an exemplary embodiment, the process of allocating corresponding link resources to each message based on the resource allocation priority of each message and the pre-configured resource information of the link resources included in the sending thread in step S306 can be specifically executed as follows: obtaining the resource type and the resource quantity corresponding to each resource type from the pre-configured resource information of the link resources included in each sending thread.

[0118] The resource types include ordinary types and dependency types. The resource type can be a specific resource category used for message transmission, reflecting the characteristics and constraints of different transmission channels. The resource quantity can be the level of resources required by the current message or message group during the transmission phase, such as the bandwidth unit, number of time slots, and number of concurrent connections required to send the message.

[0119] For example, the server obtains the resource type from the pre-configured resource information of the link resources included in each sending thread, including ordinary type and dependency type, and further obtains the resource quantity corresponding to the ordinary type link resource and the resource quantity corresponding to the dependency type link resource, laying the groundwork for subsequent resource allocation for each message.

[0120] In this embodiment, before allocating link resources, the resource types and the number of resources corresponding to each resource type in the pre-configured resource information are first obtained to provide constraints and guarantees for the link resource allocation stage. This ensures that the subsequent link resource allocation can be carried out in an orderly manner by type and layer, reducing the risk of misordering or blocking caused by insufficient resources, thereby further improving the rationality of link resource allocation in high-concurrency scenarios.

[0121] In an exemplary embodiment, the resource types of the link resources include ordinary type and dependency type, and the above link resource allocation method further includes:

[0122] If the target interface of the sending thread is determined to be a normal interface, for each message that the sending thread needs to send, the corresponding normal type link resources are allocated to each message based on the resource allocation priority of each message, and the corresponding messages are transmitted based on each link resource.

[0123] For example, if the server determines that the target interface of the sending thread is a normal interface, for each message that the sending thread needs to send, the target interface is a normal interface, which means that each message is a second message. Based on the resource allocation priority of each second message, the server only needs to consider the order in which each second message requests resources, or it can also consider the urgency of the business, allocate corresponding normal type link resources to each message, and transmit the corresponding message based on each link resource.

[0124] In this embodiment, when only ordinary interfaces are used for link resource allocation, the scheduler no longer needs to make mixed decisions between dependency-type resources and ordinary resources, nor does it need to handle cross-type conflicts between multiple types of resources. This reduces the uncertainty caused by path branches, making scheduling decisions faster, increasing scheduling throughput, and making latency more predictable in high-concurrency scenarios. Furthermore, the diversity of interfaces adapts to the diversity of resource allocation scenarios, improving the flexibility of resource allocation in business systems.

[0125] In one exemplary embodiment, another link resource allocation method is provided, including:

[0126] Step 1: Based on the needs of the business to be processed, plan the dependent link resources in advance and reserve link resources of multiple dependency types.

[0127] Specifically, assuming there are 16 link resources in link AB (from thread A to thread B), they are divided into 8 ordinary link resources and 8 dependency link resources (reserved). Step 2: Pre-build ordinary interfaces and dependency interfaces, and select an ordinary interface or a dependency interface according to the message type of the message involved in the business to be processed.

[0128] Ordinary messages (second messages) request ordinary link resources through either the ordinary interface or the dependency interface, while dependency messages (first messages) request dependency link resources through the dependency interface. The dependency interface prioritizes allocating ordinary link resources; if all ordinary link resources have already been allocated, then dependency link resources are allocated.

[0129] The dependency interface has one more input parameter, refkey (input parameter identifier), than the regular interface. The refkey is determined by...<depidx, subidx, modidx> The refkeys are composed of triplets. Different business modules and different business dependencies correspond to different refkeys. Each refkey can apply for one link resource (it can also be extended to apply for multiple different link resources with the same refkey, but here we only discuss one link resource that can be applied for with one refkey as an example).

[0130] Step 3, Resource Allocation and Reclamation. Resource allocation is performed using the dependency interface, including two allocation methods: keeping the input refkey unchanged (same input identifier) ​​and having different input refkeys.

[0131] Specifically, such as Figure 4 The diagram illustrates the principle of link resource allocation with the same input parameter identifier. In the diagram, white represents idle ordinary type link resources, yellow represents dependent link resources, and gray represents allocated link resources. One slot represents one link resource.

[0132] Step 1 (Sub-step 1): Initial state, all link resources are idle.

[0133] Step 2-9 (sub-steps 2-9): The dependency interface prioritizes allocating ordinary link resources, and allocates all 8 ordinary link resources to 8 ordinary messages;

[0134] Step 10 (Sub-step 10): Find the first free dependency resource slot key1 based on the input parameter refkey of the dependency message and assign it to the dependency message with the input parameter refkey corresponding to key1.

[0135] Step 11 (Sub-step 11): No normal link resources are available, and the link resources corresponding to slot refkey1 have already been allocated. However, additional normal messages and additional dependency messages with the same input parameter as key1 are received. The coroutine is suspended and waits, and is added to the waiting queues of the normal slot and the slot corresponding to refkey1. Figure 4 The slot wait count in the queue represents the number of messages waiting in the queue. If a normal link resource or the link resource corresponding to refkey1 is released, the coroutine element in the other waiting queue is deleted.

[0136] Step 12 (sub-step 12): Same as step 11, but upon receiving an additional normal message and an additional dependency message with the same input parameter as key1, the coroutine suspends and waits, incrementing the wait count for both the normal slot and the refkey1 slot by 1.

[0137] Step 13 (Sub-step 13): If the normal link resource is released, a coroutine is retrieved from the normal slot waiting queue and returns a message (msg). The coroutine continues execution. The coroutine element corresponding to the refkey1 dependency slot waiting queue is deleted, and the corresponding slot waiting count is decremented by 1.

[0138] Step 14 (Sub-step 14): If the link resource corresponding to slot refkey1 is released, a coroutine return message is retrieved from the slot waiting queue of refkey1 dependency slot, and the coroutine continues execution. The coroutine element corresponding to the ordinary slot waiting queue is deleted, and the corresponding slot waiting count is decremented by 1.

[0139] Step 15 (Sub-step 15): Release the first normal link resource.

[0140] Step 16: Release the link resources corresponding to slot refkey1.

[0141] In addition, such as Figure 5 As shown, a schematic diagram of link resource allocation with different input parameters is provided, including:

[0142] Step 1 (Sub-step 1): Initial state, assuming that all 8 ordinary link resources have been allocated.

[0143] Step 2 (sub-step 2): Based on the refkey1 of the dependency message, allocate the link resources of key1 to the dependency message with refkey1 as input.

[0144] Based on the refkey1 of the dependency message, allocate the link resources of key1 to the dependency message with refkey1 as input.

[0145] Step 3-9 (Sub-step 3-9): Allocate dependency link resources to the corresponding slots of each dependency message using the input parameters refkey1-refkey8.

[0146] Step 10-17 (sub-steps 10-17): Release the dependency link resources in sequence.

[0147] In this embodiment, under high concurrency scenarios, appropriate interfaces are selected for link resource allocation for messages of different message types. During the resource allocation process, resource allocation is performed based on the classification and priority of each message in the sending thread. This can make full use of limited resources to achieve efficient operation of the business; it can also refine the granularity of resource allocation and save more resources.

[0148] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0149] Based on the same inventive concept, this application also provides a link resource allocation apparatus for implementing the link resource allocation method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more link resource allocation apparatus embodiments provided below can be found in the limitations of the link resource allocation method described above, and will not be repeated here.

[0150] In one exemplary embodiment, such as Figure 6 As shown, a link resource allocation device 600 is provided, including: a message determination module 601, an interface determination module 602, and a resource allocation module 603, wherein:

[0151] The message determination module 601 is used to determine the message type of each message that needs to be transmitted between at least two corresponding threads when a pending service is received; the two threads corresponding to each message include the sending thread and the receiving thread.

[0152] The interface determination module 602 is used to determine the target interface adapted by each sending thread in the thread based on the message type of each message.

[0153] The resource allocation module 603 is used to allocate corresponding link resources for each message to be sent by the sending thread when the target interface of the sending thread is determined to be a dependency interface, based on the resource allocation priority of each message and the pre-configured resource information of the link resources included by the sending thread, and transmit the corresponding message based on each link resource.

[0154] Furthermore, in one embodiment, the interface determination module 602 is further configured to determine, in the case that the message type of each message to be sent by the sending thread includes the dependency type, the target interface adapted by the sending thread is a dependency interface; and in the case that the message type of each message to be sent by the sending thread includes the normal type but does not include the dependency type, the target interface adapted by the sending thread is a normal interface.

[0155] Furthermore, in one embodiment, the message determination module 601 is further configured to, upon receiving a pending service, determine the message type of the first message with a dependency relationship that needs to be transmitted between at least two corresponding threads as a dependency type; the dependency relationship includes chain dependency relationship and business association relationship; and determine the message type of the second message other than the first message among the messages that need to be transmitted between at least two corresponding threads as a normal type.

[0156] Furthermore, in one embodiment, the message determination module 601 is also configured to determine the input parameter identifier of the first message based on the message characteristics and dependencies of the first message.

[0157] Furthermore, in one embodiment, the message determination module 601 is also configured to determine that the input parameter identifiers of at least two first messages are the same if the business association relationship of at least two first messages is the same.

[0158] Furthermore, in one embodiment, the message determination module 601 is also configured to determine that the input parameter identifiers of at least two first messages are different if the chain dependency relationship of at least two first messages is the same.

[0159] Furthermore, in one embodiment, the resource allocation module 603 is further configured to, when determining that the target interface of the sending thread is a dependency interface, allocate corresponding link resources for each message to be sent by the sending thread based on the resource allocation priority of the second message and the pre-configured resource information of the link resources included in the sending thread, and transmit the corresponding second message based on each link resource; and allocate link resources corresponding to the input parameter identifier for the first message based on the resource allocation priority of the first message, the input parameter identifier, and the pre-configured resource information of the link resources included in the sending thread, and transmit the corresponding first message based on each link resource.

[0160] Furthermore, in one embodiment, the resource allocation module 603 is also used to obtain the resource type in the pre-configured resource information of the link resources included in each sending thread, as well as the resource quantity corresponding to each resource type; the resource types include ordinary type and dependency type.

[0161] Furthermore, in one embodiment, the resource allocation module 603 is also configured to, when it is determined that the target interface of the sending thread is a normal interface, allocate corresponding normal type link resources for each message to be sent by the sending thread based on the resource allocation priority of each message, and transmit the corresponding message based on each link resource.

[0162] Each module in the aforementioned link resource allocation device 600 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0163] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data such as message types and pre-configured resource information. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a link resource allocation method.

[0164] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0165] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0166] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0167] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0168] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0169] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0170] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method of link resource allocation, characterized by, The method comprises: In the case of receiving a to-be-processed service, determining a message type of each message required by the to-be-processed service to be transmitted between corresponding at least two threads; the two threads corresponding to each message include a sender thread and a receiver thread; Based on the message type of each message, determining a target interface adapted by each sender thread in the thread; In the case of determining that the target interface of the sender thread is a dependency interface, for each message required to be sent by the sender thread, based on the resource allocation priority of the message and the preconfigured resource information of the link resource included by the sender thread, allocating the corresponding link resource to each message, and transmitting the corresponding message based on each link resource.

2. The method of claim 1, wherein, The message type includes a dependency type and a normal type; and the target interface includes a normal interface and a dependency interface; The determination of the target interface adapted by each sender thread in the thread comprises: In the case that the message type of each message required to be sent by the sender thread includes the dependency type, it is determined that the target interface adapted by the sender thread is the dependency interface; In the case that the message type of each message required to be sent by the sender thread includes the normal type and does not include the dependency type, it is determined that the target interface adapted by the sender thread is the normal interface.

3. The method of claim 1, wherein The determination of the message type of each message required by the to-be-processed service to be transmitted between corresponding at least two threads in the case of receiving the to-be-processed service comprises: In the case of receiving the to-be-processed service, the message type of a first message having a dependency relationship required by the to-be-processed service to be transmitted between corresponding at least two threads is determined to be a dependency type; the dependency relationship includes a chain dependency relationship and a service association relationship; The message type of a second message other than the first message among each message required by the to-be-processed service to be transmitted between corresponding at least two threads is determined to be a normal type.

4. The method of claim 3, wherein, After the message type of the first message having the dependency relationship required by the to-be-processed service to be transmitted between corresponding at least two threads is determined to be the dependency type, the method further comprises: According to the message characteristics of the first message and the dependency relationship, the input parameter identifier of the first message is determined.

5. The method of claim 4, wherein, The method further comprises: In the case that the service association relationship of at least two first messages is the same, it is determined that the input parameter identifiers of the at least two first messages are the same.

6. The method of claim 4, wherein, The method further comprises: In the case that the chain dependency relationship of at least two first messages is the same, it is determined that the input parameter identifiers of the at least two first messages are different.

7. The method of claim 4, wherein, In a case where it is determined that the target interface of the sender thread is a dependency interface, for each of the messages required to be sent by the sender thread, a corresponding link resource is allocated to each of the messages based on a resource allocation priority of each of the messages and preconfigured resource information of link resources included in the sender thread, and a corresponding message is transmitted based on each of the link resources. In a case where it is determined that the target interface of the sender thread is a dependency interface, for each of the messages required to be sent by the sender thread, a corresponding link resource is allocated to each of the messages based on a resource allocation priority of each of the messages and preconfigured resource information of link resources included in the sender thread, and a corresponding message is transmitted based on each of the link resources. In a case where it is determined that the target interface of the sender thread is a dependency interface, for each of the messages required to be sent by the sender thread, a corresponding link resource is allocated to each of the messages based on a resource allocation priority of each of the messages and preconfigured resource information of link resources included in the sender thread, and a corresponding message is transmitted based on each of the link resources.

8. The method according to any one of claims 1 to 7, characterized in that, Before the allocating, the method further includes: obtaining a resource type in the preconfigured resource information of the link resources included in each of the sender threads and a resource quantity corresponding to each of the resource types; the resource types include a normal type and a dependency type.

9. The method according to any one of claims 1 to 7, characterized in that, The resource types of the link resources include a normal type and a dependency type, and the method further includes: In a case where it is determined that the target interface of the sender thread is a normal interface, for each of the messages required to be sent by the sender thread, a corresponding normal type of link resource is allocated to each of the messages based on a resource allocation priority of each of the messages, and a corresponding message is transmitted based on each of the link resources.

10. A link resource allocation apparatus characterized by comprising: The apparatus includes: a message determination module configured to, in a case where a to-be-processed service is received, determine a message type of each message required to be transmitted between corresponding at least two threads of the to-be-processed service; the two threads corresponding to each of the messages include a sender thread and a receiver thread; an interface determination module configured to determine a target interface adapted by each of the sender threads based on the message type of each of the messages; a resource allocation module configured to, in a case where it is determined that the target interface of the sender thread is a dependency interface, for each of the messages required to be sent by the sender thread, allocate a corresponding link resource to each of the messages based on a resource allocation priority of each of the messages and preconfigured resource information of link resources included in the sender thread, and transmit a corresponding message based on each of the link resources. 11.A computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the computer device is configured to perform the method according to any one of claims 1-10 when the computer program is executed by the processor. The processor implements the steps of the method of any one of claims 1 to 9 when executing the computer program.

12. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 9.

13. A computer program product comprising a computer program, characterized in that, The computer program, which is executed by a processor, implements the steps of the method according to any one of claims 1 to 9.

Images