Task processing method, device, equipment, readable storage medium and program product

Abstract

The present application relates to a task processing method, device, equipment, readable storage medium and program product. The method comprises: obtaining multiple task events for a first task object, each task event comprising a first task object and at least one other task object associated with the first task object; splitting each of the task events to obtain mutually independent task sub-events, wherein each of the task sub-events corresponds to a task object; determining a message queue corresponding to each of the task sub-events, and delivering each of the task sub-events to the corresponding message queue; executing the task sub-events in each of the message queues to complete task processing. The use of this method can ensure system efficiency and shorten response time, thereby improving system performance and system stability.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a task processing method, device, equipment, readable storage medium and program product. Background Art

[0002] In resource trading systems, resource security, system scalability and flexibility are key factors. The processing of large amounts of concurrent resource flow data is becoming increasingly important, and these data generated by various platforms need to be processed promptly and quickly to ensure the effectiveness of use.

[0003] For example, in a multi-threaded environment, when processing resource transfers from multiple sources to a single account, there are multiple interdependent resource transfer operations, which may cause a database deadlock. However, there is no solution to this technical problem in the related art. Summary of the invention

[0004] Based on this, it is necessary to provide a task processing method, device, computer equipment, computer-readable storage medium and computer program product that can ensure system efficiency and shorten response time in response to the above technical problems.

[0005] In a first aspect, the present application provides a task processing method, comprising:

[0006] Acquire multiple task events for a first task object, each task event including the first task object and at least one other task object associated with the first task object;

[0007] Splitting each of the task events to obtain mutually independent task sub-events, wherein each of the task sub-events corresponds to a task object;

[0008] Determine a message queue corresponding to each of the task sub-events, and deliver each of the task sub-events to the corresponding message queue;

[0009] Execute each task sub-event in the message queue to complete task processing.

[0010] In one embodiment, each of the task events is split to obtain a plurality of independent task sub-events, including:

[0011] Determining an event attribute of each of the task events;

[0012] According to the event attribute of each task event, the task event is split to obtain a first task sub-event and a second task sub-event that are independent of each other.

[0013] In one embodiment, the event attributes include resource transfer attributes and resource receiving attributes, and the task event is split according to the event attributes of each task event to obtain a first task sub-event and a second task sub-event that are independent of each other, including:

[0014] According to the resource transfer attribute and the resource reception attribute, each of the task events is split to obtain a first task sub-event corresponding to the resource transfer attribute and a second task sub-event corresponding to the resource reception attribute, wherein the first task sub-event and the second task sub-event are independent of each other.

[0015] In one embodiment, the multiple task events include a first task event and a second task event, the resources corresponding to the first task sub-event of the first task event are transferred out by the second task object, the resources corresponding to the second task sub-event of the first task event are received by the first task object, the resources corresponding to the first task sub-event of the second task event are transferred out by the first task object, and the resources corresponding to the second task sub-event of the second task event are received by a third task object.

[0016] In one embodiment, the multiple task events include multiple groups of task event groups for a first task object, each group of the task event groups includes at least a third task event and a fourth task event, the resources corresponding to the first task sub-event of the third task event are transferred out by the second task object, the resources corresponding to the second task sub-event of the third task event are received by the first task object, the resources corresponding to the first task sub-event of the fourth task event are transferred out by the third task object, and the resources corresponding to the second task sub-event of the fourth task event are received by the first task object.

[0017] In one embodiment, determining a message queue corresponding to each of the task sub-events and delivering each of the task sub-events to the corresponding message queue includes:

[0018] Determine a resource transferor identifier of each of the first task sub-events and a resource receiver identifier of each of the second task sub-events;

[0019] According to the resource transferor identifier and the resource receiver identifier, the first task sub-event and the second task sub-event corresponding to each other are added to the message queue corresponding to each other.

[0020] In one embodiment, adding the first task sub-event and the second task sub-event corresponding to each other to the corresponding message queue according to the resource transferor identifier and the resource receiver identifier includes:

[0021] Performing hash processing on each resource transferor identifier to obtain a corresponding first hash value;

[0022] Determine a corresponding first message queue identifier according to the first Hash value;

[0023] Determine a matching first message queue from a preset message queue according to the first message queue identifier, and add the first task sub-event to the first message queue;

[0024] Performing hash processing on each of the resource receiver identifiers to obtain a corresponding second hash value;

[0025] Determine a corresponding second message queue identifier according to the second Hash value;

[0026] A matching second message queue is determined from a preset message queue according to the second message queue identifier, and the second task sub-event is added to the second message queue.

[0027] In one embodiment, the first message queue identifier includes multiple shard identifiers, and determining the corresponding first message queue identifier according to the first hash value includes:

[0028] Performing a modulo process on the first Hash value to obtain modulo data;

[0029] According to the modulo data, determining the target shard identifier from a mapping relationship between the shard identifier and the modulo data;

[0030] A corresponding first message queue identifier is determined according to the target fragment identifier.

[0031] In one embodiment, delivering each of the task sub-events to a corresponding message queue includes:

[0032] Get the sub-event attributes of each task sub-event;

[0033] Each of the sub-event attributes is encapsulated according to a preset format to obtain a message corresponding to each of the task sub-events, and the message is added to a corresponding message queue.

[0034] In one embodiment, executing each task sub-event in the message queue to complete task processing includes:

[0035] Obtaining the execution time of each task sub-event in each of the message queues;

[0036] According to the execution time, the task sub-events in each of the message queues are executed to complete the resource update.

[0037] In one embodiment, executing each task sub-event in the message queue according to the execution time includes:

[0038] When the message queue is the second message queue and the task sub-event is the second task sub-event, querying the execution result of the first sub-event corresponding to the second task sub-event;

[0039] If the execution result is completed, the second task sub-event is executed.

[0040] In a second aspect, the present application further provides a task processing device, comprising:

[0041] An acquisition module, configured to acquire a plurality of task events for a first task object, each task event including the first task object and at least one other task object associated with the first task object;

[0042] An event splitting module, used for splitting each of the task events to obtain mutually independent task sub-events, wherein each of the task sub-events corresponds to a task object;

[0043] An event delivery module, used to determine the message queue corresponding to each of the task sub-events, and deliver each of the task sub-events to the corresponding message queue;

[0044] The execution module is used to execute the task sub-events in each of the message queues to complete task processing.

[0045] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0046] Acquire multiple task events for a first task object, each task event including the first task object and at least one other task object associated with the first task object;

[0047] Splitting each of the task events to obtain mutually independent task sub-events, wherein each of the task sub-events corresponds to a task object;

[0048] Determine a message queue corresponding to each of the task sub-events, and deliver each of the task sub-events to the corresponding message queue;

[0049] Execute each task sub-event in the message queue to complete task processing.

[0050] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the following steps are implemented:

[0051] Acquire multiple task events for a first task object, each task event including the first task object and at least one other task object associated with the first task object;

[0052] Splitting each of the task events to obtain mutually independent task sub-events, wherein each of the task sub-events corresponds to a task object;

[0053] Determine a message queue corresponding to each of the task sub-events, and deliver each of the task sub-events to the corresponding message queue;

[0054] Execute each task sub-event in the message queue to complete task processing.

[0055] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:

[0056] Acquire multiple task events for a first task object, each task event including the first task object and at least one other task object associated with the first task object;

[0057] Splitting each of the task events to obtain mutually independent task sub-events, wherein each of the task sub-events corresponds to a task object;

[0058] Determine a message queue corresponding to each of the task sub-events, and deliver each of the task sub-events to the corresponding message queue;

[0059] Execute each task sub-event in the message queue to complete task processing.

[0060] The above-mentioned task processing method, apparatus, computer equipment, computer-readable storage medium and computer program product obtain multiple task events for a first task object, each task event includes a first task object, and at least one other task object associated with the first task object; split each task event to obtain independent task sub-events, wherein each task sub-event corresponds to a task object; determine the message queue corresponding to each task sub-event, and deliver each task sub-event to the corresponding message queue; execute the task sub-events in each message queue to complete task processing. In other words, for multiple concurrent task events, by splitting the same event into two independently executed sub-events, the need to obtain double locks when processing resource update events and the competition for the same resource by multiple task events are avoided. This method avoids high-frequency lock acquisition and release, ensures system efficiency and shortens response time, thereby improving system performance and system stability. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0062] Figure 1 An application environment diagram of a task processing method in an embodiment;

[0063] Figure 2 is a flowchart of a task processing method in one embodiment;

[0064] Figure 3 is a schematic flow chart of step 204 in one embodiment;

[0065] Figure 4 A schematic diagram of a flow chart of a method for determining a message queue in one embodiment;

[0066] Figure 5 A schematic diagram of a flow chart of a method for determining a message queue identifier in an embodiment;

[0067] Figure 6 A schematic diagram of a parallel-to-serial model for resource transfer events in one embodiment;

[0068] Figure 7 is a structural block diagram of a task processing device in one embodiment;

[0069] Figure 8 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0070] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0071] In resource trading systems, resource security, system scalability, and flexibility are key factors. The processing of large amounts of concurrent resource flow data is becoming increasingly important, and these data generated by various platforms need to be processed promptly and quickly to ensure the effectiveness of use. For example, in a multi-threaded environment, when processing resource transfers from multiple sources to a single account, there is a high frequency of lock acquisition and release, resulting in reduced system efficiency and longer response time.

[0072] Taking the resource as funds as an example, in the accounting scenario, when processing the transfer of funds from multiple sources to a single account, the system faces multiple challenges. For example, in a multi-threaded environment, high-frequency lock acquisition and release are required, resulting in reduced system efficiency and extended response time, which in turn leads to insufficient system performance. Another example is the accounting processing events between multiple groups of hot accounts, where hot accounts refer to accounts whose operation frequency in the system is greater than the preset frequency. In the database, each balance change of an account will modify a balance field of the account, and the corresponding balance change flow and accounting flow will be inserted into the database. When multiple groups of transfer accounts modify their balances, because they are in the same transaction, the MYSQL database will frequently add row locks to these accounts. When the balance field of the same account is modified, lock competition will occur, resulting in deadlock. In addition, the system currently lacks effective message publishing and subscription services, which limits its scalability and flexibility. At the same time, the system also lacks the delayed message function, which is not efficient enough when processing tasks that need to be executed at a fixed time or operations with specific delay requirements.

[0073] Aiming at the technical problem of deadlock in the system under high concurrency, a task processing method is proposed, which obtains multiple task events for a first task object, each task event includes the first task object and at least one other task object associated with the first task object; splits each task event to obtain independent task sub-events, wherein each task sub-event corresponds to a task object; determines the message queue corresponding to each task sub-event, and delivers each task sub-event to the corresponding message queue; executes the task sub-events in each message queue to complete task processing.

[0074] The task processing method provided in the embodiment of the present application can be applied to Figure 1In the application environment shown. Among them, the terminal 102 communicates with the server 104 through the network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or it can be placed on the cloud or other network servers. The server obtains multiple task events for the first task object, each task event includes the first task object, and at least one other task object associated with the first task object; splits each task event to obtain independent task sub-events, wherein each task sub-event corresponds to a task object; determines the message queue corresponding to each task sub-event, and delivers each task sub-event to the corresponding message queue; executes the task sub-events in each message queue to complete the task processing. Among them, the terminal 102 can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, Internet of Things devices and portable wearable devices, and the Internet of Things devices can be smart speakers, smart TVs, smart air conditioners, smart car devices, projection devices, etc. Portable wearable devices can be smart watches, smart bracelets, head-mounted devices, etc. The head mounted device may be a virtual reality (VR) device, an augmented reality (AR) device, smart glasses, etc. The server 104 may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0075] In an exemplary embodiment, Figure 2 As shown, a task processing method is provided, which is applied to Figure 1 The server in the example is used to illustrate, including the following steps 202 to 208. Among them:

[0076] Step 202: Acquire multiple task events for a first task object, each task event including the first task object and at least one other task object associated with the first task object.

[0077] Among them, the task events for different application scenarios are different. For example, in the accounting scenario, the task event can be an asset transfer event; in the scenario of non-blocking I / O operations in environments such as Node.js, the task event can be a file read and write operation event. The number of task objects associated with each task event includes at least two. Taking the task event in the accounting scenario as an example, when processing accounting, the associated task objects involved include the resource transferor and the resource receiver. Furthermore, in the cross-regional accounting scenario, there will be different resource types in the two regions when cross-regional accounting. In order to ensure the normal transfer and reception of resources, a third-party task object can be added to enable the normal completion of accounting. For file read and write operation events, the associated task objects involved can be multiple file blocks in a large file. The number of file blocks can be determined based on the actual application scenario.

[0078] It should be noted that a task event is associated with at least two task objects. When a task thread executes a task event, it needs to acquire the lock of the related task object, that is, for a task event, it is necessary to acquire the related locks at the same time. In other words, in some business scenarios, an operation may require multiple steps or multiple resources, and these steps or resources are logically interdependent. In order to maintain the consistency and integrity of the data, the system will lock these resources. In view of this situation, when the task thread executes multiple task events for the first task object, there will be lock competition and high-frequency release and acquisition of the lock. Among them, in multi-threaded programming, locks are a mechanism for controlling the access of multiple threads to shared resources to ensure that only one thread can use resources at any time. Multithreading is a computing environment in which multiple threads execute concurrently and share resources, but appropriate synchronization mechanisms may be required during execution to avoid conflicts.

[0079] Exemplarily, multiple task processing requests for a first task object are monitored, a task event corresponding to each task processing request is generated, and the first task object associated with each task event and at least one other task object associated with each first task object are determined. The other task objects may be second task objects, third task objects, etc.

[0080] Step 204 , split each task event to obtain mutually independent task sub-events, wherein each task sub-event corresponds to a task object.

[0081] The mutually independent task sub-events can be understood as that when executing task sub-events belonging to the same task event, only the lock of the task object associated with the currently executed sub-task event needs to be acquired, and the locks of other task objects do not need to be acquired.

[0082] Task event splitting can be understood as the process of splitting a complex event into multiple smaller subtask events. Task event splitting can be implemented based on event attributes, event flow and logic. For example, in an accounting scenario, an accounting event will have a resource transfer and a resource reception. Based on the attributes of the event itself, an accounting event can be split into an incoming event and an outgoing event, i.e., the corresponding first subtask event and second subtask event. The task object corresponding to the first subtask event in this scenario can be the resource transferor, and the task object corresponding to the second subtask event can be the resource receiver.

[0083] For example, in a file reading and writing scenario, there are file reading and writing operations. A large file is split into multiple small blocks, each small block is added to the queue as an independent reading task, and data is written to the file in batches. Each write is an independent writing task. The reading task can be regarded as the first subtask event, and the writing task can be regarded as the second subtask event.

[0084] Step 206: determine the message queue corresponding to each task sub-event, and deliver each task sub-event to the corresponding message queue.

[0085] Among them, each task sub-event has its own corresponding message queue, and the message queue can be preset. The message queue can include a delayed message queue, a parallel-to-serial message queue, and a regular message queue, etc. Determining the message queue corresponding to each task sub-event can be to place the task sub-event into the corresponding preset message queue according to business rules. For example, in some scenarios, the task sub-event has a corresponding delay characteristic, and the task sub-event with the delay characteristic can be delivered to the corresponding delayed message queue. A message queue may have one task thread or multiple task threads. The number of threads corresponding to the message queue is specifically determined according to the actual business logic, and the number of threads is not limited here. The message queue can be but is not limited to LiteQueue. As a lightweight message queue system, LiteQueue can handle events more efficiently and improve the overall performance and stability of the system.

[0086] Deliver each task sub-event to the corresponding message queue. You can use the Redis ZADD command to add the message to the ordered set, where score is the execution time of the message and value is the message content.

[0087] Exemplarily, the message queue corresponding to each task sub-event is determined, and the ZADD command of Redis is used to add the message to the ordered set, that is, each task sub-event is delivered to the corresponding message queue, ensuring the specialization and efficiency of task sub-event processing.

[0088] Step 208, executing the task sub-events in each message queue to complete the task processing.

[0089] It should be noted that when executing task sub-events in each message queue, the peak thread corresponding to the message queue will monitor. When an event is detected entering the queue, the detected event will be picked up and handed over to the execution thread for processing. Before the execution thread processes the task sub-event to be executed, it first marks the event as being processed. If the event is already being processed or marked as failed, the status is updated. At the same time, the working thread calls the event processor to process the specific business logic. For example, when user A transfers money to user B, two events will be generated and placed in two queues. The first event is to deduct a sum of money from account A, and the second event is to add a sum of money to account B. The accounting request is delivered through the queue message. The push of the message is routed to the corresponding accounting executor according to the accounting type. The pushed messages will be reordered in the message queue to prevent concurrency problems. Once the event is successfully processed, the event is removed from the queue.

[0090] Exemplarily, each of the multiple task events for the first task object is split to obtain multiple task sub-events for each task event, and each task sub-event is delivered to its corresponding message queue. According to the business logic corresponding to the task sub-event, the task sub-events in each message queue are executed to complete task processing.

[0091] For example, in an accounting scenario, there are task events in which C and A transfer resources to B at the same time. The task event corresponding to the transfer of resources from C to B is split into a C resource transfer event and a B resource reception event. The task event corresponding to the transfer of resources from A to B is split into an A resource transfer event and a B resource reception event. Based on the business logic in the accounting scenario, the C resource transfer event, the B resource reception event, and the A resource transfer event are delivered to their respective corresponding message queues. Based on the message queue, when processing events in the message queue, they are processed according to the accounting logic in the accounting scenario. For example, the A resource transfer event is processed first. If the A resource transfer event is successfully processed, this event is deleted from the message queue. When executing the B resource reception event, the processing result of the A resource transfer event is queried. If the processing is successful, the B resource reception event is executed.

[0092] It is understandable that the A resource transfer-out event and the C resource transfer-out event can also be processed at the same time. The C resource transfer-out event and the A resource transfer-out event can be delivered to the same message queue or to different message queues. The C resource transfer-out event and the A resource transfer-out event can be delivered to the same message queue, and the order of entering the message queue can be determined according to the time when C and A initiate the resource transfer request.

[0093] In the above-mentioned task processing method, multiple task events for the first task object are obtained, each task event includes the first task object, and at least one other task object associated with the first task object; each task event is split to obtain independent task sub-events, wherein each task sub-event corresponds to a task object; the message queue corresponding to each task sub-event is determined, and each task sub-event is delivered to the corresponding message queue; the task sub-events in each message queue are executed to complete the task processing. In other words, for multiple concurrent task events, by splitting the same event into two independently executed sub-events, the need to obtain double locks when processing resource update events and the competition for the same resource by multiple task events are avoided, and high-frequency lock acquisition and release are avoided, thereby realizing the processing of multiple task events for the first task object, improving the performance of the system and ensuring the stability of the system.

[0094] Optionally, the multiple task events for the first task object include at least two of the following situations:

[0095] Case 1: Multiple task events include a first task event and a second task event. The resources corresponding to the first task sub-event of the first task event are transferred from the second task object, the resources corresponding to the second task sub-event of the first task event are received by the first task object, the resources corresponding to the first task sub-event of the second task event are transferred from the first task object, and the resources corresponding to the second task sub-event of the second task event are received by the third task object.

[0096] For example, taking the accounting scenario as an example, the task event is the accounting processing event, and the multiple task events include the first accounting processing event between account 1 and account 2, that is, the first task event; the second accounting processing event between account 2 and account 3, that is, the second task event. Since accounting needs to record a bilateral account, both accounts need to record the corresponding balance changes, among which, the first task sub-event corresponding to the first task event is transferred out by the second task object account 1, the second task sub-event corresponding to the first task event is received by the first task object account 2, the first task sub-event corresponding to the second task event is transferred out by the first task object account 2, and the second task sub-event corresponding to the second task event is received by the third task object account 3.

[0097] Case 2: Multiple task events include multiple task event groups for the first task object, each task event group includes at least a third task event and a fourth task event, the resources corresponding to the first task sub-event of the third task event are transferred out by the second task object, the resources corresponding to the second task sub-event of the third task event are received by the first task object, the resources corresponding to the first task sub-event of the fourth task event are transferred out by the third task object, and the resources corresponding to the second task sub-event of the fourth task event are received by the first task object.

[0098] For example, taking the accounting scenario as an example, the task event is an accounting processing event. In the case of accounting processing events between multiple groups of hot accounts, the hot account is account 1, and there are accounting processing events between account 2 and account 3 and account 1, that is, the third task event and the fourth task event. The resources corresponding to the first task sub-event of the third task event are transferred out by the second task object account 2, and the resources corresponding to the second task sub-event of the third task event are received by the first task object account 1. The resources corresponding to the first task sub-event of the fourth task event are transferred out by the third task object account 3, and the resources corresponding to the second task sub-event of the fourth task event are received by the first task object account 1.

[0099] In an exemplary embodiment, Figure 3 As shown, step 204 includes steps 302 to 304. Among them:

[0100] Step 302: Determine the event attributes of each task event.

[0101] The event attributes in different scenarios are different, and the event attributes may include resource transfer attributes and resource receiving attributes. The event attributes may also be read attributes and write attributes in file read and write events.

[0102] Step 304 : split the task event according to the event attribute of each task event to obtain a first task sub-event and a second task sub-event that are independent of each other.

[0103] Optionally, when the event attributes are the read attribute and the write attribute in the file read and write event, the task event is split into a first task sub-event corresponding to the read attribute and a second task sub-event corresponding to the write attribute.

[0104] In an exemplary embodiment, when the event attributes are resource transfer attributes and resource receiving attributes, the task event is split according to the event attributes of each task event to obtain a first task sub-event and a second task sub-event that are independent of each other, including: splitting each task event according to the resource transfer attribute and the resource receiving attribute to obtain a first task sub-event corresponding to the resource transfer attribute and a second task sub-event corresponding to the resource receiving attribute, the first task sub-event and the second task sub-event being independent of each other. Among them, resource transfer can be understood as outgoing payment, and resource receiving can be understood as incoming payment.

[0105] In the above embodiment, by splitting the task event according to the event attributes of each task event to obtain a first task sub-event and a second task sub-event that are independent of each other, flexible, efficient and robust processing of complex tasks can be achieved, which helps to build a more reliable and maintainable system.

[0106] According to the business requirements of different scenarios, on the basis of splitting multiple task events of the first task object, the split task sub-events are delivered to the corresponding message queues. In an exemplary embodiment, a method for determining a message queue is provided, such as Figure 4 As shown, it includes steps 402 to 404, wherein:

[0107] Step 402: Determine the resource transferor identifier of each first task sub-event and the resource receiver identifier of each second task sub-event.

[0108] The resource transferor identifier can be understood as the account identifier of the outgoing account, and the resource recipient identifier can be understood as the account identifier of the incoming account.

[0109] Step 404: according to the resource transferor identifier and the resource receiver identifier, the first task sub-event and the second task sub-event corresponding to each other are added to the corresponding message queues.

[0110] Among them, according to the resource transferor identifier and the resource recipient identifier, the message queues corresponding to the first task sub-event and the second task sub-event are determined respectively. This can be determined based on the mapping relationship between the resource transferor identifier, the resource recipient identifier and the message queue identifier, or it can be determined based on hash processing of the resource transferor identifier and the resource recipient identifier.

[0111] Exemplarily, the message queue corresponding to the first task sub-event is determined according to a first mapping relationship between the resource transferor identifier and the message queue identifier, and the message queue corresponding to the second task sub-event is determined according to a second mapping relationship between the resource receiver identifier and the message queue identifier.

[0112] In the above embodiment, according to the resource transferor identifier and the resource recipient identifier, the corresponding first task sub-event and the second task sub-event are added to the corresponding message queues, which can meet the needs of the corresponding business scenarios and process resource transfer-related tasks more efficiently, flexibly and stably, while providing better maintainability and scalability.

[0113] Optionally, in an exemplary embodiment, according to the resource transferor identifier and the resource recipient identifier, the corresponding first task sub-event and the second task sub-event are added to the corresponding message queues, including: performing hash processing on each resource transferor identifier to obtain a corresponding first hash value; determining a corresponding first message queue identifier according to the first hash value; determining a matching first message queue from a preset message queue according to the first message queue identifier, and adding the first task sub-event to the first message queue; performing hash processing on each resource recipient identifier to obtain a corresponding second hash value; determining a corresponding second message queue identifier according to the second hash value; determining a matching second message queue from the preset message queue according to the second message queue identifier, and adding the second task sub-event to the second message queue.

[0114] Among them, hash processing can be implemented by an existing hash algorithm, which will not be described in detail here. It should be noted that when the resource transferor identifier and the resource receiver identifier are the same, that is, the same task object, the first task sub-event and the second task sub-event of the task object can be in the same message queue. For example, the outgoing event (i.e., the first task sub-event) and the incoming event (i.e., the second task sub-event) of account B can be in the same message queue X.

[0115] In the above embodiment, the resource transferor identifier and the resource recipient identifier are hashed to determine the corresponding message queue, which can meet the needs of different business scenarios. For example, sub-events can be processed in parallel in multiple queues to improve the system's processing capabilities and response speed. In addition, it can also better handle high-concurrency scenarios and improve the system's ability to handle a large number of requests.

[0116] On the basis of determining the message queue according to the resource transferor identifier and the resource receiver identifier, in order to further more efficiently process a large number of concurrent messages and improve the stability and scalability of the system, the message queue can be sharded. The message queue shards can process messages independently, thereby improving the overall processing capacity and throughput.

[0117] In an exemplary embodiment, Figure 5 As shown, a method for determining a message queue identifier is provided, comprising steps 502 to 506, wherein:

[0118] Step 502: Perform modulo processing on the first Hash value to obtain modulo data.

[0119] The first message queue identifier includes multiple shard identifiers. The modulo processing can determine the array index corresponding to the hash value, that is, the corresponding shard identifier.

[0120] Step 504: Determine the target slice identifier from the mapping relationship between the slice identifier and the slice identifier according to the modulo data.

[0121] Step 506: Determine the corresponding first message queue identifier according to the target shard identifier.

[0122] It should be noted that the method for determining the second message queue identifier can also be implemented in this way, which will not be elaborated here.

[0123] In this embodiment, by performing a modulo process on the first hash value to determine the corresponding first message queue identifier, the allocation of the message queue can be achieved to meet actual business needs.

[0124] Optionally, in an exemplary embodiment, each task sub-event is delivered to a corresponding message queue, including: obtaining the sub-event attributes of each task sub-event; encapsulating each sub-event attribute according to a preset format to obtain a message corresponding to each task sub-event, and adding the message to the corresponding message queue.

[0125] Each message contains sub-event attributes, including message content and execution time (UNIX timestamp). The execution time specifies the specific time when the message should be processed. The message content includes the scenario transaction ID, account ID, business processing type, business processing logic, and custom fields related to the business. Taking the task sub-event as a transfer event or an outgoing event as an example, the corresponding sub-task attributes include the logic of the transfer event, account ID, transfer amount and other related attributes.

[0126] Optionally, in an exemplary embodiment, executing task sub-events in each message queue to complete task processing includes: obtaining the execution time of each task sub-event in each message queue; and executing the task sub-events in each message queue according to the execution time to complete task processing.

[0127] The task sub-event may be a first task sub-event and / or a second task sub-event.

[0128] It should be noted that in the business system, some logic needs to be processed after a delay, such as automatically closing the order if the card opening fee is not paid within 10 minutes after the order is placed. Or in the monitoring scenario, in a distributed system, a business order often requires support from multiple systems, and each system will have its own orders. For example, if the orders generated by the downstream systems are not received within 5 seconds, early warning and other operations are required. The delayed message processing mechanism based on Redis can achieve delayed triggering in seconds. By adding the delayed message function, the processing efficiency is improved when processing tasks that need to be executed at a fixed time or operations with specific delay requirements.

[0129] Furthermore, the message queue is based on Redis list storage, that is, using Redis list data structure to store message queues, using its fast insertion and deletion operations to support efficient message processing. And using the API provided by Redis list, such as LPUSH and BRPOP, to implement message publishing and subscription functions, ensuring real-time message delivery and processing. Based on effective message publishing and subscription services, the scalability and flexibility of the system are improved.

[0130] Exemplarily, periodically check whether there are expired messages in each message queue, that is, whether there is a delayed field. For delayed messages, they are processed regularly. Use the ZRANGEBYSCORE command to select all messages whose score is less than or equal to the current time. Execute the corresponding business logic for each expired message. After processing, use the ZREM command to remove the message from the collection to prevent duplicate processing. For example, in the case of multiple message queues, each message queue corresponds to a different thread. For each queue, it is possible to periodically check whether there are expired task sub-events in each message queue.

[0131] In the above embodiment, the message-based execution time can reduce conflicts in task execution time and ensure that tasks are executed in a predetermined time sequence.

[0132] Considering different actual business scenarios, in an exemplary embodiment, executing the task sub-events in each of the message queues according to the execution time includes:

[0133] When the message queue is the second message queue and the task sub-event is the second task sub-event, the execution result of the first sub-event corresponding to the second task sub-event is queried; if the execution result is completed, the second task sub-event is executed.

[0134] Among them, the second message queue includes the second task sub-event of the resource receiver, that is, the income event. When the execution thread of the second message queue processes the income event, it can obtain the execution result of the first task sub-event corresponding to the event, that is, whether the outgoing event is successfully executed. When the outgoing event is successfully executed, the income event is executed. It can be understood that when there are multiple second task sub-events for the same task object in the second message queue, the multiple second task sub-events can be executed in parallel or by one thread, which is specifically set according to business needs and is not limited here. In this way, the processing based on the first task sub-event handles complex task dependencies more intelligently, ensuring that tasks are executed in the correct order and conditions, thereby improving the overall system performance and stability.

[0135] Optionally, in an exemplary embodiment, a task processing method is provided, including: obtaining multiple task events for a first task object, each task event including a first task object and at least one other task object associated with the first task object; determining the event attributes of each task event; splitting the task event according to the event attributes of each task event to obtain mutually independent first task sub-events and second task sub-events. Determine the resource transferor identifier of each first task sub-event and the resource receiver identifier of each second task sub-event; according to the resource transferor identifier and the resource receiver identifier, add the first task sub-event and the second task sub-event corresponding to each other to the corresponding message queue. Obtain the execution time of each task sub-event in each message queue; execute the task sub-events in each message queue according to the execution time to complete the task processing.

[0136] It should be noted that the specific implementation method can be achieved through the above method, which will not be repeated here. Taking the application scenario of accounting as an example, Figure 6 As shown, it is a schematic diagram of a parallel-to-serial model of resource transfer events in an embodiment. ABDE all need to transfer money to C at the same time. The four transfer events are split into ABDE outgoing events and corresponding four C incoming events. The split task sub-events are added to the corresponding message queues according to the account identifiers of ABDE and C, that is, the outgoing events Ax and Ex of A and E are added to the first message queue Q1, the outgoing events Bx and Dx of B and D are added to the second message queue Q2, and the incoming event C+x+x+x+x of C is added to the second message queue Q2. The task thread monitors whether the messages in each queue need to be executed, that is, the task sub-events. If execution is required, each message is executed by the task thread. When the execution is completed, the message is deleted from the message queue.

[0137] Taking the accounting scenario as an example, the above approach can handle concurrent operations more effectively while providing higher system reliability and scalability. Serialization reduces lock contention, the message service enhances the system's decoupling and event-driven capabilities, and the delayed message function supports complex business logic requirements. These integrated solutions together improve the overall system performance and user experience, ensuring the security and accuracy of transactions.

[0138] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0139] Based on the same inventive concept, the embodiment of the present application also provides a task processing device for implementing the task processing method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more task processing device embodiments provided below can refer to the limitations on the task processing method above, and will not be repeated here.

[0140] In an exemplary embodiment, Figure 7 As shown, a task processing device is provided, including: an acquisition module 702, an event splitting module 704, an event delivery module 706 and an execution module 708, wherein:

[0141] The acquisition module 702 is used to acquire multiple task events for a first task object, each task event including the first task object and at least one other task object associated with the first task object.

[0142] The event splitting module 704 is used to split each task event into independent task sub-events, wherein each task sub-event corresponds to a task object.

[0143] The event delivery module 706 is used to determine the message queue corresponding to each task sub-event and deliver each task sub-event to the corresponding message queue.

[0144] The execution module 708 is used to execute the task sub-events in each message queue to complete the task processing.

[0145] The above-mentioned task processing device obtains multiple task events for the first task object, each task event includes the first task object, and at least one other task object associated with the first task object; splits each task event to obtain independent task sub-events, wherein each task sub-event corresponds to a task object; determines the message queue corresponding to each task sub-event, and delivers each task sub-event to the corresponding message queue; executes the task sub-events in each message queue to complete task processing. In other words, for multiple concurrent task events, by splitting the same event into two independently executed sub-events, the need to obtain double locks when processing resource update events and the competition for the same resource by multiple task events are avoided. This method avoids high-frequency lock acquisition and release, ensures system efficiency and shortens response time, thereby improving system performance and system stability.

[0146] In an exemplary embodiment, the event splitting module 704 is further used to determine the event attributes of each task event;

[0147] According to the event attribute of each task event, the task event is split to obtain a first task sub-event and a second task sub-event that are independent of each other.

[0148] In an exemplary embodiment, the event attributes include resource transfer attributes and resource reception attributes. The event splitting module 704 is also used to split each task event according to the resource transfer attributes and the resource reception attributes to obtain a first task sub-event corresponding to the resource transfer attribute and a second task sub-event corresponding to the resource reception attribute. The first task sub-event and the second task sub-event are independent of each other.

[0149] In an exemplary embodiment, multiple task events include a first task event and a second task event, the resources corresponding to the first task sub-event of the first task event are transferred out by the first task object, the resources corresponding to the second task sub-event of the first task event are received by the second task object, the resources corresponding to the first task sub-event of the second task event are transferred out by the second task object, and the resources corresponding to the second task sub-event of the second task event are received by the third task object.

[0150] In an exemplary embodiment, multiple task events include multiple task event groups for a first task object, each task event group includes at least a third task event and a fourth task event, the resources corresponding to the first task sub-event of the third task event are transferred from the first task object, the resources corresponding to the second task sub-event of the third task event are received by the second task object, the resources corresponding to the first task sub-event of the fourth task event are transferred from the third task object, and the resources corresponding to the second task sub-event of the fourth task event are received by the second task object.

[0151] In an exemplary embodiment, the event delivery module 706 is further used to determine the resource transferor identifier of each first task sub-event and the resource receiver identifier of each second task sub-event;

[0152] According to the resource transferor identifier and the resource receiver identifier, the first task sub-event and the second task sub-event corresponding to each other are added to the message queue corresponding to each other.

[0153] In an exemplary embodiment, the task processing device further includes a data processing module, which is used to perform hash processing on each resource transferor identifier to obtain a corresponding first hash value;

[0154] Determine a corresponding first message queue identifier according to the first hash value.

[0155] In an exemplary embodiment, the event delivery module 706 is further configured to determine a matching first message queue from preset message queues according to the first message queue identifier, and add the first task sub-event to the first message queue.

[0156] In an exemplary embodiment, the data processing module is further used to perform hash processing on each resource receiver identifier to obtain a corresponding second hash value;

[0157] Determine a corresponding second message queue identifier according to the second hash value.

[0158] In an exemplary embodiment, the event delivery module 706 is further configured to determine a matching second message queue from preset message queues according to the second message queue identifier, and add the second task sub-event to the second message queue.

[0159] In an exemplary embodiment, the data processing module is further used to perform modulo processing on the first hash value to obtain modulo data;

[0160] According to the modulo data, determine the target shard identifier from the mapping relationship between the shard identifier and the modulo data;

[0161] Determine the corresponding first message queue identifier according to the target shard identifier.

[0162] In an exemplary embodiment, the event delivery module 706 is further used to obtain sub-event attributes of each task sub-event;

[0163] Each sub-event attribute is encapsulated according to a preset format to obtain a message corresponding to each task sub-event, and the message is added to the corresponding message queue.

[0164] In an exemplary embodiment, the execution module 708 is further used to obtain the execution time of each task sub-event in each message queue;

[0165] According to the execution time, execute the task sub-events in each message queue to complete the task processing.

[0166] In an exemplary embodiment, the execution module 708 is further configured to query the execution result of the first sub-event corresponding to the second task sub-event when the message queue is the second message queue and the task sub-event is the second task sub-event;

[0167] If the execution result is completed, the second task sub-event is executed.

[0168] Each module in the above task processing device can be implemented in whole or in part by software, hardware or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.

[0169] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 8 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store task processing data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a task processing method is implemented.

[0170] Those skilled in the art will understand that Figure 8 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0171] In an exemplary embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above-mentioned method embodiments when executing the computer program.

[0172] In an exemplary embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0173] In an exemplary embodiment, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0174] 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, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0175] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0176] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0177] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A task processing method, characterized in that: The method comprises: Acquire multiple task events for a first task object, each task event including the first task object and at least one other task object associated with the first task object; Splitting each of the task events to obtain mutually independent task sub-events, wherein each of the task sub-events corresponds to a task object; Determine a message queue corresponding to each of the task sub-events, and deliver each of the task sub-events to the corresponding message queue; Execute each task sub-event in the message queue to complete task processing; The splitting of each task event to obtain multiple independent task sub-events includes: Determining event attributes of each of the task events; the event attributes include resource transfer attributes and resource reception attributes; According to the resource transfer attribute and the resource receiving attribute, each of the task events is split to obtain a first task sub-event corresponding to the resource transfer attribute and a second task sub-event corresponding to the resource receiving attribute, wherein the first task sub-event and the second task sub-event are independent of each other; the task object corresponding to the first task sub-event is the resource transferor, and the task object corresponding to the second task sub-event is the resource receiver.

2. The method according to claim 1, characterized in that: The multiple task events include a first task event and a second task event. The resources corresponding to the first task sub-event of the first task event are transferred from the second task object, the resources corresponding to the second task sub-event of the first task event are received by the first task object, the resources corresponding to the first task sub-event of the second task event are transferred from the first task object, and the resources corresponding to the second task sub-event of the second task event are received by the third task object.

3. The method according to claim 1, characterized in that The multiple task events include multiple groups of task event groups for the first task object, each group of the task event group includes at least a third task event and a fourth task event, the resources corresponding to the first task sub-event of the third task event are transferred out by the second task object, the resources corresponding to the second task sub-event of the third task event are received by the first task object, the resources corresponding to the first task sub-event of the fourth task event are transferred out by the third task object, and the resources corresponding to the second task sub-event of the fourth task event are received by the first task object.

4. The method according to any one of claims 1 to 3, characterized in that: The determining a message queue corresponding to each of the task sub-events and delivering each of the task sub-events to the corresponding message queue includes: Determine a resource transferor identifier of each of the first task sub-events and a resource receiver identifier of each of the second task sub-events; According to the resource transferor identifier and the resource receiver identifier, the first task sub-event and the second task sub-event corresponding to each other are added to the message queue corresponding to each other.

5. The method according to claim 4, characterized in that The adding the first task sub-event and the second task sub-event corresponding to each other to the corresponding message queues according to the resource transferor identifier and the resource receiver identifier includes: Performing hash processing on each resource transferor identifier to obtain a corresponding first hash value; Determine a corresponding first message queue identifier according to the first Hash value; Determine a matching first message queue from a preset message queue according to the first message queue identifier, and add the first task sub-event to the first message queue; Performing hash processing on each of the resource receiver identifiers to obtain a corresponding second hash value; Determine a corresponding second message queue identifier according to the second Hash value; A matching second message queue is determined from a preset message queue according to the second message queue identifier, and the second task sub-event is added to the second message queue.

6. The method according to claim 5, characterized in that The first message queue identifier includes a plurality of shard identifiers, and determining the corresponding first message queue identifier according to the first hash value includes: Performing a modulo process on the first Hash value to obtain modulo data; According to the modulo data, determining the target shard identifier from a mapping relationship between the shard identifier and the modulo data; A corresponding first message queue identifier is determined according to the target fragment identifier.

7. The method according to claim 6, characterized in that The delivering each of the task sub-events to the corresponding message queue includes: Get the sub-event attributes of each task sub-event; Each of the sub-event attributes is encapsulated according to a preset format to obtain a message corresponding to each of the task sub-events, and the message is added to a corresponding message queue.

8. The method according to claim 7, characterized in that The executing of each task sub-event in the message queue to complete task processing includes: Obtaining the execution time of each task sub-event in each of the message queues; According to the execution time, the task sub-events in each of the message queues are executed to complete the task processing.

9. The method according to claim 8, characterized in that The executing of each task sub-event in the message queue according to the execution time includes: When the message queue is the second message queue and the task sub-event is the second task sub-event, querying the execution result of the first sub-event corresponding to the second task sub-event; If the execution result is completed, the second task sub-event is executed.

10. A task processing device, characterized in that: The device comprises: An acquisition module, configured to acquire a plurality of task events for a first task object, each task event including the first task object and at least one other task object associated with the first task object; An event splitting module, used for splitting each of the task events to obtain mutually independent task sub-events, wherein each of the task sub-events corresponds to a task object; The event splitting module is further used to determine the event attributes of each of the task events; the event attributes include resource transfer attributes and resource reception attributes; According to the resource transfer attribute and the resource receiving attribute, each of the task events is split to obtain a first task sub-event corresponding to the resource transfer attribute and a second task sub-event corresponding to the resource receiving attribute, wherein the first task sub-event and the second task sub-event are independent of each other; the task object corresponding to the first task sub-event is the resource transferor, and the task object corresponding to the second task sub-event is the resource receiver; An event delivery module, used to determine the message queue corresponding to each of the task sub-events, and deliver each of the task sub-events to the corresponding message queue; The execution module is used to execute the task sub-events in each of the message queues to complete task processing.

11. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 9 are implemented.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.

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

Images