Parallel query data method, apparatus, device, medium and program product

Abstract

The application provides a parallel query data method, which can be applied to the technical field of data query in the field of financial technology. The method applied to the data processing end comprises the following steps: acquiring a main protocol set to be queried; determining N main protocol identifiers from the main protocol set to constitute the Mth batch, and allocating a corresponding logical index to each main protocol identifier in the Mth batch to generate Mth batch request data; sending the Mth batch request data to the server end; receiving a response data set sent from the server end, wherein the response data set comprises multiple groups of sub-protocol data corresponding to the N main protocol identifiers in the Mth batch respectively, and the response data set is obtained after the server end asynchronously and concurrently executes N query tasks after parsing the Mth batch request data; and reorganizing each group of sub-protocol data to a storage location associated with the main protocol identifier based on the logical index. The application also provides a parallel query data device, equipment, storage medium and program product.

Description

Technical Field

[0001] This application relates to the field of data query technology in the financial technology sector, specifically to a parallel data query method, apparatus, device, medium, and program product. Background Technology

[0002] In existing financial transaction systems, an "automatic query" mechanism is typically used to present a complete view of assets to clients. This mechanism generally employs a typical serial synchronous processing flow, where the system uses a deeply nested loop structure to sequentially initiate a main protocol query, traverse the main protocol to obtain a list of sub-protocols, and further query detailed asset information. Due to the limitation on the number of items returned by the interface at a time, each level usually requires paginated loop calls.

[0003] However, this processing logic suffers from several technical flaws in practical applications. First, there is a severe efficiency constraint between the CPU and the I / O system. Due to the strictly serial nature of the process, the CPU is forced into an idle waiting state after issuing an I / O request. This "request-wait-response" pause-based working mode leads to numerous intermittent pauses. Second, response latency accumulates linearly or even exponentially. As the number of products held by customers increases, the number of interactions multiplies, easily causing the front-end interface to load for extended periods. Third, high-frequency small data packet interactions result in significant resource waste. A large number of requests carrying only tiny amounts of valid data lead to huge overhead in the TCP / IP protocol stack encapsulation, frequently triggering hardware interrupts and context switches, significantly reducing system throughput. Finally, hardware resource utilization is low, and the phenomenon of "false busy" is severe. The CPU core computing power is idle during I / O waiting, and limited by the backend processing capacity, simply increasing concurrent threads can easily lead to database connection exhaustion or memory overflow, forming an inherent systemic performance bottleneck. Summary of the Invention

[0004] In view of the above problems, this application provides a method, apparatus, device, medium and program product for parallel data querying.

[0005] According to a first aspect of this application, a parallel data query method is provided, applied to a data processing end. The method includes: obtaining a set of main protocols to be queried, wherein the set of main protocols contains multiple main protocol identifiers to be queried; determining N main protocol identifiers from the set of main protocols to form an Mth batch, and assigning a corresponding logical index to each main protocol identifier in the Mth batch to generate Mth batch request data, wherein N and M are both positive integers greater than or equal to 1; sending the Mth batch request data to a server; receiving a response data set sent from the server, the response data set containing multiple sets of sub-protocol data corresponding to the N main protocol identifiers in the Mth batch, each set of sub-protocol data being configured with the same logical index as its corresponding main protocol identifier, wherein the response data set is obtained by the server parsing the Mth batch request data into N independent query tasks and then asynchronously and concurrently executing the N independent query tasks; and reorganizing each set of sub-protocol data into a storage location associated with its main protocol identifier based on the logical index.

[0006] According to an embodiment of this application, obtaining the set of main protocols to be queried includes: in response to a client query instruction, sending a client identifier query request to the server; receiving the set of main protocols sent by the server; wherein the set of main protocols is obtained by asynchronously and concurrently executing A main protocol query tasks within a single query loop, wherein the set of main protocols contains multiple main protocol identifiers corresponding to the client query instruction, and the A main protocol query tasks are established based on the parsing of the client query instruction, where A is a positive integer greater than 1.

[0007] According to an embodiment of this application, determining N main protocols from the main protocol set to form the Mth batch includes: sequentially extracting N unprocessed main protocol identifiers from the head of the main protocol set, wherein the value of N is determined based on the idle capacity of the current concurrent processing window.

[0008] According to an embodiment of this application, the step of reorganizing each group of sub-protocol data to a storage location associated with its main protocol identifier based on the logical index includes: determining a target storage location based on each group of sub-protocol data in the response data set and the logical index carried by each group of sub-protocol data; wherein the target storage location is bound to the main protocol identifier corresponding to the logical index; and storing each group of sub-protocol data in the target storage location.

[0009] According to an embodiment of this application, the response data set further includes a completion identifier associated with the query status of each of the main protocol identifiers; after reorganizing each group of sub-protocol data to the storage location associated with its main protocol identifier, the method further includes: in response to the fact that all N main protocol identifiers in the Mth batch are associated with a completion identifier indicating the end of the query, removing the N main protocol identifiers from the main protocol set; determining whether there are any remaining main protocol identifiers to be queried in the main protocol set; if so, extracting N new main protocol identifiers from the main protocol set to form the M+1th batch, and reallocating a corresponding logical index for each main protocol identifier in the M+1th batch to generate the M+1th batch request data; and sending the M+1th batch request data to the server.

[0010] According to an embodiment of this application, the response data set further includes incomplete identifiers associated with the query status of each of the main protocol identifiers; after reorganizing each group of sub-protocol data to the storage location associated with its main protocol identifier, the method further includes: in response to the existence of P main protocol identifiers associated with incomplete identifiers in the Mth batch, retaining the P main protocol identifiers to form a first part of main protocol identifiers; in response to the existence of NP main protocol identifiers associated with completion identifiers representing the end of the query in the Mth batch, removing the NP main protocol identifiers from the main protocol set; determining whether there are any remaining main protocol identifiers to be queried in the main protocol set; if so, extracting N new main protocol identifiers from the main protocol set to form a second part of main protocol identifiers; combining the first part of main protocol identifiers and the second part of main protocol identifiers to form the M+1th batch, and reallocating a corresponding logical index for each main protocol identifier in the second part of main protocol identifiers to generate the M+1th batch of request data; and sending the M+1th batch of request data to the server.

[0011] According to a second aspect of this application, a parallel data query method is provided, applied to a server. The method includes: receiving an Mth batch of request data sent from a data processing terminal, wherein the Mth batch of request data is obtained by assigning a corresponding logical index to each master protocol identifier in the Mth batch, the Mth batch consisting of N master protocol identifiers extracted from a master protocol set, the master protocol set containing multiple master protocol identifiers to be queried, where N is a positive integer greater than or equal to 1, and M is a positive integer greater than or equal to 1; parsing the Mth batch of request data into N independent query tasks corresponding to the N master protocol identifiers respectively, wherein the N query tasks are sub-protocol query processing tasks for their corresponding master protocol identifiers; asynchronously and concurrently executing the N query tasks to obtain multiple sets of sub-protocol data, wherein each set of sub-protocol data is configured with a logical index consistent with its corresponding master protocol identifier; generating a response data set according to the organization of the multiple sets of sub-protocol data and their logical indexes, and sending the response data set to the data processing terminal.

[0012] According to an embodiment of this application, the asynchronous concurrent execution of the N query tasks to obtain multiple sets of sub-protocol data includes: distributing the N query tasks to a preset thread pool, and using worker threads in the thread pool to initiate parallel sub-protocol database query processing for each of the main protocol identifiers; responding to the sub-protocol result returned by any of the worker threads, and injecting the logical index corresponding to the main protocol identifier into the sub-protocol result to generate the sub-protocol data.

[0013] According to an embodiment of this application, generating the sub-protocol data further includes: determining a query status identifier corresponding to each query task based on the sub-protocol query processing progress of each query task; associating the query status identifier with the corresponding sub-protocol result and its logical index to generate the sub-protocol data; wherein, in response to the number of unqueried sub-protocols under the main protocol identifier corresponding to each query task exceeding the single transmission threshold of the thread pool, the query status identifier is determined to be an incomplete identifier; in response to the number of unqueried sub-protocols under the main protocol identifier corresponding to each query task not exceeding the single transmission threshold of the thread pool, the query status identifier is determined to be a complete identifier.

[0014] A third aspect of this application provides a parallel data query apparatus applied to a data processing end. The apparatus includes: a first acquisition module configured to acquire a set of main protocols to be queried, wherein the set of main protocols contains multiple main protocol identifiers to be queried; a first processing module configured to determine N main protocol identifiers from the set of main protocols to form an Mth batch, and assign a corresponding logical index to each main protocol identifier in the Mth batch to generate the Mth batch of request data, wherein N and M are both positive integers greater than or equal to 1; and a first transmission module configured to send the Mth batch of request data to a server. A receiving module is configured to receive a set of response data sent from the server. The set of response data includes multiple sets of sub-protocol data corresponding to N main protocol identifiers in the Mth batch. Each set of sub-protocol data is configured with a logical index that is the same as its corresponding main protocol identifier. The set of response data is obtained by the server parsing the Mth batch of request data into N independent query tasks and then executing the N independent query tasks asynchronously and concurrently. A second processing module is configured to reassemble each set of sub-protocol data into a storage location associated with its main protocol identifier based on the logical index.

[0015] A fourth aspect of this application provides a parallel query data apparatus applied to a server. The apparatus includes: a second receiving module configured to receive an Mth batch of request data sent from a data processing terminal, wherein the Mth batch of request data is obtained by assigning a corresponding logical index to each master protocol identifier in the Mth batch, the Mth batch consisting of N master protocol identifiers extracted from a master protocol set, the master protocol set containing multiple master protocol identifiers to be queried, where N is a positive integer greater than or equal to 1, and M is a positive integer greater than or equal to 1; and a third processing module configured to process the... The Mth batch of request data is parsed into N independent query tasks corresponding to the N main protocol identifiers, wherein each of the N query tasks is a sub-protocol query processing task for its corresponding main protocol identifier; the fourth processing module is configured to execute the N query tasks asynchronously and concurrently to obtain multiple sets of sub-protocol data, wherein each set of sub-protocol data is configured with a logical index consistent with its corresponding main protocol identifier; the second transmission module is configured to generate a response data set based on the organization and logical index of the multiple sets of sub-protocol data, and send the response data set to the data processing terminal.

[0016] A fifth aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0017] A sixth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0018] A seventh aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0019] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0020] Figure 1 The illustration shows an application scenario diagram of the parallel data query method, apparatus, device, medium, and program product according to embodiments of this application;

[0021] Figure 2 A flowchart illustrating a parallel data query method applied to a data processing terminal according to an embodiment of this application is shown schematically;

[0022] Figure 3 The flowchart illustrating step S100 of a parallel data query method applied to a data processing terminal according to an embodiment of this application is shown in the schematic diagram.

[0023] Figure 4 The flowchart illustrating step S500 of a parallel data query method applied to a data processing terminal according to an embodiment of this application is shown in the schematic diagram.

[0024] Figure 5 A first supplementary flowchart illustrating a parallel data query method applied to a data processing terminal according to an embodiment of this application is shown schematically.

[0025] Figure 6 A second supplementary flowchart illustrating a parallel data query method applied to a data processing terminal according to an embodiment of this application is shown schematically;

[0026] Figure 7 A flowchart illustrating a parallel data query method applied to a server according to an embodiment of this application is shown schematically.

[0027] Figure 8 The flowchart illustrating step S800 of a parallel data query method applied to a server according to an embodiment of this application is shown in the schematic diagram.

[0028] Figure 9 The flowchart illustrating step S820 of a parallel data query method applied to a server according to an embodiment of this application is shown in the schematic diagram.

[0029] Figure 10 This schematically illustrates a structural block diagram of a parallel data query device applied to a data processing terminal according to an embodiment of this application;

[0030] Figure 11 This schematically illustrates a structural block diagram of a parallel data query device applied to a server according to an embodiment of this application;

[0031] as well as

[0032] Figure 12 A block diagram schematically illustrates an electronic device suitable for implementing a parallel data query method according to an embodiment of this application. Detailed Implementation

[0033] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0034] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0035] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0036] When using expressions such as "at least one of A, B, and C," the meaning should generally be interpreted according to the understanding of someone skilled in the art. For example, "a system having at least one of A, B, and C" should include, but is not limited to, systems having A alone, having B alone, having C alone, having A and B, having A and C, having B and C, and / or having A, B, and C. Similarly, when using expressions such as "at least one of A, B, or C," the meaning should generally be interpreted according to the understanding of someone skilled in the art. For example, "a system having at least one of A, B, or C" should include, but is not limited to, systems having A alone, having B alone, having C alone, having A and B, having A and C, having B and C, and / or having A, B, and C.

[0037] In the financial service system of modern commercial banks, real-time querying and display of customer asset data is one of the core business scenarios. To accurately understand the technical solution of this application, the relevant core data objects and processing logic are first defined and explained.

[0038] Account: An account is a data entity set up according to accounting subjects in the core business system of a bank. It is used to classify and account for the economic content contained in the accounting subjects in detail. It is a specialized data structure that reflects the specific increases and decreases in the content of accounting elements and their results, and is the basic carrier of fund flows.

[0039] Products: Products are collections of business logic based on account attributes, used to differentiate and define the operational permissions and business rules for different accounts. In banking systems, common account types (such as current accounts, time deposits, and loans) are further subdivided into various specific products based on different attributes, such as current deposits, current savings accounts, current account passbooks, and time deposits. Products define the account's behavioral patterns and interest calculation rules.

[0040] Assets: Assets are a key quantitative indicator for measuring a client's risk tolerance and investment potential. The data comes from the real-time status of various accounts under the client's name. Specific forms of assets include, but are not limited to, deposit balances, fund unit balances, market value of wealth management products, and loanable amounts, and serve as the basic data support for client profiling and financial service recommendations.

[0041] Master Agreement and Sub-Agreements: Agreements are logical structures used to manage account data and their hierarchical relationships. The system uses the "Master Agreement" to manage the top-level relationship between customer entities and specific financial products. Based on the multi-dimensional attributes of the products (such as different currencies, different loan terms, and different terms), each Master Agreement can have multiple "Sub-Agreements" attached for fine-grained management. For example, a fixed-term deposit certificate master agreement may contain sub-agreements for multiple currencies, or multiple fixed-term deposit certificate sub-agreements with different terms.

[0042] Master Agreement Query: This refers to the process of retrieving a list of all signed master agreements under a customer's name from a database or backend service based on the customer's unique identifier (such as customer number). This process aims to obtain an overview of the products held by the customer.

[0043] Sub-protocol query: This refers to the process of retrieving detailed information (including currency, real-time balance, account opening time, account opening location, etc.) of all sub-protocols under a specific main protocol number. This process requires in-depth traversal of the specific data nodes under the main protocol and is a key step in obtaining asset values.

[0044] In existing financial transaction systems, an "automatic query" mechanism is typically used to present a complete asset view to clients or account managers. The execution logic of this mechanism is a typical serial synchronous processing flow: First, the system initiates a main protocol query to obtain a list of main protocols under the client's name. Since backend service interfaces usually have a limit on the number of records returned at one time (e.g., to prevent excessively large messages, a maximum of 10 main protocols are returned at a time), when the number of main protocols under the client's name exceeds this limit, the system must perform paginated loop calls until all main protocols are obtained. Second, after obtaining the main protocol list, the system must iterate through each main protocol in the list sequentially. For each main protocol, the system again initiates a sub-protocol query request to obtain a list of sub-protocols under that main protocol. Similarly, if the number of sub-protocols is large, paginated loop calls are also required. Finally, for each sub-protocol retrieved, the system needs to further obtain its detailed balance or asset information and perform processing such as exchange rate conversion. The entire process is a deeply nested loop structure: the system first iterates through the main query to retrieve all main protocols, and then within the main protocol loop, it sequentially performs sub-queries until all sub-protocols under all main protocols have been processed. During this process, a severe efficiency constraint exists between the computer's central processing unit (CPU) and the input / output (I / O) system: because the entire process is strictly serial, whenever the CPU issues a network query instruction (I / O request), due to the time required for data transmission and database retrieval, the CPU cannot execute subsequent computational tasks while waiting for the data to return, and is forced into an idle waiting state. Only after the data packet for the current account is completely returned and received can the CPU be awakened to process the data and initiate a query for the next account. This "request-wait-response-request" pause-based working mode forcibly slows down the CPU's high-speed computing power due to slow network I / O operations, resulting in numerous intermittent pauses throughout the query process.

[0045] Based on the above query logic, existing technologies have revealed multiple insurmountable technical defects in practical applications, specifically in the following aspects:

[0046] First, the response latency caused by serial processing accumulates linearly or even exponentially, severely degrading the user experience. This query mechanism, based on multi-layered nested loops, does not simply sum up the time of each operation; rather, it's a product of the individual operations. As the number of product types (main protocol) and specific documents (sub-protocols) held by the customer increases, the number of interactions multiplies. Even minor network fluctuations or congestion in the backend database while processing a specific sub-protocol can amplify this latency infinitely across all subsequent query steps. For high-value customers with abundant assets, querying a complete asset view can take several seconds or even longer, causing the front-end interface to remain "frozen" or in a loading state for extended periods, significantly impairing service smoothness.

[0047] Secondly, the high-frequency interaction of small data packets leads to a significant waste of network resources and system bus capacity. In the aforementioned process, each pagination query targeting the main protocol or a sub-protocol requires initiating an independent network connection. However, the effective business data carried in a single request (such as just a protocol number) is very small, but to complete this transmission, the computer system must construct complete network transport protocol header and trailer information for each tiny request. This also means that each tiny data interaction (which may only contain a protocol number) needs to undergo a complete TCP / IP protocol stack encapsulation and decapsulation process, causing the amount of header information to often exceed the effective payload. This results in network bandwidth being filled with a large amount of protocol overhead data rather than effective business data. At the same time, when these fragmented requests arrive at the server, they frequently trigger hardware interrupts, forcing the server to constantly switch contexts between handling network interrupts and processing business logic, consuming a large amount of system resources. This not only greatly wastes network bandwidth resources but also triggers server network card interrupt storms, significantly reducing system throughput.

[0048] Then, the "false busyness" of hardware resources limits the overall system throughput. Because the CPU spends most of its time in an "idling" state waiting for I / O returns, although query tasks appear to be running macroscopically, the CPU's core computing resources are not actually being fully utilized. This mechanism means that when facing high concurrency requests, although the CPU load may not have reached its peak, the system is unable to respond to new requests because threads are blocked in long I / O wait queues. This idle hardware computing power and wasted resources caused by serial logic cannot be solved simply by increasing server hardware configuration; it is an inherent, systemic performance bottleneck in the existing technical architecture.

[0049] Finally, the system suffers from low resource utilization that is difficult to resolve through simple capacity expansion. Limited by the serial synchronous execution of I / O, the CPU remains idle for extended periods during I / O wait times, failing to effectively utilize the parallel computing capabilities of multi-core processors. While increasing the number of threads on the application server can attempt to alleviate this, blindly adding concurrent threads can lead to database connection pool exhaustion or memory overflow, especially given the limited processing capacity of the backend database. Furthermore, limitations in the existing interface design prevent batch data aggregation without altering the underlying communication structure. Therefore, how to break free from the constraints of serial processing within the existing system architecture and achieve efficient collaboration between hardware and software resources and rapid asset information retrieval is a pressing challenge for those skilled in the art.

[0050] The parallel data query method, apparatus, device, medium, and program products of this application can be used in the field of data query technology in the financial technology field, or in other fields. The application fields of the parallel data query method, apparatus, device, medium, and program products of this application are not limited.

[0051] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, application, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0052] Figure 1 The illustration shows an application scenario diagram of the parallel data query method, apparatus, device, medium, and program product according to embodiments of this application.

[0053] like Figure 1 As shown, application scenario 100 according to this embodiment may include a parallel data query method, apparatus, device, medium, and program product. Network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0054] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as financial service applications, web browser applications, search applications, email clients, social media platform software, etc. (for example only).

[0055] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0056] Server 105 can be a server that provides various services, such as a backend management server that supports information browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0057] It should be noted that, in the first aspect, the parallel data query method provided in this application embodiment can be executed by server 105; in the second aspect, the parallel data query method provided in this application embodiment can be executed by first terminal device 101, second terminal device 102, or third terminal device 103. Correspondingly, in the third aspect, the parallel data query device provided in this application embodiment can be located in server 105; in the fourth aspect, the parallel data query device provided in this application embodiment can be located in first terminal device 101, second terminal device 102, or third terminal device 103. The parallel data query method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with first terminal device 101, second terminal device 102, third terminal device 103, and / or server 105. Correspondingly, the parallel data query device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with first terminal device 101, second terminal device 102, third terminal device 103, and / or server 105.

[0058] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0059] The following will be based on Figure 1 The described scene, through Figures 2-9 The parallel data query method of the application embodiments is described in detail.

[0060] like Figure 2 As shown, in the first aspect of this application, a parallel data query method is provided, applied to a data processing end, including operations S100 to S500.

[0061] Specifically, in operation S100, the main protocol set to be queried is obtained, wherein the main protocol set contains multiple main protocol identifiers to be queried. In some specific embodiments, the data processing end can obtain the main protocol set to be queried in various ways to adapt to different business triggering scenarios. For example, method one can be real-time interactive triggering: when a bank customer manager enters the customer's unique number (such as ID card number or customer internal code) in the interface of the front-end business system and clicks the "Asset Panorama Query" button, the data processing end responds to the triggering operation, initializes an empty pending container, and prepares to receive all the signed account information under the customer's name retrieved from the server. This signed account information constitutes the main protocol set. Method two can be batch job triggering: in the scenario where the system performs day-end settlement or generates monthly asset reports, the data processing end reads a batch of customer lists to be updated from the local cache or database snapshot according to the preset scheduled task, and generates a corresponding main protocol set to be queried for each customer.

[0062] In operation S100, the master protocol set is structurally represented as a global queue or list to be processed. This set does not contain specific asset values ​​(such as balances), but rather stores several master protocol identifiers to be queried. These master protocol identifiers are index keys used to uniquely distinguish the contractual relationships of different financial products under a customer's name. For example, a master protocol identifier could be the main account number of a debit card, the passbook account number of a fixed-term deposit account, or the contract number of a personal housing loan. Logically, the master protocol set represents the summary of all the top-level business relationships that the customer has signed within the banking system, and the master protocol identifiers are the basic data source for subsequent in-depth asset queries. At this time, each master protocol in the master protocol set is in a "pending retrieval" or "not expanded" state, and has not yet been associated with specific sub-account (sub-protocol) data.

[0063] like Figure 3 As shown, in some exemplary embodiments, obtaining the set of main protocols to be queried includes: operations S110 to S120.

[0064] Specifically, in operation S110, in response to a customer query instruction, a customer identification query request is sent to the server. In some specific embodiments, operation S110 involves the initiation of a main query, aiming to establish a mapping relationship between customer identity and business agreements. Specifically, in actual banking business scenarios, a customer query instruction typically corresponds to the business need of "obtaining a complete picture of customer assets" or "establishing a customer view." When a teller or automated system issues this instruction, it is actually requesting the system to answer the question, "What types of products does this customer own?" After receiving the instruction, the data processing end extracts the key information carried in the instruction and encapsulates it into a customer identification query request. This request is a lightweight network message; its purpose is not to query a specific amount, but to request the server to retrieve all the customer's contract records in the core system. This request is associated with the customer's identity credential information and the scope and permissions of the query (e.g., whether to query deposit agreements, or simultaneously query loan, wealth management, and fund agreements). The data processing end sends this request to the server through a secure network link to trigger the server's full protocol retrieval process, thereby providing the original data basis for constructing the aforementioned main protocol set.

[0065] Specifically, in operation S120, the server receives the main protocol set sent by the server. This main protocol set is obtained by asynchronously and concurrently executing A main protocol query tasks within a single query loop. The main protocol set contains multiple main protocol identifiers corresponding to the customer's query instruction. The A main protocol query tasks are established based on the parsing of the customer's query instruction, where A is a positive integer greater than 1. In some specific embodiments, the server employs a parallelization strategy to accelerate the construction of the main protocol set when responding to customer identifier query requests. Since a customer may have contractual relationships with multiple different business lines (such as savings systems, credit systems, wealth management systems, etc.), the time consumption would be unacceptable if a traditional serial scanning method were used. Therefore, the server splits the retrieval actions for different business lines into A independent main protocol query tasks.

[0066] In one specific embodiment, the server is configured with an asynchronous thread pool, which is set to accommodate a maximum of N (e.g., 10) concurrent threads within a single parallel processing window. Specific query methods include Embodiment 1 and Embodiment 2.

[0067] In Implementation Example 1, the number of tasks exceeds the thread pool capacity (A>N), requiring execution in cycles. For example, based on a customer's contract attributes, the server parses out A=15 main protocol query tasks (e.g., querying 15 different underlying business tables or subsystems such as current accounts, fixed deposits, government bonds, wealth management products, funds, precious metals, mortgages, and car loans). In this case, the server cannot complete all tasks in one cycle. Therefore, the server executes two query cycles: First query cycle: The server schedules the first 10 tasks from the 15 tasks (i.e., the thread pool's upper limit N), distributing them to 10 worker threads in the thread pool. These 10 tasks are executed asynchronously and concurrently, without blocking each other; the CPU utilizes its multi-core advantage to process these 10 I / O requests simultaneously. Second query cycle: After the tasks from the first cycle return results or release resources, the server schedules the remaining 5 tasks into the thread pool for execution. These 5 tasks are also executed concurrently. Finally, the server aggregates all query results returned from these two cycles, removes duplicates, and reorganizes them to generate a complete main protocol set, which is then sent to the data processing end. The term "single query loop" here refers to the fact that tasks are performed in parallel within each independent scheduling cycle, rather than waiting sequentially.

[0068] In Example 2, the number of tasks does not exceed the thread pool capacity (A≤N), and is completed in a single cycle. For example, if a customer's business is relatively simple, the server parses out that only A=6 main protocol query tasks need to be executed. At this time, the number of A (6) is less than the thread pool's concurrency limit (10). The server does not need to split the cycle and directly distributes these 6 tasks to the thread pool simultaneously within one query cycle. These 6 tasks start in parallel within the same time period and independently retrieve the main protocol identifier from the corresponding business system. After all tasks (or meet specific return conditions) are completed, the server immediately returns the summarized main protocol set to the data processing end.

[0069] Through the aforementioned concurrent query mechanism, the server can collect a complete list of client master protocols across multiple business systems in a very short time, greatly shortening the waiting time of traditional serial scanning and ensuring that the data processing end can quickly obtain the master protocol identifier for subsequent deep queries.

[0070] Specifically, in operation S200, N master protocol identifiers are determined from the master protocol set to form the Mth batch, and a corresponding logical index is assigned to each master protocol identifier in the Mth batch to generate the Mth batch of request data, where N and M are both positive integers greater than or equal to 1. In some specific embodiments, operation S200 transforms the originally discrete, single-account-based serial query requests into batch-based vectorized requests to adapt to the data throughput requirements of high-concurrency business scenarios in banks. Specifically, after the data processing end obtains the master protocol set containing all contractual relationships under the customer's name, it does not immediately initiate a query for each master protocol, but first initializes a batch builder. For example, the customer has a total of 25 master protocol identifiers in the bank, including current account, fixed deposit account, personal loan account, wealth management account, fund account, and precious metal trading account. The system does not generate 25 independent network requests, but instead treats these master protocol identifiers as elements to be processed according to a preset aggregation strategy. When building the Mth batch (e.g., the 1st batch), the system extracts a set (e.g., 10) of master protocol identifiers from these 25 identifiers, thereby reducing the frequency of handshake interactions.

[0071] In some specific embodiments, the allocation of logical indexes and the generation of batch request data provide technical means for subsequent asynchronous out-of-order reassembly. Once the system determines the N main protocol identifiers for the Mth batch, it dynamically assigns a logical index to each main protocol identifier within that batch. This logical index is typically an integer sequence that increments from 0 (e.g., 0, 1, ..., N-1), and it is unique within the lifecycle of the current batch. For example, the system assigns index 0 to "Current Account A," index 1 to "Regular Account B," and so on. Next, the system generates the Mth batch of request data, which is logically represented as an aggregate array containing N objects. Each object carries not only the main protocol identifier used for server-side retrieval but also a logical index used for backtracking by the data processing end. This allows the data processing end to accurately map the sub-protocol query results back to the corresponding main protocol slot based on this "logical index" even when the server-side returns results out of order due to multi-threaded concurrent processing, without relying on time-consuming sorting algorithms or complex comparison logic.

[0072] In some specific implementations, the parameters N and M are not fixed but dynamically adjusted variables based on system load and task progress. M represents the current batch round number, which increases as the query task progresses (M=1,2,3...) until all master protocol identifiers in the master protocol set have been processed. N represents the concurrency granularity of the current batch (i.e., how many items are queried in a batch), and its value directly affects the utilization of hardware resources. During system initialization, N is usually set to a value that matches the optimal thread pool size or maximum concurrency threshold of the backend server (e.g., if the preset maximum concurrency is 10, then N is initially set to 10). However, in actual operation, the value of N may change according to real-time conditions. For example, in the first batch of queries, the system processes at full load with N=10; while in the last batch of queries, if only 3 master protocol identifiers remain unprocessed, then N is automatically adjusted to 3, and the system generates a request packet containing only 3 elements, avoiding invalid empty polling and achieving fine-grained adaptation of computing resources.

[0073] In some exemplary embodiments, determining N master protocols from the master protocol set to form the Mth batch includes: sequentially extracting N unprocessed master protocol identifiers from the head of the master protocol set, wherein the value of N is determined based on the idle capacity of the current concurrent processing window. In some specific embodiments, when the system is preparing to construct the Mth batch request, it reads the current position of the pointer and, starting from that position, sequentially extracts N master protocol identifiers in the "unprocessed" state. After extraction, the pointer moves forward N positions, marking that these N master protocols have entered the "processing" state.

[0074] In some specific embodiments, the value of N is determined based on the idle capacity of the current concurrent processing window. In actual high-concurrency complex scenarios, there are several typical dynamic adjustment scenarios: Embodiment 1, Embodiment 2 and Embodiment 3.

[0075] In Implementation Example 1, the concurrent window is completely idle. For example, the maximum concurrent processing window capacity agreed upon by the data processing end and the server end is 10 (i.e., allowing 10 subquery tasks corresponding to the main protocol to run simultaneously). At the beginning of the first batch (M=1), since there are no tasks being executed, the window's idle capacity is 10. At this time, the system sets N to 10 and directly extracts all 10 main protocol identifiers from the header of the main protocol set to fill the current concurrent window, thereby maximizing the utilization of the server's parallel computing capabilities.

[0076] In Example 2, there are unfinished historical tasks. For example, in the Mth batch of queries, one main protocol has an extremely large number of sub-protocols, causing the server to be unable to return all the data of that main protocol in a single response. When building the next batch (M+1th batch), to ensure data continuity, this unfinished main protocol must be retained in the current concurrent window for subsequent pagination queries. At this time, one of the original 10 slots in the concurrent window is occupied by this "old task," and the actual available free capacity becomes 9. Therefore, N is dynamically determined to be 9, and only 9 new main protocol identifiers are extracted from the main protocol set to fill the gap. This mechanism constitutes sliding window flow control, effectively preventing memory overflow or response timeouts caused by blindly introducing new tasks when the data volume of individual accounts is too large.

[0077] In Example 3, the concurrent window is occupied by an external process. For example, the data processing end may be running multiple background tasks simultaneously. Suppose the system's global concurrency limit policy detects that other high-priority processes are occupying some network or computing resources, causing the number of available threads currently allocated to the asset query function to be temporarily reduced. For example, of the original quota of 10 threads, 4 are occupied by other urgent transactions. At this time, the idle capacity of the concurrent processing window for the asset query task is compressed to 6, and N is dynamically adjusted to 6.

[0078] Specifically, in operation S300, the Mth batch of request data is sent to the server. In some specific embodiments, the process of sending the Mth batch of request data to the server employs a one-time encapsulation and transmission technique to solve the network congestion problem caused by frequent small packet interactions in existing technologies. The data processing end serializes an aggregate array containing N main protocol identifiers and their corresponding logical indices into a compact binary stream or a standardized JSON message body. Subsequently, the data processing end calls the underlying network communication interface to establish a connection to the server. In this process, regardless of whether N is 1 or 10, the system only triggers one network sending operation at the physical layer, generating a TCP / IP data packet (or a set of consecutive data frames). This means that the overhead of triggering N hardware interrupts and performing N protocol stack encapsulation / decapsulation in existing technologies is compressed to one in this application. After the data packet is sent, the data processing end does not block and wait, but immediately releases the sending thread to handle other UI interactions until it receives an asynchronous callback notification from the server. This sending mechanism greatly reduces network link congestion and significantly improves the effective bandwidth utilization rate.

[0079] Specifically, in operation S400, a response data set sent from the server is received. This response data set contains multiple sets of sub-protocol data corresponding to the N main protocol identifiers in the Mth batch. Each set of sub-protocol data is configured with a logical index identical to its corresponding main protocol identifier. The response data set is obtained by the server parsing the Mth batch of request data into N independent query tasks and then asynchronously and concurrently executing these N independent query tasks. In some specific embodiments, the response data set received by the data processing end is the product of parallel processing by the server. Specifically, this set contains multiple sets of sub-protocol data corresponding one-to-one with the N main protocol identifiers in the Mth batch of requests. It should be noted that because the server uses an asynchronous discrete scheduling mechanism, these N query tasks are executed concurrently. Therefore, the order of these data in the response set may not be consistent with the order in which they were requested, but each set of data strictly carries a logical index matching its corresponding main protocol identifier. This data set embodies the technical characteristics of "vectorized input requests" and "discrete aggregation of output results."

[0080] Specifically, in operation S500, based on the logical index, the data of each group of sub-protocols is reassembled into the storage location associated with its main protocol identifier. In some specific embodiments, data reassembly achieves "unordered input, ordered display" on the client side. Due to the uncertainty of network transmission and the difference in processing response time of different business systems on the server side, the sub-protocol data in the response data set often arrives out of order. For example, the main protocol identifier at the top of the list may be processed more slowly due to the large amount of data, while the main protocol identifier at the bottom of the list may be processed more quickly. If the data processing end simply fills in the data according to the order in which it is received, it will lead to incorrect placement of the customer's asset information (for example, the data of a fixed deposit is incorrectly attached to a current account). To solve this problem, the logical index allocated in the aforementioned steps is used as the sole anchor point for data repositioning. Regardless of when or in what order the data packets arrive, the system restores the discrete sub-protocol data to its corresponding main protocol framework based solely on this index value, thereby achieving consistent data reassembly.

[0081] like Figure 4 As shown, in some exemplary embodiments, the step of reorganizing each group of sub-protocol data to a storage location associated with its main protocol identifier based on the logical index includes: operations S510 to S520.

[0082] Specifically, in operation S510, the target storage location is determined based on each group of sub-protocol data in the response data set and the logical index carried by each group of sub-protocol data; wherein, the target storage location is bound to the main protocol identifier corresponding to the logical index. In some specific embodiments, the data processing end pre-constructs a linear result list with N storage units. When the system parses the response data set, it directly reads the logical index value (e.g., value K) carried in a certain group of sub-protocol data. The system does not need to scan the list from the beginning, but directly locates the Kth storage unit in the linear result list based on the value K. In other specific embodiments, the system maintains an association mapping table between the main protocol identifier and the storage area. When data is received, the system extracts the logical index and uses the index to look up the corresponding main protocol identifier. Subsequently, the system uses the main protocol identifier as a lookup credential to quickly locate the corresponding storage area in the association mapping table. Through any of the above embodiments, the system can ensure that a strict and tamper-proof binding relationship is established between the "target storage location" and the "main protocol identifier corresponding to the logical index", thus ensuring the accuracy of data writing in a multi-task concurrent environment.

[0083] Specifically, in operation S520, the sub-protocol data of each group is stored in the target storage location. In some specific embodiments, the operation of storing sub-protocol data in the target storage location not only includes writing the data but also involves the synchronous update of the query status to drive the dynamic rendering of the front-end interface. Specifically, after the system writes the sub-protocol list (such as specific currency, amount, interest rate, etc.) to the determined storage location, it will further check the status identifier carried in the response data: if the identifier shows that the query is complete, the system sets the processing status corresponding to the main protocol to "ready," and the front-end interface can be refreshed immediately to show the user the complete asset data of the bank; if the identifier shows that it is incomplete (indicating that there is more sub-protocol data under the main protocol to be queried), the system will append the data received this time to the existing data in the storage location and keep the status of the main protocol "loading." This mechanism supports a "streaming loading" user experience, that is, users do not need to wait for all accounts to be queried, but rather display one after another, and display one page after another, greatly alleviating the anxiety of waiting.

[0084] like Figure 5 As shown, in some exemplary embodiments, the response data set further includes a completion identifier associated with the query status of each of the main protocol identifiers; after reassembling each group of sub-protocol data to the storage location associated with its main protocol identifier, the method further includes: operations S100A to S400A.

[0085] Specifically, in operation S100A, in response to the fact that all N main protocol identifiers in the Mth batch are associated with a completion identifier indicating the end of the query, the N main protocol identifiers are removed from the main protocol set. In some specific embodiments, when the data processing end receives the response data set of the Mth batch, a status verification process is initiated. The system iterates through and checks the "completion identifier" carried by each sub-protocol data packet in the response set. If the system confirms that the return results corresponding to the N main protocol identifiers (e.g., 10) sent in this batch are all configured with completion identifiers, this indicates that the server has completed querying all sub-protocol data under these N main protocols in one go, and there is no remaining pagination data. At this time, the data processing end determines that the current batch task has ended. Subsequently, the system performs a queue removal operation: in the locally maintained main protocol set, the N main protocol identifiers currently at the head are located and permanently deleted from the set, or their status is updated from "processing" to "archived / completed". This action is logically equivalent to sliding the processing window backward by N units, freeing up N idle concurrent slots to prepare for accepting new query tasks.

[0086] Specifically, in operation S200A, it determines whether there are any remaining master protocol identifiers to be queried in the master protocol set. In some specific embodiments, after performing the above removal operation, the system immediately queries the data structure attributes of the current master protocol set, specifically checking the remaining quantity in the master protocol set or determining whether the queue pointer points to null. If the detection result shows that there are still master protocol identifiers in the set that have not been marked as "completed", it means that there are many types of assets under the customer's name, and not all of them have been traversed. The system will generate a "continue execution" control signal to trigger the subsequent batch construction process. Conversely, if the set is empty, it means that all of the customer's signed agreements have been retrieved and reorganized. The system will trigger a "full process end" signal, close the network connection, send a "all data loaded" notification to the front-end interface, and hide the loading progress bar.

[0087] Specifically, in operation S300A, if so, N new master protocol identifiers are extracted from the master protocol set to form the (M+1)th batch, and a corresponding logical index is reassigned to each master protocol identifier in the (M+1)th batch to generate the (M+1)th batch request data. In some specific embodiments, the system first calculates the available idle capacity of the current concurrent processing window. Since all N tasks in the Mth batch have been completed and removed in operation S100A, theoretically N concurrent slots are released. At this time, there are different specific implementations of the mechanism for determining the number of N in Embodiment 1, Embodiment 2, and Embodiment 3.

[0088] In Example 1, for example, the system sets the maximum concurrent window size to 10. In the Mth batch, N is 10. When all 10 tasks are completed, the window is completely cleared, and there are still more than 10 master protocol identifiers remaining to be queried in the master protocol set. At this time, the system determines that there is no need to adjust the concurrency strategy and continues to set N to 10 for the (M+1)th batch. The system extracts 10 new master protocol identifiers from the head of the remaining set. Subsequently, the system performs an index reset operation: reallocates logical indexes for these 10 new master protocol identifiers. Note that the logical indexes here are relative to the (M+1)th batch. Reusing the index slots of the previous batch ensures that the index values ​​are always controlled within a small integer range, facilitating memory mapping.

[0089] In Example 2, the system's available resources may fluctuate in real time. For example, when executing batch M, N is set to 10, but when preparing to execute batch M+1, the operating system's resource monitoring module detects that the current device's memory usage is too high, or the user has switched to power-saving mode, automatically triggering a degradation protection strategy that temporarily reduces the maximum allowed concurrency to 5. In this case, although batch M releases 10 slots, N for batch M+1 will be limited to 5. The system only extracts 5 new master protocol identifiers from the set and assigns them indices 0 to 4. This dynamic adjustment mechanism ensures that the asset query function does not affect the overall stability of the terminal due to excessive resource consumption.

[0090] In Example 3, due to the limited amount of remaining data, the value of N is less than the concurrent idle capacity. For example, the idle capacity of the concurrent processing window is 10, but when determining the remaining quantity of the main protocol set, it is found that only 3 main protocol identifiers remain to be queried. At this time, the system directly sets N to 3 for the (M+1)th batch. These last 3 main protocol identifiers are extracted, and logical indices 0, 1, and 2 are assigned to them. The generated (M+1)th batch of request data contains only these 3 elements. This processing method avoids the unnecessary occupation of server resources.

[0091] Specifically, in operation S400A, the request data of the M+1th batch is sent to the server.

[0092] like Figure 6 As shown, in some exemplary embodiments, the response data set further includes an incomplete identifier associated with the query status of each of the main protocol identifiers; after reassembling each group of sub-protocol data to the storage location associated with its main protocol identifier, the method further includes: operations S100B to S600B.

[0093] Specifically, in operation S100B, in response to the existence of P main protocol identifiers with incomplete flags in the Mth batch, the P main protocol identifiers are retained to form the first part of the main protocol identifiers. In some specific embodiments, after the data processing end receives the response data set of the Mth batch, the system will parse the status information in each group of sub-protocol data one by one. In actual banking operations, the number of sub-protocols under certain specific main protocols, such as settlement accounts of large enterprises or personal investment accounts with extremely frequent transactions, may be very large, far exceeding the server's single transmission capacity limit (e.g., only ten can be transmitted at a time). In this case, the server will explicitly mark the "incomplete flag" in the response data set of the main protocol identifier. In a specific embodiment, in the N tasks of the Mth batch, P main protocol identifiers are associated with incomplete flags (P is a positive integer less than or equal to N). This means that the data of these P main protocols has not been fully retrieved and must be queried in the next round of requests; otherwise, data will be missing in the customer's asset view. Therefore, a task retention operation is performed: these P main protocol identifiers are temporarily locked and not removed from the current concurrent processing window, and they are marked as the first part of the main protocol identifiers, serving as the basic framework for building the next round of requests. This ensures that incomplete tasks can continue to occupy system resources until all their data has been thoroughly retrieved.

[0094] Specifically, in operation S200B, in response to the NP main protocol identifiers in the Mth batch being associated with completion identifiers indicating the end of the query, the NP main protocol identifiers are removed from the main protocol set. In some specific embodiments, relative to the P tasks that need to continue querying, the remaining NP main protocol identifiers in the Mth batch are associated with "completion identifiers". For these completed main protocols, the system performs a removal operation. The status of these main protocols in the local cache is updated to "processed", and then these main protocol identifiers are removed from the pending queue of the main protocol set. This is equivalent to sliding the concurrent processing window forward by the corresponding number of units, thereby releasing an equal number of idle concurrent slots.

[0095] Specifically, in operation S300B, it determines whether there are any remaining master protocol identifiers to be queried in the master protocol set. In some specific embodiments, the system checks whether there are any master protocol identifiers in the master protocol set that are still in a "pending processing" state. If the set is empty (i.e., all accounts under the customer's name have entered the processing flow), the system only needs to continue processing the P old tasks that are still pending in the next batch, without introducing new tasks; however, if the set is not empty, the system needs to calculate how many new tasks should be extracted to fill the gap, so as to ensure that the concurrent window is always in a saturated working state and avoid idle waste of hardware resources.

[0096] Specifically, in operation S400B, if so, N new master protocol identifiers are extracted from the master protocol set to form the second part of the master protocol identifiers. In some specific embodiments, determining how many new master protocol identifiers to extract from the master protocol set is a dynamic resource adaptation process. The core calculation logic here is: the newly extracted quantity N equals the target concurrency of the current batch minus the already retained quantity P. Regarding the mechanism for determining the target concurrency of the new batch, there are different specific implementations in Embodiment 1, Embodiment 2, and Embodiment 3.

[0097] In Implementation Example 1, the concurrency capacity is constant. For example, the system's target concurrency is always set to the maximum value, such as 10, and the previous batch was also running at full capacity. In this case, since P tasks are retained, "10 minus P" slots are released. The system continues to maintain the target concurrency of 10 for the next batch. Therefore, the number of new tasks N that the system needs to extract is equal to "10 minus P," ensuring that the system's throughput is always maintained at its peak.

[0098] In Example 2, concurrent resources are degraded. For example, when executing the next batch, due to severe device overheating or network bandwidth constraints, the system decides to reduce the maximum concurrency from 10 to 8. At this point, although 3 tasks were retained from the previous batch, the target total for the new batch is only allowed 8. Therefore, the system calculates the extraction quantity N to be equal to "8 minus 3", meaning only 5 new tasks are extracted. Specifically, if the degradation is extremely severe, causing the target concurrency to be less than or equal to the retained quantity (e.g., the target is reduced to 3, but 3 are retained), then the system does not extract any new tasks in this round, only processing the backlogged tasks.

[0099] In Example 3, the system's target concurrency is 10, with 3 tasks retained, theoretically 7 new tasks should be extracted. However, upon checking the main protocol set, it was found that only 2 main protocol identifiers remained to be queried. At this point, the system cannot gather 10. The system will extract these 2 remaining main protocol identifiers as the second part of the main protocol identifiers. The final total number of tasks in the next batch will be "3 retained tasks plus 2 new tasks," a total of 5. In this case, although the concurrency window is not fully loaded, it has achieved full coverage of the remaining data.

[0100] Specifically, in operation S500B, the first part of the main protocol identifier and the second part of the main protocol identifier are combined to form the M+1th batch, and a corresponding logical index is reassigned to each main protocol identifier in the second part of the main protocol identifier to generate the M+1th batch of request data. In some specific embodiments, the construction of mixed batches and the remapping of logical indexes are involved. The system merges the first part of the main protocol identifier (P old tasks that have been delayed) with the second part of the main protocol identifier (N newly extracted tasks) to assemble the M+1th batch.

[0101] Specifically, in operation S600B, the request data of the M+1th batch is sent to the server.

[0102] like Figure 7 As shown, in a second aspect of this application, a parallel data query method is provided, applied to a server, including operations S600 to S900.

[0103] Specifically, in operation S600, the server receives the Mth batch of request data sent from the data processing end. This Mth batch of request data is obtained by assigning a corresponding logical index to each master protocol identifier in the Mth batch. The Mth batch consists of N master protocol identifiers extracted from a master protocol set, which contains multiple master protocol identifiers to be queried, where N is a positive integer greater than or equal to 1, and M is a positive integer greater than or equal to 1. In some specific embodiments, the Mth batch of request data received by the server is a structured data packet constructed by the data processing end based on the current query requirements. Specifically, this request data directly corresponds to the N master protocol identifiers extracted by the data processing end from its locally maintained master protocol set. When generating this request data, the data processing end has assigned a unique logical index within this batch to each of these N master protocol identifiers. Therefore, after parsing the Mth batch of request data, the server obtains a data list containing N sets of mapping relationships, each set of mapping relationships explicitly containing the master protocol identifier to be queried and its bound logical index. This data structure ensures that the server can always identify the original request source corresponding to each query task through logical indexes during subsequent processing, without having to maintain complex session states on the server side.

[0104] Specifically, in operation S700, the Mth batch of request data is parsed into N independent query tasks, each corresponding to one of the N main protocol identifiers. Each of the N query tasks is a sub-protocol query processing task for its corresponding main protocol identifier. In some specific embodiments, after obtaining the Mth batch of request data, the server iterates through and parses its contents, decomposing the list containing the N main protocol identifiers into N independent query tasks. During this process, the system associates the logical index carried in the request data with the corresponding query task as an attribute parameter for that task. These N query tasks are logically independent of each other, each corresponding to a sub-protocol query processing task for a different main protocol identifier. For example, the query task for the first main protocol identifier is encapsulated as an independent execution unit, and the query task for the second main protocol identifier is encapsulated as another execution unit.

[0105] Specifically, in operation S800, the N query tasks are executed asynchronously and concurrently to obtain multiple sets of sub-protocol data. Each set of sub-protocol data is configured with a logical index consistent with its corresponding main protocol identifier. In some specific embodiments, the server does not execute these N query tasks sequentially according to the parsing order, but instead starts the execution flow of these tasks simultaneously. These N query tasks are submitted concurrently to the underlying execution resources, each initiating a sub-protocol query to the database targeting its corresponding main protocol identifier. Regardless of the execution time of these N query tasks, the server will eventually obtain N sets of corresponding sub-protocol data. Furthermore, since attribute parameters are associated during task creation, each set of generated sub-protocol data is strictly configured with a logical index consistent with its source main protocol identifier.

[0106] like Figure 8 As shown, in some exemplary embodiments, the asynchronous concurrent execution of the N query tasks to obtain multiple sets of sub-protocol data includes: operations S810 to S820.

[0107] Specifically, in operation S810, the N query tasks are distributed to a pre-configured thread pool, and worker threads in the thread pool initiate sub-protocol database query processing for each of the main protocol identifiers in parallel. In some specific embodiments, the system distributes the parsed N query tasks to a pre-configured thread pool on the server side. Idle worker threads in the thread pool will pick up these tasks in parallel, and each worker thread will initiate sub-protocol database query processing for each main protocol identifier. This mechanism ensures that the sub-protocol query operations of the N main protocols overlap in physical time, thereby greatly reducing the overall processing time.

[0108] Specifically, in operation S820, in response to the sub-protocol result returned by any of the worker threads, the logical index corresponding to the main protocol identifier is injected into the sub-protocol result to generate the sub-protocol data. In some specific embodiments, when any worker thread in the thread pool completes a database query operation and returns a sub-protocol result, the worker thread (or callback processing logic) immediately reads the logical index stored in the current task context. Subsequently, the system injects the logical index into the sub-protocol result, thereby generating the final sub-protocol data. This means that each piece of sub-protocol data generated carries its own "location information," ensuring that the data processing end can accurately reassemble it based on the logical index.

[0109] like Figure 9 As shown, in some exemplary embodiments, generating the sub-protocol data includes operations S821 to S824.

[0110] Specifically, in operation S821, based on the sub-protocol query processing progress of each query task, the query status identifier corresponding to each query task is determined. In some specific embodiments, when the server executes sub-protocol query processing, it obtains the total amount of sub-protocol data under the main protocol identifier or the pagination cursor information of the database, using this as the basis for judging the sub-protocol query processing progress, and thereby determining the query status identifier corresponding to the query task.

[0111] Specifically, in operation S822, the query status identifier is associated with the corresponding sub-protocol result and its logical index to generate the sub-protocol data. In some specific embodiments, the system uses the determined query status identifier as a key field, associating and packaging it with the corresponding sub-protocol result and logical index to generate complete sub-protocol data. In this way, when the data processing end receives data, it can not only obtain business data but also know whether the query for the main protocol has been completely completed.

[0112] Specifically, in operation S823, in response to the number of unqueried sub-protocols under the main protocol identifier corresponding to each query task exceeding the single transmission threshold of the thread pool, the query status identifier is determined to be an incomplete identifier. In some specific embodiments, if the system detects that the number of unqueried sub-protocols under the main protocol identifier corresponding to a query task exceeds the single transmission threshold of the thread pool (e.g., the single transmission limit is 10 records, but there are actually 50), the system will truncate the data within the threshold range as the result for this time, and determine the query status identifier of this data as an incomplete identifier. This indicates to the data processing end that the data of the main protocol has not been completely transmitted and needs to be retained and the query continued.

[0113] Specifically, in operation S824, in response to the fact that the number of unqueried sub-protocols under the main protocol identifier corresponding to each query task does not exceed the single transmission threshold of the thread pool, the query status identifier is determined to be a completion identifier. In some specific embodiments, if the system detects that the number of unqueried sub-protocols under the main protocol identifier corresponding to a query task does not exceed the single transmission threshold of the thread pool, or if the current data is the last page, the system determines the query status identifier of that data as a completion identifier. This indicates to the data processing end that all sub-protocol data of the main protocol has been transmitted.

[0114] Specifically, in operation S900, a response data set is generated based on the multiple sets of sub-protocol data and their logical indexes, and then sent to the data processing terminal. In some specific embodiments, after the server waits for all N query tasks in this batch to be completed, it organizes the collected multiple sets of sub-protocol data (each set containing sub-protocol results, logical indexes, and query status identifiers) together to generate a response data set. Subsequently, the server sends this response data set to the data processing terminal via the network, completing the response process for the Mth batch of requests.

[0115] In this embodiment, the operations S100~S500, S600, S700, S800, S900, S110, S120, S510, S520, S810, S820, S821, S822, S823, and S824 described above can also be executed on the system side, and will not be repeated here.

[0116] Based on the above-mentioned parallel data query method applied to the data processing end, this application also provides a parallel data query device applied to the data processing end, which will be described below in conjunction with... Figure 10 The device is described in detail.

[0117] Figure 10 The diagram illustrates a structural block diagram of a parallel data query device applied to a data processing end according to an embodiment of this application.

[0118] like Figure 10 As shown, the parallel data query device 200 applied to the data processing end in this embodiment includes a first acquisition module 210, a first processing module 220, a first transmission module 230, a first receiving module 240, and a second processing module 250.

[0119] The first acquisition module 210 is configured to acquire a set of main protocols to be queried, wherein the set of main protocols contains multiple identifiers of the main protocols to be queried. In some embodiments, the first acquisition module 210 mainly undertakes the initialization responsibility of the query process. Specifically, in response to external business trigger signals (such as user clicks or batch job scheduling), the first acquisition module 210 initiates a basic information retrieval for the customer's identity to the server. Subsequently, the first acquisition module 210 receives the full list of protocols returned by the server and constructs it into a local set of main protocols. This set of main protocols serves as the data source for subsequent parallel processing and contains unique identifiers for all financial products to be retrieved under the customer's name. At this time, these identifiers are not yet associated with specific asset values ​​and are in a state of pending expansion. In one embodiment, the first acquisition module 210 can be used to execute the operation S100, as well as operations S110 and S120 described above, which will not be repeated here.

[0120] The first processing module 220 is configured to determine N master protocol identifiers from the master protocol set to form the Mth batch, and to assign a corresponding logical index to each master protocol identifier in the Mth batch to generate the Mth batch of request data, where N and M are both positive integers greater than or equal to 1. In some embodiments, the first processing module 220 sequentially extracts N master protocol identifiers to be processed from the head of the master protocol set according to the current system's concurrent capacity or a preset window size. The first processing module 220 is responsible for establishing context anchors, that is, assigning a unique logical index to each of these N identifiers within the current batch. Through this processing, the first processing module 220 converts discrete service identifiers into structured Mth batch request data with location information, laying the foundation for subsequent out-of-order reordering. The first processing module 220 can be used to execute the operation S200 described above, which will not be repeated here.

[0121] The first transmission module 230 is configured to send the Mth batch of request data to the server. In some embodiments, the first transmission module 230 serializes and encapsulates the aggregated request data containing N elements generated by the first processing module, and establishes a connection with the server through a network interface. This module ensures that the entire batch of request instructions is transmitted in a single network interaction, thereby replacing the inefficient mode of initiating requests separately for each protocol in traditional technologies, significantly reducing the handshake overhead and transmission latency of the network protocol stack. In one embodiment, the first transmission module 230 can be used to perform the operation S300 described above, which will not be repeated here.

[0122] The first receiving module 240 is configured to receive a set of response data sent from the server. The set of response data includes multiple sets of sub-protocol data corresponding to N main protocol identifiers in the Mth batch. Each set of sub-protocol data has a logical index identical to its corresponding main protocol identifier. The response data set is obtained by the server parsing the Mth batch of request data into N independent query tasks and then asynchronously and concurrently executing these N independent query tasks. In some embodiments, the first receiving module 240 listens on a network port to receive the set of response data returned by the server. This set of response data contains N sets (or fewer than N sets) of sub-protocol data processed in parallel by the server. The first receiving module 240 can parse this data and identify the logical indexes and query status identifiers carried within it. Regardless of the physical order of this data in the data packet, the first receiving module 240 can completely parse it into standardized data objects suitable for subsequent processing. In one embodiment, the first receiving module 240 can be used to perform the operation S400 described above, which will not be repeated here.

[0123] The second processing module 250 is configured to reassemble the data of each group of sub-protocols to a storage location associated with its main protocol identifier based on the logical index. In some embodiments, the second processing module 250 performs deterministic data reassembly and flow control management. Based on the parsed logical index, the second processing module 250 calculates the precise location of each group of sub-protocol data in the local storage area or UI view and performs direct mapping write, thereby solving the out-of-order problem caused by concurrent returns. Furthermore, the second processing module 250 is also responsible for parsing the query status identifier (completed or incomplete), thereby determining whether certain main protocols need to be retained in the current processing window, and whether new tasks need to be extracted from the main protocol set to build the next batch, thus realizing a sliding window-style continuous query processing logic. In one embodiment, the second processing module 250 can be used to execute the previously described operation S500, as well as operations S510 and S520, which will not be elaborated further here.

[0124] Based on the above-described parallel data query method applied to the server side, this application also provides a parallel data query device applied to the server side, which will be described below in conjunction with... Figure 11 The device is described in detail.

[0125] Figure 11 The diagram illustrates a structural block diagram of a parallel data query device applied to a server according to an embodiment of this application.

[0126] like Figure 11 As shown, the parallel query data device 200 applied to the server side in this embodiment includes a second receiving module 260, a third processing module 270, a fourth processing module 280, and a second transmission module 290.

[0127] The second receiving module 260 is configured to receive the Mth batch of request data sent from the data processing end. The Mth batch of request data is obtained by assigning a corresponding logical index to each master protocol identifier in the Mth batch. The Mth batch consists of N master protocol identifiers extracted from a master protocol set, which contains multiple master protocol identifiers to be queried, where N is a positive integer greater than or equal to 1, and M is a positive integer greater than or equal to 1. In one embodiment, the second receiving module 260 can be used to execute the operation S600 described above, which will not be repeated here.

[0128] The third processing module 270 is configured to parse the Mth batch of request data into N independent query tasks corresponding to the N main protocol identifiers, wherein the N query tasks are sub-protocol query processing tasks for their corresponding main protocol identifiers. The third processing module 270 can be used to execute the operation S700 described above, which will not be repeated here.

[0129] The fourth processing module 280 is configured to asynchronously and concurrently execute the N query tasks to obtain multiple sets of sub-protocol data, wherein each set of sub-protocol data is configured with a logical index consistent with its corresponding main protocol identifier. In one embodiment, the fourth processing module 280 can be used to execute the operation S800 described above, as well as operations S810, S820, S821, S822, S823, and S824, which will not be described in detail here.

[0130] The second transmission module 290 is configured to generate a response data set based on the multiple sets of sub-protocol data organization and their logical indexes, and send the response data set to the data processing terminal. In one embodiment, the second transmission module 290 can be used to perform the operation S900 described above, which will not be repeated here.

[0131] According to embodiments of this application, any multiple modules among the first acquisition module 210, first processing module 220, first conveying module 230, first receiving module 240, second processing module 250, second receiving module 260, third processing module 270, fourth processing module 280, and second conveying module 290 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the first acquisition module 210, first processing module 220, first transmission module 230, first receiving module 240, second processing module 250, second receiving module 260, third processing module 270, fourth processing module 280, and second transmission module 290 can be at least partially implemented as hardware circuits, such as field-programmable gate arrays (FPGAs), programmable logic arrays (PLAs), systems-on-a-chip, systems-on-a-substrate, systems-on-package, application-specific integrated circuits (ASICs), or any other reasonable means of integrating or packaging circuits, or implemented in hardware or firmware, or in any one of software, hardware, and firmware implementations, or in a suitable combination of any of these. Alternatively, at least one of the first acquisition module 210, first processing module 220, first transmission module 230, first receiving module 240, second processing module 250, second receiving module 260, third processing module 270, fourth processing module 280, and second transmission module 290 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0132] Figure 12 A block diagram schematically illustrates an electronic device suitable for implementing a parallel data query method according to an embodiment of this application.

[0133] like Figure 12 As shown, an electronic device 900 according to an embodiment of this application includes a processor 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage portion 908 into a random access memory (RAM) 903. The processor 901 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 901 may also include onboard memory for caching purposes. The processor 901 may include a single processing module or multiple processing modules for performing different actions of the method flow according to an embodiment of this application.

[0134] RAM 903 stores various programs and data required for the operation of electronic device 900. Processor 901, ROM 902, and RAM 903 are interconnected via bus 904. Processor 901 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 902 and / or RAM 903. It should be noted that programs may also be stored in one or more memories other than ROM 902 and RAM 903. Processor 901 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0135] According to embodiments of this application, the electronic device 900 may further include an input / output (I / O) interface 905, which is also connected to a bus 904. The electronic device 900 may also include one or more of the following components connected to the input / output (I / O) interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the input / output (I / O) interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 910 as needed so that computer programs read from it can be installed into the storage section 908 as needed.

[0136] This application also provides a computer-readable storage medium, which may be included in the apparatus described in the above embodiments; or it may exist independently and not assembled into the apparatus. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0137] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the 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. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 902 and / or RAM 903 and / or one or more memories other than ROM 902 and RAM 903 described above.

[0138] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code enables the computer system to implement the parallel data query method provided in the embodiments of this application.

[0139] When the computer program is executed by the processor 901, it performs the functions defined in the apparatus of the embodiments of this application. According to the embodiments of this application, the apparatus and the like described above can be implemented by computer program modules.

[0140] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 909, and / or installed from a removable medium 911. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0141] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 909, and / or installed from the removable medium 911. When the computer program is executed by the processor 901, it performs the functions defined in the system of the embodiments of this application. According to embodiments of this application, the apparatuses described above can be implemented by computer program modules.

[0142] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0143] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of 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 the 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 consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0144] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

[0145] The embodiments of this application have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of this application. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Without departing from the scope of this application, those skilled in the art can make various substitutions and modifications, all of which should fall within the scope of this application.

Claims

1. A parallel data query method, characterized in that, Applied to a data processing end, the method includes: Obtain the set of main protocols to be queried, wherein the set of main protocols contains multiple identifiers of the main protocols to be queried; N master protocol identifiers are determined from the master protocol set to form the Mth batch, and a corresponding logical index is assigned to each master protocol identifier in the Mth batch to generate the Mth batch request data, where N and M are both positive integers greater than or equal to 1; Send the Mth batch of request data to the server. The server receives a set of response data sent from the server. The set of response data contains multiple sets of sub-protocol data corresponding to the N main protocol identifiers in the Mth batch. Each set of sub-protocol data is configured with a logical index that is the same as its corresponding main protocol identifier. The set of response data is obtained by the server after parsing the Mth batch of request data into N independent query tasks and then executing the N independent query tasks asynchronously and concurrently. Based on the logical index, the data of each group of sub-protocols is reorganized into the storage location associated with its main protocol identifier.

2. The method according to claim 1, characterized in that, The process of obtaining the set of main protocols to be queried includes: In response to a customer query command, a customer identifier query request is sent to the server. Receive the main protocol set sent by the server; wherein the main protocol set is obtained by asynchronously and concurrently executing A main protocol query tasks in a single query loop, wherein the main protocol set contains multiple main protocol identifiers corresponding to the client query instruction, and the A main protocol query tasks are established based on the parsing of the client query instruction, where A is a positive integer greater than 1.

3. The method according to claim 1, characterized in that, The step of determining N master protocols from the master protocol set to form the Mth batch includes: N unprocessed main protocol identifiers are sequentially extracted from the head of the main protocol set, wherein the value of N is determined based on the idle capacity of the current concurrent processing window.

4. The method according to claim 1, characterized in that, The step of reorganizing the data of each group of sub-protocols to a storage location associated with its main protocol identifier based on the logical index includes: The target storage location is determined based on each group of sub-protocol data in the response data set and the logical index carried by each group of sub-protocol data; wherein the target storage location is bound to the main protocol identifier corresponding to the logical index. The sub-protocol data of each group is stored in the target storage location.

5. The method according to claim 3, characterized in that, The response data set also includes a completion identifier associated with the query status of each of the main protocol identifiers; After reassembling the data of each group of sub-protocols into the storage location associated with its main protocol identifier, the method further includes: In response to the fact that all N main protocol identifiers in the Mth batch are associated with a completion identifier indicating the end of the query, the N main protocol identifiers are removed from the main protocol set; Determine whether there are any remaining main protocol identifiers to be queried in the main protocol set; If so, extract N new main protocol identifiers from the main protocol set to form the M+1th batch, and reassign the corresponding logical index to each main protocol identifier in the M+1th batch to generate the M+1th batch request data; The M+1th batch of request data is sent to the server.

6. The method according to claim 5, characterized in that, The response data set also includes incomplete identifiers associated with the query status of each of the main protocol identifiers; After reassembling the data of each group of sub-protocols into the storage location associated with its main protocol identifier, the method further includes: In response to the existence of P main protocol identifiers with incomplete association in the Mth batch, the P main protocol identifiers are retained to form the first part of the main protocol identifiers; In response to the fact that NP master protocol identifiers in the Mth batch are associated with completion identifiers indicating the end of the query, the NP master protocol identifiers are removed from the master protocol set; Determine whether there are any remaining main protocol identifiers to be queried in the main protocol set; If so, extract N new main protocol identifiers from the main protocol set to form the second part of the main protocol identifiers; The first part of the main protocol identifier and the second part of the main protocol identifier are combined to form the M+1th batch, and the corresponding logical index is reassigned to each main protocol identifier in the second part of the main protocol identifier to generate the M+1th batch of request data. The M+1th batch of request data is sent to the server.

7. A parallel data query method, characterized in that, Applied to the server side, the method includes: Receive the Mth batch of request data sent from the data processing end, wherein the Mth batch of request data is obtained by assigning a corresponding logical index to each master protocol identifier in the Mth batch, the Mth batch consists of N master protocol identifiers extracted from the master protocol set, the master protocol set contains multiple master protocol identifiers to be queried, where N is a positive integer greater than or equal to 1, and M is a positive integer greater than or equal to 1; The Mth batch of request data is parsed into N independent query tasks corresponding to the N main protocol identifiers, wherein the N query tasks are sub-protocol query processing tasks for their corresponding main protocol identifiers; The N query tasks are executed asynchronously and concurrently to obtain multiple sets of sub-protocol data, wherein each set of sub-protocol data is configured with a logical index that is consistent with the corresponding main protocol identifier; Based on the multi-group sub-protocol data organization and its logical index, a response data set is generated and sent to the data processing terminal.

8. The method according to claim 7, characterized in that, The asynchronous concurrent execution of the N query tasks yields multiple sets of sub-protocol data, including: The N query tasks are distributed to a pre-set thread pool, and the worker threads in the thread pool are used to initiate sub-protocol database query processing for each of the main protocol identifiers in parallel. In response to the sub-protocol result returned by any of the worker threads, the logical index corresponding to the main protocol identifier is injected into the sub-protocol result to generate the sub-protocol data.

9. The method according to claim 8, characterized in that, The generation of the sub-protocol data also includes: Based on the sub-protocol query processing progress of each query task, determine the query status identifier corresponding to each query task. The query status identifier is associated with the corresponding sub-protocol result and its logical index to generate the sub-protocol data; Wherein, in response to the number of unqueried sub-protocols under the main protocol identifier corresponding to each query task exceeding the single transmission threshold of the thread pool, the query status identifier is determined to be an incomplete identifier; In response to the fact that the number of unqueried sub-protocols under the main protocol identifier corresponding to each query task does not exceed the single transmission threshold of the thread pool, the query status identifier is determined to be a completion identifier.

10. A parallel data query device, applied at a data processing end, characterized in that, The device includes: The first acquisition module is configured to acquire a set of main protocols to be queried, wherein the set of main protocols contains multiple main protocol identifiers to be queried; The first processing module is configured to determine N main protocol identifiers from the main protocol set to form the Mth batch, and assign a corresponding logical index to each main protocol identifier in the Mth batch to generate the Mth batch request data, where N and M are both positive integers greater than or equal to 1; The first delivery module is configured to send the Mth batch of request data to the server. The first receiving module is configured to receive a set of response data sent from the server. The set of response data includes multiple sets of sub-protocol data corresponding to N main protocol identifiers in the Mth batch. Each set of sub-protocol data is configured with a logical index that is the same as its corresponding main protocol identifier. The set of response data is obtained by the server after parsing the Mth batch of request data into N independent query tasks and then executing the N independent query tasks asynchronously and concurrently. The second processing module is configured to reassemble the data of each group of sub-protocols into a storage location associated with its main protocol identifier based on the logical index.

11. A parallel data query device, characterized in that, The device, applied to the server side, includes: The second receiving module is configured to receive the Mth batch of request data sent from the data processing end. The Mth batch of request data is obtained by assigning a corresponding logical index to each master protocol identifier in the Mth batch. The Mth batch consists of N master protocol identifiers extracted from the master protocol set. The master protocol set contains multiple master protocol identifiers to be queried, where N is a positive integer greater than or equal to 1 and M is a positive integer greater than or equal to 1. The third processing module is configured to parse the Mth batch of request data into N independent query tasks corresponding to the N main protocol identifiers, wherein the N query tasks are sub-protocol query processing tasks for their corresponding main protocol identifiers. The fourth processing module is configured to execute the N query tasks asynchronously and concurrently to obtain multiple sets of sub-protocol data, wherein each set of sub-protocol data is configured with a logical index that is consistent with the corresponding main protocol identifier; The second transmission module is configured to generate a response data set based on the multiple sets of sub-protocol data organization and their logical index, and send the response data set to the data processing terminal.

12. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 9.

13. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 9.

14. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 9.

Images