A media resource traffic distribution optimization method

Abstract

The application discloses a media resource traffic distribution optimization method, relates to the technical field of digital media traffic distribution, and is used for solving the problems of feedback attribution error caused by asynchronous overlap of multiple resource execution feedback after service traffic request is redirected and current running state being covered by late feedback error. Execution record is established every time service traffic request is actually sent to a media resource, sending association information and sending sequence in the media resource are associated; original execution record is kept and new execution record is established when redirection is performed; corresponding execution record and media resource are determined according to sending association information after execution feedback is returned, and the execution record actually adopted is determined to determine the media resource to undertake; current running state is updated by earlier execution feedback according to the sending sequence in the same media resource, and the processed current running state is used for subsequent service traffic distribution.

Description

Technical Field

[0001] This invention relates to the field of digital media traffic allocation technology, specifically to a method for optimizing media resource traffic allocation. Background Technology

[0002] With the development of digital media delivery and programmatic advertising, media platforms typically need to allocate continuously incoming business traffic requests to different media resources and continue to select resources for subsequent requests based on resource response, business conditions, and operational status. In application scenarios such as real-time bidding, the same advertising request may initiate resource calls to one or more demand-side platforms and receive the returned results within a limited response time. Existing publicly available solutions already involve traffic control, resource selection, and asynchronous request processing. For example, CN107171970A discloses a method and system for advertising delivery in a real-time bidding system, which adds requests sent to different DSPs to their corresponding waiting queues, asynchronously requests DSPs through a connection pool, and continues bidding processing after each DSP returns advertising content or reaches a timeout period; CN110060084A discloses an advertising traffic allocation control method, which performs a comprehensive quality evaluation of the target ad group and controls the media-side traffic allocation accordingly. The above technologies show that existing media traffic processing can already complete request sending, waiting for response, resource switching, or subsequent traffic allocation based on resource conditions.

[0003] However, during continuous media traffic processing, the resource selection state and the actual resource calls do not always end synchronously. When a business traffic request has been sent to the original target media resource, but the execution result of that resource has not yet been fully returned, the platform may redirect the same business traffic request to other media resources due to timeout, resource anomalies, or changes in existing traffic control conditions. At this time, the invocation process of the original target media resource may still be ongoing, and the redirected media resource may also generate a new execution result. Therefore, the execution processes of multiple resources corresponding to the same business traffic request and their asynchronous feedback may overlap in time.

[0004] Under the above conditions, if subsequent feedback processing is primarily based on the media resource currently targeted by the business traffic request, the latest allocation result of the request, or a single request identifier, a mismatch may occur between the delayed execution feedback from the original target media resource and the new feedback formed by the redirected media resource. Furthermore, even if the feedback can identify its source media resource, delayed feedback formed by earlier resource execution may still affect the current operational state even after the media resource has completed its subsequent execution. Therefore, the actual execution attribution of the business traffic request and the current operational state of the media resource may deviate from the actual execution process, causing subsequent business traffic allocation to read state information inconsistent with the actual resource execution sequence. Thus, accurately maintaining the correspondence between different resource execution processes and avoiding incorrect resource state attribution or time sequence rollback caused by delayed feedback when business traffic requests are redirected and multiple resource execution feedbacks overlap asynchronously is a technical problem that needs further resolution in the continuous allocation of this type of media resource traffic. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a method for optimizing media resource traffic allocation, thereby solving the problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a media resource traffic allocation optimization method, comprising: S1. When a business traffic request is actually sent to the target media resource, an execution record is created for this send, which associates the business traffic request, the target media resource, the sending association information of the corresponding subsequent execution feedback, and the sending order within the target media resource. S2. When the execution result of the target media resource has not been fully returned and the business traffic request is redirected, the original execution record is retained, and a new execution record is created when the data is actually sent to the redirected media resource. S3. After the execution feedback is returned, determine the corresponding execution record and media resources based on the sent association information; S4. From the execution record of the business traffic request, determine the return result selected by the platform and write it into the execution record of the final output of the business traffic request, and assign the result to the media resource corresponding to the execution record. S5. For the current running status of the media resource corresponding to the execution feedback, compare the sending order of the execution record corresponding to the feedback with the execution record already used to form the current running status within the media resource. If the former is earlier, do not update the current running status with the feedback, and use the processed current running status for subsequent business traffic allocation.

[0007] Furthermore, the result of accepting business traffic requests only belongs to the media resource corresponding to the execution record that the returned result is written into the final output by the platform; For execution records that are not ultimately used in the same business traffic request, their execution feedback does not change the acceptance result. When the sending order of the execution record in the corresponding media resource is later than that of the execution record that has been used to form the current running state, the current running state is updated with the execution feedback.

[0008] Furthermore, the associated information is a sub-request identifier generated for each actual media resource call; Different actual resource calls for the same business traffic request use different sub-request identifiers. The sub-request identifier is associated with the corresponding execution record and media resource when it is actually sent and is carried by the execution feedback. When the execution feedback does not directly carry the sub-request identifier, the sub-request identifier is recovered from the context of this communication transaction.

[0009] Furthermore, the sending order is represented by the sending sequence number within the same media resource; When the sequence number of a new execution feedback is greater than the sequence number of an execution record already used to form the current running status, the current running status is updated with this execution feedback; If the two are equal, the execution feedback is written to the corresponding execution record and the current running state remains unchanged; When the former is smaller, the execution feedback is written to the corresponding execution record and the current running status is not updated.

[0010] Furthermore, after the execution feedback is returned, the corresponding execution record is first located based on the sub-request identifier, and then the media resources that are fixedly associated in the execution record are read. When the platform writes a certain return result into the final output of the business traffic request, it searches for the execution record again based on the sub-request identifier corresponding to the return result, and determines the actual media resource to be received based on the media resource corresponding to the execution record.

[0011] Furthermore, the execution record should at least be associated with the business traffic request identifier, media resource identifier, sub-request identifier, and the sending order within the media resource; When resource redirection occurs, the media resource identifier, sub-request identifier, and sending order in the original execution record remain unchanged. A new execution record is created when the redirected media resource is actually sent.

[0012] Furthermore, each time a media resource call enters the corresponding media resource's sending entry point and is submitted, the sending sequence number of that media resource is atomically incremented. The incremented sending sequence number indicates the actual sending order of each execution record for the same media resource, and the sending order is not determined by the execution feedback return order.

[0013] Furthermore, when the same business traffic request is redirected to multiple resources, an independent execution record is established for each actual transmission to a new media resource. Each execution record is associated with the corresponding transmission association information and the transmission order within its respective media resource, and is jointly associated with the same business traffic request. The execution feedback returned by each media resource is used to determine the execution record based on the corresponding sent associated information.

[0014] Furthermore, the current running status includes the resource call result reflected in the most recent execution feedback used to update the current running status, as well as the sending sequence number of the execution record corresponding to that execution feedback; The result of resource access can be one of the following: success, failure, or explicit rejection by the resource side.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. By establishing an execution record each time a business traffic request is actually sent to a media resource, and using the sending association information to map subsequent execution feedback to the actual execution record and media resource, multiple actual execution processes before and after resource redirection can maintain their independent correspondence, thereby avoiding the error of attributing late execution feedback to other media resources due to changes in the current target of the business traffic request.

[0016] 2. By using whether the returned result is selected by the platform and written into the final output of the business traffic request as the basis for determining the actual media resource to be accepted, and processing it separately from the actual resource source of the execution feedback, the delayed success feedback of the original media resource does not change the already formed business traffic request acceptance result, thereby avoiding the same business traffic request being duplicated or incorrectly assigned to different media resources due to the overlap of asynchronous feedback.

[0017] 3. By comparing the sending order of the execution record corresponding to the execution feedback with the execution record already used to form the current running state within the same media resource, the late feedback of the earlier execution record is restricted from covering the current running state, and the processed current running state is used for subsequent business traffic allocation, so that the media resource state can continue to carry over along the actual sending process, reducing the resource state rollback and subsequent allocation basis distortion caused by asynchronous feedback out-of-order. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a method for optimizing media resource traffic allocation. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Example: Combined with Appendix Figure 1 This embodiment provides a method for optimizing media resource traffic allocation, including: S1. When a business traffic request is actually sent to the target media resource, an execution record is created for this send, which associates the business traffic request, the target media resource, the sending association information of the corresponding subsequent execution feedback, and the sending order within the target media resource. S2. When the execution result of the target media resource has not been fully returned and the business traffic request is redirected, the original execution record is retained, and a new execution record is created when the data is actually sent to the redirected media resource. S3. After the execution feedback is returned, determine the corresponding execution record and media resources based on the sent association information; S4. From the execution record of the business traffic request, determine the return result selected by the platform and write it into the execution record of the final output of the business traffic request, and assign the result to the media resource corresponding to the execution record. S5. For the current running status of the media resource corresponding to the execution feedback, compare the sending order of the execution record corresponding to the feedback with the execution record already used to form the current running status within the media resource. If the former is earlier, do not update the current running status with the feedback, and use the processed current running status for subsequent business traffic allocation.

[0021] This implementation method is applied to the continuous allocation process of business traffic in digital media operation or media delivery platforms. The platform continuously receives business traffic requests that need to be executed by specific media resources. The existing media resource allocation process determines the current target media resource according to the platform's existing resource selection logic and sends the business traffic request to the determined media resource. The media resource in this article is a media resource unit that can receive and execute business traffic requests. It can correspond to different resource positions, different resource access terminals, or different media resource services called separately by the platform within the same media platform. How media resources are selected based on budget, price, click-through rate, conversion rate, or other existing factors is not the focus of this implementation method. This implementation method starts from when the business traffic request has determined the target media resource and is ready to be actually sent, and continuously processes the multiple actual execution processes formed before and after resource redirection of a single request, the subsequent execution feedback returned by each execution process, and the current running status of the corresponding media resource.

[0022] In actual platform operation, the same business traffic request might be sent to the first media resource first. Before the execution result of the first media resource has been fully returned, the platform's traffic control logic redirects the same business traffic request to the second media resource. The first media resource has already received the request and may continue to return a response later, while the second media resource also begins to form a new execution result. Therefore, the same business traffic request may simultaneously have two resource execution processes that have not yet been fully completed within a certain period of time. If the platform only saves the media resource currently pointed to by the business traffic request, and directly replaces the first media resource with the second media resource during resource redirection, then the delayed execution feedback subsequently returned by the first media resource may lose a stable execution attribution basis. If the delayed execution feedback is subsequently processed based on the second media resource currently pointed to by the business traffic request, the execution result formed by the first media resource will be incorrectly applied to the second media resource. On the other hand, even if the delayed execution feedback has been correctly identified as being formed by the first media resource, the resource execution corresponding to this feedback may be earlier than other execution processes that the first media resource has later completed. Directly using this delayed feedback to overwrite the current running state of the first media resource will also cause the current state to revert to an earlier execution moment.

[0023] To ensure the above process operates according to a unified technical standard, this implementation treats each actual call made by a business traffic request to a specific media resource as an independent execution process. The platform generates an execution record corresponding to each actual send. This execution record does not repeatedly register the business traffic request itself, but rather represents an actual call made by the business traffic request to a specific media resource. Even if the same business traffic request is subsequently redirected, the already generated execution record maintains its original media resource correspondence and is not rewritten due to changes in the current target media resource. Subsequent execution feedback is first mapped to the execution record that actually generated the feedback, and then the platform determines which media resource will handle the current business traffic request based on the result returned by which execution record is ultimately used. For delayed feedback belonging to a specific media resource, it is also necessary to consider the actual sending order of different execution records within that media resource to determine whether it can still change the current operating state of that media resource.

[0024] The platform can utilize existing business request processing programs to complete data formation, association, and status updates, eliminating the need for separate new hardware modules for each process. Execution records and the current running status of media resources can be stored in the platform's existing request context storage, runtime memory, or persistent storage, as long as they can be retrieved by subsequent execution feedback and resource status processing within the business traffic request lifecycle. Ordinary network connections, API calls, data serialization, power supply, and basic storage all utilize existing platform facilities; the specific implementation differences do not alter the execution source confirmation, actual acceptance confirmation, and timing constraints within resources as described in this document.

[0025] When the platform's existing traffic allocation process has already determined the target media resource for a business traffic request, and the business request handler is preparing to issue an actual call to that target media resource, the platform first reads the request identifier of the current business traffic request itself and the resource identifier of the target media resource. The business traffic request identifier is used to distinguish different business requests being processed simultaneously by the platform, and the media resource identifier is used to distinguish the media resource targeted by this actual call. Both are derived from existing business requests and resource configurations on the platform and do not need to be recalculated.

[0026] For this actual transmission, the platform generates a sub-request identifier unique to this resource call and writes this sub-request identifier as transmission association information into the execution record. Simultaneously, it places this sub-request identifier into the request field, request header, or callback association field of this transmission to the target media resource. This allows the target media resource to carry the sub-request identifier in its subsequent response, or enables the platform to recover the sub-request identifier based on the context of this communication transaction. The main implementation uses the platform-generated sub-request identifier as transmission association information. This sub-request identifier remains different across different actual resource calls for the same service traffic request, ensuring that each resource call can be individually identified when the same service traffic request is sent to different media resources sequentially. The specific character length and encoding format of the sub-request identifier are not involved in subsequent judgments, as long as it uniquely corresponds to this actual transmission in the execution feedback return.

[0027] The platform also maintains the actual sending sequence at the target media resource level. The main implementation maintains a monotonically increasing sending sequence number within each media resource. When a service traffic request enters the sending entry point of a target media resource and submits the call, the current sending sequence number of that target media resource is atomically incremented once. The incremented value is written to the current execution record, and this sequence number indicates the order in which the call enters the same media resource's sending entry point. The sending sequence number is only used to compare the actual sending sequence of different execution records within the same media resource; direct comparison between sending sequence numbers of different media resources is not required. For example, if the current sending sequence number of the first media resource is 125, the execution record formed when the current service traffic request is actually sent to the first media resource is written with sending sequence number 126; if the second media resource has an independent sending sequence number 57, and the service traffic request is later redirected and actually sent to the second media resource, its new execution record is written with sending sequence number 58. The aforementioned 126 and 58 are not used for cross-resource comparisons.

[0028] When the same media resource is sent concurrently, the sending entry point corresponding to the media resource performs the aforementioned atomic increment upon submission of each call, ensuring that each call entering the sending entry point of that media resource obtains a definite and unique sequence value. This sequence value, along with the corresponding execution record, is then submitted for this media resource call. Therefore, the sending sequence number indicates the order in which calls for the same media resource enter the sending entry point, rather than the order in which different processing threads obtain processing opportunities or the execution feedback return time. As long as different actual sending of the same media resource can form a stable sequential relationship, using resource-independent counter values, existing sending queue sequence numbers, or other sequence values ​​that can indicate the sending order of the same resource will not change the subsequent technical relationships. The main implementation path below will be explained using resource-independent incrementing sending sequence numbers.

[0029] An execution record corresponds to at least the current business traffic request identifier, the actual target media resource identifier, the sub-request identifier, and the sending sequence number within the media resource. The platform completes the above association when the call is submitted to the target media resource sending entry point, and maintains the execution record for subsequent execution feedback after the call is delivered to the target media resource interface. Each execution record corresponds one-to-one with the actual sending; therefore, if the same business traffic request is actually sent to a media resource only once, one execution record is formed. If the same business traffic request is subsequently redirected to another media resource and actually sent again, a new execution record is formed. The two execution records are not merged because they belong to the same business traffic request.

[0030] For example, when a business traffic request enters the platform with a request identifier 20260001, the existing media traffic allocation logic determines the first media resource as the initial target. When the platform prepares to initiate a call to the first media resource, it generates a sub-request identifier 20260001-01. The current sending sequence number of the first media resource increments from 125 to 126, forming an execution record. This record stores the business traffic request identifier 20260001, the resource identifier of the first media resource, the sub-request identifier 20260001-01, and the sending sequence number 126. The network request carries the sub-request identifier 20260001-01. Subsequently, regardless of whether the current target resource of the business traffic request changes, this execution record always indicates the technical fact that request identifier 20260001 was actually sent to the first media resource with sending sequence number 126.

[0031] Once the execution record is generated, the platform does not need to wait for the media resource to return a result before processing other business traffic requests. The sequence number corresponding to the first media resource will continue to increment as subsequent business traffic requests are actually sent. For example, while request identifier 20260001 is waiting for a response from the first media resource, another business traffic request can obtain a sequence number of 127 when it is actually sent to the first media resource. This sequence relationship will be used to determine whether an earlier execution feedback can still represent the current operating status of the first media resource when a late feedback is returned.

[0032] The platform monitors issued media resource calls according to existing traffic control logic. When the execution result of the original target media resource has not yet fully returned, and the existing traffic control logic has determined that the same business traffic request needs to be redirected to another media resource, a resource redirection event serves as the trigger for continued processing in this implementation. "Execution result not yet fully returned" in this context means that, as of the time the resource redirection result is formed, the platform has not yet obtained a complete response sufficient to end the processing of this media resource call; the original media resource call may still return execution feedback. The timeout threshold, resource availability conditions, or resource selection rules used for redirection are determined by the platform's existing traffic control process; this implementation does not change this determination.

[0033] After receiving the resource redirection result, the platform does not rewrite the media resource identifier in the original execution record with the redirected media resource identifier, nor does it delete the sub-request identifier and sending sequence number in the original execution record. The original execution record continues to maintain the actual sending relationship between the business traffic request and the original target media resource, so that when the original target media resource subsequently returns a delayed feedback, the corresponding actual execution process can still be found.

[0034] When the same service traffic request is actually sent to the redirected media resource, the platform generates a new execution record in the same way as the initial actual send. For this new actual send, the platform generates a new sub-request identifier, obtains the sending sequence number of the redirected media resource itself, and writes the same service traffic request identifier, the redirected media resource identifier, the new sub-request identifier, and the sending sequence number within the redirected media resource into the new execution record. The new execution record and the original execution record are both associated with the same service traffic request, but they correspond to different media resources and different actual sends.

[0035] Taking business traffic request identifier 20260001 as an example, this request has already been sent to the first media resource with sub-request identifier 20260001-01 and sending sequence number 126. If the platform's existing traffic control logic determines to redirect the current business traffic request to the second media resource before the execution result of the first media resource has been fully returned, the original execution record remains unchanged. When the current business traffic request is actually sent to the second media resource, the platform generates sub-request identifier 20260001-02; the current sending sequence number of the second media resource increases, for example, from 57 to 58. Therefore, the new execution record stores business traffic request identifier 20260001, the second media resource identifier, sub-request identifier 20260001-02, and sending sequence number 58. At this time, business traffic request identifier 20260001 has two actual execution records, corresponding to the first media resource and the second media resource respectively.

[0036] The two execution records mentioned above only establish a common source relationship through the same business traffic request; it is not required to combine the sending sequence number 126 of the first media resource and the sending sequence number 58 of the second media resource into a unified cross-resource sequence. The sending sequence number 126 of the first media resource is only compared with other sending sequence numbers of the first media resource, and the sending sequence number 58 of the second media resource is only compared with other sending sequence numbers of the second media resource. The order of resource redirection is naturally determined by the fact that the same business traffic request first existed in the original execution record, and then the redirection occurred and a new execution record was formed; there is no need to establish a separate cross-resource global clock order.

[0037] In a representative deployment, the platform's existing resource call waiting time can be set to 200ms. If the first media resource fails to produce the complete execution result required by the platform's existing process within this waiting period, the platform's original control logic generates a redirection result and selects a second media resource. This implementation does not use 200ms as a core processing parameter; in different deployment environments, the waiting time can be configured by the existing platform according to interface service level, network conditions, or resource response requirements. Regardless of the specific redirection conditions, as long as the execution result corresponding to the first media resource has not been fully returned when resource redirection occurs, the original execution record is retained, and a new execution record is created when the second media resource is actually sent.

[0038] If the first media resource returns execution feedback after a redirect, this feedback will not be directly attributed to the second media resource simply because the business traffic request has now been redirected. The sub-request identifier and the first media resource identifier in the original execution record will continue to serve as the true basis for confirming the source of subsequent feedback. The execution feedback of the second media resource will also be processed independently through a new execution record, and the two execution processes will not overwrite each other due to the same business request identifier.

[0039] When the target media resource or redirected media resource returns execution feedback, the platform first reads the sub-request identifier carried in the execution feedback. The main implementation requires that the media resource response or callback can send back the sub-request identifier provided by the platform in this actual transmission. For calls using synchronous response interfaces, the sub-request identifier can be obtained from the corresponding request field in the response; for calls using asynchronous callbacks, the sub-request identifier can be obtained from the callback parameters. Based on this, the platform searches for the same sub-request identifier in the execution records already formed by the current business traffic request. Since each actual resource transmission uses a different sub-request identifier, the matching result can identify a specific execution record.

[0040] After obtaining the specific execution record, the platform directly reads the media resource identifier that is fixedly associated with the actual transmission in that execution record, thereby determining the actual media resource corresponding to the current execution feedback. The processing order for confirming the feedback source is to first determine the specific execution record based on the transmission association information, and then determine the media resource based on that execution record, rather than first reading the current target media resource of the business traffic request and then inferring the feedback source. After resource redirection, even if the business traffic request currently points to the second media resource, as long as the sub-request identifier in the returned feedback is consistent with 20260001-01 in the original execution record, the feedback is still determined to be the feedback of the execution process corresponding to the first media resource.

[0041] For example, the second media resource first returns a successful execution feedback carrying sub-request identifier 20260001-02. The platform matches 20260001-02 with each sub-request identifier in the execution record, determining that this feedback corresponds to the second media resource and the execution record with sending sequence number 58. Subsequently, the first media resource returns feedback carrying sub-request identifier 20260001-01, and the platform determines that this feedback corresponds to the first media resource and the execution record with sending sequence number 126. The order in which the two feedbacks arrive at the platform does not change their respective resource sources; the fact that the current business traffic request is already directed to the second media resource does not change the actual execution attribution of the delayed feedback from the first media resource.

[0042] The content actually involved in subsequent processing in the execution feedback includes at least the sending association information corresponding to the feedback and the execution result content that reflects the current resource call execution result. The execution result can be represented as a successful return from the resource interface, a failed execution of the resource interface, an explicit rejection from the resource side, or other execution results that can be identified by the platform's existing processes. The business content of the execution result is not used for reverse selection of media resources, but is written into the corresponding execution record after the feedback source has been determined, and is used to form the current running status of the corresponding media resource when the sending order conditions described later are met.

[0043] If the media resource interface used by the platform does not directly send back the sub-request identifier in the response body, as long as the platform can determine from the context of this communication transaction which resource call the current response corresponds to, it can also use the information in the transaction context that corresponds one-to-one with the actual sending as the sending association information. For example, when initiating an asynchronous call, the platform saves the correspondence between the current call handle and the execution record, and when the asynchronous callback is triggered, the corresponding execution record is restored from the call handle. This implementation still follows the same technical relationship, that is, the sending association information must establish a definite correspondence with the specific execution record at the time of actual sending, and the actual execution source is determined based on the same correspondence when the execution feedback is returned, rather than inferring it afterward based on the current media resource request from the business traffic. The main implementation path will still be continuously described using the direct return of the sub-request identifier.

[0044] When the same service traffic request has been redirected multiple times, each actual transmission to a new media resource has a different sub-request identifier and an independent execution record is established. When execution feedback is returned, it is based on the specific execution record corresponding to its own sub-request identifier. Therefore, when the same service traffic request has three or more execution records, the feedback source confirmation rules do not change. Multiple redirections are merely a repeated application of the same actual transmission and feedback correspondence; they do not alter the subsequent processing mechanism for actual acceptance confirmation and the determination of the transmission order within the media resource.

[0045] After the execution feedback has been mapped to specific execution records and media resources, the platform still needs to distinguish between two technical facts: "a certain media resource returned an execution result" and "the execution result of that media resource was ultimately used by the platform to output the current business traffic request." In resource redirection scenarios, the original target media resource may return a success result late, even after the second media resource has completed its execution. Therefore, the success or failure of the execution feedback alone cannot determine which media resource ultimately completes the current business traffic request.

[0046] When forming the final output of the current business traffic request, the platform uses the actual resource execution result written into the final output as the confirmation basis. The platform's existing business output processing program selects one result from the resource execution results already returned by the current business traffic request to form the final response, and maintains the correspondence between the result and its sub-request identifier when selecting it; when the content of the result is written into the final output buffer or final response object of the current business traffic request, the platform looks up the execution record based on the sub-request identifier corresponding to the result, and determines the media resource that is fixedly associated in the execution record as the actual receiving media resource of the current business traffic request.

[0047] This implementation does not change the platform's original result selection rules. The platform may select the final output result based on existing bidding results, resource response conditions, existing priorities, or other existing business rules. These selection rules themselves do not participate in the resource feedback attribution mechanism described herein. What this document requires is that, regardless of the existing rules the platform uses to select the final result, the specific execution record should be confirmed by the objective event of the current business traffic request being written into the final output. The actual acceptance relationship cannot be inferred solely from the first or last return, or from which media resource the business traffic request currently points to.

[0048] For example, the execution result of the sub-request identifier 20260001-02 corresponding to the second media resource is returned first and written into the final response of request identifier 20260001 by the platform. Based on this, the platform determines that the second media resource is the actual receiving media resource of request identifier 20260001. Subsequently, the sub-request identifier 20260001-01 corresponding to the first media resource returns a success result. Since this result is not written into the final output of request identifier 20260001, although the first media resource has indeed completed its delayed response, the actual receiving result of this business traffic request still belongs only to the second media resource. The delayed success result of the first media resource is retained as the execution result of the execution record corresponding to the first media resource's sending sequence number 126, without changing the already formed actual receiving media resource.

[0049] When assigning resources based on the actual acceptance results of business traffic requests, the platform only creates an acceptance record for the media resource corresponding to the execution record that is actually written into the final output. Even if the same business traffic request generates multiple execution records due to one or more resource redirections, the current main implementation path still determines one actual accepted media resource based on the execution record that is ultimately selected by the platform and written into the final output of the business traffic request. The remaining execution records retain their respective execution results but do not change the already formed actual accepted media resource.

[0050] Once the actual service acceptance relationship is confirmed, the platform can save the identifier of the actual execution record or directly save the corresponding media resource identifier in the business traffic request context for subsequent statistics on the business traffic actually accepted by the current media resource. This saving action only records the actual output that has already occurred and does not re-evaluate the resource's quality. For other execution records in the same business traffic request that were not ultimately adopted, their execution feedback can still be used to record the execution result of the corresponding resource calling itself and the current running status judgment of the media resource (described later), but the current business traffic request will not be repeatedly counted in the actual acceptance results of multiple media resources.

[0051] After the actual source of the execution feedback has been identified, the platform further determines whether the feedback can still change the current operating status of the corresponding media resource. The current operating status in this document is resource-side operating information that the platform reads for subsequent business traffic allocation, reflecting the resource execution results that the platform has recently processed. The main implementation method at least saves the execution result content corresponding to the current operating status and the transmission sequence number within the media resource that formed the current operating status, enabling the platform to know which actual transmission of the same media resource the current resource status has reached.

[0052] When a media resource first establishes its current operational state, the platform writes the first complete execution feedback received and whose source has been confirmed into the current operational state, and simultaneously records the sending sequence number of the execution record corresponding to this feedback as the sending sequence number already processed in the current operational state. Subsequently, whenever the media resource returns another execution feedback, the platform reads the sending sequence number of the execution record corresponding to that feedback and compares it with the processed sending sequence numbers saved in the current operational state. If the sending sequence number of the newly arrived feedback is greater than the currently processed sending sequence number, it indicates that the actual sending of the feedback occurred later than the execution of the resource that established the current state. The platform updates the current operational state based on the execution result in the feedback and updates the currently processed sending sequence number to the sending sequence number corresponding to the feedback. If the two are equal, the feedback belongs to the same execution position that has already been processed; only the corresponding execution record is updated, and the currently processed sending sequence number is not advanced.

[0053] If the sequence number of a newly arrived feedback is less than the processed sequence number saved in the current running state, it indicates that although the feedback truly belongs to the media resource, its actual transmission occurred before the execution of subsequent resources that have already formed the current running state. The platform writes this feedback into its own execution record as the actual execution result of this resource call, but does not use the feedback to overwrite the current running state of the media resource, nor does it roll back the currently processed sequence number to a smaller value. Therefore, whether feedback can change the current running state of a media resource depends on the actual transmission order of the same media resource, not on the order in which the feedback arrives at the platform.

[0054] For example, while the execution feedback for request identifier 20260001 corresponding to sequence number 126 of the first media resource has not yet returned, the first media resource continues to receive other service traffic requests, with corresponding execution record sending sequence numbers of 127 and 128 respectively. Assuming the execution feedback corresponding to sending sequence number 128 returns first and has already been used to form the current operating state of the first media resource, the processed sending sequence number saved in the current state of the first media resource is 128. Subsequently, the late feedback corresponding to sending sequence number 126 returns. The platform confirms that it indeed comes from the first media resource based on the sub-request identifier, but 126 is less than 128. Therefore, this late feedback is only written to the execution record of sending sequence number 126 and does not overwrite the current operating state of the first media resource. Even if the late feedback of sending sequence number 126 is a success result, the newer current operating state already formed by sending sequence number 128 cannot be changed back to the state corresponding to sending sequence number 126.

[0055] In another continuous operation scenario, if the feedback with sequence number 126 from the first media resource is returned, but there is no feedback with a sequence number greater than 126 that has already formed the current operating state for the first media resource, then the processed sequence number saved in the current operating state may be 125 or smaller. The platform compares these and determines that 126 is greater than the processed sequence number, thus allowing the execution result corresponding to sequence number 126 to update the current operating state of the first media resource and advancing the processed sequence number to 126. Therefore, whether the same late feedback can change the current operating state of a media resource is determined by the subsequent execution progress of the resource itself, and is not automatically determined by whether the feedback is ultimately adopted in the business traffic request.

[0056] The actual acceptance of a service traffic request and the current operating state of a media resource are handled using different criteria. Which media resource the current service traffic request is actually accepted by depends on which execution record's return result is actually written into the final output of the service traffic request by the platform. Whether the execution feedback of a media resource can change its current operating state depends on whether the execution record to which the feedback belongs was sent earlier within that media resource than subsequent execution records that have already established the current operating state. Therefore, a late success feedback from the first media resource may be correctly identified as feedback from the first media resource, but if the current service traffic request has already been actually accepted by the second media resource, this late success feedback does not change the acceptance attribution of the current request. Similarly, if the current operating state of the first media resource has already been established by a later-sent execution record, this late success feedback also does not change the current operating state of the first media resource. These two judgments respectively address the issues of request acceptance attribution and media resource state timing.

[0057] For the cumulative actual traffic received, the platform increments the number of media resources received based on the confirmed current requests. The cumulative result is not overridden by the resource's sending order, as the actual receipt of different business traffic requests is a fact that can be accumulated. For the current running status of media resources, the overriding boundary is controlled according to the resource's sending order, as this status represents the most recently processed execution status of the media resource. By distinguishing between the cumulative received facts and the current running status, earlier execution feedback will not revert the current status due to a later arrival, and actual business traffic received will not be missed due to different feedback order.

[0058] When subsequent service traffic requests reach the media resource allocation stage, the platform's existing traffic allocation process reads the current operating status of the media resources, formed after the aforementioned source confirmation and sending order constraints, as the input for the current operating status of the media resources in the subsequent service traffic allocation. The platform still completes the determination of the media resources for the next service traffic request according to its existing resource selection logic. This implementation method does not require changes to the existing scoring, ratio, budget, or bidding processes. What is changed is that the resource status provided to the existing allocation process has eliminated the timing distortion caused by cross-resource incorrect attribution and early / late feedback overwriting subsequent statuses.

[0059] For example, in the aforementioned execution segment, request identifier 20260001 is ultimately received by the second media resource. The delayed feedback from the first media resource (sending sequence number 126) cannot overwrite the current execution state because the first media resource's current state has already been processed up to sending sequence number 128. Subsequently, when request identifier 20260002 enters the platform, the existing allocation process reads the current execution state of the first media resource (formed by the execution result corresponding to sending sequence number 128) and the current execution state of the second media resource. It will not mistakenly write the delayed result of the first media resource's sending sequence number 126 to the second media resource, nor will it revert the current state of the first media resource to the time corresponding to sending sequence number 126. Subsequent resource selection continues to be executed by the platform's existing logic.

[0060] The following example, using a series of continuous service traffic requests, illustrates the technical relationships involved in real media traffic processing. The times and sequence numbers in this segment are representative data for illustrating the processing relationships and do not imply that the platform must use the same values. The platform has a first media resource and a second media resource, each maintaining its own monotonically increasing transmission sequence number. At the start of the operation, the first media resource has processed a transmission sequence number of 340, and the current running state is determined by the execution result of transmission sequence number 340; the second media resource has processed a transmission sequence number of 211. The platform receives the first service traffic request, which has a unique service request identifier. The existing traffic allocation process selects the first media resource as the target media resource.

[0061] When the first service traffic request is actually sent to the first media resource, the first media resource's sequence number increments from 340 to 341. The platform generates a sub-request identifier for the current actual call and forms an execution record. The execution record stores the first service traffic request identifier, the first media resource identifier, the sub-request identifier, and the sequence number 341. The network call carries this sub-request identifier. After receiving the call, the first media resource begins processing, but a complete execution result is not formed within the platform's existing waiting range. Based on this, the platform's original traffic control process determines to redirect the first service traffic request to the second media resource.

[0062] When resource redirection occurs, the original execution record corresponding to sequence number 341 is not deleted or rewritten, and the actual call relationship between the first service traffic request and the first media resource is maintained. When the first service traffic request is actually sent to the second media resource, the second media resource's sending sequence number increments from 211 to 212, the platform generates a new sub-request identifier and establishes a new execution record. The new execution record stores the same first service traffic request identifier, second media resource identifier, new sub-request identifier, and sending sequence number 212. At this time, the same service traffic request has two real execution records, representing the first media resource call and the second media resource call that have already occurred, respectively.

[0063] The second media resource returns a successful execution feedback after 80ms, carrying the sub-request identifier used when the second media resource was actually sent. The platform searches the execution record according to the sub-request identifier, determines the execution record corresponding to the second media resource sending sequence number 212, and writes the successful execution result to that record. The platform's existing output processing procedure uses the result returned by the second media resource to form the final response to the first service traffic request. Therefore, when the final output is written, the platform again locates the execution record of the second media resource sending sequence number 212 based on the sub-request identifier of this result, and determines that the first service traffic request was actually received by the second media resource. The cumulative number of times the second media resource has been received increases accordingly by 1.

[0064] The execution feedback of the second media resource's sending sequence number 212 is also used to process the current operating status of the second media resource. Since the current status of the second media resource has previously processed sending sequence number 211, and sending sequence number 212 is greater than 211, the platform updates the current operating status of the second media resource based on the successful execution result of sending sequence number 212, and advances the processed sending sequence number to 212. Thus, both the actual acceptance of the first service traffic request by the second media resource and the current operating status of the second media resource itself are updated accordingly, but these two updates originate from the final output event and the comparison of the internal sending order of the media resource, respectively.

[0065] After the first service traffic request has completed its final output, the platform receives a second and a third service traffic request. The existing traffic allocation process sends both requests to the first media resource, with the first media resource's sending sequence numbers increasing sequentially from 341 to 342 and 343, respectively, each forming its own independent execution record. The feedback corresponding to sending sequence number 342 is returned first and processed by the platform, advancing the first media resource's processed sending sequence number from 340 to 342. The feedback corresponding to sending sequence number 343 is returned subsequently, further advancing the processed sending sequence number to 343. Regardless of whether the first media resource ultimately handles both requests, its current operating status remains consistent with the latest processed sending sequence number within the first media resource, maintaining the execution result corresponding to 343.

[0066] Subsequently, the execution feedback for the first service traffic request, initially sent to the first media resource, is returned. This delayed feedback carries a sub-request identifier corresponding to the execution record with sending sequence number 341. The platform determines that this feedback originates from the first media resource with sending sequence number 341 based on the sub-request identifier, and will not write this feedback to the second media resource simply because the first service traffic request is ultimately handled by the second media resource. The platform writes the actual execution result corresponding to the delayed feedback into the execution record of the first media resource with sending sequence number 341. Since the final output of the first service traffic request already uses the execution result corresponding to the second media resource with sending sequence number 212, even if the first media resource with sending sequence number 341 returns a success result, it does not change the fact that the first service traffic request was actually handled by the second media resource.

[0067] The platform further compares the transmission sequence number 341 with the currently processed transmission sequence number 343 of the first media resource. Since 341 is earlier than 343, it indicates that the current operating state of the first media resource has progressed to a later stage in the resource execution process that occurred after the first service traffic request. Therefore, the late feedback with transmission sequence number 341 does not cover the current operating state of the first media resource, and the currently processed transmission sequence number of the first media resource remains 343. Thus, the same late feedback yields three clear processing results: the actual source of the feedback is still the first media resource; the actual acceptance of the first service traffic request still belongs to the second media resource; and the current operating state of the first media resource remains the newer state corresponding to transmission sequence number 343.

[0068] The platform subsequently received a fourth service traffic request. When the existing media resource allocation process reads the current running state of the first media resource, it obtains the current running state corresponding to sequence number 343. When reading the current running state of the second media resource, it obtains the current state formed by at least sequence number 212 and subsequent processed executions. The delayed feedback of the first service traffic request corresponding to the first media resource's sequence number 341 neither polluted the state of the second media resource nor caused the state of the first media resource to regress. Therefore, the media resource state used by the fourth service traffic request remains consistent with the most recently processed actual execution process of each media resource. The media resource allocation process can continue to use the existing selection logic of the original platform.

[0069] If, upon receiving the aforementioned delayed feedback, the first media resource has not continued processing transmission sequence numbers 342 and 343 (meaning the first media resource's currently processed transmission sequence number is still 340), the platform compares 341 and 340 and allows the execution result corresponding to transmission sequence number 341 to update the current running status of the first media resource, advancing the currently processed transmission sequence number to 341. Even if the first service traffic request is ultimately handled by the second media resource, the fact that the first media resource did indeed produce the execution result corresponding to transmission sequence number 341 can still be used to characterize the execution status of the first media resource at that time, the most recent completed processing. The actual attribution and the current running status of the resource are not forced to maintain the same judgment conclusion simply because they belong to the same feedback.

[0070] In the main implementation, the sending association information uses a sub-request identifier generated by the platform for each actual media resource call. The sub-request identifier is formed after the business traffic request is determined to be sent to a certain media resource and before the actual request message is delivered to the media resource interface. The platform first reads the business request identifier in the business traffic request context, then generates a unique sub-request identifier for the current call, writes the business request identifier, sub-request identifier, and media resource identifier into the execution record, and then includes requests with the same sub-request identifier in the request sent to the media resource. Thus, the sending association information has already established a definite relationship with the specific execution record and the specific media resource before the feedback is returned, and does not depend on re-inferring after the feedback arrives.

[0071] The sub-request identifier can be formed by combining the business traffic request identifier with the current call sequence number of the request. For example, the business traffic request identifier can be appended with an incrementally increasing call sequence number within the scope of this request, or it can be directly generated by the platform's existing unique identifier generation function. The generation method of the sub-request identifier only needs to ensure that different actual media resource calls for the same business traffic request do not use the same sub-request identifier. The main implementation path takes the combination of the business traffic request identifier and the current request call sequence number as an example. For example, the first actual media resource transmission of business traffic request identifier 20260001 uses 20260001-01, and the second actual transmission after redirection uses 20260001-02. This encoding is only used to illustrate the one-to-one correspondence and does not constitute a fixed character format.

[0072] When a media resource returns a synchronous response, the platform obtains the sub-request identifier from the response and directly searches the execution record. When the media resource uses an asynchronous callback, the platform obtains the sub-request identifier from the callback parameters and performs the same search. If the communication framework itself can guarantee that an asynchronous response handle corresponds to only one media resource call, the platform can also establish a correspondence between the call handle and the execution record during actual sending and restore the execution record through the call handle when feedback is triggered. Regardless of the specific interface form used, the feedback correspondence rule remains the same: a stable correspondence between a call and the execution record is first formed during actual sending, and the source is determined based on this correspondence when feedback is returned, rather than using the current target resource field of the business traffic request as the source.

[0073] The sending order within a media resource only reflects the order in which requests actually enter the same media resource sending stage, and does not use the execution feedback return time as the sending order. This is because network transmission, media resource processing time, and asynchronous callback delays can all cause earlier-sent requests to return later than later-sent requests. If the feedback arrival time were used to represent the resource execution order, later feedback from earlier actual executions would be incorrectly identified as the latest state. The main implementation increments the sequence number of the media resource itself before actual sending; therefore, the sequence number is fixed before the feedback returns and is unaffected by response delays.

[0074] The platform retains the processed sending sequence number that led to the current running status of each media resource. For example, if the current running status of the first media resource is determined by the execution result corresponding to sending sequence number 350, then the processed sending sequence number is recorded as 350. If feedback corresponding to sending sequence number 351 is subsequently received, since 351 is greater than 350, the platform allows this feedback to update the current running status and advances the processed sending sequence number to 351. If a late feedback with sending sequence number 349 is returned, since 349 is earlier than 351, only the execution record of sending sequence number 349 is updated, without changing the current running status. This comparison only requires integer size judgment or other sequential value judgment; no additional scoring or prediction models are needed.

[0075] When the transmission sequence number equals the currently processed transmission sequence number, the platform writes this feedback as supplementary information for the processed execution position into the corresponding execution record. The currently processed transmission sequence number remains unchanged, and the current running state of the media resource is not advanced again due to repeated feedback from the same execution position. The specific fields of the current running state are determined by the platform's existing resource state definition used for subsequent media resource allocation. The main implementation method uses at least the most recent resource call success, failure, or explicit rejection result that allows updating the current state, along with the corresponding processed transmission sequence number, to represent the current running state. The transmission order comparison is used to control whether a late feedback that was actually executed earlier can cover the current running state.

[0076] The cumulative information on the actual traffic received by media resources does not use the aforementioned overlay-based time-series judgment. Each traffic request is only attributed to the corresponding media resource when the platform finally outputs a result returned by a specific execution record. Therefore, the acceptance facts of different traffic requests can be accumulated according to their occurrence frequency. The current operating status of a media resource represents the most recent state available for subsequent traffic allocation at a given moment. It is necessary to prevent late feedback from earlier executions from overwriting states already formed by later executions. The update conditions for these two types of information are different, which avoids mistaking cumulative facts for overlay states or overlay states for simple cumulative quantities.

[0077] When the platform deploys multiple service request processing processes simultaneously, it only needs to ensure that the sending sequence numbers used for comparison within the same media resource have a consistent order. In practice, sequence number allocation can be completed by the existing sending entry point corresponding to the media resource, or by utilizing the platform's existing counting mechanism that guarantees incrementality. This implementation requirement stems from the "comparable actual sending order within the same media resource" relationship already established in this implementation method. It does not require different media resources to share the same sequence number generator, nor does it require the establishment of a new global clock synchronization system.

[0078] Resource redirection only changes the media resource that the business traffic request will actually send subsequently; it does not modify the actual sending facts that have already occurred. If a business traffic request is redirected from the first media resource to the second media resource, and the execution result of the second media resource has not yet fully returned, and then redirected to the third media resource according to the platform's existing control logic, then the first, second, and third media resources each have independent execution records. Each execution record has its own sub-request identifier and the corresponding media resource's internal sending sequence number, and the three execution records are collectively associated with the same business traffic request.

[0079] Regardless of the chronological order in which the execution feedback from the first, second, and third media resources is returned, it is first determined based on the specific execution record corresponding to the associated information sent by each resource. When the platform ultimately uses the return result from the third media resource to form the final output of the business traffic request, the actual acceptance result of that business traffic request belongs to the third media resource. The subsequent returns from the first and second media resources are still written into their respective execution records, and each resource's internal sending order is used to determine whether the current running status of the corresponding media resource can be updated. During multiple redirections, the execution relationship of the new media resource does not overwrite the original media resource relationship that has been fixed in the previous execution record; each media resource call that has actually occurred is retained.

[0080] If the first media resource does not return any execution result after the business traffic request is redirected, the corresponding execution record of the first media resource can still indicate that the actual sending has occurred, but an execution result will not be generated out of thin air. The actual acceptance of the business traffic request is still determined by other execution records that actually enter the final output. The current running status of the first media resource will not be updated due to a non-existent execution feedback. If the first media resource subsequently generates late feedback, it will then proceed to the corresponding processing according to its sending association information and the sending order within the resource.

[0081] If the original media resource returns its execution result after the redirection action but before the actual sending of the redirected media resource, and the platform's existing business processing still decides to use the original media resource's result and write it into the final output of the business traffic request, then the actual receiving media resource is still determined by the final writing action as the original media resource. If the platform's existing control process has already actually sent a request to the second media resource before the original resource's result is returned, then the execution record corresponding to the second media resource is still retained to handle any further feedback from the second media resource. This article does not determine the final receiving object based on the moment the redirection instruction is generated, but rather on which actual resource's execution result is ultimately written into the business traffic request output.

[0082] When allocating subsequent business traffic, the platform reads the current operating status of each candidate media resource before processing new business traffic requests. This current operating status is updated by the execution feedback when the sequence number corresponding to a newly arrived execution feedback is greater than the currently processed sequence number; when they are equal, only the corresponding execution record is added, and the current operating status remains unchanged. Therefore, its formation is based on the most recent actual transmission process processed for the same media resource. The platform's existing resource selection logic can then continue to determine the target media resource based on the current operating status and existing business conditions. This paper does not change the formation method of the candidate media resource set, nor does it change the existing allocation rules; it only ensures that the current operating status of the media resources used is not incorrectly overwritten due to misattribution in cross-resource feedback or early execution followed by late feedback.

[0083] Assume the current running state of the first media resource has been established by the execution feedback of sequence number 410, and the current running state of the second media resource has been established by the execution feedback of sequence number 267. When a new service traffic request arrives, the platform reads these states as input to the existing traffic allocation logic. If a late feedback of sequence number 405 for the first media resource arrives at this time, the platform first determines that its source is still the first media resource, then compares 405 with 410, maintaining the current running state of the first media resource unchanged. The new service traffic request will not read a resource state formed by an older execution process simply because the late feedback of 405 arrives later.

[0084] If a new service traffic request is actually sent to the first media resource and obtains a sending sequence number of 411, after the execution feedback for sending sequence number 411 is returned, if 411 is greater than 410, the platform can advance the current running state of the first media resource to sending sequence number 411 based on this execution result. Subsequently, if feedback for sending sequence number 409 is returned, 409 is earlier than 411 and will not overwrite the current running state. Therefore, the current running state of the media resource monotonically progresses as the actual sending process of the resource advances, without time rollback due to out-of-order asynchronous feedback.

[0085] The actual assignment of business traffic requests is determined independently based on the final output of each request. For example, if 6 out of 10 consecutive business traffic requests use the execution result of the first media resource and 4 use the execution result of the second media resource, the actual number of requests assigned can be accumulated as 6 and 4 respectively. A delayed success feedback from a first media resource that was not used will not count the same business traffic request again as a first media resource. The actual number of requests assigned and the current running status of the media resource respectively reflect "which requests are actually processed by this resource to form the final output" and "the execution status of the most recently processed resource". Both can be used by the platform's existing operation and management, but the rules for their formation remain independent.

[0086] In a representative time series illustrating the overlapping relationships of asynchronous feedback, a business traffic request enters the platform at 10:00:00.000, and the existing traffic allocation process determines the first media resource. At 10:00:00.010, the platform actually sends a request to the first media resource, forming a sub-request identifier and a first media resource sending sequence number 501. The first media resource does not fully return its execution result within the platform's existing waiting range. At 10:00:00.210, the platform's existing traffic control process generates a resource redirection result. At 10:00:00.220, the business traffic request is actually sent to the second media resource, forming a new sub-request identifier and a second media resource sending sequence number 305.

[0087] At 10:00:00.300, the second media resource returned a successful execution feedback. The platform, based on the sub-request identifier, determined that this feedback belonged to the execution record of the second media resource's sending sequence number 305. At 10:00:00.320, the platform's business output processing used the content returned by the second media resource to write the final output of the current business traffic request; therefore, the current business traffic request was actually inherited by the second media resource. At 10:00:00.350, the platform sent another business traffic request to the first media resource, forming the first media resource's sending sequence number 502; the execution feedback for this request returned at 10:00:00.430, and the platform updated the current running status of the first media resource to sending sequence number 502.

[0088] At 10:00:00.500, the first media resource finally returned a successful response corresponding to the initial business traffic request, sequence number 501. This response arrived later than the response corresponding to sequence number 502 of the first media resource, but its sub-request identifier still corresponds to the execution record of sequence number 501. Therefore, the source of the response was determined to be the first media resource, not the second media resource. The initial business traffic request has already been finalized by the execution result of the second media resource, and the successful response of sequence number 501 will not change the actual receiving resource of the request. The current operating state of the first media resource has already been determined by sequence number 502; 501 is earlier than 502, therefore the delayed successful response of sequence number 501 will not overwrite the current operating state of the first media resource.

[0089] If the feedback return time corresponding to the first media resource sending sequence number 502 is changed to 10:00:00.700, then when feedback from sending sequence number 501 is received at 10:00:00.500, the current running status of the first media resource has not yet been formed by the later sending sequence number. The platform can use the execution result corresponding to sending sequence number 501 to form the current running status of the first media resource at that time, and advance the processed sending sequence number to 501; after the feedback from sending sequence number 502 arrives at 10:00:00.700, the current running status is then advanced to 502. The sending sequence number itself is always determined by the actual sending time. The timing of the feedback arrival only affects when data can be processed, and does not change the sequential relationship between the execution of the two actual resources.

[0090] The aforementioned time values ​​are only used to demonstrate how execution records and resource states are continuously inherited when the original resource has not fully returned, resource redirection, subsequent resource returns first, the original resource arrives late, or subsequent execution occurs during the original resource's execution. The actual platform response latency can vary depending on the media resource interface, network environment, and existing operational configuration. This implementation method only requires the ability to determine the actual execution records sent to the media resource for each business traffic request, the correspondence between feedback and execution records, the final execution result adopted by the platform, and the actual order of transmission of the same media resource.

[0091] The service traffic request identifier remains consistent throughout the lifecycle of a service traffic request, used to group multiple execution records before and after resource redirection into the same request. The sub-request identifier is generated with each actual resource transmission, used to distinguish different resource executions within the same service traffic request. The media resource identifier is fixed when the execution record is established, used to indicate the media resource to which the feedback actually applies after the feedback source has been determined. The in-resource transmission sequence number is also fixed during actual transmission, used to determine the chronological position of the resource execution resulting from the corresponding feedback within the media resource's own execution history. These four data types have different purposes from their inception, and the same field is not used to represent multiple judgments.

[0092] The final output of business traffic requests is generated by the platform's existing business output program. When the platform actually writes the return result of a media resource into the final output, this return result can already correspond to an execution record through the sub-request identifier. Therefore, the actual accepted media resource can be directly obtained from the media resource identifier in the execution record. There is no need to calculate the media resource score separately, nor is there a need to compare the feedback arrival times of different resources. The actual output event separates "which execution result is ultimately adopted" from the general response success status, ensuring that a delayed success of the original resource will not cause the same business traffic request to be counted as actually accepted by two media resources simultaneously.

[0093] There is no mandatory consistency between the current operational state of a media resource and the final output of a service traffic request in terms of update timing. Even if a feedback message is not adopted by the current service traffic request, it may still be a valid execution result for that media resource. If the sequence number corresponding to this execution feedback is later than the currently processed sequence number of the media resource, the execution result can still be used to update the current operational state of the media resource. Conversely, even if this execution feedback was adopted as the final output by a service traffic request, if it only entered the current state processing much later, and the media resource has already formed its current operational state with a later sequence number, then the earlier execution result should not be used to revert the current state. Therefore, the actual attribution and the current state of the resource are handled according to their respective true technical facts.

[0094] The platform executes writes to the current running status at the same media resource level. For execution feedback of the first media resource, only the sending sequence number of the first media resource is compared with the currently processed sending sequence number of the first media resource; for execution feedback of the second media resource, only the sending sequence number of the second media resource itself is compared. Even if the sending sequence numbers of different media resources are the same, there is no overwriting relationship between them. This limitation avoids irrelevant constraints caused by unified sorting across resources, while also meeting the practical requirement that delayed feedback judgment only needs to identify the execution relationship within the same media resource.

[0095] Sending associated information is not limited to using specific protocol fields. The primary implementation method uses the sub-request identifier of each actual resource call, which is the most direct implementation path. If the platform communication framework can uniquely recover the corresponding execution record through this connection transaction, asynchronous call handle, or callback context, the recovered information can also complete the processing of "establishing a correspondence when actually sending and restoring the same correspondence when the feedback is returned." Regardless of how the specific carrier changes, the determination of the correspondence between each actual media resource call and subsequent execution feedback cannot be omitted.

[0096] The actual transmission order within the same media resource is not limited to decimal integers. The main implementation uses monotonically increasing transmission sequence numbers for easy direct comparison. If the platform's existing transmission link already provides queue numbers or sequence values ​​that guarantee the actual transmission order within the same media resource, these sequence values ​​can also be directly saved. Any alternative implementation should satisfy the following: the sequence value is determined when actual transmission occurs; two execution records of the same media resource can be compared in order; and the feedback arrival order cannot reverse the already determined transmission order.

[0097] The storage medium for execution records is not a core limitation. For platforms with low transaction volumes or where execution feedback is typically returned within a short period, execution records can be maintained within the context of the current business request. For platforms that require receiving asynchronous callbacks across processes, existing persistent storage can also be used to store execution records. Regardless of the storage method used, execution records must remain readable at least for the timeframe during which corresponding execution feedback is likely to be received, so that the execution feedback can locate the corresponding record based on the associated information. The specific retention period is determined by the platform's existing interface responses and data retention requirements, and does not alter the technical relationships described in this document.

[0098] The specific service field used for the current operating state is determined by the existing definition of the media resource allocation system. This implementation requires the ability to identify the processed transmission sequence number corresponding to the state and, upon the arrival of new execution feedback, to decide whether to allow the current state to be overwritten based on the transmission order of the same media resource. For data that is only accumulated and does not have the meaning of a "current value," such as the amount of service traffic that has actually been received, the earlier feedback is not used to overwrite the newer feedback; instead, the actual received events are accumulated based on the confirmed events. This ensures that the current state does not experience time rollback while also preserving the actual received data.

[0099] The specific reasons for resource redirection and the method of media resource selection after redirection are not part of the core processing conditions in this paper. The platform can generate a redirection result when the original resource response times out, the resource side returns a failure, or existing running logic determines that the resource can no longer handle the load. As long as the business traffic request is actually sent to another media resource before the execution result of the original media resource has been fully returned, the original execution record is retained and a new execution record is formed in accordance with the method described in this paper. This boundary allows the specific implementation to be independent of a particular anomaly detection algorithm.

[0100] According to the above process, a traceable execution record is formed when the business traffic request is first actually sent to the target media resource. Resource redirection will not overwrite the original resource execution facts that have already occurred. The subsequent execution feedback returned by the original target media resource and the redirected media resource are restored to their respective execution records through the correlation information formed when the request was actually sent. Which media resource ultimately receives the current business traffic request is based on the execution record actually written to the final output by the platform. Whether a delayed execution feedback belonging to a certain media resource can change the current running state of that media resource is based on the relationship between the actual sending order of the execution record within the same media resource and the currently processed sending order. The above two judgments handle the acceptance of the business traffic request and the current state of the media resource respectively, without using an abstract state to replace both simultaneously.

[0101] As the platform continuously processes subsequent business traffic requests, the current operating status of each media resource progresses according to the actual sending order of the same resource. Even if a delayed feedback from the original resource arrives after the redirected resource has completed its output, it retains its original resource source. A delayed successful return of an original resource does not cause a request for the same business traffic that has already been output by the redirected resource to be repeatedly attributed to the original resource. Furthermore, if the execution corresponding to a delayed feedback from an original resource is earlier than the subsequent execution already processed by that resource, it does not cause the current operating status of that resource to revert. The subsequent media resource allocation process reads the current operating status formed by the execution of the most recently processed resource and continues working, thus ensuring that the feedback source, the actual receiving media resources, and the current operating status of the media resources in continuous business traffic processing remain consistent with the actual execution process.

[0102] It should be noted that the methods, systems, devices, or equipment described in the above embodiments can be implemented in software, hardware, or a combination of both, depending on the actual application scenario. When implemented in software, the corresponding program instructions can be stored in a computer-readable storage medium and executed by a processor to achieve the processing steps or functions described in the above embodiments. For the specific processing procedures of each functional module in the system, device, or equipment, refer to the corresponding processing procedures in the foregoing method embodiments.

[0103] The above description is merely a specific embodiment of the present invention, used to illustrate the technical solution of the present invention, and is not intended to limit the scope of protection of the present invention. Without departing from the technical concept of the present invention, any equivalent substitutions, reasonable modifications, or combinations made by those skilled in the art based on the disclosure of this specification should be determined according to the claims to determine whether they fall within the scope of protection of the present invention.

Claims

1. A method for optimizing media resource traffic allocation, characterized in that, include: S1. When a business traffic request is actually sent to the target media resource, an execution record is created for this send, which associates the business traffic request, the target media resource, the sending association information of the corresponding subsequent execution feedback, and the sending order within the target media resource. S2. When the execution result of the target media resource has not been fully returned and the business traffic request is redirected, the original execution record is retained, and a new execution record is created when the data is actually sent to the redirected media resource. S3. After the execution feedback is returned, the corresponding execution record and media resources are determined based on the sent association information; S4. From the execution record of the business traffic request, determine the return result selected by the platform and write it into the execution record of the final output of the business traffic request, and assign the result to the media resource corresponding to the execution record. S5. For the current running status of the media resource corresponding to the execution feedback, compare the sending order of the execution record corresponding to the feedback with the execution record already used to form the current running status within the media resource. If the former is earlier, do not update the current running status with the feedback, and use the processed current running status for subsequent business traffic allocation.

2. The media resource traffic allocation optimization method according to claim 1, characterized in that, The result of accepting business traffic requests belongs only to the media resources corresponding to the execution record that the returned result is written into the final output by the platform; For execution records that are not ultimately used in the same business traffic request, their execution feedback does not change the acceptance result. When the sending order of the execution record in the corresponding media resource is later than that of the execution record that has been used to form the current running state, the current running state is updated with the execution feedback.

3. The media resource traffic allocation optimization method according to claim 1, characterized in that, The associated information is a sub-request identifier generated for each actual media resource call; Different actual resource calls for the same business traffic request use different sub-request identifiers. The sub-request identifier is associated with the corresponding execution record and media resource when it is actually sent and is carried by the execution feedback. When the execution feedback does not directly carry the sub-request identifier, the sub-request identifier is recovered from the context of this communication transaction.

4. The media resource traffic allocation optimization method according to claim 1, characterized in that, The sending order is represented by the sending sequence number within the same media resource; When the sequence number of a new execution feedback is greater than the sequence number of an execution record already used to form the current running status, the current running status is updated with this execution feedback; If the two are equal, the execution feedback is written to the corresponding execution record and the current running state remains unchanged; When the former is smaller, the execution feedback is written to the corresponding execution record and the current running status is not updated.

5. The media resource traffic allocation optimization method according to claim 3, characterized in that, After the execution feedback is returned, first look up the corresponding execution record based on the sub-request identifier, and then read the media resources that are permanently associated in the execution record; When the platform writes a certain return result into the final output of the business traffic request, it searches for the execution record again based on the sub-request identifier corresponding to the return result, and determines the actual media resource to be received based on the media resource corresponding to the execution record.

6. The media resource traffic allocation optimization method according to claim 3, characterized in that, The execution record should at least include the business traffic request identifier, media resource identifier, sub-request identifier, and the sending order within the media resource; When resource redirection occurs, the media resource identifier, sub-request identifier, and sending order in the original execution record remain unchanged. A new execution record is created when the redirected media resource is actually sent.

7. The media resource traffic allocation optimization method according to claim 4, characterized in that, Each time a media resource call enters the corresponding media resource's sending entry point and is submitted, the sending sequence number of that media resource is atomically incremented. The incremented sending sequence number indicates the actual sending order of each execution record for the same media resource, and the sending order is not determined by the execution feedback return order.

8. The media resource traffic allocation optimization method according to claim 1, characterized in that, When the same business traffic request is redirected to multiple resources, an independent execution record is established for each actual transmission to a new media resource. Each execution record is associated with the corresponding transmission association information and the transmission order within its respective media resource, and is jointly associated with the same business traffic request. The execution feedback returned by each media resource is used to determine the execution record based on the corresponding sent associated information.

9. The media resource traffic allocation optimization method according to claim 4, characterized in that, The current running status includes the resource call result reflected in the most recent execution feedback used to update the current running status, as well as the sending sequence number of the execution record corresponding to that execution feedback; The result of resource access can be one of the following: success, failure, or explicit rejection by the resource provider.

Images