Concurrent processing method, device, equipment, medium and product of task

Abstract

Embodiments of the present application provide a task concurrent processing method and device, equipment, medium and product, relating to the field of financial technology or other related fields. The method, in response to a processing request of a target task, first combines a buffer queue and account information of the target task to query whether there is a corresponding concurrent task in processing, thereby executing different processing strategies for the target task, storing the account information in processing in the buffer queue, allowing subsequent concurrent tasks to be identified and temporarily stored in a data buffer pool, avoiding multiple transactions simultaneously competing for database row locks, and through the above configuration, realizing that the first task is directly executed without waiting, the subsequent task is pulled for processing after being put into the pool, forming a serial task processing chain, automatically cleaning up the queue mark after all task processing is completed, improving the concurrent processing efficiency, avoiding long waiting time, realizing fast response, and improving the task processing efficiency.

Description

Technical Field

[0001] This application relates to the field of financial technology or other related fields, and in particular to a method, apparatus, device, medium and product for concurrent processing of tasks. Background Technology

[0002] In business scenarios such as financial transactions, e-commerce, and corporate cash management, it is common to see a large number of transactions updating the same account's data records simultaneously; such accounts are known as "hot accounts." For example, in high-concurrency scenarios such as bank-enterprise interconnection systems and cash management systems, a large number of concurrent requests for the same account may be submitted to the core system for processing at the same time.

[0003] In related technologies, there are various methods for handling hot account use cases, such as business process optimization, hashed ledger entry, and multi-point linked entry. Business process optimization requires modifying existing business processes, which is intrusive to the system; hashed ledger entry distributes funds to multiple sub-accounts, but essentially it splits accounts rather than solves the problem; multi-point linked entry increases the overhead of accounting sub-accounts and complicates accounting processes.

[0004] However, the task processing methods in related technologies suffer from low processing efficiency in scenarios involving concurrent processing of multiple transactions for hot accounts. Summary of the Invention

[0005] This application provides a method, apparatus, device, medium, and product for concurrent processing of tasks, in order to solve the technical problem of low processing efficiency in task processing methods in related technologies when multiple transactions are processed concurrently for hot accounts.

[0006] Firstly, this application provides a method for concurrent processing of tasks, including:

[0007] In response to the processing request of the target task, obtain the account information of the target task;

[0008] Based on the account information and the buffer queue, determine whether there are concurrent tasks corresponding to the account information;

[0009] If no concurrent tasks exist, add the account information to the buffer queue and execute the target task;

[0010] If there are concurrent tasks corresponding to account information, the target task will be stored in the data buffer pool.

[0011] After the concurrent task and / or target task are completed, the next response task corresponding to the account information is retrieved from the data buffer pool and executed; wherein, the response task includes the concurrent task and / or target task;

[0012] Once all response tasks corresponding to the account information have been completed, the account information is removed from the buffer queue.

[0013] Here, this application embodiment provides a method for concurrent task processing applicable to hot accounts. When responding to a processing request for a target task, it first checks whether there are corresponding concurrent tasks being processed, combining the buffer queue and the account information of the target task, and then executes different processing strategies for the target task. By storing the account information of the processing tasks in the buffer queue, subsequent concurrent tasks are temporarily stored in the data buffer pool after being identified, avoiding multiple transactions competing for database row locks at the same time. Through the above configuration, the first task is executed directly without waiting, and subsequent tasks are automatically pulled and processed after entering the pool, forming a serial task processing chain. After all tasks are processed, the queue mark is automatically cleared, improving the efficiency of concurrent processing, avoiding long waiting times, achieving fast response, and improving task processing efficiency.

[0014] In one possible embodiment, determining whether there is a concurrent task corresponding to the account information based on the account information and the buffer queue includes:

[0015] Based on the account information, perform query processing in the buffer queue;

[0016] If account information exists in the buffer queue, then concurrent tasks are confirmed to exist.

[0017] If no account information is found in the buffer queue, then it is determined that there are no concurrent tasks.

[0018] In this embodiment, the account information of the currently executing task is stored in the buffer queue. By querying the account information of the target task in the buffer queue, it is possible to accurately determine whether there is a concurrent task corresponding to the target task, thereby further improving the task processing efficiency.

[0019] In one possible embodiment, performing the target task includes:

[0020] Obtain task information for the target task; wherein, task information includes at least one of task processing logic, lending direction information, amount information, and category information;

[0021] Based on the task information, the preset core services are invoked to process the task information.

[0022] In this embodiment, the processing logic, lending direction, amount, and currency parameters in the task information are parsed to invoke a preset core service to perform accounting processing. This structured extraction of task information ensures the complete transmission of processing parameters, and the core service updates the account balance according to specified logic, achieving accurate execution of the target task and improving task processing efficiency and reliability.

[0023] In one possible embodiment, storing the target task in a data buffer pool includes:

[0024] Obtain the invocation information of the target task; wherein, the invocation information includes at least one of the following: transaction serial number, lending direction information, amount information, and category information;

[0025] The call information is written to the storage area in the data buffer pool corresponding to the account information.

[0026] This application embodiment extracts call information such as transaction serial number, lending direction, amount, and currency from the target task and writes this information into the storage area corresponding to the account information in the data buffer pool. This storage area is used to store all pending task information for the account. After the write operation is completed, the task call information is temporarily stored, awaiting subsequent reading and execution. This avoids the loss of task information during the waiting period, improves the reliability of the data buffer, and further enhances the efficiency of parallel task processing.

[0027] In one possible embodiment, after writing the call information to the storage area in the data buffer pool corresponding to the account information, the method further includes:

[0028] Return the success message of the target task to the preset task caller; wherein the preset task caller includes at least one of the channel terminal that initiated the processing request, the client application, or the application programming interface caller.

[0029] In this embodiment, after writing the target task's invocation information into the data buffer pool, a success response is returned to the preset task invoking client. With this configuration, although the target task has not yet been actually executed, the upstream invoking party has already received confirmation of receipt and does not need to wait for the task to complete, reducing the upstream invoking party's waiting time and further improving the parallel processing efficiency of the task.

[0030] In one possible embodiment, retrieving the next response task corresponding to the account information from the data buffer pool includes:

[0031] Based on the writing order of the response tasks corresponding to the account information in the data buffer pool, read the next response task corresponding to the account information from the data buffer pool.

[0032] In this embodiment, when reading the next response task from the data buffer pool, the order in which each response task was written to the data buffer pool is used to ensure that tasks written earlier are read first, and tasks written later are read later. This reading method ensures that multiple concurrent tasks of the same account are processed sequentially according to their arrival order, preventing later tasks from being executed before earlier ones, and further improving the reliability and accuracy of task processing for hot accounts.

[0033] In one possible embodiment, the account information includes at least one of account information, name information, and a unique identifier.

[0034] This application embodiment configures a variety of different account information, which can be applied to different application scenarios and improves the flexibility of task processing.

[0035] In one possible embodiment, before obtaining the account information of the target task in response to the processing request of the target task, the method further includes:

[0036] In response to a processing request for a pending task, obtain the account information corresponding to the pending task;

[0037] Based on account information and preset hot account judgment rules, determine whether the task to be processed belongs to the hot account.

[0038] If the task pertains to a popular account, then the task to be processed will be designated as the target task.

[0039] Here, in this embodiment, before processing the target task, the account information of the task to be processed is first obtained. Then, based on the account information and the preset hot account judgment rules, it is determined whether the task belongs to the hot account. If it belongs to the hot account, the task is identified as the target task and enters the subsequent buffer processing flow. If it does not belong to the hot account, it does not need to enter the buffer processing flow. In this way, tasks of non-hot accounts will not perform operations such as buffer queue query and data buffer pool writing, saving screening time for non-hot tasks and further improving task processing efficiency.

[0040] Secondly, embodiments of this application provide a concurrent processing apparatus for a task, comprising:

[0041] The first acquisition module is used to acquire the account information of the target task in response to the processing request of the target task;

[0042] The determination module is used to determine whether there are concurrent tasks corresponding to the account information based on the account information and the buffer queue;

[0043] The first processing module is used to add account information to the buffer queue and execute the target task if there are no concurrent tasks.

[0044] The second processing module is used to store the target task in the data buffer pool if there are concurrent tasks corresponding to account information.

[0045] The second acquisition module is used to retrieve the next response task corresponding to the account information from the data buffer pool and execute the next response task after the concurrent task and / or target task have been completed; wherein, the response task includes the concurrent task and / or target task;

[0046] The third processing module is used to remove the account information from the buffer queue after all response tasks corresponding to the account information have been executed.

[0047] In one possible embodiment, the determining module is specifically used for:

[0048] Based on the account information, a query process is performed in the buffer queue;

[0049] If the account information exists in the buffer queue, then it is determined that the concurrent task exists;

[0050] If the account information is not present in the buffer queue, then it is determined that there is no concurrent task.

[0051] In one possible embodiment, the first processing module is specifically used for:

[0052] Obtain task information for the target task; wherein, the task information includes at least one of task processing logic, lending direction information, amount information, and category information;

[0053] Based on the task information, a preset core service is invoked to process the task information.

[0054] In one possible embodiment, the second processing module is specifically used for:

[0055] Obtain the invocation information of the target task; wherein, the invocation information includes at least one of transaction serial number, lending direction information, amount information, and category information;

[0056] The call information is written to the storage area in the data buffer pool corresponding to the account information.

[0057] In one possible embodiment, after the second processing module writes the call information to the storage area in the data buffer pool corresponding to the account information, the above device further includes a caching module for:

[0058] The response success information of the target task is returned to the preset task calling terminal; wherein, the preset task calling terminal includes at least one of the channel terminal that initiated the processing request, the client application, or the application programming interface calling terminal.

[0059] In one possible embodiment, the second acquisition module is specifically used for:

[0060] Based on the writing order of the response tasks corresponding to the account information in the data buffer pool, the next response task corresponding to the account information is read from the data buffer pool.

[0061] In one possible embodiment, the account information includes at least one of account information, name information, and unique identifier.

[0062] In one possible embodiment, before the first acquisition module acquires the account information of the target task in response to the processing request of the target task, the apparatus further includes a filtering module for:

[0063] In response to a processing request for a pending task, obtain the account information corresponding to the pending task;

[0064] Based on the account information and the preset hot account judgment rules, determine whether the task to be processed belongs to the hot account-related task;

[0065] If the task pertains to a popular account, then the task to be processed will be designated as the target task.

[0066] Thirdly, embodiments of this application provide an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0067] The memory stores instructions that the computer executes;

[0068] The processor executes computer-executable instructions stored in memory to implement the method described in the first aspect above.

[0069] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in the first aspect above.

[0070] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0071] This application provides a method, apparatus, device, medium, and product for concurrent task processing. When responding to a processing request for a target task, it first checks whether there are corresponding concurrent tasks being processed, combining a buffer queue and the target task's account information, and then executes different processing strategies for the target task. By storing the account information of tasks in processing in the buffer queue, subsequent concurrent tasks are temporarily stored in a data buffer pool after being identified, avoiding multiple transactions simultaneously competing for database row locks. Through this configuration, the first task is executed directly without waiting, and subsequent tasks are automatically retrieved and processed after being added to the pool, forming a serial task processing chain. The queue marker is automatically cleared after all tasks are processed, improving concurrent processing efficiency, avoiding long waiting times, achieving rapid response, and increasing task processing efficiency. Attached Figure Description

[0072] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0073] Figure 1 A schematic diagram of a concurrent processing system architecture for a task provided in an embodiment of this application;

[0074] Figure 2 This is a schematic diagram of the structure of a multi-transaction processing system provided in an embodiment of this application;

[0075] Figure 3 A flowchart illustrating a method for concurrent processing of tasks provided in an embodiment of this application;

[0076] Figure 4 A schematic diagram illustrating the flow direction of a task, provided as an embodiment of this application;

[0077] Figure 5 A schematic diagram of the structure of a concurrent processing device for a task provided in an embodiment of this application;

[0078] Figure 6 This is a schematic diagram of the structure of a concurrent processing device for a task provided in an embodiment of this application.

[0079] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0080] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0081] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, they do not violate public order and good morals, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0082] It should be noted that the methods, apparatus, devices, storage media and products for concurrent processing of tasks provided in this application can be used in the field of fintech or other related fields, and can also be used in any field other than fintech. The application fields of the methods, apparatus, devices, storage media and products for concurrent processing of tasks in this application are not limited.

[0083] Hot accounts refer to accounts (including personal or corporate accounts) whose data records are updated by a large number of transactions within a certain period of time (high business volume, high concurrency). Accounts that form a waiting queue in the database account records become hot accounts. For example, if the waiting time exceeds 30 seconds, it may cause business losses or actual business impact.

[0084] In special business scenarios, core systems often process a large amount of data from the same account simultaneously. Such situations trigger concurrent processing of multiple transactions for hot accounts, requiring high concurrency and high performance to be met at the same time.

[0085] For hot account use cases, common practices in various business scenarios include business process optimization, hashed ledger entries, and multi-point posting. Each of these methods has its advantages and diverse applicability. While multiple methods exist, such as business process optimization which requires modifying business processes to handle multiple debit / credit scenarios (e.g., adjusting to a single debit / multiple credit model), this is intrusive to business process management. Multi-point posting increases the overhead of sub-accounts and complicates accounting. Hashed ledger entries disperse funds across multiple accounts, essentially splitting the hot account itself, rendering the hot account a pseudo-proposition and not truly solving the problem. Current solutions, while offering some relief for hot accounts, do not directly address or resolve the issue. Furthermore, task processing methods in related technologies suffer from low processing efficiency in scenarios involving multiple concurrent transactions of hot accounts.

[0086] To address the aforementioned issues, embodiments of this application provide a method, apparatus, device, medium, and product for concurrent task processing. This method combines a buffer queue and the account information of the target task to query whether any corresponding concurrent tasks are being processed, thereby executing different processing strategies for the target task. By storing the account information of the processing task in the buffer queue, subsequent concurrent tasks are temporarily stored in a data buffer pool after being identified, avoiding multiple transactions simultaneously competing for database row locks, thus improving task processing efficiency.

[0087] Optionally, this application also proposes a modeling method for an intermediate buffer layer for concurrent processing of multiple transactions involving hot accounts. This modeling enables rapid response and reaction to concurrent transactions involving hot accounts, avoiding long waiting times for channel terminals or customer callers. The intermediate buffer layer for concurrent processing of multiple transactions involving hot accounts proposed in this application satisfies both upstream business processing and downstream accounting processing.

[0088] Optional, Figure 1 This is a schematic diagram of a concurrent processing system architecture for a task, provided as an embodiment of this application. Figure 1 In the above architecture, at least one of receiving device 101, processor 102 and display device 103 is included.

[0089] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the architecture of a concurrent processing system for tasks. In other feasible embodiments of this application, the above architecture may include more or fewer components than illustrated, or combine some components, or split some components, or arrange different components, which can be determined according to the actual application scenario and is not limited here. Figure 1 The components shown can be implemented in hardware, software, or a combination of both.

[0090] In the specific implementation process, the receiving device 101 can be an input / output interface or a communication interface.

[0091] The processor 102 can combine the buffer queue and the account information of the target task to query whether there are corresponding concurrent tasks being processed, and thus execute different processing strategies for the target task. By storing the account information of the processing task in the buffer queue, subsequent concurrent tasks are temporarily stored in the data buffer pool after being identified, avoiding multiple transactions competing for database row locks at the same time, thereby improving task processing efficiency.

[0092] The display device 103 can be used to display the above results, etc.

[0093] The display device can also be a touch screen, used to receive user commands while displaying the above content, so as to achieve interaction with the user.

[0094] It should be understood that the aforementioned processor can be implemented by reading instructions from memory and executing those instructions, or it can be implemented through chip circuitry.

[0095] Furthermore, the network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0096] Optionally, Figure 2 This is a schematic diagram of the structure of a multi-transaction processing system provided in an embodiment of this application. The concurrent processing method for tasks in this embodiment can be based on... Figure 2 The implementation of a multi-transaction processing system.

[0097] like Figure 2 As shown, this application embodiment constructs a multi-transaction processing middleware layer for hot accounts, used to automatically identify situations with a large number of user requests and excessively high peak transaction volumes. This middleware layer works collaboratively through the following modules to achieve rapid response and buffering processing for concurrent multi-transactions of hot accounts:

[0098] Optionally, the buffer model access module is responsible for the unified access of the overall hot account multi-transaction concurrent fast response buffer processing model, initially performing business processing access and traffic redirection, and completing the initial concurrent traffic distribution. This module maintains the concurrent response module request table, providing a quick account or customer maintenance list of the concurrent queue of hot accounts currently in buffer processing, facilitating quick confirmation of whether there are corresponding hot accounts being processed concurrently at any given time.

[0099] Optionally, the business concurrency response module performs judgment and identification, and completes the diversion of business requests to the intermediate buffer layer. Simultaneously, this module also undertakes identification, monitoring, and early warning functions such as response time monitoring, overload warning, and multi-level overload tracking. Specifically, for data introduced through account analysis and the access layer, if it is in the buffer concurrency queue, the corresponding request content needs to be stored in the data buffer pool of the resource storage module; after account analysis, the account information stored in the buffer concurrency queue and the corresponding call information stored in the data buffer pool need to be synchronized, and the data synchronization into the queue and buffer pool operations need to be completed.

[0100] Optionally, the control processing module is the core scheduling unit of the entire business buffering process. It mainly performs control processing on same-account business scenarios that require buffering processing, as identified and monitored by the business concurrency response module. This module provides the setting and evaluation of core parameters, processing coordination, dynamic allocation of multi-level caches, and allows for manual or automatic updates of the allocation algorithm.

[0101] Optionally, the resource storage module forms a business buffer data storage pool of a certain range. Through data buffer storage, it performs pre-calculation of business requests and generates storage processing queues, and reports them to the control processing module to complete the connection with the core processing stock process and realize the connection with the business processing system.

[0102] Optionally, the shared information module can share information on business processes in different business scenarios and processing modes to assist the control processing module in the unified allocation of resource storage and to connect with enterprise-level resource scheduling and control to achieve unified coordination of group resources.

[0103] Optionally, the enterprise-level resource scheduling and docking module coordinates resources externally, formats different resource processing modules, and performs flexible system automated replication and automated operation to achieve automated dynamic integration of resources.

[0104] Optionally, the log information registration and processing module registers the action and processing log information of the overall buffer layer's business processing, recording the processing trajectory of each business request in the buffer layer.

[0105] Through the coordinated operation of the above seven core modules, the hot account multi-transaction processing middleware constructed in this application embodiment can quickly respond to and respond to the concurrent multi-transactions of hot accounts, avoiding long waiting times for channel terminals or customer callers, thus satisfying the upstream business processing needs and being compatible with downstream accounting processing.

[0106] It is understandable that the above structure of a multi-transaction processing system is only illustrative, and in the actual implementation process, it can be implemented with more or fewer modules.

[0107] The technical solution of this application will be described in detail below with reference to specific embodiments:

[0108] Optionally, Figure 3 This is a flowchart illustrating a concurrent task processing method provided in an embodiment of this application. The execution entity in this embodiment can be... Figure 1 The processor 102 in the code can be specifically executed based on the actual application scenario. For example... Figure 3 As shown, the method includes the following steps:

[0109] S301: In response to the processing request of the target task, obtain the account information of the target task.

[0110] The target task can be a task unit that is currently received and waiting for system processing in account-related business processing. This task unit can be a transfer request, accounting request, deduction request, crediting request, freeze / unfreeze request, settlement request, accounting adjustment request, or other processing objects that need to be executed at the account level.

[0111] In one possible embodiment, the account information includes at least one of account information, name information, and a unique identifier.

[0112] This application embodiment configures a variety of different account information, which can be applied to different application scenarios and improves the flexibility of task processing.

[0113] Optionally, the account information is used to identify the specific account associated with the target task. It is the basic identification data for subsequent account-level concurrent identification, queue occupancy marking, buffer temporary storage location, and task sequential release. The account information may include any one or more combinations of account number, sub-account number, customer number and account mapping identifier, currency dimension identifier, ledger identifier, and channel account index, as long as it can be unique or sufficient to distinguish the account processing object corresponding to the target task.

[0114] To ensure that subsequent steps can be executed reliably, standardization processing can also be performed simultaneously when obtaining account information.

[0115] Optionally, the normalization process includes at least one of the following: account field non-empty validation, character format standardization, account alias conversion, master-sub-account merging, case normalization, channel code stripping, and generating internal account key-value pairs according to preset mapping rules. For example, different channels may use different formats to represent the same account. The system can first convert the external account representation into an internal unified account index before entering the concurrency judgment process. If account information is missing, the format is invalid, or it cannot be mapped to an account entity, this embodiment of the application can transfer the task to the exception handling channel, where the exception handling module generates a failure result or compensation record to avoid invalid tasks entering the concurrency control logic and affecting system stability.

[0116] In one possible embodiment, the account information may also include auxiliary data such as task arrival time, priority identifier, and business type identifier, for subsequent sequential scheduling or anomaly recovery.

[0117] In one possible embodiment, before step S301, the method further includes: in response to a processing request of a task to be processed, obtaining account information corresponding to the task to be processed; determining whether the task to be processed belongs to a task related to a hot account based on the account information and a preset hot account judgment rule; if it belongs to a task related to a hot account, then determining the task to be processed as the target task.

[0118] Here, in this embodiment, before processing the target task, the account information of the task to be processed is first obtained. Then, based on the account information and the preset hot account judgment rules, it is determined whether the task belongs to the hot account. If it belongs to the hot account, the task is identified as the target task and enters the subsequent buffer processing flow. If it does not belong to the hot account, it does not need to enter the buffer processing flow. In this way, tasks of non-hot accounts will not perform operations such as buffer queue query and data buffer pool writing, saving screening time for non-hot tasks and further improving task processing efficiency.

[0119] S302: Based on the account information and the buffer queue, determine whether there are concurrent tasks corresponding to the account information.

[0120] In one possible embodiment, determining whether there is a concurrent task corresponding to the account information based on the account information and the buffer queue includes: performing a query process in the buffer queue based on the account information; if the account information exists in the buffer queue, then it is determined that there is a concurrent task; if the account information does not exist in the buffer queue, then it is determined that there is no concurrent task.

[0121] In this embodiment, the account information of the currently executing task is stored in the buffer queue. By querying the account information of the target task in the buffer queue, it is possible to accurately determine whether there is a concurrent task corresponding to the target task, thereby further improving the task processing efficiency.

[0122] Optionally, in this embodiment of the application, a concurrent task refers to a task that has the same account information as the target task and whose account already has other tasks being executed when the target task arrives.

[0123] In one possible implementation, when a processing request for a target task is received, if the account information for the target task already exists in the buffer queue, it means that the account currently has a task being executed, and the target task is identified as a concurrent task; if the account information does not exist in the buffer queue, it means that the account currently has no task being executed, and the target task is identified as the first task.

[0124] In this embodiment, the buffer queue is used to record account information that has entered the account-level processing state. Its function is not to store all pending tasks themselves, but to mark which accounts are currently occupied or in processing. Concurrent tasks refer to tasks that correspond to the same account information as the current target task and have entered the processing chain before the current target task or are still in a state of incomplete completion. In other words, as long as there is a record matching the current account information in the buffer queue, it can be determined that the account currently has a task being executed or is in the process of being connected, and a concurrent relationship is formed between the current target task and the prior task at the account level.

[0125] In the specific implementation, after obtaining the account information, a buffer queue is accessed for query matching. The buffer queue can be implemented based on in-memory data structures, such as hash tables, concurrent mapping tables, or state dictionaries built based on account keys. It can also be implemented based on distributed caching, such as recording account occupancy status through distributed key-value storage. Alternatively, it can be implemented using a lightweight state table in a database. However, from the perspective of response efficiency in high-concurrency scenarios, in-memory or distributed caching structures are generally more beneficial for reducing decision latency. During the query, a lookup key can be generated based on the account information, and the buffer queue is searched to see if the key already exists. If it exists, it means that the same account has already been occupied by another task, and the current target task cannot directly enter the execution chain. If it does not exist, it means that the account is not currently in the concurrent processing state defined by this method, and the current target task can obtain the processing entry point for the account.

[0126] Optionally, to avoid multiple threads repeatedly entering execution due to multiple threads simultaneously determining that an account is not occupied in high-concurrency, transient scenarios, the query buffer queue and subsequent account information writing operations can be completed atomically. For example, the system can use a compare-and-swap mechanism, distributed atomic locking commands, single-threaded event loop processing, database unique index insertion, or other methods with atomic semantics to determine and register account occupancy. In this way, even if multiple target tasks hit the same account in a very short time, only one task will successfully obtain the account processing qualification, and the remaining tasks will be transferred to the data buffer pool after the atomic determination fails, thereby avoiding disordered competition for the same account at the core accounting layer.

[0127] In one possible implementation, in addition to recording account information, the buffer queue can also synchronously record the account's current status, currently executing task identifier, last active time, number of buffered tasks, and abnormal retry flags. When determining whether concurrent tasks exist, the system can not only simply check if the account key exists, but also combine the status field to determine whether the account is in a transitional state such as executing, awaiting release, undergoing abnormal recovery, or about to be cleaned up. For scenarios involving execution timeouts or abnormal node exits, the system can also perform recovery checks on stale records in the buffer queue based on the last active time and timeout threshold to prevent abnormal legacy states from occupying the account processing entry point for an extended period.

[0128] S303: If no concurrent tasks exist, add the account information to the buffer queue and execute the target task.

[0129] In one possible embodiment, executing the target task includes: obtaining task information of the target task; and, based on the task information, invoking a preset core service to process the task information.

[0130] The task information includes at least one of the following: task processing logic, lending direction information, amount information, and category information.

[0131] Optionally, category information can be used to distinguish currencies.

[0132] In this embodiment, the processing logic, lending direction, amount, and currency parameters in the task information are parsed to invoke a preset core service to perform accounting processing. This structured extraction of task information ensures the complete transmission of processing parameters, and the core service updates the account balance according to specified logic, achieving accurate execution of the target task and improving task processing efficiency and reliability.

[0133] In this embodiment, when the judgment result of S302 indicates that the current account information has not been occupied by other tasks, it means that the target task is the first task of the account to enter the processing chain at the current moment. At this time, the system first adds the account information to the buffer queue to establish an occupation mark at the account level, and then executes the target task. The addition action here is used to declare that the account has entered the processing state controlled by this method. Subsequently, while the target task has not been processed, any new task that hits the same account information again will be identified as a concurrent task and transferred to the buffer to wait, thereby forming a single-entry serial processing mechanism with the account as the granularity.

[0134] In the specific implementation process, adding account information to the buffer queue can include the following: writing the internal key value corresponding to the account information, establishing the association between the account and the currently executing task identifier, recording the current processing status as executing, recording the start time or heartbeat time, and binding auxiliary metadata such as task source, business type, and request serial number to the account's usage record.

[0135] Optionally, write operations in the buffer queue typically need to guarantee atomicity to ensure that no two tasks can simultaneously write successfully to the same account. For single-machine deployments, this can be achieved using thread-safe containers and locking mechanisms; for distributed deployments, it can be achieved using atomic write commands from distributed caches or distributed lock services. After the account information is successfully added, the system can schedule the target task to enter the actual execution logic.

[0136] In some possible implementations, the execution of the target task can invoke the corresponding account processing flow based on the business type. For example, in a payment scenario, it can execute balance verification, credit limit verification, fund deduction, accounting record generation, and status write-back; in an accounting scenario, it can execute voucher generation, debit and credit entry posting, account balance update, and end-of-day summary marking; in a clearing scenario, it can execute clearing instruction reception, account posting, error marking, and receipt generation.

[0137] Optionally, during execution, you can either wait for the accounting result to return synchronously or use an asynchronous execution method to have it handled by a background worker thread or task executor, as long as the subsequent release logic of this method can be called back when the execution ends.

[0138] In one possible embodiment, the status information in the buffer queue can also be updated when the target task is executed, such as updating the status from occupied to processing, or recording the progress of the current step, to support anomaly monitoring and recovery.

[0139] To ensure task traceability and fault recoverability, this step can also persistently register the target task before execution. For example, the system writes the task flow, account information, request message summary, submission time, and current status to the task log table or message log before invoking core accounting capabilities. When execution is successful, the result status is updated and subsequent tasks are triggered; when execution fails, business rules determine whether to retry, roll back, or terminate. If the failure is a retryable temporary exception, a retry can be performed while maintaining the account occupancy flag, preventing subsequent tasks under the same account from skipping the failed task and disrupting the order; if the failure is a clearly defined final state, after recording the failure result, it continues to check whether there is still a next response task under the account and processes it according to the established order.

[0140] S304: If there are concurrent tasks corresponding to account information, store the target task in the data buffer pool.

[0141] In this embodiment, the data buffer pool is used to temporarily store the call information corresponding to concurrently arriving tasks.

[0142] Optionally, the data buffer pool can maintain an independent first-in-first-out queue for each account, which stores the task call information that the account is waiting to be processed.

[0143] The data buffer pool can be implemented using a memory queue or a distributed message queue to adapt to different scales of concurrent scenarios.

[0144] In this embodiment, when S302 determines that the current account information already has a corresponding record in the buffer queue, it indicates that the account already has a concurrent task occupying the processing entry point. The current target task cannot directly enter the execution chain, but needs to enter the data buffer pool to wait. The data buffer pool is used to temporarily store target tasks that cannot be executed immediately and subsequent tasks of the same account. It is essentially a storage area for tasks to be executed built around the account information, used to accommodate a large influx of tasks that have not yet obtained processing qualifications during high concurrency, and released sequentially in a predetermined order after the previous tasks are completed. The next response task is the next task to be processed retrieved from the data buffer pool after the currently executing task ends. This task can be a previously temporarily stored target task or a task that arrives later from another account.

[0145] In the specific implementation process, the corresponding storage partition in the data buffer pool is located based on the account information. The data buffer pool can be implemented using an account-level queue structure, such as establishing a first-in-first-out sub-queue for each account, or using account key-value pairs as indexes and maintaining linked lists, array queues, message partitions, or priority containers in a unified storage structure. When storing the target task in the data buffer pool, it is usually necessary to write information such as task content or task reference, unique task identifier, account information, arrival time, sequence number, business type, retry flag, and task status. To ensure that subsequent tasks can be executed sequentially according to the receiving order, this application embodiment can generate a monotonically increasing sequence number when the task enters the pool, or directly use a combination of the receiving timestamp and serial number as the sorting basis. For distributed systems, to avoid ambiguity caused by timestamp concatenation or clock skew, a central sequence, local atomic counter, or an account-level incremental sequence number generation mechanism can be used.

[0146] Optionally, the data buffer pool can be deployed in memory to improve access speed, or in middleware with persistence capabilities to improve fault recovery. For example, in scenarios with extremely high request volume and short task waiting times, a high-performance memory queue can be used; in scenarios where task loss is not required after node failure, database tables, log-type message queues, or persistent caching systems can be used. In one possible embodiment, the system can also adopt a hybrid approach of in-memory plus persistent logging, where tasks are first written to the memory queue for fast scheduling, while being asynchronously recorded to persistent storage, to balance performance and reliability.

[0147] In one possible embodiment, storing the target task in a data buffer pool includes: obtaining the call information of the target task; and writing the call information into the storage area in the data buffer pool corresponding to the account information.

[0148] The information to be retrieved includes at least one of the following: transaction serial number, lending direction information, amount information, and category information.

[0149] This application embodiment extracts call information such as transaction serial number, lending direction, amount, and currency from the target task and writes this information into the storage area corresponding to the account information in the data buffer pool. This storage area is used to store all pending task information for the account. After the write operation is completed, the task call information is temporarily stored, awaiting subsequent reading and execution. This avoids the loss of task information during the waiting period, improves the reliability of the data buffer, and further enhances the efficiency of parallel task processing.

[0150] In one possible embodiment, after writing the call information to the storage area corresponding to the account information in the data buffer pool, the method further includes: returning the response success information of the target task to the preset task caller.

[0151] The preset task initiating end includes at least one of the following: the channel terminal that initiates the processing request, the client application, or the application programming interface (API) initiating end.

[0152] In this embodiment, after writing the target task's invocation information into the data buffer pool, a success response is returned to the preset task invoking client. With this configuration, although the target task has not yet been actually executed, the upstream invoking party has already received confirmation of receipt and does not need to wait for the task to complete, reducing the upstream invoking party's waiting time and further improving the parallel processing efficiency of the task.

[0153] Once the target task is stored in the data buffer pool, it can immediately return an accepted or processing status to the upstream, avoiding long-term blocking of requests while waiting for the underlying accounting to complete, thereby improving the response experience of external calls. Alternatively, it can maintain a synchronous connection, monitoring whether it is quickly released for execution within the business-allowed waiting time, and returning to the queued status only after exceeding the threshold. Regardless of the return method used, the target task itself has been stably taken over by the system and maintains a binding relationship with the account information. Subsequent processing will continue by the release logic after the current task executed by that account is completed.

[0154] This step involves setting up a data buffer pool to handle subsequent tasks from the same account. This redirects concurrent requests that would otherwise directly impact the core processing flow to an ordered waiting area at the account level, preventing collisions between multiple tasks from the same account during the underlying accounting update, transaction registration, and lock contention phases. For hot account scenarios, without altering the upstream submission process and account architecture, a middleware buffer smooths out peak traffic, absorbing instantaneous concurrent traffic. This allows the system to transform high-concurrency input at the account level into sequential, controllable execution output, improving overall processing stability.

[0155] S305: After the concurrent task and / or the target task is completed, retrieve the next response task corresponding to the account information from the data buffer pool and execute the next response task.

[0156] The response task includes concurrent tasks and / or target tasks.

[0157] In this embodiment of the application, the term "response task" is used to refer to all tasks related to the same account information and included in the processing chain of this method. These include both concurrent tasks that have already started execution and target tasks that subsequently enter the data buffer pool to wait.

[0158] Once a task is completed, the processing entry point corresponding to that account is not immediately released. Instead, the system first checks if there are any pending tasks for that account in the data buffer pool. If so, the next response task is retrieved from the data buffer pool and processed as the new current task. Thus, a group of tasks under the same account logically forms a closed-loop processing mechanism: the first task is triggered, subsequent tasks are taken over, and the tasks are executed sequentially.

[0159] In one possible implementation, task completion can be triggered in several ways. For example, the core accounting module might notify the scheduling module via a callback interface when returning success, failure, or other final results; the asynchronous executor might send a completion event after the task ends; or the system might identify the completion of a task for a specific account by monitoring changes in the task status table. Once task completion is confirmed, the scheduling module queries the corresponding sub-queue or index partition in the data buffer pool based on the account information. When retrieving the next response task, it can be read in a preset order, typically the task writing order, or a combination of business priority, task type, and arrival order. If business rules require strict adherence to the request entry order, a first-in, first-out (FIFO) approach is used. If some tasks have higher timeliness requirements, limited priority scheduling rules can be set under the same account; however, to avoid disrupting accounting logic consistency, the priority rules must satisfy the interpretability of the order under the same business constraints.

[0160] Upon successfully retrieving the next response task, the system updates its status from "waiting" to "executing" and continues to invoke the corresponding account processing logic. At this point, because the account information remains in the buffer queue, subsequent new tasks arriving under the same account will still be considered concurrent tasks and enter the data buffer pool, ensuring that only one task for that account is ever actually executing. The process of executing the next response task can be the same as the target task execution process in S303, including pre-validation, business processing, accounting entries, result recording, and completion callback. After the task execution is complete, the system checks again whether there are still pending tasks for that account in the data buffer pool. If so, it continues to retrieve and execute tasks in a loop until all tasks for that account have been processed.

[0161] In one possible implementation, to improve throughput, the system can adopt an event-driven approach, triggering the scheduling of the next task immediately after each task is completed, instead of periodically polling the data buffer pool. This reduces waiting gaps and makes the account processing chain smoother. For abnormal execution results, the system can decide whether to continue scheduling subsequent tasks based on business rules. For example, if the failure is an independent failure that does not affect subsequent tasks, the result is recorded and the next response task is retrieved; if the failure will affect the consistency of subsequent accounting, the release of subsequent tasks for that account can be suspended, and the process can be transferred to manual intervention or compensation. In any case, whether to continue releasing the next task should be managed based on account information to ensure that the task processing status of the same account is clear and controllable.

[0162] In one possible embodiment, obtaining the next response task corresponding to the account information from the data buffer pool includes: reading the next response task corresponding to the account information from the data buffer pool according to the writing order of the response tasks corresponding to the account information in the data buffer pool.

[0163] In this embodiment, when reading the next response task from the data buffer pool, the order in which each response task was written to the data buffer pool is used to ensure that tasks written earlier are read first, and tasks written later are read later. This reading method ensures that multiple concurrent tasks of the same account are processed sequentially according to their arrival order, preventing later tasks from being executed before earlier ones, and further improving the reliability and accuracy of task processing for hot accounts.

[0164] Based on the above analysis, this step, by immediately acquiring and executing the next response task after the previous task concludes, ensures that waiting tasks in the data buffer pool are continuously released. This avoids invalid gaps in account usage between tasks and prevents subsequent tasks from returning to the global scheduling layer for further contention. This step constitutes a crucial mechanism that distinguishes this method from simple locking or single-queue schemes. It not only focuses on whether a task is intercepted but also on how intercepted tasks are received and processed in an orderly manner. With this continuous scheduling mechanism, a large number of tasks that accumulate in a short period in hot account scenarios can be organized into a stable execution sequence within a single account, thereby reducing request-response jitter, minimizing timeout accumulation, and improving the system's adaptability to sudden concurrent traffic.

[0165] S306: Once all response tasks corresponding to the account information have been completed, remove the account information from the buffer queue.

[0166] In this embodiment, when the task currently being executed by an account has ended and there is no next response task corresponding to that account in the data buffer pool, it can be determined that all response tasks for that account within this processing cycle have been completed. At this time, the system needs to remove the account information from the buffer queue to release the account's occupancy status, allowing subsequent newly arriving tasks from the same account to re-enter the execution chain as new first tasks. The removal action in the buffer queue is the end marker of the account-level processing loop, indicating that the current account is no longer in a concurrent processing state.

[0167] In the actual implementation process, before the system is ready to remove account information, it can re-verify whether the number of tasks corresponding to the account in the data buffer pool is zero, and confirm that the current execution status has been updated to the completed state, so as to avoid accidental deletion of occupied records due to state propagation delay.

[0168] Optionally, verification may include checking if the account's sub-queue is empty, checking for any in-transit tasks with unsubmitted results, and checking for any pending tasks undergoing abnormal recovery. After confirming there are no pending tasks, the system performs a buffer queue deletion operation and simultaneously cleans up temporary state data associated with the account, such as the current task identifier, heartbeat time, buffer count, error flags, and statistical metrics. For distributed deployment environments, the deletion action also needs to be atomic to prevent state inconsistencies caused by new tasks arriving under the same account at the moment of deletion. One feasible approach is to combine version numbers or status bits for protection before and after deletion, enabling newly arriving tasks to re-register after detecting that the account state has been released.

[0169] In one possible implementation, after account information is removed, if the system receives a new task processing request for that account again, the new request will be re-executed according to S301 to S305, i.e., re-acquiring account information, determining the buffer queue status, and obtaining processing eligibility when unoccupied or entering the data buffer pool when occupied. Thus, this method forms a cyclical processing mechanism around a single account that allows for repeated entry and release. To facilitate system operation and maintenance, this step can also output statistical data for this round of account processing, such as the total number of processed tasks, total time consumed, buffer peak, success / failure distribution, and number of abnormal retries, and write this data to the monitoring system or audit log to support subsequent capacity assessment and fault analysis.

[0170] This application provides a method for concurrent task processing applicable to hot accounts. When responding to a processing request for a target task, it first checks whether there are corresponding concurrent tasks being processed, combining the buffer queue and the account information of the target task, and then executes different processing strategies for the target task. By storing the account information of the processing tasks in the buffer queue, subsequent concurrent tasks are temporarily stored in the data buffer pool after being identified, avoiding multiple transactions competing for database row locks at the same time. Through the above configuration, the first task is executed directly without waiting, and subsequent tasks are automatically pulled and processed after entering the pool, forming a serial task processing chain. After all tasks are processed, the queue mark is automatically cleared, improving the efficiency of concurrent processing, avoiding long waiting times, achieving fast response, and improving task processing efficiency.

[0171] Optionally, Figure 4 This application provides a schematic diagram of the task flow direction in an embodiment, as shown below. Figure 4As shown, in this embodiment of the application, after the accounting service request is accessed through the buffer model, the account comparison is first performed and the buffer concurrent queue data is retrieved to complete the account verification. Based on the account comparison result, the business concurrent response stage is entered. After the business concurrent response is completed, on the one hand, it jumps to the queue account judgment step, and the task is scheduled from the buffer concurrent queue by the buffer queue. On the other hand, after passing through the account analysis and concurrent response modules in sequence, it is sent to the core side for processing. The output result of the buffer queue processing is written back to the buffer concurrent queue, forming a closed-loop flow logic of serial queuing and execution of tasks for the same account.

[0172] Combination Figure 4 and in the above embodiments Figure 2 This application embodiment constructs a multi-transaction processing middleware layer for hot accounts, used to automatically identify situations with a large number of user requests and excessively high peak transaction volumes. This middleware layer achieves rapid response and buffering processing for concurrent multi-transactions of hot accounts through the collaborative work of the following modules.

[0173] The buffer model access module is responsible for the unified access of the overall hot account multi-transaction concurrent fast response buffer processing model, and initially performs business processing access and traffic redirection to complete the initial concurrent traffic distribution.

[0174] Specifically, the model access module maintains a request table for the concurrent response module, providing a quick account or customer maintenance list for the concurrent queue of currently hot accounts in the buffer processing. This allows for quick confirmation of whether a corresponding hot account is currently being processed concurrently. The lifecycle of the buffer concurrent queue data is as follows: when the second concurrent request for the same account arrives, the account information is added to the queue; after the current account is processed, if the concurrent response module has corresponding pending information, the account information is stored; otherwise, the account information is removed from the queue. If the data for the account exists in the buffer concurrent queue, the corresponding request enters the concurrent response queue to await processing; if the data for the account does not exist in the buffer concurrent queue, the corresponding request is directly connected to the core side for processing.

[0175] The business concurrency response module makes judgments and identifications, and completes the diversion of business requests to the intermediate buffer layer. At the same time, this module also undertakes the identification, monitoring and early warning functions such as response time monitoring, overload early warning, and multi-level overload tracking.

[0176] Specifically, for data that has undergone account analysis and is introduced through the access layer, if the account information is in the buffered concurrent queue, the corresponding request content needs to be stored in the data buffer pool of the resource storage module. The corresponding request may include specific request information (such as transaction serial number, lending direction, transaction amount, currency, etc.). After account analysis, the account needs to be stored in the buffered concurrent queue and the corresponding call information needs to be stored in the data buffer pool for synchronization processing, completing the data synchronization queue and buffer pool operations.

[0177] Optionally, the execution logic of the business concurrency response module is implemented using the following pseudocode:

[0178] First, the system reads the account buffer queue to determine if the account information exists in it. If the account information exists, it further checks if the incoming account information meets preset conditions. If the conditions are met, the incoming account information is written to the data buffer pool; otherwise, it exits and returns a failure message. If the account information does not exist in the account buffer queue, the system directly calls the core service to process the incoming account information. After completing the above checks, the account information is written to the account buffer queue, and finally, the system exits and returns a success message.

[0179] Optionally, the logic for determining whether the call information meets the conditions is as follows: Obtain the processing logic, lending / borrowing direction, amount, and currency information from the call information; accumulate the amount in the account cache queue; and then determine whether the account balance meets the incremental amount for this transaction. For example, for a debit transaction, determine whether the current account balance minus the accumulated amount of queued tasks in the data buffer pool is still not less than the transaction amount; for a credit transaction, determine whether the current account balance plus the transaction amount does not exceed the preset limit.

[0180] In one possible implementation, a callback operation is triggered after the core service completes processing the current task. The callback logic is as follows: the account information is removed from the account buffer queue, and then it is checked again whether the account information is still in the account buffer queue (in the actual implementation, this check is used to confirm whether any new concurrent tasks have been added to the queue after the removal operation). If the account information is still in the account buffer queue, the next call information is read from the data buffer pool, and the core service is invoked to process the call information.

[0181] The aforementioned callback mechanism enables automatic task retrieval and sequential execution. When there are pending tasks in the data buffer pool, account information is retained in the account buffer queue to ensure that subsequent tasks can be continuously retrieved; when there are no pending tasks in the data buffer pool, the account information is removed from the account buffer queue, releasing queue resources.

[0182] The aforementioned intermediate-layer buffer processing model for handling concurrent multi-transactions of hot accounts enables rapid response and resolution to such requests, preventing long waiting times for channel terminals or customer callers. This solution satisfies both the rapid response requirements of upstream business processing and the orderly execution requirements of downstream accounting processing. Specifically, the first task directly calls the core service for execution, while subsequent concurrent tasks are temporarily stored in a data buffer pool and a success response is immediately returned upstream. After the current task is completed, a callback mechanism automatically retrieves the next task for processing, forming a serial task processing chain. This avoids processing blockage caused by multiple transactions simultaneously competing for database row locks.

[0183] Figure 5 A schematic diagram of the structure of a concurrent processing device for a task provided in an embodiment of this application is shown below. Figure 5 As shown, the apparatus in this embodiment includes: a first acquisition module 501, a determination module 502, a first processing module 503, a second processing module 504, a second acquisition module 505, and a third processing module 506. The concurrent processing device for the task here can be a processing device or the processor itself, or a chip or integrated circuit that implements the functions of a processor. It should be noted that the division of the first acquisition module 501, determination module 502, first processing module 503, second processing module 504, second acquisition module 505, and third processing module 506 is only a logical functional division; physically, they can be integrated or independent.

[0184] The first acquisition module is used to acquire the account information of the target task in response to the processing request of the target task.

[0185] The determination module is used to determine whether there are concurrent tasks corresponding to the account information based on the account information and the buffer queue;

[0186] The first processing module is used to add account information to the buffer queue and execute the target task if there are no concurrent tasks.

[0187] The second processing module is used to store the target task in the data buffer pool if there are concurrent tasks corresponding to account information.

[0188] The second acquisition module is used to retrieve the next response task corresponding to the account information from the data buffer pool and execute the next response task after the concurrent task and / or target task have been completed; wherein, the response task includes the concurrent task and / or target task;

[0189] The third processing module is used to remove the account information from the buffer queue after all response tasks corresponding to the account information have been executed.

[0190] In one possible embodiment, the determining module is specifically used for:

[0191] Based on the account information, perform query processing in the buffer queue;

[0192] If account information exists in the buffer queue, then concurrent tasks are confirmed to exist.

[0193] If no account information is found in the buffer queue, then it is determined that there are no concurrent tasks.

[0194] In one possible embodiment, the first processing module is specifically used for:

[0195] Obtain task information for the target task; wherein, task information includes at least one of task processing logic, lending direction information, amount information, and category information;

[0196] Based on the task information, the preset core services are invoked to process the task information.

[0197] In one possible embodiment, the second processing module is specifically used for:

[0198] Obtain the invocation information of the target task; wherein, the invocation information includes at least one of the following: transaction serial number, lending direction information, amount information, and category information;

[0199] The call information is written to the storage area in the data buffer pool corresponding to the account information.

[0200] In one possible embodiment, after the second processing module writes the call information to the storage area corresponding to the account information in the data buffer pool, the above-mentioned device further includes a caching module for:

[0201] Return the success message of the target task to the preset task caller; wherein the preset task caller includes at least one of the channel terminal that initiated the processing request, the client application, or the application programming interface caller.

[0202] In one possible embodiment, the second acquisition module is specifically used for:

[0203] Based on the writing order of the response tasks corresponding to the account information in the data buffer pool, read the next response task corresponding to the account information from the data buffer pool.

[0204] In one possible embodiment, the account information includes at least one of account information, name information, and a unique identifier.

[0205] In one possible embodiment, before the first acquisition module acquires the account information of the target task in response to the processing request of the target task, the above-mentioned apparatus further includes a filtering module for:

[0206] In response to a processing request for a pending task, obtain the account information corresponding to the pending task;

[0207] Based on account information and preset hot account judgment rules, determine whether the task to be processed belongs to the hot account.

[0208] If the task pertains to a popular account, then the task to be processed will be designated as the target task.

[0209] refer to Figure 6 The diagram illustrates a structural schematic of a concurrent processing device 600 suitable for implementing tasks according to embodiments of the present disclosure. This concurrent processing device 600 can be a terminal device or a server. The terminal device can include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, personal digital assistants (PDAs), portable Android devices (PADs), portable media players (PMPs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 6 The concurrent processing device for the task shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0210] like Figure 6 As shown, the concurrent processing device 600 for the task may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 602 or a program loaded from storage device 608 into random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the operation of the concurrent processing device 600. The processing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0211] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, magnetic tapes, hard disks, etc.; and communication devices 609. Communication device 609 allows the concurrent processing device 600 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 A concurrent processing device 600 with various devices is shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0212] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by the processing device 601, it performs the functions defined in the methods of embodiments of this disclosure.

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

[0214] The aforementioned computer-readable medium may be included in the concurrent processing device for the aforementioned task; or it may exist independently and not assembled into the concurrent processing device for the task.

[0215] The aforementioned computer-readable medium carries one or more programs that, when executed by a concurrent processing device for the task, cause the concurrent processing device for the task to perform the method shown in the above embodiments.

[0216] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0217] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two 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 the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0218] The units described in the embodiments of this disclosure can be implemented in software or in hardware. The name of a unit does not necessarily limit the unit itself; for example, the first acquisition unit can also be described as "a unit that acquires at least two Internet Protocol addresses".

[0219] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0220] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0221] The concurrent processing device for the tasks in this application embodiment can be used to execute the technical solutions in the above-described method embodiments of this application. Its implementation principle and technical effect are similar, and will not be repeated here.

[0222] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement a concurrent processing method for any of the tasks described above.

[0223] This application also provides a computer program product, including a computer program, which, when executed by a processor, is used to perform a concurrent processing method for implementing any of the tasks described above.

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

[0225] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0226] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0227] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for concurrent processing of tasks, characterized in that, include: In response to a processing request for a target task, obtain the account information for the target task; Based on the account information and the buffer queue, determine whether there is a concurrent task corresponding to the account information; If no concurrent task exists, the account information is added to the buffer queue, and the target task is executed. If there are concurrent tasks corresponding to the account information, the target task is stored in the data buffer pool; After the concurrent task and / or the target task are completed, the next response task corresponding to the account information is obtained from the data buffer pool and executed; wherein, the response task includes the concurrent task and / or the target task; Once all response tasks corresponding to the account information have been completed, the account information is removed from the buffer queue.

2. The method according to claim 1, characterized in that, The step of determining whether there is a concurrent task corresponding to the account information based on the account information and the buffer queue includes: Based on the account information, a query is performed in the buffer queue; If the account information exists in the buffer queue, then it is determined that the concurrent task exists; If the account information is not present in the buffer queue, then it is determined that there is no concurrent task.

3. The method according to claim 1, characterized in that, The execution of the target task includes: Obtain task information for the target task; wherein the task information includes at least one of task processing logic, lending direction information, amount information, and category information; Based on the task information, a preset core service is invoked to process the task information.

4. The method according to claim 1, characterized in that, The step of storing the target task in the data buffer pool includes: Obtain the invocation information of the target task; wherein, the invocation information includes at least one of transaction serial number, lending direction information, amount information, and category information; The call information is written to the storage area in the data buffer pool corresponding to the account information.

5. The method according to claim 4, characterized in that, After writing the call information to the storage area in the data buffer pool corresponding to the account information, the method further includes: The response success information of the target task is returned to the preset task calling terminal; wherein, the preset task calling terminal includes at least one of the channel terminal that initiated the processing request, the client application, or the application programming interface calling terminal.

6. The method according to claim 1, characterized in that, The step of retrieving the next response task corresponding to the account information from the data buffer pool includes: Based on the writing order of the response tasks corresponding to the account information in the data buffer pool, the next response task corresponding to the account information is read from the data buffer pool.

7. The method according to any one of claims 1 to 6, characterized in that, The account information includes at least one of account information, name information, and unique identifier.

8. The method according to any one of claims 1 to 6, characterized in that, Before obtaining the account information of the target task in response to the processing request of the target task, the method further includes: In response to a processing request for a pending task, obtain the account information corresponding to the pending task; Based on the account information and the preset hot account judgment rules, determine whether the task to be processed belongs to the hot account-related task; If the task pertains to a popular account, then the task to be processed will be designated as the target task.

9. A device for concurrent processing of tasks, characterized in that, include: The first acquisition module is used to acquire the account information of the target task in response to the processing request of the target task; The determination module is used to determine whether there is a concurrent task corresponding to the account information based on the account information and the buffer queue; The first processing module is used to add the account information to the buffer queue and execute the target task if no concurrent task exists. The second processing module is used to store the target task in the data buffer pool if there is a concurrent task corresponding to the account information. The second acquisition module is used to acquire the next response task corresponding to the account information from the data buffer pool and execute the next response task after the concurrent task and / or the target task have been completed; wherein the response task includes the concurrent task and / or the target task; The third processing module is used to remove the account information from the buffer queue after all response tasks corresponding to the account information have been executed.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

Images