Order data management method, device, equipment, medium and product

Abstract

The application relates to the technical field of financial data processing, in particular to an order data management method, device, equipment, medium and product. The method comprises the following steps: sending an order data request to a server, and determining a corresponding order query scene according to a request type; receiving an order data set corresponding to the order data request, and configuring a scene source identifier for each order data in the order data set according to the order query scene; determining a scene processing strategy configured according to the order query scene; and updating a global order cache warehouse based on the scene processing strategy, each order data in the order data set and the scene source identifier of the order data, so that invalid network requests can be reduced, abnormal data misjudgment can be avoided, and the accuracy and processing efficiency of financial order data can be improved.

Description

Technical Field

[0001] This application generally relates to the field of financial data processing technology, and specifically to an order data management method, apparatus, equipment, medium, and product. Background Technology

[0002] In trading platform products, order data is the core business carrier of user behavior throughout the entire lifecycle of orders, including placing, modifying, canceling, and completing transactions. It is the key data supporting users' interactive needs such as viewing order progress, executing order operations, and tracing transaction records. The accuracy, consistency, and real-time nature of order data directly determine the reliability of the transaction process and the user experience, and it is a core data that must be reliably guaranteed within the trading platform.

[0003] However, due to communication anomalies between the server and the terminal (such as data loss), the terminal may generate dirty or erroneous data. In order to correct the abnormal data, the existing technology usually requires the terminal to make a full data request to the server again, which increases the server load and makes it difficult to guarantee the accuracy of local order data. Summary of the Invention

[0004] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide an order data management method, apparatus, equipment, medium and product to reduce invalid network requests, avoid misjudgment of abnormal data, and improve the accuracy and processing efficiency of financial order data.

[0005] In a first aspect, embodiments of this application provide an order data management method, including: Send an order data request to the server and determine the corresponding order query scenario based on the request type; Receive the order dataset corresponding to the order data request, and configure a scenario source identifier for each order data in the order dataset according to the order query scenario; Determine the scenario processing strategy configured for the order query scenario; Based on the scenario processing strategy, the scenario source identifier of each order in the order dataset, and the scenario source identifier of the order data, the global order cache repository is updated.

[0006] In one embodiment, configuring a scenario source identifier for each order data item in the order dataset includes: Construct an order source information structure for each piece of order data, which serves as the source identifier for the scenario. The order source information structure includes: the data version field returned by the server, the scenario source field, and the latest protocol request time field.

[0007] In one embodiment, updating the global order cache repository based on the scenario processing strategy, each order data in the order dataset, and the scenario source identifier of the order data includes: In response to the scenario processing strategy, which includes a data update strategy, intersecting order data between the order data in the order dataset and the local order data in the global order cache repository is obtained. Based on the data version field in the scenario source identifier, the intersecting order data are compared for versions, and data updates are performed based on the version comparison results.

[0008] In one embodiment, updating the global order cache repository based on the scenario processing strategy, each order data in the order dataset, and the scenario source identifier of the order data includes: In response to the scenario processing strategy including the data addition strategy, the first disjoint order data that exists in the order dataset but does not exist in the global order cache repository is obtained; Insert the first disjoint order data into the global order cache repository.

[0009] In one embodiment, updating the global order cache repository based on the scenario processing strategy, each order data in the order dataset, and the scenario source identifier of the order data includes: In response to the scenario processing strategy including the data deletion strategy, the second disjoint order data that exists in the global order cache warehouse but does not exist in the order dataset is obtained; From the second disjoint order data, determine the first abnormal data whose scenario source field in the scenario source identifier is consistent with the order query scenario of the order data request, perform a query verification operation on the first abnormal data, and update the first abnormal data in the global order cache warehouse based on the operation result of the query verification operation; From the second disjoint order data, determine the second abnormal data in which the scene source field in the scene source identifier does not include a field consistent with the order query scene of the order data request; If the latest protocol request time field of the second abnormal data is less than the request time of the order data request, the second abnormal data is deleted from the global order cache repository.

[0010] In one embodiment, the intersecting order data includes first order data in the order dataset and second order data in the local order data; the step of comparing the versions of the intersecting order data according to the data version field in the scenario source identifier, and performing data updates based on the version comparison results, includes: Determine whether the version field of the first order data in the order dataset is greater than the version field of the second order data in the local order data; If the version field of the first order data is greater than the version field of the second order data, the second order data in the local order data is overwritten and updated according to the first order data, and the scenario source field and the latest protocol request time field are synchronously written. If the version field in the order dataset is not greater than the version field in the second order data, the second order data in the local order data remains unchanged.

[0011] In one embodiment, after updating the first abnormal data in the global order cache repository based on the operation result of the query verification operation, the method further includes: If the result of the query verification operation is that the order data is valid and exists, delete the scene source field corresponding to the order query scene in the scene source identifier corresponding to the first abnormal data. If the query and verification operation results in invalid or non-existent order data, the corresponding first abnormal data is deleted from the global order cache repository.

[0012] In one embodiment, after receiving the order dataset corresponding to the order data request, the method further includes: A preset state machine is associated with each order data in the order dataset; the state machine's state identifiers include: initial state, valid state, local retention state, and pending deletion state; When the order dataset is received, it is uniformly marked as the initial state; Based on the scenario processing strategy and the scenario source identifier of each order data in the order dataset, the global order cache repository is updated. The status identifier is switched according to the data judgment result, and data update, cache retention or data deletion operations are performed according to the status identifier matching and handling rules.

[0013] Secondly, embodiments of this application provide an order data management device, including: The order scenario determination module is used to send order data requests to the server and determine the corresponding order query scenario based on the request type. The dataset labeling module is used to receive the order dataset corresponding to the order data request and configure a scenario source identifier for each piece of order data in the order dataset according to the order query scenario. The strategy determination module is used to determine the scenario processing strategy configured for the order query scenario. The data update module is used to update the global order cache repository based on the scenario processing strategy, the individual order data in the order dataset, and the scenario source identifier of the order data.

[0014] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in embodiments of this application.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in embodiments of this application.

[0016] Fifthly, embodiments of this application provide a computer program product, including a computer program, characterized in that, when the computer program is executed by a processor, it implements the method described in embodiments of this application.

[0017] The order data management method provided in this application first divides order query scenarios according to request type. After receiving the order dataset from the server, it configures a scenario source identifier for each order data. The source identifier accurately distinguishes the business scenario to which each order belongs, clearly defining the boundaries of order data for different lists and different businesses. This fundamentally solves the problem of indistinguishable and easily misjudged abnormal data, improving the accuracy of order data identification. Second, it configures independent scenario processing strategies for each query scenario. Orders in different scenarios are processed differently according to customized rules, unifying the business logic of orders across multiple terminals and reducing redundant development costs. Finally, the scenario processing strategy and the order scenario source identifier jointly drive the update of the global order cache repository. Based on the source identifier, it distinguishes two types of abnormal orders and adopts a hierarchical verification mechanism: only abnormal orders with scenario associations are sent to the server for verification, while other abnormal orders are directly judged and cleaned through local time thresholds. This abandons the existing approach of fully re-fetching all abnormal data from the server, significantly reducing invalid network requests and lowering server load. At the same time, it relies on a unified global cache and scenario source markers to control the flow of order data, avoiding dirty and erroneous data caused by communication anomalies, and effectively ensuring the accuracy and consistency of financial order data throughout its entire lifecycle.

[0018] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0019] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1The following diagram illustrates the implementation environment architecture of the order data management method provided in this application embodiment; Figure 2 This illustration shows a schematic diagram of order scenario distribution and strategy binding on the order data server side according to an embodiment of this application; Figure 3 A flowchart illustrating an embodiment of the order data management method provided in this application is shown. Figure 4 This illustration shows a schematic diagram of an order data scenario provided in an embodiment of this application; Figure 5 A schematic diagram of order processing logic provided in an embodiment of this application is shown; Figure 6 A schematic diagram of order processing logic provided in another embodiment of this application is shown; Figure 7 A schematic diagram of order processing logic provided in another embodiment of this application is shown; Figure 8 A schematic diagram of order processing logic provided in another embodiment of this application is shown; Figure 9 A schematic diagram of order processing logic provided in another embodiment of this application is shown; Figure 10 A schematic diagram of order processing logic provided in another embodiment of this application is shown; Figure 11 This illustration shows a schematic diagram of the comparison and processing logic between the server and the local cache of order data provided in an embodiment of this application; Figure 12 This illustration shows a schematic diagram of the entire process control logic from the server to the local cache processing of order data, according to an embodiment of this application. Figure 13 A schematic diagram of order processing logic provided in an embodiment of this application is shown; Figure 14 A schematic diagram of order processing logic provided in another embodiment of this application is shown; Figure 15 A schematic diagram of order processing logic provided in another embodiment of this application is shown; Figure 16 This illustration shows a simplified path diagram of the status transition in today's order scenario provided by an embodiment of this application; Figure 17 This illustration shows a closed-loop path diagram of state transition with detailed verification provided in an embodiment of this application; Figure 18 This illustration shows a complete lifecycle state diagram of order data provided in an embodiment of this application; Figure 19This illustration shows a control logic diagram for order data lifecycle management provided in an embodiment of this application; Figure 20 This illustration shows a schematic diagram of order deletion processing according to an embodiment of this application; Figure 21 A schematic diagram of the structure of an order data management device provided in an embodiment of this application is shown; Figure 22 A schematic diagram of the structure of a computer system suitable for implementing an electronic device or server according to embodiments of this application is shown. Detailed Implementation

[0020] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0022] In trading platform products, order data is the core business carrier of user behavior throughout the entire lifecycle of orders, including placing, modifying, canceling, and completing transactions. It is the key data supporting users' interactive needs such as viewing order progress, executing order operations, and tracing transaction records. The accuracy, consistency, and real-time nature of order data directly determine the reliability of the trading process and the user experience, and are therefore core data that trading platforms must reliably protect.

[0023] As business scenarios become increasingly diverse, the types of transaction products increase, and the interaction methods provided by clients also become more varied. For example, clients may need to provide multi-dimensional views of orders, such as today's orders, orders from the last three days, recently updated orders, and order details. This often requires repeatedly implementing business logic such as order data requests, caching, and updates. Furthermore, accurately identifying abnormal data when packet loss or timeouts occur during communication with the server becomes a prominent issue in order data management.

[0024] Currently, order data management is typically implemented independently by each terminal and each business page. Each terminal connects to different backend interfaces and data sources according to its own interface requirements, and independently implements order retrieval, cache updates, list filtering, and exception handling. When anomalies occur, such as inconsistencies between local cache and server-side data, overlapping data sources, packet loss, or timeouts, the existing solution mainly involves re-requesting the server for confirmation of all inconsistent data. While the logic is simple, it significantly increases the number of requests and client-side latency.

[0025] For the specific implementation environment of the order data management method proposed in this application, please refer to [link / reference needed]. Figure 1 . Figure 1 The implementation environment architecture diagram of the order data management method provided in the embodiments of this application is shown.

[0026] like Figure 1 As shown, the implementation environment architecture includes: user terminal 101, transaction business server 102, and order data server 103.

[0027] User terminal 101 runs a client application, which integrates an order data management device. All steps of the order data management method in this application are executed by the order data management device within the client. The client hosts the transaction operation page, providing a transaction interaction interface to the user, receiving user-initiated order placement, order query, update, and change monitoring commands, and simultaneously displaying a multi-dimensional order view, order progress, and transaction results to the user. User terminal 101 can be a desktop computer, laptop computer, smartphone, tablet computer, personal digital assistant, or other terminal device; the device type is not specifically limited. User terminal 101 is equipped with an independent local storage module for deploying a dedicated global order cache repository for the client.

[0028] The transaction service server 102 is connected to the user terminal 101 and the order data server 103 respectively, and is responsible for various order query requests issued by the relay terminal, transparent transmission of order datasets and strategy configurations.

[0029] The order data server 103 is responsible for the unified storage and maintenance of raw order data for all categories, basic information of financial products, transaction business parameters and various business configuration rules. It provides data source retrieval services according to business scenarios and outputs the corresponding order dataset and scenario processing strategy configuration according to the terminal query request, providing basic data support for the client to carry out order data acquisition, verification and processing locally.

[0030] like Figure 2 The diagram illustrates the order scenario distribution and strategy binding on the order data server side. The order list protocol serves as a unified request entry point, receiving various order query requests forwarded by the terminal via the transaction business server 102. It then distributes these requests according to business query needs, categorizing them into independent query scenarios such as today's order list, the order list of the last three days, the recently updated order list, and the historical order list. Each order list scenario is bound to a dedicated scenario processing strategy through a mapping relationship, corresponding to today's order strategy, recent order strategy, completed order strategy, incomplete order strategy, and historical order strategy, respectively, ensuring a one-to-one match between the query scenario and the dedicated processing strategy. All scenario processing strategies are uniformly maintained and distributed by a unified global strategy configuration management service. After completing the scenario and strategy matching, the order data server sends the order dataset matching the current query scenario and corresponding strategy parameters to the user terminal 101, providing a foundation for the terminal to perform local order data processing.

[0031] After the order data server completes the scenario distribution and data and policy distribution, the order data management device integrated within the user terminal 101 client takes over the subsequent local data processing flow. The processing logic for the complete chain is as follows: The first level is the order data management and aggregation layer, which is deployed on the order data management device of user terminal 101. It receives multi-scenario order datasets from the order data server, uniformly aggregates and processes various scenario data, shields the differences between multiple scenarios and terminals of the upper-layer business, and synchronously marks each order data with the corresponding scenario source identifier to complete the local preprocessing of order data. The second level is the policy control layer, with the core execution entity being the order data management device within the terminal. The order data server is only responsible for issuing standardized policy configurations. The order data management device executes local order data processing based on synchronously acquired policy rules. Core rules include, but are not limited to: whether to allow data access, whether to insert new data when updating data, whether to verify abnormal orders, and data source credibility determination. It also combines order source identifiers, local global cache, and differences between the data issued by the server to complete comprehensive decisions. Through standardized policy logic, it completes unified verification, addition, updating, and cleanup of order data in different scenarios on the client side, achieving standardized and consistent management of order data across multiple scenarios.

[0032] The transaction server 102 can be a standalone physical server, a server cluster composed of multiple physical servers, a distributed service system, or it can be deployed using a cloud server with capabilities such as cloud computing, cloud storage, big data processing, and network interaction.

[0033] User terminal 101 establishes a direct / indirect data interaction link with transaction business server 102 and order data server 103 using wired or wireless communication methods. The communication network follows common standard communication protocols and can use any combination of network forms such as the Internet, local area network, metropolitan area network, wide area network, mobile communication network, and virtual private network to complete data transmission.

[0034] This method relies on the client's internal order data management device in conjunction with a local global cache repository to achieve comprehensive control over all types of order data. It accurately distinguishes two types of abnormal orders based on the order source identifier and adopts a hierarchical verification mechanism. Only abnormal orders with scenario-related characteristics are sent to the server for verification requests. Other abnormal orders are directly judged and cleaned up based on local time thresholds, which significantly reduces the frequency of invalid requests from the terminal to the server. At the same time, it relies on the source identifier to eliminate the problem of data misjudgment in different abnormal scenarios, avoids dirty data and erroneous data caused by communication anomalies, and ensures the accuracy and consistency of local storage of financial order data throughout the entire lifecycle of entrustment, transaction, and cancellation.

[0035] In addition, to achieve unified management and control of business scenarios, processing strategies, and data permissions, this implementation environment is also equipped with a business configuration service. This service can be deployed on the transaction business server 102 or an independent configuration management server, providing visual business management functions, covering functional modules such as transaction scenario configuration, order processing strategy editing, data source control, abnormal rule maintenance, and business change approval. It supports rule addition, modification, batch maintenance, legality verification, and process approval. After configuration, the updated strategy will be uniformly and synchronously distributed to each terminal client for internal order data management devices to call, providing unified configuration guarantee for the standardized management of client order data throughout the entire process.

[0036] To further illustrate the technical solutions provided in the embodiments of this application, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation instruction steps as shown in the following embodiments or drawings, the method may include more or fewer operation instruction steps based on conventional methods or without inventive effort. In steps where there is no logically necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application. In actual processing or when the device executes the method, it may be executed sequentially or in parallel according to the method shown in the embodiments or drawings.

[0037] It should be noted that the acquisition or use of data in the embodiments of this application requires the user's consent. The relevant data can only be obtained after the user's authorization and permission, and the acquisition or use of the data complies with the laws and regulations of the relevant regions.

[0038] Please refer to Figure 3 , Figure 3 A flowchart illustrating an embodiment of the order data management method provided in this application is shown. Figure 3 As shown, the method includes: Step 201: Send an order data request to the server and determine the corresponding order query scenario based on the request type.

[0039] Order data requests can be generated based on data query behavior triggered by users or upper-level business processes, and are used to obtain the required order information.

[0040] Specifically, after a user or upper-layer business triggers a data query, the client can generate an order data request and send it to the server. Based on the request type carried in the order data request, it is categorized into a preset order query scenario. The request type indicates the order query scenario corresponding to the order data request.

[0041] In this embodiment, the specific types of request types configured are not limited, and can be set according to the actual application scenario.

[0042] In a specific application scenario, taking a financial transaction client as an example, request types can include today's order query, the last three days' order query, recently updated order query, and order details query, but are not limited to these. Specifically, the client can provide a today's order page, a last three days' order page, and a historical order page. When a user enters the today's order page in the client, a request of the today's order query type can be triggered to obtain all order data with an order creation time of today. If the user switches from the today's order page to the last three days' order page in the client, a request of the last three days' order query type can be triggered to obtain all order data with an order creation time of the last three days. If the user clicks on a specific order on the today's order page or the last three days' order page, a request of the order details query type can be triggered.

[0043] Order query scenarios are standardized business classifications of client-side order data query needs. They are used to identify the business scenario corresponding to the order data request, or in other words, the data acquisition entry point for the request. Continuing with the example of the aforementioned financial transaction client, order query scenarios may include today's order query scenario, the order query scenario of the past three days, the recently updated order query scenario, the order details query scenario, etc., but are not limited to these.

[0044] Figure 4 The diagram defines different order query scenarios such as "orders in the last 3 days", "orders today", and "recently updated orders". It should be noted that the client's global order cache repository can maintain a scenario queue for each order query scenario. This scenario queue includes a set of order IDs of visible orders in that business scenario, but does not independently store the complete order data. When a user triggers an operation on the client to query order information, an order data request can be triggered. At this time, the corresponding order query scenario can be determined by the request type of the order data request, so as to obtain the order ID from the scenario queue corresponding to the order query scenario, and then obtain the complete order data from the global order cache repository based on the order ID, and return it to the client.

[0045] After generating and sending the order data request in this step, the request type field of the order data request is matched one by one with the preset scenario rules. This consolidates the scattered and diverse query requirements into a standardized, reusable, and uniformly manageable order query scenario, eliminating the logic fragmentation problem caused by differences in terminals, business, and interfaces. This accurately determines the order query scenario corresponding to the current request, avoiding business differences caused by custom query logic on each terminal. Through unified entry point control of order requests from multiple terminals, multiple businesses, and multiple views, it achieves unified business logic across multiple terminals, reduces redundant development costs, and reduces cross-data source confusion.

[0046] Step 202: Receive the order dataset corresponding to the order data request, and configure the scenario source identifier for each order data in the order dataset according to the order query scenario.

[0047] Different order query scenarios will request corresponding order data. The same order data may appear in multiple datasets from different query scenarios. Order data from all scenarios will eventually be aggregated into a unified data warehouse. In traditional methods, the system cannot distinguish the original query scenario of a single order data, and it is difficult to identify the data acquisition context. This can easily lead to problems such as blurred data boundaries and confused sources, which in turn affect the accuracy of subsequent data verification, anomaly detection, and logical processing.

[0048] To address this issue, this step obtains the complete order dataset in response to the current order query request. This dataset contains all pending order data for the current query scenario. After receiving the data, the system matches the order query scenario corresponding to this request, such as preset scenarios like today's orders, orders from the last three days, or order details, using this as the configuration basis. Then, it iterates through the entire order dataset, attaching a unique identifier to each individual order data entry to identify its source scenario (order query scenario). This ensures that each data entry carries clear scenario attribution information, allowing for clear identification of the order query scenario it originated from during subsequent processing, storage, and use—for example, from today's orders, orders from the last three days, recently updated orders, or order details.

[0049] By binding a scenario source identifier to each order data entry, the source of the data becomes clear and traceable, avoiding confusion between order data from different order query scenarios. This provides a reliable basis for subsequent differentiated processing based on the scenario and for identifying abnormal order data.

[0050] Step 203: Determine the scenario processing strategy corresponding to the order query scenario.

[0051] Based on the established order query scenario, a set of standardized data processing rules pre-bound to that order query scenario are retrieved and activated. This standardizes the behavior of writing subsequent order data into the global cache repository, ensuring that all order data under the same query scenario follows a unified and fixed logic to perform subsequent operations.

[0052] The scenario processing strategy refers to a set of pre-configured and specially adapted processing rules for each order query scenario. These rules define the behavioral standards for writing, updating, verifying, and handling exceptions of order data in that scenario, including but not limited to: whether it is allowed to insert order data into the global order cache repository, whether it is allowed to update existing order data, whether it is allowed to delete order data, and whether abnormal data needs to be checked by calling the server interface.

[0053] Different order query scenarios have business differences in data update methods, exception handling requirements, and cache maintenance logic. If a uniform rule is used to process data for all scenarios, the processing logic will not match the business needs, and it will be impossible to balance data accuracy, processing efficiency, and exception control. This step configures and determines a unique processing strategy for each scenario, which can make the data processing behavior fit the characteristics of the scenario and achieve precise adaptation between rules and business.

[0054] It should be noted that the above steps do not limit the specific type of order query scenario configuration. Correspondingly, the scenario processing strategy is configured according to the order query scenario. This step also does not limit the specific rules of the scenario processing strategy configured under different order query scenarios. It can be configured according to the specific data management needs of the actual application scenario. For example, for today's order query scenario, a strategy can be configured to allow data insertion, allow data updates, and perform verification processing on abnormal data; for the order query scenario of the last three days, a strategy can be configured to allow data updates, restrict data insertion, and only mark abnormal data without immediate deletion; for recently updated order query scenario, a strategy can be configured to only allow data updates, not allow new data insertion, and directly ignore abnormal data. All kinds of strategies are flexibly set around the data range, display characteristics and reliability requirements of the corresponding scenario to meet diverse order data management needs.

[0055] Step 204: Update the global order cache repository based on the scenario processing strategy, the individual order data in the order dataset, and the scenario source identifier of the order data.

[0056] Based on the scenario processing strategy, each order data in the order dataset and its associated scenario source identifier, an update operation is performed on the global order cache repository. During the operation, in accordance with the rules for data addition, version update, data verification, and graded handling of abnormal orders specified by the scenario processing strategy corresponding to the current order query scenario, and combined with the scenario source identifier attached to each order data, a full update process is completed for the addition, overwriting, and cleanup of order data in the global order cache repository.

[0057] Among them, the global order cache repository is a centralized cache container used to store, maintain, and manage order data of all scenarios and types. It is used to replace the scattered caches on each terminal and realize the unified storage and shared use of order data of multiple terminals and multiple businesses.

[0058] In this embodiment, the specific order data storage method in the global order cache warehouse is not limited. The table below constructs a key-value data warehouse with the unique order identifier (OrderID) as the key and the order data as the value. All order data is stored in a unified form without distinguishing business scenarios, realizing the normalized management of the underlying data. However, it is not limited to this. Different storage methods can be referred to the description in this embodiment, which will not be elaborated here.

[0059]

[0060] Updating the global order cache repository based on scenario processing strategies, order datasets, and scenario source identifiers corresponding to each order's data clarifies the acquisition channel and business request scenario for each order's data at the data level. This allows the system to accurately identify the data source scenario during cache updates, anomaly detection, data overwriting, and data cleanup, avoiding data confusion and misjudgments caused by multiple views, lists, and data sources. Executing cache update operations according to scenario processing strategies enables differentiated and adaptive data updates for different order query scenarios according to preset rules. This ensures that data updates, additions, validations, and anomaly handling behaviors accurately match current business needs, avoiding problems such as inapplicable rules, over- or under-processing of data caused by using a unified processing logic. Furthermore, replacing distributed caching with centralized caching simplifies data maintenance logic, reduces redundant development costs, and improves the overall stability and efficiency of order data management.

[0061] The order data management method provided in this embodiment first divides order query scenarios according to request type. After receiving the order dataset from the server, it configures a scenario source identifier for each order data. The source identifier accurately distinguishes the business scenario to which each order belongs, clearly defining the boundaries of order data for different lists and different businesses. This fundamentally solves the problem of indistinguishable and easily misjudged abnormal data, improving the accuracy of order data identification. Secondly, it configures independent scenario processing strategies for each query scenario. Orders in different scenarios are processed differently according to customized rules, unifying the business logic of orders across multiple terminals and reducing redundant development costs. Finally, the scenario processing strategy and the order scenario source identifier jointly drive the update of the global order cache repository. Based on the source identifier, it distinguishes two types of abnormal orders and adopts a hierarchical verification mechanism: only abnormal orders with scenario associations are sent to the server for verification, while other abnormal orders are directly judged and cleaned through local time thresholds. This abandons the existing approach of fully re-fetching all abnormal data from the server, significantly reducing invalid network requests and reducing server load. At the same time, it relies on a unified global cache and scenario source markers to control the flow of order data, avoiding dirty and erroneous data caused by communication anomalies, and effectively ensuring the accuracy and consistency of financial order data throughout its entire lifecycle.

[0062] The above embodiments do not limit the configuration method of the scene source identifier. In order to further improve the traceability, consistency and accuracy of order data in complex financial transaction environments such as multi-scenario intersection, network anomalies and data update conflicts, and to solve the problems of ambiguous anomaly judgment and difficulty in cleaning dirty data caused by the lack of source information in traditional order data, this embodiment proposes a configuration method of scene source identifier. Specifically, step 203 configures a scene source identifier for each order data in the order dataset, which can be performed as follows: construct an order source information structure for each order data as a scene source identifier; wherein, the order source information structure includes: the data version field returned by the server, the scene source field and the latest protocol request time field.

[0063] This configuration method expands the scene source identifier from a single tag to a multi-dimensional information tag that includes a data version field, a scene source field, and a latest protocol request time field, among which: The data version field returned by the server is used to identify the version number of the order data issued by the server, in order to distinguish between new and old data and the order of updates.

[0064] The scenario source field is used to clarify the order query scenario to which the order data belongs, enabling data source traceability. In one embodiment, the scenario source field can accurately mark the business request scenario of the order data by bit enumeration. Continuing with the example of a financial transaction client, when the order query scenario is today's order query type, the scenario source field can be "0001"; when the order query scenario is the order query type of the last three days, the scenario source field can be "0010"; when the order query scenario is the recently updated order query type, the scenario source field can be "0100"; when the order query scenario is the order details query type, the scenario source field can be "1000"; and when the order query scenario includes both today's order query type and three-day order query type, the scenario source field can be "0011".

[0065] The Latest Protocol Request Time field records the time when the order data was most recently requested to be retrieved, and is used to identify the data retrieval sequence and validity.

[0066] The above three fields form a complete set of judgment criteria that can be mutually verified and quantified from three dimensions: data version, business request scenario, and request time sequence. This enables the system to no longer rely on fuzzy strategies or duplicate requests when updating data, handling conflicts, and verifying anomalies, thus significantly improving data consistency and processing reliability.

[0067] Of course, the configuration method of the scenario source identifier is not limited to this. Different fields can be configured according to different data management needs. For example, order status flag field, terminal type field, data source interface number field, data validity identifier field, etc. can be added according to data management needs to adapt to more scenarios of traceability, verification, filtering and statistical needs.

[0068] Traditional solutions lack a unified comparison rule for overlapping orders on both the local and server sides, easily leading to problems such as disordered overwriting of old and new versions and inconsistent data update logic across different ends. To standardize the update determination process for overlapping orders, this embodiment proposes a data update process that utilizes the version field carried by the structure to achieve precise incremental updates. Based on a scenario processing strategy, the overwrite operation is performed only when the order version is updated on the server side, avoiding data corruption caused by invalid overwriting. It also leverages structured identifiers to achieve lightweight and precise incremental updates, ensuring the accuracy of cached data while reducing unnecessary data rewriting overhead. In one embodiment, step 204, based on the scenario processing strategy and the scenario source identifier of each order in the order dataset, updates the global order cache repository, which may include the following steps: Step 411, in response to the scenario processing strategy including the data update strategy, obtain the intersecting order data between the order data in the order dataset and the local order data in the global order cache repository.

[0069] Step 412: Based on the data version field in the scenario source identifier, perform a version comparison on the intersecting order data, and perform data update based on the version comparison results.

[0070] The order data in the currently acquired order dataset is matched against the local order data stored in the global order cache repository, one by one. This distinguishes between intersecting order data that exists on both sides, non-intersecting order data that exists only in the current dataset, and non-intersecting order data that exists only in the cache repository. For intersecting order data, the data version field stored in the scenario source information structure bound to each intersecting order is extracted. The server-side order version is compared with the local cached order version one by one. Based on the version size relationship, it is determined whether to update the local cache. Specifically, if the server-side order version is higher, the server-side order is used to completely cover the local intersecting orders. If the server-side order version is lower than or equal to the local cached version, the original local order data can be retained without modification. This embodiment does not impose any restrictions on this.

[0071] This embodiment first filters intersecting orders and then processes them accordingly, eliminating the need to rewrite all orders. This reduces local cache read / write overhead and improves terminal data processing efficiency.

[0072] To enhance understanding, this embodiment introduces corresponding application scenario implementation methods for different situations. In this embodiment, the legend for the example diagram is defined as follows: In the diagram, letters represent order identifiers, numbers represent data version fields in the order source information structure, and numbers within circles represent scenario source fields in the order source information structure. Specifically, ① indicates the scenario source field is "Today's Orders," ② indicates the scenario source field is "Orders from the Last Three Days," ③ indicates the scenario source field is "Recently Updated Orders," and ④ indicates the scenario source field is "Order Details." Text indicates elements where the version number or source information has changed. For example, A1-① represents order A, data version field 1, and the order's scenario source field ① (Today's Order Scenario).

[0073] Figure 5 This demonstrates the processing logic for order data in the local global order cache repository when the order data returned by the server is updated in the order query scenario of "Today's Orders" and the scenario processing strategy includes a data update strategy.

[0074] Specifically, the order dataset returned by the server for the "Today's Orders ①" order query scenario includes order data A2 for order A, order data B2 for order B, and order data C2 for order C (the data version field for orders A, B, and C is 2). The local single queue (i.e., the global order cache repository) already stores order data A1-① (order A's data version field is 1, and the scenario source field is ①), B2-① (order B's data version field is 2, and the scenario source field is ①), and C1-② (order C's data version field is 1, and the scenario source field is ②).

[0075] The client can compare the order data returned by the server with the order data in the local global order cache repository to obtain the intersecting order data between the order data in the order dataset and the local order data in the global order cache repository, including order A, order B, and order C. Based on the data version field in the scenario source identifier, the client performs a version comparison on the intersecting order data and performs data updates based on the version comparison results, as follows: Order A: The data version field of the order data returned by the server is 2, which is higher than the data version field of the order data stored in the local global order cache repository (the data version field of the order data stored in the global order cache repository is 1). Therefore, the order data of Order A in the global order cache repository can be updated to A2-① (the data version field is 2, and the scenario source field ① remains unchanged).

[0076] Order B: The data version field of the order data returned by the server and the data version field of the order data stored in the local global order cache repository are both 2, and the data has not changed. Therefore, B2-① remains unchanged.

[0077] Order C: The data version field of the order data returned by the server is 2, which is higher than the data version field of the order data stored in the local global order cache repository. Therefore, the order data of order C in the local global order cache repository is updated to C2-②①, where the data version field is updated to 2 and a new scenario source field ① is added, indicating that order C exists in both scenario source field ② and scenario source field ①.

[0078] To fully utilize scene source identifiers to achieve standardized management of new orders and avoid the defects of scattered new data processing logic and inconsistent implementation across multiple terminals, this embodiment further proposes a data addition strategy processing method. By pre-screening to distinguish new orders, it is possible to avoid performing write operations on all orders and reduce local cache read and write overhead.

[0079] In one embodiment, step 204, which updates the global order cache repository based on the scenario processing strategy, the individual order data in the order dataset, and the scenario source identifier of the order data, may also include the following steps: Step 421, in response to the scenario processing strategy including the data addition strategy, obtain the first disjoint order data that exists in the order dataset but does not exist in the global order cache repository.

[0080] Step 422: Insert the first disjoint order data into the global order cache repository.

[0081] If the scenario processing strategy for the current order query scenario triggers the addition of new data, the order dataset issued by the server is first compared with the local orders already stored in the global order cache repository. The first disjoint order data, which exists only in the order dataset issued by the server and has no corresponding record in the local global order cache repository, is then extracted and the newly added order data is separated. The first disjoint order data, along with the configured order source information structure, is then written into the global order cache repository to complete the local storage of the newly added order data.

[0082] This embodiment filters new orders through pre-processing comparison, eliminating the need to traverse and rewrite all cached data. This significantly reduces local storage read / write operations and improves terminal order data processing efficiency. Furthermore, inserting only orders that do not exist locally effectively prevents duplicate entries of the same order, thus avoiding redundant and dirty data in the cache. When a new order is added, the source identifier is simultaneously retained, fully recording the query scenario, data version, and request time corresponding to that order. This provides comprehensive criteria for subsequent version updates, abnormal data identification, and order cleanup.

[0083] Figure 6 This demonstrates the processing logic for order data in the local global order cache repository when the order data returned by the server is updated in the order query scenario of "Today's Orders" and the scenario processing strategy includes a data addition strategy.

[0084] Specifically, the order dataset returned by the server for the "Today's Orders ①" order query scenario includes order data A2 for order A, order data B2 for order B, order data C2 for order C, and order data D2 for order D. Order data A1-①, B2-①, and C1-② are already stored in the local single queue (i.e., the global order cache repository). The client can compare the order data returned by the server with the order data in the local global order cache repository, retrieve the first disjoint order data (order D) that exists in the order data set but does not exist in the global order cache repository, and insert the first disjoint order data (order D's order data) into the global order cache repository, as follows: Order D: Order D exists in the order dataset returned by the server. However, Order D does not exist in the local single queue (global order cache repository). Therefore, according to the scenario processing strategy, the client inserts the order data D2-① (the data version field of order D is 2, and the scenario source field is ①) of order D as new data into the local single queue.

[0085] Understandably, the processing logic for orders A, B, and C is consistent with the "order data update process" described above: update the order data of order A to A2-①, keep the order data of order B unchanged, and update the order data of order C to C2-②①.

[0086] In one embodiment, step 204, which updates the global order cache repository based on the scenario processing strategy, the individual order data in the order dataset, and the scenario source identifier of the order data, may also include the following steps: Step 431: In response to the scenario processing strategy, including the data deletion strategy, obtain the second disjoint order data that exists in the global order cache warehouse but does not exist in the order dataset.

[0087] Step 432: From the second disjoint order data, determine the first abnormal data whose scenario source field in the scenario source identifier is consistent with the order query scenario of the order data request. Perform a query verification operation on the first abnormal data and update the first abnormal data in the global order cache warehouse based on the operation result of the query verification operation.

[0088] Step 433: From the second disjoint order data, determine the second abnormal data where the scenario source field in the scenario source identifier does not include a field consistent with the order query scenario of the order data request.

[0089] Step 434: If the latest protocol request time field of the second abnormal data is less than the request time of the order data request, delete the second abnormal data from the global order cache repository.

[0090] When the scenario processing strategy triggers data deletion, the client compares the order dataset sent by the server with the local order data in the global order cache repository. It then selects the second set of disjoint orders that are only retained in the local global order cache repository and have no matching records in the current order dataset returned by the server. These disjoint orders are designated as the set of abnormal orders to be verified. Next, based on the scenario source identifier bound to the order data, a scenario source field matching judgment is performed. Order data marked with the scenario source field corresponding to the current order query scenario is selected as the first abnormal data. The client then proactively initiates a query and verification operation on the order data to the server. Based on the result of the query and verification operation, the order data corresponding to the first abnormal data in the global order cache repository is updated accordingly. Furthermore, the first abnormal data can also be obtained from the global order cache repository by retrieving the scenario queue corresponding to the current order data request. Based on the order data in the scenario queue, the client selects the first abnormal data that exists in the scenario queue but does not exist in the order dataset returned by the server.

[0091] Next, the remaining second disjoint orders are further differentiated. Orders whose scenario source field does not contain the current query scenario are classified as second abnormal data. The latest protocol request time field in the second abnormal data order source information structure is read and compared with the request time of the current order data request. If the latest protocol request time field is earlier than the request time of the current order data request, the order data corresponding to the second abnormal data is determined to be invalid and is directly removed from the global order cache repository. It can be understood that if the latest protocol request time field is later than the request time of the current order data request, the order data corresponding to the second abnormal data is determined to be valid and the original order data can be retained without modification. This embodiment does not impose this limitation.

[0092] This embodiment first uniformly filters out second-disjoint orders and then classifies and processes them, achieving centralized aggregation of abnormal orders and reducing the terminal computing power consumption caused by full cache traversal. Then, it distinguishes between two types of abnormal orders based on the scenario source field. Remote verification is initiated only for the first type of abnormal data strongly related to the current order query scenario, while the remaining second-type abnormal data is determined using the local time field. This abandons the traditional approach of re-fetching server data for all abnormal orders, thus significantly reducing invalid network requests and lowering server load. For second-type abnormal data unrelated to the current order query scenario, lightweight local verification is performed using the latest protocol request time field, allowing for the determination of cross-scenario invalid orders without additional network interaction, improving terminal cache cleanup efficiency. This overall differentiated processing method avoids the accidental deletion of valid orders belonging only to other business scenarios, solves the problem of dirty data and erroneous deletion of valid data caused by communication anomalies, and significantly improves the accuracy of financial order cache data.

[0093] In an order data management system operating concurrently across multiple terminals and query scenarios, factors such as network fluctuations, asynchronous data synchronization, and differences in query scope can lead to redundant invalid data, increased cache usage, and decreased data authenticity if only anomaly marking is performed after the first abnormal data is identified in the global order cache repository, and dynamic purification of cached data cannot be achieved. In step 432, after updating the first abnormal data in the global order cache repository based on the query verification operation result, if the query verification operation result indicates that the order data is valid and exists, the scenario source field corresponding to the order query scenario in the scenario source identifier of the first abnormal data is deleted; if the query verification operation result indicates that the order data is invalid or does not exist, the corresponding first abnormal data is deleted from the global order cache repository.

[0094] After completing the query and verification operation for the first abnormal data with the server and obtaining the result of the query and verification operation, the order data corresponding to the first abnormal data in the global order cache warehouse can be subjected to differentiated update processing based on the result of the query and verification operation: when the result of the query and verification operation shows that the order is real and valid and the server still has the corresponding order record, only the scenario source field in the order scenario source identifier that is consistent with the current query scenario is cleared, while the order data itself and other scenario source fields are retained; when the result of the query and verification operation shows that the order has expired or the server has no corresponding order record, the order data corresponding to the first abnormal data is directly removed completely from the global order cache warehouse.

[0095] Furthermore, after deleting the scenario source field corresponding to the order query scenario in the scenario source identifier of the first abnormal data, if the scenario source field in the scenario source identifier of the first abnormal data is empty, the first abnormal data can be removed from the global order cache repository.

[0096] Specifically, for orders that remain valid, only the corresponding scenario marker is deleted instead of the entire order. This preserves the order's displayability in other business scenarios, preventing the accidental deletion of valid orders in other query scenarios due to data loss in a single order query scenario. This fundamentally avoids issues such as cached data loss and missing orders on the page. Furthermore, by partially modifying the scenario source field instead of full deletion, there's no need to repeatedly fetch complete order information from the server, reducing data interaction between the terminal and the server, and lowering server request frequency and network transmission overhead. This embodiment distinguishes between the actual invalidation of an order and the temporary absence of an order in a single query scenario, addressing the data cleanup defects caused by the uniform deletion of abnormal orders in existing technologies, while ensuring the traceability of order data throughout its entire lifecycle.

[0097] Furthermore, to avoid excessive server pressure caused by verifying each item individually, the client can enable a quantity threshold control mechanism. Specifically, this includes acquiring the number of first abnormal data items. When the number of abnormal data items reaches a preset threshold, the client will no longer perform query verification operations on the first abnormal data items. Instead, it will send an order data request for the same order query scenario to the server to re-retrieve the complete order dataset for the corresponding order query scenario. Based on the newly acquired order dataset, the global order cache repository will be updated, thereby efficiently handling batch "pseudo-abnormal" data caused by time changes.

[0098] Order data deletion is one of the core processing steps of this method. This step is mainly for application scenarios where the local global order cache repository contains order data, but the order data returned by the server does not contain the corresponding order data. The following section introduces three application scenarios of data deletion with reference to the attached diagram.

[0099] The first scenario involves receiving a normal order deletion notification, as described below. Figure 7 , Figure 7 The local single queue (global order cache repository) includes order data: A1-①, B2-①, and C1-②. First, the client receives an order deletion push notification from the server, informing the user that order A has been deleted. The client's processing logic is as follows: Upon successfully receiving the order deletion push notification, the client directly removes order data A1-① from the local single queue according to the push instruction. The updated local single queue includes: B2-① and C1-②.

[0100] At this point, the client can receive a business trigger from the upper layer and initiate an order data request for the order query scenario "Today's Orders ①". The order data returned by the server includes: order data B2 of order B and order data C2 of order C.

[0101] The client can compare the order data returned by the server with the order data in the local global order cache repository to obtain the intersecting order data between the order data in the order dataset and the local order data in the global order cache repository, including orders B and C. Based on the data version field in the scenario source identifier, the client can perform a version comparison on the intersecting order data and perform data updates based on the version comparison results, as follows: Order B: The data version field of the order data returned by the server and the data version field of the order data stored in the local global order cache repository are both 2, and the data has not changed. Therefore, B2-① remains unchanged.

[0102] Order C: The data version field of the order data returned by the server is 2, which is higher than the data version field of the order data stored in the local global order cache repository. Therefore, the order data of Order C in the local global order cache repository is updated to C2-②①, where the data version field is updated to 2, and a new scenario source field ① is added, indicating that Order C exists in both scenario source field ② and scenario source field ①. The client directly performs data cleanup based on the server's deletion command, without needing to initiate an additional detailed verification request, making the process simple and efficient.

[0103] The second scenario involves not receiving the data deletion notification. Please refer to [the relevant documentation / reference]. Figure 8 , Figure 8 The local single queue (global order cache repository) includes order data: A1-①, B2-①, and C1-②. First, the server sends an order deletion push notification to the client user, informing them that order A has been deleted. However, the client does not receive this deletion push notification and does not perform any action; the order data in the client's local single queue remains unchanged.

[0104] At this point, the client can receive a business trigger from the upper layer and initiate an order data request for the order query scenario "Today's Orders ①". Since the order data of order A has been deleted from the server, the order data returned by the server includes: order data B2 of order B and order data C2 of order C.

[0105] The client can compare the order data returned by the server with the order data in the local global order cache repository to obtain the second disjoint order data, i.e., order A, which exists in the global order cache repository but not in the order data set. Since the scenario source field ① in the order data A1-① of order A in the global order cache repository is consistent with the order query scenario requested by the order data, order data A1-① of order A is the first abnormal data. A query verification operation can be performed on order A and / or order data A1 of order A. For example, according to the policy, the order details interface (such as the 4707 protocol) can be called to request the server to query whether order A and / or order data A1 of order A exist. The operation result corresponding to the query verification operation is that the order data is invalid or does not exist, and order data A1 of order A has been deleted. The system will delete the A1-① data in the local queue.

[0106] Understandably, the processing logic for intersecting order data, such as Order B and Order C, is consistent with the first scenario described above.

[0107] The third scenario involves data that has changed over a period of time but is not returned normally, as described in the following example. Figure 9On day T, the client may receive a request from the upper-layer business to initiate an order data query scenario of "Today's Orders ①". At this time, the order data returned by the server includes: order data A1 of order A, order data B2 of order B, and order data C2 of order C. At this time, the local single queue (global order cache repository) includes order data: A1-①, B2-①, and C2-①.

[0108] On day (T+1), the client receives another trigger from the upper-layer business, initiating an order data request for the "Today's Orders ①" scenario. At this time, the server returns order data including order data C2 for order C. Understandably, because it spans multiple days, after receiving the order data request for "Today's Orders ①", the server will no longer return order data A1 for order A and order data B2 for order B. The client's processing logic at this point is as follows: The client can compare the order data returned by the server with the order data in the local global order cache repository to obtain the second disjoint order data, i.e., the order data of order A and order B, which exist in the global order cache repository but not in the order data set. Since the scenario source field ① in the order data A1-① of order A and the order data B2-① of order B in the global order cache repository is consistent with the order query scenario requested by the order data, i.e., the order data A1-① of order A and the order data B2-① of order B are both first abnormal data, a query verification operation can be performed on the order data A1 of order A and the order data B2 of order B. For example, according to the policy, the order detail query interface (such as the 4707 protocol) can be called to request the server to query whether the order data A1 of order A and the order data B2 of order B exist. The operation result corresponding to the query verification operation is that the order data is invalid or does not exist, and the order data of order A and the order data of order B have been deleted. The client can delete the order data A1-① and the order data B2-① in the local queue.

[0109] Furthermore, to avoid excessive server load due to item-by-item verification, the client can enable a quantity threshold control mechanism. Specifically, this includes determining the number of records for the first abnormal data. When the number of records for the first abnormal data reaches a preset threshold, the client will no longer call the detailed query interface item by item. Instead, it will send an order data request for the same order query scenario to the server, thereby retrieving the complete order dataset for the corresponding order query scenario. Figure 10As shown, on day T, the client can receive a trigger from the upper-layer business to initiate an order data request for the order query scenario "Today's Orders ①". At this time, the order data returned by the server includes: order data A1 of order A, order data B2 of order B, and order data C2 of order C. At this time, the local single queue (global order cache repository) includes order data: A1-①, B2-①, and C2-①.

[0110] On day (T+1), the client receives another trigger from the upper-layer business and initiates an order data request for the order query scenario "Today's Orders ①". At this time, the order data returned by the server includes: order data C2 of order C. The client can then compare the order data returned by the server with the order data in the local global order cache repository to obtain the second disjoint order data that exists in the global order cache repository but not in the order data set, namely the order data of order A and order B. Since the scenario source field ① in the order data A1-① of order A and the order data B2-① of order B in the global order cache repository is consistent with the order query scenario of the order data request, both the order data A1-① of order A and the order data B2-① of order B are considered the first abnormal data.

[0111] At this point, since the number of data entries for the first abnormal data has reached a preset threshold, the client no longer calls the detailed query interface item by item. Instead, it sends another order data request to the server for the order query scenario "Today's Orders ①". The order data returned by the server includes: order data C2 for order C. Based on the order data returned by the server this time, the client overwrites the entire local single queue. In the end, the local single queue only retains the order C1-① returned by the server, while order data A1 for order A and order data B2 for order B are removed.

[0112] This mechanism avoids invalid detail verification requests caused by a large number of expired orders in cross-day scenarios, significantly reducing the query pressure on the server side, while ensuring the consistency between local order data and server-side data.

[0113] Figure 11The diagram illustrates the comparison and processing logic of order data between the server and local cache. In the diagram, the left circle represents the order data sent by the server (which can be labeled as SVR data), and the right circle represents the local data in the global order cache repository. The intersection of the two circles represents intersecting data, i.e., order data that exists simultaneously on both the server and local cache. The corresponding processing logic is to compare the data versions and perform an overwrite update based on the version. The area inside the server circle and outside the local circle represents non-intersecting data A, i.e., order data added on the server but not existing locally. The corresponding processing logic is to directly insert the data. The area inside the local circle and outside the server circle represents non-intersecting data B, i.e., order data that exists in the local cache but not in the current server response. The corresponding processing logic is to initiate a confirmation request for the order list or details interface, and if the data is determined to be abnormal, to perform subsequent processing according to the scenario strategy.

[0114] Figure 12 The diagram illustrates the entire control logic from order data being sent from the server to local cache processing. Upon receiving the order dataset from the server, the system first confirms the scenario processing strategy corresponding to the current order query scenario. Then, it enters the layered data processing judgment logic: First, it determines whether data updates are allowed. If so, it filters out intersecting order data that exists in both the server-returned order dataset and the local global order cache repository (i.e., orders present in both the server and the local global order cache repository). It then determines whether the version of the first order data returned by the server is higher. If the version of the first order data is higher, indicating a version update, it executes the local data overwrite procedure. The first step involves several steps: First, determining if new data needs to be added. If so, filtering out new order data that exists in the order data returned by the server but not in the local global order cache (i.e., disjoint data) and inserting it into the local cache. Second, determining if data needs to be deleted. If so, filtering out abnormal order data that exists in the local global order cache but not in the order data returned by the server, and then deciding whether to call the order details interface to verify with the server again based on the scenario strategy: if no verification is needed or the verification result is that the order has been deleted, then directly delete it from the local cache; if the verification result is that the order still exists, then keep the local data unchanged. After all data processing is complete, a unified order list is built and the process ends. The processing actions at each stage are determined by the scenario processing strategy, achieving scenario-based and strategy-based closed-loop management of order data, ensuring the consistency and validity of local cache data and server-side data.

[0115] In updating based on the data version field, to avoid data overwriting errors caused by unclear data version identification, and to ensure that the identification information is updated synchronously with the main data, specifically, assuming that the first order data in the order dataset and the second order data in the local order data are intersecting order data, then step 412, comparing the versions of the intersecting order data according to the data version field in the scenario source identifier, and performing data updates based on the version comparison results, can be performed as follows: Step 4121: Determine whether the version field of the first order data in the order dataset is greater than the version field of the second order data in the local order data.

[0116] Step 4122: If the version field of the first order data is greater than the version field of the second order data, update the second order data in the local order data according to the first order data, and synchronously write the scenario source field and the latest protocol request time field.

[0117] Step 4123: If the version field in the order dataset is not greater than the version field in the second order data, keep the second order data in the local order data unchanged.

[0118] The above embodiments use the value of the data version field as an objective criterion to compare the version of the current order data to be written with the local order data in the global cache. When it is determined that the current data version is updated, not only is the original order main data in the cache overwritten and replaced, but the scenario source field and the latest protocol request time field are also refreshed simultaneously to ensure that the identification information and business data are updated synchronously. This ensures that the source identifier and time sequence information of each order data are matched with the latest business data, maintaining the overall integrity and traceability of the data. When it is determined that the current data version is not updated or is lower, the original data in the cache is directly retained without performing any change operations. This prevents old data from overwriting valid new data and also reduces the frequency of cache operations and system resource consumption.

[0119] To enhance understanding, this embodiment describes corresponding application scenarios and implementation methods for different situations.

[0120] Reference Figure 13 The global order cache repository contains: A1-①, B2-①, and C1-②. A client initiates order data request 1 for the "Today's Orders" query scenario, retrieving order data for the "Today's Orders ①" query scenario; the server responds to order data request 1 by returning the order dataset, such as... Figure 13 The server returned order data A1, B2, and C1.

[0121] During the execution of order data request 1, the client receives an order creation push notification from the server, notifying the user that order D has been created. The client actively calls the order details query interface, initiating order data request 2 with the order query scenario of "order details" to obtain detailed order data for order D. The server returns order data for order data request 2, which contains order D. Since order D does not exist in the local single queue (global order cache repository), the client, according to the scenario processing strategy, inserts order data D1-④ (data version field 1 of order D, scenario source field marked as ④, representing the order details query scenario) as new data into the global order cache repository, i.e., the local single queue. At this time, the global order cache repository is updated to: A1-①, B2-①, C1-②, D1-④.

[0122] After order data request 1 is executed, the order dataset returned by the server for the order query scenario "Today's Orders ①" consists of order data A1 corresponding to order A, order data B2 corresponding to order B, and order data C2 corresponding to order C, but does not include order D. At this time, the intersecting order data between the order data in the order dataset and the local order data in the global order cache repository, namely order A, order B, and order C, is processed according to the following logic: Order A and Order B: The data version field of the order data returned by the server is the same as the data version field of the order data stored in the local global order cache repository. The data has not changed, so A1-① and B2-① remain unchanged. Order C: The data version field of the order data returned by the server is 2, which is higher than the data version field of the order data stored in the local global order cache repository. Therefore, the order data of order C in the local global order cache repository is updated to C2-②①, where the data version field is updated to 2 and a new scenario source field ① is added, indicating that order C exists in both scenario source field ② and scenario source field ①.

[0123] For the second disjoint order data that exists in the global order cache repository but not in the order dataset, since the scenario source field ④ of order D is not consistent with the order query scenario ① of order data request 1, it is determined that order D does not belong to the abnormal data of the current query scenario. No additional verification or deletion operation is required, and it is only kept in the local queue.

[0124] At this point, the global order cache repository is updated to: A1-①, B2-①, C2-②①, D1-④.

[0125] The client then initiates another order data request 3 with the order query scenario "Today's Orders," retrieving order data for the "Today's Orders ①" query scenario. The server responds to this order data request 3 with an order dataset for the "Today's Orders ①" query scenario, including order data A1, B2, C1, and D1. In other words, the server will normally return order data D1 for order D. The client's specific processing logic for order data D is as follows: The data version field of the order data returned by the server and the data version field of the order data stored in the local global order cache repository are both 1, indicating no data change. However, the scenario source field in the scenario source identifier corresponding to order D needs to be updated to include ①, forming order data D1-④①, thus formally incorporating it into the lifecycle management of the "Today's Orders" scenario.

[0126] This process effectively distinguishes between normal scenarios where the local data version is leading and abnormal scenarios where data is missing by using differentiated identification of source tags, thus avoiding misjudgments and unnecessary detailed verification requests.

[0127] This scenario can be extended into two special branch scenarios. The first type of branch scenario: see [link to relevant section]. Figure 14 The client initiates two order data requests, namely Order Data Request 1 and Order Data Request 3, for the "Today's Orders" query scenario, to retrieve order data for the "Today's Orders ①" query scenario. The server responds to Order Data Request 1 by returning an order dataset containing order data A1, B2, and C1, and responds to Order Data Request 3 by returning an order dataset containing order data A1, B2, C2, and D1.

[0128] During the execution of order data request 1, the server successively sends out order creation push and order deletion push for order D: The client first receives the order creation push for order D, calls the details interface to obtain the order data D1-④ corresponding to order D, and inserts the order data D1-④ into the local queue; then it receives the deletion push for order D, calls the details interface again to verify and confirm that the order has been deleted, and directly removes the order data D1-④ from the local queue.

[0129] After order data request 1 is executed, the "Today's Orders ①" dataset returned by the server does not contain order D. However, at this time, there is also no order data for order D in the local queue. There is no abnormal state of "the order exists in the local global order cache repository, but not in the order dataset returned by the server". Even if the order dataset returned by the server in response to the next order data request (such as order data request 3) still does not contain order D, it has been cleaned up locally through deletion push, and there will be no problem of the scene source field tag not being able to be updated or lifecycle management being interrupted.

[0130] The second category is extreme scenarios spanning multiple days; please refer to [the relevant documentation]. Figure 15The initial global order cache repository contains: A1-①, B2-①, and C1-②. On the first day, the client initiates order data request 1 for the "Today's Orders" scenario; the server responds to order data request 1 by returning order data A1, B2, and C2.

[0131] During the response to order data request 1, the client receives an order creation push notification from the server, notifying the user that order D has been created. The client actively calls the order details query interface, initiating order data request 2 with the order query scenario of "order details" to obtain detailed order data for order D. The server returns order data for order data request 2, which contains order D. Since order D does not exist in the local single queue (global order cache repository), the client, according to the scenario processing strategy, inserts order data D1-④ (data version field 1 of order D, scenario source field marked as ④, representing the order details query scenario) as new data into the global order cache repository, i.e., the local single queue. At this time, the global order cache repository is updated to: A1-①, B2-①, C1-②, D1-④.

[0132] After the response to order data request 1 is completed, the first round of order query scenario returned by the server is "Today's Orders ①". The order dataset consists of order data A1 corresponding to order A, order data B2 corresponding to order B, and order data C2 corresponding to order C, but does not include order D. At this time, the intersecting order data between the order data in the order dataset and the local order data in the global order cache repository, namely order A, order B, and order C, are processed in the same way as above. At this time, the global order cache repository is updated to: A1-①, B2-①, C2-②①, D1-④.

[0133] On the second day, the client initiated another order data request 3 for the "Today's Orders" query scenario, and pulled the order dataset for the "Today's Orders ①" query scenario again. The server responded to the order data request 3 and returned the order dataset for the "Today's Orders ①" query scenario, which consisted of order data A2, B3, and C3. Order data D did not exist (because order D was created on the first day, and the time is now the second day, order D cannot be returned as order data for the "Today's Orders ①" query scenario).

[0134] At this time, the local single queue contains order data D1-④ for order D, whose scenario source identifier only contains the field ④ and has not been updated to include the tag combination ①. The client's processing logic for the order data of order D is as follows: Order data D1-④ of order D is the second disjoint order data that exists in the global order cache repository but does not exist in the order dataset. Furthermore, order data D1-④ is the second abnormal data whose scenario source field does not include the field consistent with the order query scenario of order data request 1. The latest protocol request time field of order data D1-④ of order D can be obtained. If the latest protocol request time field is earlier than the request time of order data request 3, the second abnormal data is deleted from the global order cache repository. If the latest protocol request time field is later than the request time of order data request 3, the order data is retained in the global order cache repository.

[0135] If the order data D1-④ of order D is retained in the global order cache repository, and the client subsequently initiates another order data request with the order query scenario "Today's Orders ①", the order data of order D will still not be in the order dataset returned by the server, causing its scenario source field to remain unupdated. In this case, the client's processing logic for the order data of order D is as follows: The order data D1-④ of order D is the second disjoint order data that exists in the global order cache repository but does not exist in the order dataset. Furthermore, the order data D1-④ is the second abnormal data whose scenario source field does not include the field consistent with the order query scenario of order data request 1. The latest protocol request time field of the order data D1-④ of order D can be obtained. Since the latest protocol request time field is necessarily less than the request time of this order data request, the second abnormal data can be deleted from the global order cache repository. This avoids the problem of the order data of order D remaining in the local scenario queue corresponding to the "Today's Orders" order query scenario for a long time and not being able to be cleaned up normally.

[0136] Based on the configuration of the order scenario source identifier, this embodiment further proposes a processing method for cache deletion scenarios. By using the scenario source field to distinguish abnormal order-related scenarios, it can avoid indiscriminate full requests to the server, significantly reduce invalid network requests, and reduce server pressure.

[0137] It should be noted that this embodiment only uses the order source information structure, which includes the data version field returned by the server, the scenario source field, and the latest protocol request time field, as an example. Other configuration methods can refer to the description in this embodiment, and will not be repeated here.

[0138] In order data management scenarios involving multiple terminals and business operations, order data undergoes multiple stages, including acquisition, caching, updating, anomaly detection, and cleanup. Traditional methods rely on single fields or temporary logic to distinguish data states, which can lead to problems such as ambiguous state definitions, scattered handling logic, and inconsistent processing rules across different stages, hindering standardized management throughout the data lifecycle. To achieve refined differentiation of order data flow states and provide unified state judgment criteria and execution standards for cache writing, difference comparison, and anomaly handling, further standardizing the entire process, a state machine management mechanism can be added after acquiring the order dataset.

[0139] In step 202, after receiving the order dataset corresponding to the order data request, a preset state machine can be further associated with each order data in the order dataset. The state machine's state identifiers include: initial state, valid state, local retention state, and pending deletion state. When the order data acquisition is complete, it is uniformly marked as the initial state. Based on the scenario processing strategy and each order data in the order dataset as well as the scenario source identifier of the order data, the global order cache repository is updated. The state identifier is switched according to the data judgment result, and data update, cache retention, or data deletion operations are performed according to the state identifier matching and processing rules.

[0140] The above embodiment binds each order data entry to a predefined state machine, which sets four state identifiers: initial state, valid state, local retention state, and pending deletion state. After order data is retrieved from the data source, it is uniformly set to the initial state. During the process of writing data to the global order cache repository according to the scenario processing strategy, the state identifier corresponding to the data is dynamically switched based on data judgment results such as data comparison, version verification, and anomaly detection. Based on the current state, the corresponding processing rules are matched to complete operations such as data update, cache retention, or data deletion. Taking the "Today's Orders" scenario as an example, two typical state transition paths are demonstrated: Figure 16 To simplify the processing path, order data goes directly from the initial state (none) to the active state after the response to today's order list request. If a subsequent list request indicates that the order does not exist, it will be transferred to the delete state. Figure 17 To introduce a closed-loop path for detailed verification, after the data enters the valid state from the initial state, if the list request reports that the order does not exist, it enters an abnormal state. Then, the validity of the order is verified by calling the order details interface. If it is verified that the order does not exist, it flows to the pending deletion state; if it is verified that the order exists, it falls back to the valid state, thus realizing closed-loop verification of abnormal data.

[0141] Figure 18It displays the complete lifecycle states of order data, including four states: initial state (none), local retention state (local), active state (active), and delete state (pending deletion). The state transition is implemented through event-driven mechanisms: In the initial state, if the order exists in the client's cache and the server does not respond, it enters the local retention state; after the local retention state data is confirmed by the server's response, it enters the active state; in the active state, if any list request indicates that the order does not exist, it can directly transition to the delete state; local retention state data can also directly transition to the delete state by the user actively refreshing the order details.

[0142] Each order data entry is associated with an independent state machine, and data types are categorized using standardized state identifiers, replacing scattered temporary markers. This makes the stage of the data immediately clear, and each data entry is uniformly marked as an initial state after acquisition. A unified starting state is set for all newly added data to ensure consistent initial rules and eliminate logical deviations caused by different starting standards for different data. During the data writing process, the state is dynamically switched based on the judgment results, and corresponding processing rules are matched according to the state. Data state is strongly bound to operations such as update, retention, and deletion, so that each type of data follows fixed rules to perform actions. This streamlines and simplifies complex business logic, effectively avoids processing logic chaos caused by unclear states, improves the orderliness and execution efficiency of data management, and also makes the data flow process traceable and controllable, enhancing adaptability and stability in complex business scenarios.

[0143] It should be noted that although the operation of the method of the present invention is described in a specific order in the accompanying drawings, this does not require or imply that the operations must be performed in that specific order, or that all the operations shown must be performed in order to achieve the desired result.

[0144] Based on the above-mentioned order data request processing flow, the order data management method provided in this application also provides three core functions: query, update, and monitoring, forming a complete closed loop for order data management.

[0145] The query function allows upper-layer businesses to directly read and retrieve order data from the global order cache repository based on dimensions such as unique order identifier, business scenario, and status identifier, without repeatedly sending requests to the server, thus achieving fast data access. The update function allows upper-layer businesses to proactively trigger synchronous updates of order data in scenarios such as changes in order status or modifications to business information. The system will complete server-side data retrieval, local cache comparison, version verification, and data writing operations according to preset scenario processing strategies and state machine rules, ensuring data consistency after the update. The listening function allows upper-layer businesses to subscribe to data change events for specified orders or scenarios. When order data in the global order cache repository is added, updated, or deleted, the system will proactively push change notifications to subscribers, allowing upper-layer businesses to perceive changes in order status in real time without polling.

[0146] By integrating four types of functions—request, query, update, and listen—it provides an undifferentiated entry point for order data access and interaction for upper-layer businesses, shielding the complex details of underlying cache management, data synchronization, and state transitions, and achieving unified management and efficient collaboration of order data across multiple business scenarios.

[0147] To enhance understanding, this embodiment introduces the control process for the entire lifecycle management of order data. Figure 19 The diagram shows the control logic for the entire lifecycle management of order data, covering the entire chain of control logic from request retrieval, identifier configuration, policy matching, data comparison, cache processing to anomaly verification and status changes.

[0148] Order data lifecycle management mainly includes two parts: order list data refresh and proactive order detail updates. Upon receiving an order list request, the system first identifies the corresponding order query scenario and retrieves and activates the pre-defined scenario processing strategy. Then, it receives the order dataset from the order data server. Each record in this dataset is pre-configured with a scenario source identifier, including a data version field, a scenario source field, and the latest protocol request time field. The system then compares the acquired order dataset with the local order data in the global order cache repository, identifying overlapping and non-overlapping order data.

[0149] For intersecting order data, the version fields of both parties are read to determine the version. If the current order dataset has a higher version, the corresponding order data in the global cache is overwritten and updated based on the new data, and the scenario source field and the latest protocol request time field are refreshed simultaneously. If the current data version is lower or the same, the original data in the global cache is retained without modification.

[0150] For disjoint order data that exists only in the current order dataset and is not included in the global cache, perform data insertion operations according to the scenario processing strategy to complete the addition of new order data to the cache.

[0151] For disjoint order data that is only stored in the global order cache repository and not returned by the server in this response, it is uniformly identified as abnormal data. Then, based on the scenario handling strategy, it is determined whether to trigger a query verification operation: if the strategy requires verification, the order details interface is called to initiate verification to the server. If the verification result determines that the order is valid and exists, the corresponding abnormal data in the global cache is updated; if the verification result determines that the order is invalid or has been deleted, the data is directly deleted from the global order cache repository; if the strategy does not require verification, the abnormal data is marked and retained. After completing all data updates, insertions, deletions, and abnormal handling, the state machine identifier of the corresponding order data is switched based on the data processing results, and finally, the cache dedicated to each scenario is synchronously written back, and this round of order list data refresh process ends.

[0152] The proactive order details update process includes the following steps: Upon receiving an order details update request, the system first matches the corresponding order query scenario and loads the scenario processing strategy. Simultaneously, it performs validity and permission checks on the order data corresponding to the request. If the checks pass, it initiates a data synchronization request to the order data server to obtain the latest order details data. The system compares and verifies the newly acquired details data with historical data in the global order cache repository, performing incremental updates or full overwrite operations. It synchronously updates the order entity information, scenario source information, and the latest protocol request time field, and switches the state machine identifier corresponding to the order data based on the data change results. If the order data validity and permission checks fail, the update process is terminated directly, ensuring the compliance and security of order data operations. These two processes work together, relying on unified scenario rules, version verification mechanisms, state machine control, and anomaly verification capabilities to achieve standardized, closed-loop management of the entire order data lifecycle, ensuring the accuracy, consistency, and real-time performance of order data across multiple terminals and business scenarios.

[0153] The specific steps involved can be referred to in the above embodiments, and will not be repeated here.

[0154] To further explain the logic of scenario source identification, abnormal data judgment, order data deletion and full-process control in this method, a complete explanation is provided below with actual business scenarios and running examples.

[0155] Assuming that order OrderA is already stored in the global order cache repository, this order is initially retrieved and cached by today's order query scenario, with the corresponding scenario source tag configured synchronously. During the order list refresh process, it is common to encounter a phenomenon where the order is stored in the local cache, but the order is not present in the dataset returned by the server in this instance. This phenomenon can be divided into two categories: normal business loss and loss due to communication anomalies.

[0156] Scenario 1: Today's Orders Refresh The user initiated another order query request for today. Due to the change in time range, OrderA is no longer within the scope of today's orders, and the server's returned list no longer contains this order. The local OrderA is marked as candidate abnormal data. Combining business rules and scenario source identifiers, it can be determined that this data loss is a normal business change, and the order can be directly cleared. The judgment result is accurate.

[0157] Scenario 2: Recent order update packet loss When a user initiates a request to query recently updated orders, OrderA should appear in the list returned by the server. However, due to network packet loss, the server data loses the order, and the local OrderA is also marked as candidate abnormal data. This type of missing data is caused by communication abnormalities. If it is directly deleted, it will cause accidental data deletion, which is a typical abnormal scenario.

[0158] In traditional technical solutions without setting scenario source markers, the two scenarios described above appear completely identical externally: data exists locally, but new requests for data lack corresponding content, and the system cannot distinguish the cause of the missing data. Traditional solutions mainly fall into two categories: one is to uniformly send a secondary confirmation request to the server for all candidate abnormal data. Although the logic is simple, this significantly increases the number of network requests and puts a heavy burden on the server. The other is to rely solely on inherent attributes such as order update time for inference and judgment, which is prone to errors and generates dirty data.

[0159] The scenario source marker added to this method does not primarily describe the business attributes of the order itself, but rather records the request channel and query scenario corresponding to a single piece of local data. This marker offers three main advantages: First, it distinguishes between reasonable and abnormal missing data; differences in data from the same source are often due to normal business updates, while missing data from different sources likely indicates communication anomalies. Second, it enables refined strategy matching, combining the scenario source marker with the current query scenario to perform differentiated processing, abandoning a one-size-fits-all approach. Third, it addresses the lack of judgment dimensions in traditional solutions, completely eliminating data misjudgment vulnerabilities.

[0160] Finally combined Figure 20 This section describes the complete order deletion process. The system first receives order data from the server and determines the appropriate scenario handling strategy for the current query. Then, it iterates through all local orders, identifying all candidate abnormal orders that exist locally but not on the server. These are then categorized into two types based on their source markers. The first type consists of orders with the same source as the server data. The system first determines whether to delete the order. If deletion is required, it calls the order details interface for verification. If the verification confirms the order has already been deleted, local data deletion is performed directly. If the verification confirms the order is still valid, the source marker for the current scenario is removed from the order's source information.

[0161] The second category consists of orders whose data source differs from that of the server. The system also first determines whether a deletion operation is necessary. If deletion is required, it further determines the order's status by considering the latest protocol request time field, and then calls the order details interface for verification. If the verification confirms the order has been deleted, local data deletion is performed; if the order is still valid, the data is retained but the source marker is not updated, awaiting synchronization upon subsequent requests.

[0162] During processing, if the number of abnormal orders reaches a preset threshold, the system will no longer initiate verification requests for each order individually. Instead, it will directly retrieve the complete order list again and perform a complete overwrite update on the local data to avoid excessive pressure on the server.

[0163] Ultimately, all abnormal orders were processed, the system updated the local single queue data and ended the current round of the process, achieving standardized closed-loop management of order data from multiple scenarios and sources.

[0164] Figure 21 The diagram shows a schematic of the structure of an order data management device provided in an embodiment of this application. The device can be implemented based on an SDK+BFF architecture (a layered aggregation architecture that combines a software development kit with a backend as the frontend) to complete the aggregation of full-process management capabilities such as order data requests and maintenance. The upper-layer business does not need to distinguish between different terminal environments such as devices and systems, nor does it need to differentiate the processing of different business scenarios such as ordinary orders, foreign exchange business, and institutional business, as well as various interactive requests such as today's orders, orders in the last three days, and recently updated orders.

[0165] like Figure 21 As shown, the order data management device 10 includes: The order scenario determination module 11 is used to send an order data request to the server and determine the corresponding order query scenario based on the request type.

[0166] The dataset labeling module 12 is used to receive the order dataset corresponding to the order data request and configure the scenario source identifier for each order data in the order dataset according to the order query scenario.

[0167] The strategy determination module 13 is used to determine the scenario processing strategy configured for the order query scenario.

[0168] The data update module 14 is used to update the global order cache repository based on the scenario processing strategy, the data of each order in the order dataset, and the scenario source identifier of the order data.

[0169] In some embodiments, the dataset tagging module 12 can be specifically used to: construct an order source information structure for each order data as a scene source identifier; the order source information structure includes: a data version field returned by the server, a scene source field, and a latest protocol request time field.

[0170] In some embodiments, the data update module 14 may be specifically used to: in response to a scenario processing strategy including a data update strategy, obtain intersecting order data between order data in the order dataset and local order data in the global order cache repository; perform version comparison on the intersecting order data according to the data version field in the scenario source identifier, and perform data update according to the version comparison result.

[0171] In some embodiments, the data update module 14 may be specifically used to: in response to a scenario processing strategy including a data addition strategy, obtain first disjoint order data that exists in the order dataset but does not exist in the global order cache repository; and insert the first disjoint order data into the global order cache repository.

[0172] In some embodiments, the data update module 14 may be specifically used to: in response to a scenario processing strategy including a data deletion strategy, obtain second disjoint order data that exists in the global order cache repository but does not exist in the order dataset; determine, from the second disjoint order data, first abnormal data whose scenario source field in the scenario source identifier includes a field consistent with the order query scenario of the order data request, perform a query verification operation on the first abnormal data, and update the first abnormal data in the global order cache repository based on the operation result of the query verification operation; determine, from the second disjoint order data, second abnormal data whose scenario source field in the scenario source identifier does not include a field consistent with the order query scenario of the order data request; if the latest protocol request time field of the second abnormal data is less than the request time of the order data request, delete the second abnormal data from the global order cache repository.

[0173] Assuming the intersecting order data includes the first order data in the order dataset and the second order data in the local order data, the data update module 14 performs a version comparison of the intersecting order data based on the data version field in the scenario source identifier, and performs a data update process based on the version comparison result. Specifically, this process can be as follows: determine whether the version field of the first order data in the order dataset is greater than the version field of the second order data in the local order data; if the version field of the first order data is greater than the version field of the second order data, update the second order data in the local order data according to the first order data, and synchronously write the scenario source field and the latest protocol request time field; if the version field in the order dataset is not greater than the version field of the second order data, keep the second order data in the local order data unchanged.

[0174] In some embodiments, the data update module 14 can also be used to: if the result of the query verification operation is that the order data is valid and exists, delete the scenario source field corresponding to the order query scenario in the scenario source identifier corresponding to the first abnormal data; if the result of the query verification operation is that the order data is invalid or does not exist, delete the corresponding first abnormal data from the global order cache repository.

[0175] In some embodiments, the order data management device 10 can also be used to: associate a preset state machine with each order data in the order dataset; the state machine's state identifiers include: initial state, valid state, local retention state, and pending deletion state; when the order dataset is received, it is uniformly marked as the initial state; based on the scenario processing strategy and each order data in the order dataset and the scenario source identifier of the order data, update the global order cache repository, switch the state identifiers in combination with the data judgment results, and perform data update, cache retention, or data deletion operations according to the state identifier matching and processing rules.

[0176] It should be understood that the modules or modules described in the order data management device 10 are related to the reference. Figure 3 The steps in the described method correspond accordingly. Therefore, the operations and features described above for the method also apply to the order data management device 10 and its included modules, and will not be repeated here. The order data management device 10 can be pre-implemented in the browser or other security applications of an electronic device, or it can be loaded into the browser or its security applications of an electronic device through download or other means. The corresponding modules in the order data management device 10 can cooperate with the modules in the electronic device to implement the solutions of the embodiments of this application.

[0177] The division of modules or units mentioned in the detailed description above is not mandatory. In fact, according to the embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0178] The following is for reference. Figure 22 , Figure 22 A schematic diagram of the structure of a computer system suitable for implementing the embodiments of this application is shown. like Figure 22As shown, the computer system 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 502 or programs loaded from storage section 508 into random access memory (RAM) 503. RAM 503 also stores various programs and data required for the system's operating instructions. CPU 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0179] The following components are connected to I / O interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to I / O interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 510 as needed so that computer programs read from it can be installed into storage section 508 as needed.

[0180] Specifically, according to embodiments of this application, the above reference flow Figure 3 The described process can be implemented as a computer software program. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program contains program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit (CPU) 501, it performs the functions defined in the system of this application.

[0181] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. Computer-readable storage media can include, but are not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0182] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operational instructions of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two connected blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified functions or operational instructions, or using a combination of dedicated hardware and computer instructions.

[0183] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be housed in a processor; for example, a processor can be described as including an acquisition module, a determination module, an update module, a matching module, and a recommendation module. The names of these units or modules do not necessarily limit the specific unit or module itself; for example, an acquisition module can also be described as acquiring virtual resource requirement information input by the user.

[0184] In another aspect, this application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiments, or may exist independently and not assembled into the electronic device. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the order data management method described in this application.

[0185] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. An order data management method, characterized in that, include: Send an order data request to the server and determine the corresponding order query scenario based on the request type; Receive the order dataset corresponding to the order data request, and configure a scenario source identifier for each order data in the order dataset according to the order query scenario; Determine the scenario processing strategy configured for the order query scenario; Based on the scenario processing strategy, the scenario source identifier of each order in the order dataset, and the scenario source identifier of the order data, the global order cache repository is updated.

2. The order data management method according to claim 1, characterized in that, The step of configuring a scenario source identifier for each order in the order dataset according to the order query scenario includes: Construct an order source information structure for each piece of order data, which serves as the source identifier for the scenario. The order source information structure includes: the data version field returned by the server, the scenario source field, and the latest protocol request time field.

3. The order data management method according to claim 2, characterized in that, The step of updating the global order cache repository based on the scenario processing strategy, each order data in the order dataset, and the scenario source identifier of the order data includes: In response to the scenario processing strategy, which includes a data update strategy, intersecting order data between the order data in the order dataset and the local order data in the global order cache repository is obtained. Based on the data version field in the scenario source identifier, the intersecting order data are compared for versions, and data updates are performed based on the version comparison results.

4. The order data management method according to claim 2, characterized in that, The step of updating the global order cache repository based on the scenario processing strategy, each order data in the order dataset, and the scenario source identifier of the order data includes: In response to the scenario processing strategy including the data addition strategy, the first disjoint order data that exists in the order dataset but does not exist in the global order cache repository is obtained; Insert the first disjoint order data into the global order cache repository.

5. The order data management method according to claim 2, characterized in that, The step of updating the global order cache repository based on the scenario processing strategy, each order data in the order dataset, and the scenario source identifier of the order data includes: In response to the scenario processing strategy including the data deletion strategy, the second disjoint order data that exists in the global order cache warehouse but does not exist in the order dataset is obtained; From the second disjoint order data, determine the first abnormal data whose scenario source field in the scenario source identifier is consistent with the order query scenario of the order data request, perform a query verification operation on the first abnormal data, and update the first abnormal data in the global order cache warehouse based on the operation result of the query verification operation; From the second disjoint order data, determine the second abnormal data in which the scene source field in the scene source identifier does not include a field consistent with the order query scene of the order data request; If the latest protocol request time field of the second abnormal data is less than the request time of the order data request, the second abnormal data is deleted from the global order cache repository.

6. The order data management method according to claim 3, characterized in that, The intersecting order data includes the first order data in the order dataset and the second order data in the local order data; The step of comparing the versions of the intersecting order data based on the data version field in the scenario source identifier, and performing data updates based on the version comparison results, includes: Determine whether the version field of the first order data in the order dataset is greater than the version field of the second order data in the local order data; If the version field of the first order data is greater than the version field of the second order data, the second order data in the local order data is overwritten and updated according to the first order data, and the scenario source field and the latest protocol request time field are synchronously written. If the version field in the order dataset is not greater than the version field in the second order data, the second order data in the local order data remains unchanged.

7. The order data management method according to claim 5, characterized in that, After updating the first abnormal data in the global order cache repository based on the operation result of the query verification operation, the following steps are also included: If the result of the query verification operation is that the order data is valid and exists, delete the scene source field corresponding to the order query scene in the scene source identifier corresponding to the first abnormal data. If the query and verification operation results in invalid or non-existent order data, the corresponding first abnormal data is deleted from the global order cache repository.

8. The order data management method according to any one of claims 1 to 7, characterized in that, After receiving the order dataset corresponding to the order data request, the method further includes: A preset state machine is associated with each order data in the order dataset; the state machine's state identifiers include: initial state, valid state, local retention state, and pending deletion state; When the order dataset is received, it is uniformly marked as the initial state; Based on the scenario processing strategy and the scenario source identifier of each order data in the order dataset, the global order cache repository is updated. The status identifier is switched according to the data judgment result, and data update, cache retention or data deletion operations are performed according to the status identifier matching and handling rules.

9. An order data management device, characterized in that, include: The order scenario determination module is used to send order data requests to the server and determine the corresponding order query scenario based on the request type. The dataset labeling module is used to receive the order dataset corresponding to the order data request and configure a scenario source identifier for each piece of order data in the order dataset according to the order query scenario. The strategy determination module is used to determine the scenario processing strategy configured for the order query scenario. The data update module is used to update the global order cache repository based on the scenario processing strategy, the individual order data in the order dataset, and the scenario source identifier of the order data.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the order data management method as described in any one of claims 1-8.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements the order data management method as described in any one of claims 1-8.

12. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the order data management method according to any one of claims 1-8.

Images