Task processing method and device, computer device, storage medium and program product

Abstract

The application relates to a task processing method and device, computer equipment, a storage medium and a program product. A bit field segmentation isolation coding mode is adopted, attribute data of each dimension is independently mapped into a specified bit segment of a fixed length coding space, and then a single target sub-coding is synthesized through a bitwise OR operation, the carry interference problem of a traditional weighted summation method is avoided, the strict dictionary partial order relationship between multi-dimensional attribute data is reserved, a task sorting result meets a business scheduling expectation, and the accuracy of task scheduling is improved.

Description

Technical Field

[0001] This application relates to the field of task scheduling technology, and in particular to a task processing method, apparatus, computer equipment, storage medium, and program product. Background Technology

[0002] With the widespread adoption of microservices and cloud-native architectures, asynchronous task queues have become a crucial infrastructure for achieving business decoupling, traffic smoothing, and distributed task collaboration. They are widely used in various business scenarios such as order processing, message push, scheduled batch processing, and asynchronous notifications. Task queue sorting is typically implemented using a Sorted Set (ZSet) from a remote dictionary service (Redis).

[0003] In traditional techniques, a preset weight coefficient is usually assigned to the sorting attribute corresponding to each task. The attribute value is multiplied by the corresponding weight and then summed. The resulting comprehensive score is used as the sorting score of the Redis ZSet. The tasks are then prioritized based on their corresponding scores.

[0004] However, in the above sorting method, the accumulation of low-priority attribute values ​​will produce a carry effect, which may result in a situation where the overall score of low-priority tasks is higher than that of high-priority tasks, leading to a discrepancy with the true priority of task scheduling and a problem of low task scheduling accuracy. Summary of the Invention

[0005] Therefore, it is necessary to provide a task processing method, apparatus, computer equipment, storage medium, and program product to address the aforementioned technical problems and improve the accuracy of task scheduling.

[0006] Firstly, this application provides a task processing method, including:

[0007] Upon receiving a task to be executed, acquire attribute data for at least one dimension of the task to be executed;

[0008] Each attribute data is encoded separately to obtain the initial sub-encoder corresponding to each attribute data;

[0009] For each initial sub-encoder, the initial sub-encoder is written into the initial encoding space at the offset position corresponding to the initial sub-encoder to obtain the intermediate sub-encoder corresponding to the initial sub-encoder; wherein, the initial encoding space is an encoding space of a preset length corresponding to the initial sub-encoder;

[0010] Perform a bitwise OR operation on each intermediate sub-encoder to obtain the target sub-encoder;

[0011] The tasks to be executed are sorted in the task queue according to the target sub-encoding.

[0012] In one embodiment, the target sub-encoding includes at least an encoding corresponding to the task execution state of the task to be executed, and the step of sorting the tasks to be executed in the task queue according to the target sub-encoding includes:

[0013] The execution status of the task to be executed is determined based on the code corresponding to the task execution status.

[0014] Based on the execution status of the task to be executed, add the task to its respective task queue; and,

[0015] The order in which the tasks to be executed are arranged in the task queue is determined based on the target sub-encoding.

[0016] In one embodiment, the task queue includes a real-time task queue and a delayed task queue; after determining the order of the tasks to be executed in the task queue according to the target sub-encoding, the method further includes:

[0017] Once the pending tasks in the delayed task queue meet the execution conditions, the pending tasks are transferred to the real-time task queue; and,

[0018] The order of the tasks to be executed in the real-time task queue is determined based on the target sub-code corresponding to the task to be executed.

[0019] In one embodiment, the method further includes:

[0020] The code corresponding to the task execution status of the target task in the real-time task queue is updated to the target value; wherein, the target task is the task at the front of the queue, and the target value is used to indicate that the target task is in the execution state;

[0021] Send the task identifier of the target task to the task execution terminal; wherein the task identifier is used to instruct the task execution terminal to obtain the task execution parameters of the target task and execute the target task based on the task execution parameters.

[0022] In one embodiment, each attribute data includes at least a creation timestamp and an expiration timestamp. The step of encoding each attribute data to obtain an initial sub-encoder corresponding to each attribute data includes:

[0023] Determine the creation offset of the creation timestamp relative to the base time, and encode the creation offset to obtain the initial sub-encode corresponding to the creation offset; and,

[0024] Determine the failure offset of the failure timestamp relative to the reference time, and encode the failure offset to obtain the sub-code corresponding to the failure offset.

[0025] In one embodiment, the step of encoding each attribute data to obtain an initial sub-encoder corresponding to each attribute data includes:

[0026] For each attribute data, determine whether the attribute data satisfies the bit width constraint condition; wherein, the bit width constraint condition includes the attribute data being less than or equal to the constraint value, and the constraint value is determined according to the bit width corresponding to the attribute data;

[0027] Under the condition that the bit width constraint is met, the attribute data is encoded to obtain the initial sub-encoder corresponding to the attribute data.

[0028] Secondly, this application also provides a task processing apparatus, comprising:

[0029] The acquisition module is used to acquire attribute data of at least one dimension of the task to be executed after receiving the task to be executed;

[0030] The encoding module is used to encode each attribute data separately to obtain the initial sub-encoder corresponding to each attribute data;

[0031] The writing module is used to write the initial sub-encoder into the initial encoding space at the offset position corresponding to the initial sub-encoder for each initial sub-encoder, thereby obtaining the intermediate sub-encoder corresponding to the initial sub-encoder; wherein, the initial encoding space is an encoding space of a preset length corresponding to the initial sub-encoder;

[0032] The arithmetic module is used to perform bitwise OR operations on each intermediate sub-encoder to obtain the target sub-encoder;

[0033] The sorting module is used to sort the tasks to be executed in the task queue according to the target sub-encoding.

[0034] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0035] Upon receiving a task to be executed, acquire attribute data for at least one dimension of the task to be executed;

[0036] Each attribute data is encoded separately to obtain the initial sub-encoder corresponding to each attribute data;

[0037] For each initial sub-encoder, the initial sub-encoder is written into the initial encoding space at the offset position corresponding to the initial sub-encoder to obtain the intermediate sub-encoder corresponding to the initial sub-encoder; wherein, the initial encoding space is an encoding space of a preset length corresponding to the initial sub-encoder;

[0038] Perform a bitwise OR operation on each intermediate sub-encoder to obtain the target sub-encoder;

[0039] The tasks to be executed are sorted in the task queue according to the target sub-encoding.

[0040] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0041] Upon receiving a task to be executed, acquire attribute data for at least one dimension of the task to be executed;

[0042] Each attribute data is encoded separately to obtain the initial sub-encoder corresponding to each attribute data;

[0043] For each initial sub-encoder, the initial sub-encoder is written into the initial encoding space at the offset position corresponding to the initial sub-encoder to obtain the intermediate sub-encoder corresponding to the initial sub-encoder; wherein, the initial encoding space is an encoding space of a preset length corresponding to the initial sub-encoder;

[0044] Perform a bitwise OR operation on each intermediate sub-encoder to obtain the target sub-encoder;

[0045] The tasks to be executed are sorted in the task queue according to the target sub-encoding.

[0046] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0047] Upon receiving a task to be executed, acquire attribute data for at least one dimension of the task to be executed;

[0048] Each attribute data is encoded separately to obtain the initial sub-encoder corresponding to each attribute data;

[0049] For each initial sub-encoder, the initial sub-encoder is written into the initial encoding space at the offset position corresponding to the initial sub-encoder to obtain the intermediate sub-encoder corresponding to the initial sub-encoder; wherein, the initial encoding space is an encoding space of a preset length corresponding to the initial sub-encoder;

[0050] Perform a bitwise OR operation on each intermediate sub-encoder to obtain the target sub-encoder;

[0051] The tasks to be executed are sorted in the task queue according to the target sub-encoding.

[0052] The aforementioned task processing methods, devices, computer equipment, storage media, and program products employ a bit-field segmented isolation encoding method. This method independently maps the attribute data of each dimension to a specified bit segment in a fixed-length encoding space, and then synthesizes them into a single target sub-encoder through bitwise OR operations. This avoids the carry interference problem of the traditional weighted summation method, preserves the strict lexicographical partial order relationship between multi-dimensional attribute data, and ensures that the task sorting results meet business scheduling expectations, thereby improving the accuracy of task scheduling. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0054] Figure 1 This is a flowchart illustrating a task processing method in one embodiment;

[0055] Figure 2 This is a flowchart illustrating the process of sorting tasks to be executed in one embodiment;

[0056] Figure 3 This is a structural diagram of a task processing system in one embodiment;

[0057] Figure 4 This is a data flow diagram in one embodiment;

[0058] Figure 5 Here is a task scheduling flowchart for one embodiment;

[0059] Figure 6 This is a structural block diagram of a task processing device in one embodiment;

[0060] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0062] The task processing method provided in this application can be applied to application scenarios where tasks are prioritized during task scheduling.

[0063] This method can be executed by a server or a terminal. The server can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server providing cloud computing services. The terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle systems, and projection devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses.

[0064] In one exemplary embodiment, such as Figure 1 As shown, a task processing method is provided. Taking the application of this method to a server as an example, it includes the following steps:

[0065] S101, after receiving the task to be executed, obtain attribute data of at least one dimension of the task to be executed.

[0066] The tasks to be executed are those generated by the business system, including but not limited to order processing, message push, scheduled batch processing, asynchronous notification, and other types of tasks.

[0067] The attribute data consists of multi-dimensional parameters used to characterize task scheduling features, including discrete enumeration type and continuous numerical type parameters.

[0068] For example, when a business system generates an asynchronous task processing requirement, it sends a task creation request to the producer, which carries the task's business parameters and scheduling rules. After receiving the task creation request, the producer first generates a globally unique task identifier using the snowflake algorithm or a Universally Unique Identifier (UUID) mechanism to ensure that each task has a unique identity; then, it extracts at least one dimension of attribute data from the request for sorting and scheduling.

[0069] Attribute data can include multiple dimensions to adapt to complex scheduling strategies. For example, it can include discrete enumerated attributes, such as primary priority, business line, task type, etc. These attributes take finite enumerated values ​​and are used to implement hierarchical and classified management of tasks. It can also include continuous numerical attributes, such as creation timestamp, expiration timestamp, etc. These attributes are continuous time values ​​and are used to implement time-series scheduling and expiration control of tasks.

[0070] During the process of acquiring attribute data, the producer can perform preliminary format validation to ensure that the data type and value range conform to the preset specifications and prevent illegal parameters from entering the subsequent coding process.

[0071] S102, encode each attribute data separately to obtain the initial sub-encoder corresponding to each attribute data.

[0072] The initial sub-encoding is the raw binary code value obtained after numerical conversion of single-dimensional attribute data. It has not yet undergone bit field offset and only corresponds to the semantic value range of the attribute itself.

[0073] For example, different encoding methods can be used for different types of attribute data. For example, for discrete enumeration attributes, such as primary priority, business line, task type, etc., their enumeration sequence number can be directly converted into an unsigned binary number with the corresponding bit width. For example, an 8-bit primary priority can support 256 priority levels from 0 to 255, and a 6-bit business line can support 64 business fields from 0 to 63, which can cover the business division needs of most enterprises.

[0074] For continuous numerical attributes, such as timestamp attributes, preprocessing is required before encoding. For example, first, the absolute timestamp is converted into an offset relative to a preset base time, typically the system's launch time as the zero point. The relative offset value is obtained by the difference between the absolute time and the base time. Second, the time granularity can be adjusted according to business precision requirements. For example, creation time can be granularized to seconds, and expiration time to minutes, further compressing the numerical range without affecting business performance. The preprocessed attribute value is then converted into a binary number with the corresponding bit width, yielding the initial sub-encoding for that attribute.

[0075] The bit width of the initial sub-encoder corresponds one-to-one with the value range of the attribute. The bit width design follows the principle of just covering the maximum value of the business logic, avoiding wasted bit width, and thus accommodating more dimensions of attributes within a limited encoding space. The initial sub-encoder of each attribute only carries the semantics of its own dimension and does not involve the positional relationship with other attributes. Therefore, it is an independent and individually verifiable basic encoding unit.

[0076] S103, for each initial sub-code, write the initial sub-code into the initial coding space at the offset position corresponding to the initial sub-code to obtain the intermediate sub-code corresponding to the initial sub-code.

[0077] The initial encoding space is a preset length encoding space corresponding to the initial sub-encoding, used to carry the encoding of attribute data of all dimensions, such as a 64-bit unsigned integer space.

[0078] The offset position is the starting position number of the initial sub-encoder of a certain attribute data in the initial encoding space, and its value is equal to the sum of the bit widths of all other attribute data with lower sorting priority than this attribute data.

[0079] The intermediate sub-encoder is the encoding result obtained by logically shifting the initial sub-encoder to the left according to the corresponding offset position and writing it into the specified bit segment of the initial encoding space. It has only valid binary bits in its own bit field, and the rest of the bits are 0.

[0080] For example, the initial encoding space can be a 64-bit unsigned integer space. This length is suitable for the numerical precision of most programming languages ​​and databases, and is also sufficient to support 3-6 dimensions of scheduling attributes, thus balancing encoding capacity and compatibility.

[0081] The offset position corresponding to each attribute can be predetermined by bit field planning rules. The higher the sorting priority of the attribute data, the larger the corresponding offset position, and the more binary bits it occupies in the encoding space. For example, if the attribute data is sorted from high to low priority as follows: main priority, business line, task type, expiration time, creation time, and status flag, with corresponding bit widths of 8 bits, 6 bits, 4 bits, 16 bits, 28 bits, and 2 bits respectively, then the offset position of the main priority is 6+4+16+28+2=56 bits, the offset position of the business line is 4+16+28+2=50 bits, and so on, ensuring that the high-order attribute data always dominates the size of the encoded value.

[0082] The initial sub-encode can be written to the corresponding offset position by a logical left shift operation. The binary value of the initial sub-encode is then shifted to the left by the corresponding number of bits, with the low bits automatically padded with 0, thus obtaining the intermediate sub-encode.

[0083] The intermediate sub-encoder contains only valid bits within the bit field corresponding to the attribute data, with all other bits being 0. Therefore, there is no overlap in bits between the intermediate sub-encoders corresponding to different attribute data, achieving bit field isolation of different attributes at the physical level. In other words, spatial partitioning of multi-dimensional attributes is achieved through bit shifting operations, ensuring that the encoding of each attribute is only effective within its own bit field, fundamentally avoiding mutual interference between different attribute values.

[0084] S104: Perform a bitwise OR operation on each intermediate sub-encoder to obtain the target sub-encoder.

[0085] The target sub-encode is an integrated code value synthesized by bitwise OR operation of the intermediate sub-encodes of all dimensions, and can be directly used as the sorting score of the ordered set.

[0086] For example, bitwise OR is the basic type of binary bitwise operation. The rule is that if at least one of the corresponding binary bits is 1, the result bit is 1; only when both bits are 0 is the result bit 0.

[0087] Since the valid bits of each generated intermediate sub-encoder are completely distributed in different bit segments, no two intermediate sub-encoders have binary bits that are simultaneously 1. Therefore, the result of the bitwise OR operation is equivalent to concatenating the encoded values ​​of each attribute to the corresponding positions of the same 64-bit integer, without producing any carry effect.

[0088] This mechanism differs fundamentally from the traditional linear weighted summation method. Traditional weighted summation synthesizes a composite score through multiplication and addition. The accumulation of lower-order attribute values ​​can lead to carry-over, affecting higher-order attribute values ​​and causing lower-priority tasks to have higher composite scores than higher-priority tasks, resulting in severe sorting errors. In contrast, this embodiment uses bitwise OR operations, where each attribute's bit field is completely independent. The value of a lower-order attribute has no impact on the encoding of higher-order attributes, thus ensuring a strict lexicographical order. Higher-order attributes always have higher priority than lower-order attributes, and sorting is only performed based on lower-order attributes when higher-order attribute values ​​are identical. The resulting target sub-encode is a single 64-bit integer, which can be directly used as the sorting score for Redis ordered sets, adapting to the physical constraints of single-score ordered sets without requiring any database modifications.

[0089] In this embodiment, lossless synthesis of multidimensional attributes is achieved through bitwise OR operation, which not only preserves the scheduling semantics of all dimensions, but also avoids carry interference problems.

[0090] S105, Sort the tasks to be executed in the task queue according to the target sub-encoding.

[0091] The task queue is a storage structure built on an ordered set of key-value databases, used to store tasks to be scheduled and automatically maintain their sorting order.

[0092] For example, the task queue can be implemented based on an ordered set of a key-value database. Each member of the ordered set corresponds to a task identifier, and each member is bound to a score, which is the target sub-encoder.

[0093] The sorted set can be implemented using a hybrid structure of skip lists and hash tables. It can automatically maintain the ordered arrangement of tasks according to their scores. The time complexity of operations such as insertion, deletion, and query by ranking is O(logN), which has extremely high scheduling performance.

[0094] Because the target sub-encoding uses a bit field layout where high-order bits correspond to high-priority attributes, the score relationship perfectly corresponds to the task scheduling priority. That is, the smaller the score of a task, the higher the priority of its high-order attribute, and the earlier it is scheduled. For example, a task with a primary priority attribute located in the highest 8 bits and a priority value of 1 has a much smaller value in its highest bit segment than a task with a priority value of 2, so its overall score is smaller and it will be placed earlier in the queue. Only when two tasks have the same primary priority will the next highest bit of the business line attribute be compared, and so on. Ultimately, this achieves a multi-level strict sorting of primary priority > business line > task type > expiration time > creation time, perfectly matching the expected logic of business scheduling.

[0095] When writing a task to the queue, the task identifier and the corresponding target sub-code are written together by adding the command through the elements of the sorted set. The sorted set will automatically insert it into the correct sorting position without the need for additional sorting calculations.

[0096] For example, the initial encoding space is set to a 64-bit unsigned integer space, and the base time T0 is 1700000000 (Unix timestamp). The bit field is planned as follows, sorted from the most significant bit to the least significant bit:

[0097] Major priority P: 8 bits, offset bit 56, value range 0-255;

[0098] Business line B: 6 bits, offset position 50, value range 0-63;

[0099] Task type T: 4 bits, offset position 46, value range 0-15;

[0100] Failure offset E: 16 bits (minute level), offset position 30, value range 0-65535;

[0101] Create offset C: 28 bits (seconds), offset position 2, value range 0-268435455;

[0102] Status flag S: 2 bits, offset position 0, value range 0-3.

[0103] There is a task A to be executed. Its attribute data includes primary priority P=2, business line B=3, task type T=1, creation timestamp 1700003600 (corresponding to creation offset C=3600), failure offset E=120, and execution status S=0.

[0104] Generate initial sub-encoders: The initial sub-encoder of P is binary 00000010, B is 000011, T is 0001, E is 0000000001111000, C is 0000000000001110000100010000, and S is 00.

[0105] Generate intermediate sub-encoders: shift P left by 56 bits, B left by 50 bits, T left by 46 bits, E left by 30 bits, C left by 2 bits, and S left by 0 bits to obtain 6 intermediate sub-encoders with no overlap in their bit fields.

[0106] Synthesize the target sub-encode: Perform a bitwise OR operation on each of the 6 intermediate sub-encodes to obtain the final 64-bit integer score, which is 144115967926517760 in decimal.

[0107] Enqueue sorting: Write the identifier of task A and the above target sub-code into an ordered set, and the ordered set will automatically insert them into the corresponding sorting position.

[0108] There is another task B to be executed, with a primary priority of P=3 and all other attributes being exactly the same as task A. Therefore, the highest bit segment value of its target sub-encode is larger, and its overall score is higher than that of task A. It is placed after task A in the queue, which conforms to the scheduling rule of prioritizing high-priority tasks.

[0109] In the above embodiments, a bit-field segmented isolation encoding method is adopted, which independently maps the attribute data of each dimension to a specified bit segment in a fixed-length encoding space, and then synthesizes them into a single target sub-encoder through bitwise OR operation. This avoids the carry interference problem of the traditional weighted summation method, preserves the strict dictionary partial order relationship between multi-dimensional attribute data, makes the task sorting result meet the business scheduling expectations, and improves the accuracy of task scheduling.

[0110] In the above embodiments, see Figure 2 , Figure 2 A flowchart illustrating the process of prioritizing tasks to be executed is provided, which includes the following steps:

[0111] S201, determine the execution status of the task to be executed based on the code corresponding to the task execution status.

[0112] The code corresponding to the task execution status is a specific bit segment reserved in the target sub-code, which is used to represent the current scheduling stage of the task in binary code form.

[0113] The execution state refers to the stage a task is in during its scheduling lifecycle, including ready state, delayed state, executing state, and failed state. Different states correspond to different scheduling strategies.

[0114] For example, in the bit field planning of the target sub-encoding, one or more low bits are reserved as status flag bits to carry task status information.

[0115] A bitwise AND operation can be performed between the target sub-encode and the mask corresponding to the status bits. The result is the encoded value corresponding to the task execution status. Different encoded values ​​correspond to different execution states. For example, 00 corresponds to the ready state, 01 corresponds to the delayed state, 10 corresponds to the executing state, and 11 corresponds to the failed state.

[0116] Traditional solutions typically store task status in separate hash keys or string keys, separate from the sorting score. Querying the status requires additional database access, and the atomicity of updates to both status and sorting score cannot be guaranteed. In contrast, this solution embeds the status code directly into the bit field of the target sub-encoder. Only a single score read is needed to simultaneously obtain sorting and status information, eliminating the need for additional storage access. The decoding operation is merely a simple bitwise operation with negligible computational overhead. Thus, by decoding the embedded status code, the execution stage of a task can be quickly and cost-effectively determined, providing a basis for queue routing.

[0117] S202, based on the execution status of the task to be executed, add the task to its respective task queue.

[0118] The task queue is divided into different scheduling queues according to the task execution status. Tasks in different statuses enter the corresponding queue for independent scheduling and management.

[0119] For example, multiple types of task queues can be set in advance according to the stage requirements of task scheduling. Each type of queue corresponds to one or a type of execution state. For example, the ready state corresponds to the real-time task queue, and the delayed state corresponds to the delayed task queue, etc.

[0120] After determining the execution status of a task, it can be added to the corresponding task queue based on the mapping relationship between the status and the queue. This achieves scheduling isolation for tasks at different stages. For example, delayed tasks that have not yet reached their execution time do not need to participate in real-time scheduling contention; placing them in a separate delayed queue avoids interference with the sorting and scheduling of the real-time queue, improving the scheduling efficiency of the real-time queue. Simultaneously, different queues can adopt data structures adapted to their own characteristics. For instance, the real-time queue can use ordered sets to support priority sorting, while the delayed queue can use a streaming data structure to support blocking reads, achieving optimal matching between data structure and business scenario.

[0121] When adding a task to its assigned queue, the target sub-encode is used as the sorting score to ensure that tasks within the same queue still follow multi-dimensional priority sorting rules. In this way, through state-driven queue routing, hierarchical management of task scheduling is achieved, which optimizes the scheduling strategy of tasks at different stages and maintains the sorting consistency within the queue.

[0122] S203, determine the order of tasks to be executed in the task queue based on the target sub-encoding.

[0123] For example, after a task is added to the corresponding queue, the underlying ordered set structure of the queue automatically places the task in the correct arrangement position according to the numerical value of the target sub-encoder.

[0124] Since tasks within the same queue have the same execution status and identical status bit encoding values, the status bit does not affect the queue's order. The ordering logic is still determined by the higher-order bits such as priority and time, ensuring the correctness of scheduling priorities among tasks in the same status. For example, if all tasks in the real-time task queue are in the ready state and their status bits are all 00, the order within the queue is entirely determined by attributes such as primary priority, business line, and creation time.

[0125] Assuming the status bits are the lowest two bits, 00 corresponds to ready and 01 corresponds to delay.

[0126] Task C has a primary priority P=1, business line B=2, task type T=1, creation offset C=7200, failure offset E=300, and execution status is delayed, corresponding to status code S=01. A bitwise AND operation can be performed between the target sub-code of Task C and mask 3, resulting in 1 (binary 01), indicating the task is in a delayed state. Based on this delayed state, Task C is added to the delayed task queue. Within the delayed task queue, tasks are sorted by their target sub-code. Since Task C's primary priority is 1, it is higher than tasks with a priority of 2 in the same queue, thus placing Task C earlier. Task D, on the other hand, has an execution status of ready, with all other attributes identical to Task C, and status code S=00. Therefore, it is added to the real-time task queue, where it is sorted by its target sub-code.

[0127] In the above embodiments, the task execution status code is embedded in the bit field of the target sub-code, eliminating the need to maintain a separate status storage key, thus reducing additional storage overhead and database access frequency. At the same time, by diverting tasks to corresponding dedicated queues through status coding, isolated management of tasks at different scheduling stages is achieved. The optimal data structure and scheduling strategy can be adopted for different queues, improving overall scheduling efficiency and management flexibility.

[0128] In some alternative implementations, after determining the order of tasks to be executed in the task queue based on the target sub-encoding, tasks to be executed in the delayed task queue can be transferred to the real-time task queue after the execution conditions are met; and the order of tasks to be executed in the real-time task queue can be determined based on the target sub-encoding corresponding to the tasks to be executed.

[0129] The real-time task queue is a queue used to store ready tasks that have met the execution conditions and can be scheduled for execution at any time.

[0130] The delayed task queue is a queue used to store tasks that have not yet reached their execution time and need to wait for a specified time before they can be executed, thus realizing delayed scheduling and buffering of tasks.

[0131] The execution condition is the trigger condition that allows a delayed task to be switched to real-time scheduling, which is usually the current system time reaching the task's preset execution time.

[0132] For example, the delayed task queue contains tasks whose execution time has not yet arrived. A separate daemon process can continuously monitor the tasks in the delayed task queue to determine whether they meet the execution conditions. The execution condition is determined based on the task's execution time, which can be calculated by combining the failure offset field in the decoded target sub-encoding with the base time. When the current system time is greater than or equal to the execution time, the task is deemed to meet the execution conditions.

[0133] The daemon process can listen by blocking reads or timed polling. If the delayed queue is implemented using a streaming data structure, event-driven listening can be achieved through blocking read commands. When an expired message arrives, it will automatically trigger processing without frequent polling, thus reducing CPU idle overhead.

[0134] When a task that meets the execution conditions is detected, the daemon process extracts the task identifier and corresponding target sub-code of the task, modifies the status flag in the target sub-code, changes the code corresponding to the delayed state to the code corresponding to the ready state, and obtains the updated target sub-code. Then, it writes the task to the real-time task queue through atomic operations, and removes the task from the delayed task queue, completing the task transfer. The entire transfer process is guaranteed to be atomic through a server-side script to prevent tasks from being lost or duplicated during the transfer process.

[0135] In this way, the automatic transfer mechanism upon expiration enables a seamless transition from delayed tasks to real-time tasks, ensuring the timely execution of delayed tasks while maintaining the purity of the real-time queue and preventing unexpired tasks from occupying real-time scheduling resources.

[0136] Furthermore, after a task is transferred to the real-time task queue, the updated target sub-encoding is used as the sorting score, and the sorted position of the transferred task is automatically determined by the ordered set structure of the real-time queue.

[0137] Since the status bit has been modified to the ready state, consistent with the status bits of other tasks in the real-time queue, the sorting logic is entirely determined by attributes such as priority and time, following the same sorting rules as the original tasks in the queue. This means that even tasks transferred from the delayed queue will be directly inserted into the front of the real-time queue as long as their priority is high enough, achieving millisecond-level preemption of high-priority tasks, without having their scheduling priority reduced due to being transferred from a delayed queue.

[0138] For example, when a high-priority delayed task expires, it will be placed directly in front of all low-priority tasks in the real-time queue and immediately retrieved and executed by the consumer, thus meeting the scheduling requirements of high-priority timed tasks.

[0139] In the above embodiments, a dual-chain architecture with separate real-time task queues and delayed task queues is adopted. Unexpired tasks are removed from the real-time scheduling link, avoiding invalid scanning and scheduling interference to the real-time queue and improving the scheduling efficiency of real-time tasks. At the same time, delayed tasks automatically modify their status and are transferred to the real-time queue after they expire, and follow a unified sorting rule after the transfer. This ensures the timely execution of delayed tasks and maintains the consistency and accuracy of scheduling priority across the entire queue.

[0140] In some optional implementations, after placing the task to be executed into its respective queue, the code corresponding to the task execution status of the target task in the real-time task queue can be updated to the target value; where the target task is the task at the front of the queue, the target value is used to indicate that the target task is in the execution state; and the task identifier of the target task is sent to the task execution end.

[0141] The target task is the task at the front of the real-time task queue, i.e., the task with the highest current priority that should be scheduled for execution first. The target value is a status code representing the task's execution status, which can be set to binary 10.

[0142] The task execution end is a consumer node deployed on an independent computing node, responsible for executing the specific business logic of the task.

[0143] The task identifier is a globally unique task ID used to uniquely identify a task. The task identifier is also used to instruct the task execution end to obtain the task execution parameters of the target task and execute the target task based on the task execution parameters.

[0144] Task execution parameters are non-ordered attributes such as payload data, context information, and configuration parameters required for the task execution business logic, and can be stored in an independent metadata structure.

[0145] For example, when consuming tasks, the task execution end can call a pre-built server-side script. The script completes the entire process of reading, verifying, and modifying in one go under the single-threaded database execution model. First, the script uses an ordered set query command to retrieve the first-ranked element in the real-time task queue, which is the target task with the lowest score and highest priority, and also retrieves its corresponding target sub-code.

[0146] Next, the script decodes the status bits in the target sub-encode to verify whether the task is in a ready state, preventing tasks that have already been consumed or have abnormal states from being retrieved repeatedly. After successful verification, the script modifies the encoded value of the status bits to the target value, i.e., the encoding corresponding to the current execution state, thus obtaining the updated target sub-encode. Finally, the updated target sub-encode is rewritten into the ordered set to complete the state update.

[0147] The entire process is executed in a single operation on the database server without interruption by other requests, thus possessing complete atomicity and avoiding the race condition problem of multiple consumers simultaneously acquiring the same task in distributed scenarios. Compared to the traditional approach of retrieving and then deleting tasks, this embodiment uses a status marking method instead of direct deletion. The task remains in the queue, and if the task execution terminal crashes, causing the task to fail, the status can be reset to ready through a timeout detection mechanism, and the task can be re-added to the scheduler, preventing task loss and improving scheduling reliability.

[0148] In this way, atomic state updates not only ensure the uniqueness of task consumption but also provide a basis for fault recovery, thereby improving the reliability of task scheduling.

[0149] Furthermore, upon receiving the task identifier, the task executor does not directly retrieve the task parameters from the queue. Instead, it reads the task execution parameters from a separate task metadata store based on the task identifier. The task metadata can be stored using a hash structure, with keys in a unified format corresponding to the task identifier, and fields containing non-sorted information such as task payload, business context, and extended parameters.

[0150] This design, which separates the sorting score from the business data, allows the queue structure to retain only the minimum information necessary for sorting, reducing the queue's memory footprint and improving the performance of sorting operations. At the same time, task metadata can be read and written independently of the queue, supporting more flexible field expansion without affecting the queue's sorting logic.

[0151] After loading all execution parameters, the task execution client calls the corresponding business logic to execute the task and returns the execution result upon completion. For example, if the execution is successful, the task execution client removes the task from the real-time ready queue and deletes the corresponding task metadata hash; if the execution fails, the server extracts the reserved retry counter or context information from the encoded value. If the maximum retry threshold is not reached, the task is re-added to the real-time ready queue; if the threshold is reached, the primary priority field (P) in the encoded value is dynamically adjusted, for example, by increasing its priority value to achieve priority boosting, and then re-encoded and written to the real-time queue.

[0152] In this way, the sorting queue and business data are decoupled through task identifiers, which optimizes the storage and performance of the queue while ensuring the complete execution capability of the task business logic.

[0153] In the above embodiments, by performing sequential operations of retrieving tasks, verifying status, and marking the status in execution, the problem of duplicate task consumption in distributed concurrent scenarios is avoided; at the same time, by using status marking to process tasks, compared with the method of directly deleting tasks, task recovery after a crash is supported, reducing the risk of task loss.

[0154] In some optional implementations, the attribute data may include a creation timestamp and an expiration timestamp. To avoid the initial sub-codes corresponding to the creation timestamp and expiration timestamp occupying too much bit width, the creation timestamp and expiration timestamp are encoded by determining the creation offset of the creation timestamp relative to the base time and encoding the creation offset to obtain the initial sub-code corresponding to the creation offset; and by determining the expiration offset of the expiration timestamp relative to the base time and encoding the expiration offset to obtain the sub-code corresponding to the expiration offset.

[0155] The creation timestamp is an absolute time value that identifies the moment a task is created. It typically uses the Unix timestamp format and is accurate to the second or millisecond. It is used to implement first-in-first-out sorting of tasks with the same priority.

[0156] The expiration timestamp is an absolute time value that identifies the time when a task is due to be executed or when it expires. It is used for time determination and expiration control of delayed tasks.

[0157] The reference time is a preset zero point, which serves as the benchmark for calculating the relative offset. It can be the system's online time or a fixed historical time.

[0158] The creation offset is the difference between the creation timestamp and the base time. It is a relative time value used to compress the encoding bit width.

[0159] The failure offset is the difference between the failure timestamp and the base time. It is a relative time value used to compress the encoding bit width.

[0160] For example, directly using absolute timestamps for encoding would require at least 32 bits, and as the value increases over time, it would consume a significant amount of valuable encoding space. Therefore, a base time can be introduced, selecting a fixed historical moment as the zero point, and converting the absolute timestamp into an offset relative to that zero point. The base time can be the moment the system officially went live; no tasks will be generated before this moment, so the offsets will all be non-negative, eliminating the need to handle negative numbers.

[0161] The formula for calculating the creation offset is: Creation Offset = Creation Timestamp - Base Time. Since the maximum value of the offset is the duration of the system's lifecycle, which is much smaller than the range of the absolute timestamp, the required bit width is significantly reduced. Furthermore, the granularity can be adjusted according to the business's time precision requirements. Creation time typically requires second-level precision to ensure the first-in, first-out order of tasks with the same priority; therefore, a second-level granularity can be used to calculate the offset. For example, a 28-bit unsigned integer can represent the range from 0 to 268,435,455 seconds, which translates to approximately 8.5 years, fully covering the lifecycle of a typical business system. After obtaining the creation offset, it is converted into a binary number with the corresponding bit width, thus obtaining the initial sub-encoding corresponding to the creation time dimension.

[0162] Similarly, expiration timestamps are typically used to determine the execution time of delayed tasks. For most business scenarios, minute-level precision is sufficient and there is no need to be accurate to the second. This allows for saving bit width by reducing the time granularity.

[0163] Failure offsets can be calculated at the minute level using the formula: Failure Offset = (Failure Timestamp - Base Time) / 60, rounded down. Reducing the granularity significantly increases the range of time that can be represented by the same bit width, or in other words, requires less bit width to represent the same time range. For example, a 16-bit unsigned integer at the minute level can represent a range from 0 to 65536 minutes, which is approximately 45 days, fully meeting the maximum duration requirements of most delayed tasks.

[0164] If the business requires a longer latency, the bit width or granularity can be adjusted. For example, using hour-level granularity, 16 bits can represent approximately 7.4 years, supporting flexible configuration.

[0165] After obtaining the failure offset, convert the failure offset into a binary number with the corresponding bit width to obtain the initial sub-code corresponding to the failure time dimension.

[0166] In the above embodiments, the absolute timestamp is converted into an offset relative to the base time, which compresses the encoding bit width occupied by time-type attributes and improves the utilization of encoding space and the carrying capacity of multi-dimensional scheduling.

[0167] In some optional implementations, bit width constraint verification can be performed on each attribute data during the encoding process to avoid tampering with the encoding of adjacent attributes and semantic confusion in sorting due to overflow.

[0168] For example, for each attribute data, it can be determined whether the attribute data meets the bit width constraint condition; wherein, the bit width constraint condition includes that the attribute data is less than or equal to the constraint value, and the constraint value is determined according to the bit width corresponding to the attribute data; if the bit width constraint condition is met, the attribute data is encoded to obtain the initial sub-encoder corresponding to the attribute data.

[0169] Bit width constraints are numerical constraints set to ensure that attribute values ​​do not exceed the allocated bit range. They are a prerequisite check rule to prevent bit overflow.

[0170] The constraint value is the maximum allowed value of a certain attribute, which is determined by the bit width allocated to that attribute. It can be the maximum value of an unsigned integer with the corresponding bit width.

[0171] Bit width is the number of binary bits allocated to a certain attribute, which determines the range of values ​​that attribute can represent. For example, see Table 1, which shows the number of binary bits allocated to each attribute data.

[0172] Table 1:

[0173]

[0174] Among them, the bit width corresponding to each attribute data satisfies P bits +B bits +T bits +E bits +C bits +S bits ≤64.

[0175] For example, an n-bit unsigned binary number can represent a value ranging from 0 to 2. n-1 Therefore, the formula for calculating the constraint value is: Constraint value = The bit-width constraint condition is that the value of the attribute data is less than or equal to the constraint value, and greater than or equal to 0.

[0176] If attribute data exceeds this range, bit overflow will occur during binary encoding. The extra binary bits will intrude into the adjacent higher-order attribute bit fields, causing the encoded values ​​of the higher-order attributes to be tampered with, ultimately leading to sorting logic errors. For example, in a 4-bit task type field with a constraint value of 15, if a task's type value is 16, which is represented as 10000 in binary, it requires 5 bits to hold. Forcibly writing it into the 4-bit space will cause overflow to the 5th bit. Since the 5th bit belongs to the bit field of the business line attribute, this will cause an error in the encoding of the business line attribute, ultimately resulting in an abnormal sorting score for the task and a deviation from the expected scheduling order.

[0177] Bit-field encoding ensures that each attribute is independent and free from interference. By verifying whether each attribute data meets the bit width constraint before encoding is executed, the risk of overflow can be blocked from the source, thus ensuring the correctness of the encoding.

[0178] If all attribute data passes the bit-width constraint check, the normal encoding process begins, generating initial sub-codes for each attribute. If any attribute data fails to meet the bit-width constraint, a preset exception handling strategy is triggered. This strategy can be configured according to business needs. For example, it could be a rejection strategy, which directly rejects the task creation request, returns an error message indicating that the parameter exceeds the limit, and requires the business to adjust the attribute value; or a degradation strategy, which automatically adjusts the attribute value that exceeds the limit to the maximum constraint value of the attribute, sacrificing some precision but ensuring the encoding is valid; or an expansion strategy, which dynamically adjusts the bit-width allocation and expands the bit-width of the attribute to accommodate the exceeding value if there are reserved free bits in the encoding space. This strategy offers the highest flexibility but requires pre-reserved bit-width support.

[0179] In this way, by verifying the branch logic, the normal encoding process of legal attributes is guaranteed, while illegal attributes are handled in a controllable manner to prevent overflow errors from entering the subsequent synthesis stage.

[0180] In the above embodiments, bit width constraint verification is performed on all attribute data before encoding execution, which can prevent bit overflow caused by attribute values ​​exceeding the bit field range from the source, avoid adjacent attribute encoding tampering and sorting semantic disorder caused by overflow, improve the correctness of multi-dimensional bit field encoding, and enhance the stability and reliability of task scheduling.

[0181] In some alternative implementations, see [link to relevant documentation]. Figure 3 , Figure 3 A task processing system architecture diagram is provided, specifically including:

[0182] A Redis service node is a physical or virtual server running Redis 6.0 or later, providing support for ZSet and Stream data structures.

[0183] Producer: A software module deployed on the business application server, responsible for receiving business requests and generating tasks.

[0184] Consumer (Worker Node): A software module deployed on an independent computing node, responsible for retrieving and executing tasks from the queue.

[0185] Multi-dimensional bit-domain encoder: A software module integrated into the producer or used as independent middleware.

[0186] Scheduler: The control logic that resides in Redis or on the client, usually encapsulated as a Lua script.

[0187] In some alternative implementations, see [link to relevant documentation]. Figure 4 , Figure 4A data flow diagram is provided, which includes the following steps:

[0188] Task production and metadata storage:

[0189] After multiple producers generate tasks to be executed, they first store the complete metadata of the tasks (including sorting score, business parameters, etc.) into the task metadata hash of the Redis service cluster, which serves as the basic data carrier of the tasks.

[0190] Task distribution into queue:

[0191] If it is a delayed task, add the task ID and corresponding score to the Delay Stream (delay stream queue), temporarily store them in the order of message ID, and wait for the execution time to arrive;

[0192] If the task is to be executed immediately, the task ID and score are directly written into the Ready ZSet (ready ordered set), and the set is automatically sorted by priority according to the score.

[0193] Delayed task migration activation:

[0194] Once the delayed task reaches its execution time, it is removed from the Delay Stream, moved to the Ready ZSet, and inserted into the queue at the corresponding sorting position according to its own score.

[0195] Task consumption execution:

[0196] Multiple consumer nodes use a pull (PULL) mode to retrieve the highest-priority task from the Ready ZSet, load the metadata, and then execute the business logic.

[0197] In some alternative implementations, see [link to relevant documentation]. Figure 5 , Figure 5 A task scheduling flowchart is provided, which includes the following steps:

[0198] The process starts, creating a task and initializing its various attribute parameters.

[0199] A Score is generated based on the multi-dimensional attributes of the task, which serves as the basis for task ranking.

[0200] Determine whether the task needs to be executed immediately:

[0201] If so: directly add to the ready queue ZSet, the queue will automatically maintain priority sorting according to score;

[0202] If not: Add to the delayed queue Stream and enter the waiting phase.

[0203] The daemon process reads the delay queue in a blocking manner to determine if the task has reached its execution time.

[0204] If not achieved: continue blocking and listening;

[0205] If the condition has been met: move the task to the ready queue ZSet.

[0206] Read the highest priority task from the ready queue according to its score, parse the encoded value, and verify the validity of the task status.

[0207] Consumers receive tasks and execute business logic.

[0208] Determine the execution result:

[0209] If successful: Process ends;

[0210] If execution fails: calculate the number of retries, and the task re-enters the scheduling link to retry, forming a closed loop.

[0211] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0212] Based on the same inventive concept, this application also provides a task processing apparatus for implementing the task processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more task processing apparatus embodiments provided below can be found in the limitations of the task processing method described above, and will not be repeated here.

[0213] In one exemplary embodiment, such as Figure 6 As shown, a task processing apparatus is provided, comprising:

[0214] The acquisition module 10 is used to acquire attribute data of at least one dimension of the task to be executed after receiving the task to be executed;

[0215] Encoding module 20 is used to encode each attribute data separately to obtain the initial sub-encode corresponding to each attribute data;

[0216] The writing module 30 is used to write the initial sub-encoder into the offset position corresponding to the initial sub-encoder in the initial encoding space for each initial sub-encoder, so as to obtain the intermediate sub-encoder corresponding to the initial sub-encoder; wherein, the initial encoding space is an encoding space of a preset length corresponding to the initial sub-encoder;

[0217] The operation module 40 is used to perform bitwise OR operations on each intermediate sub-encoder to obtain the target sub-encoder;

[0218] The sorting module 50 is used to sort the tasks to be executed in the task queue according to the target sub-encoding.

[0219] In the above embodiments, a bit-field segmented isolation encoding method is adopted, which independently maps the attribute data of each dimension to a specified bit segment in a fixed-length encoding space, and then synthesizes them into a single target sub-encoder through bitwise OR operation. This avoids the carry interference problem of the traditional weighted summation method, preserves the strict dictionary partial order relationship between multi-dimensional attribute data, makes the task sorting result meet the business scheduling expectations, and improves the accuracy of task scheduling.

[0220] In one embodiment, the target sub-encoding includes at least the encoding corresponding to the task execution state of the task to be executed, and the sorting module 50 is specifically used for:

[0221] Based on the code corresponding to the task execution status, determine the execution status of the task to be executed; based on the execution status of the task to be executed, add the task to be executed to its respective task queue; and based on the target sub-code, determine the order in which the tasks to be executed are arranged in the task queue.

[0222] In one embodiment, the task queue includes a real-time task queue and a delayed task queue; the sorting module 50 is further configured to:

[0223] Once the execution conditions are met, the tasks to be executed in the delayed task queue are transferred to the real-time task queue; and the order of the tasks to be executed in the real-time task queue is determined according to the target sub-code corresponding to the task to be executed.

[0224] In one embodiment, the device further includes a transmitting module for:

[0225] Update the code corresponding to the task execution status of the target task in the real-time task queue to the target value; where the target task is the task at the front of the queue, and the target value is used to indicate that the target task is in the execution state; send the task identifier of the target task to the task execution end; where the task identifier is used to instruct the task execution end to obtain the task execution parameters of the target task and execute the target task based on the task execution parameters.

[0226] In one embodiment, each attribute data includes at least a creation timestamp and an expiration timestamp, and the encoding module 20 is specifically used for:

[0227] Determine the creation offset of the creation timestamp relative to the base time, and encode the creation offset to obtain the initial sub-code corresponding to the creation offset; and determine the failure offset of the failure timestamp relative to the base time, and encode the failure offset to obtain the sub-code corresponding to the failure offset.

[0228] In one embodiment, the encoding module 20 is specifically used for:

[0229] For each attribute data, determine whether the attribute data meets the bit width constraint condition; wherein, the bit width constraint condition includes that the attribute data is less than or equal to the constraint value, and the constraint value is determined according to the bit width corresponding to the attribute data; if the bit width constraint condition is met, encode the attribute data to obtain the initial sub-code corresponding to the attribute data.

[0230] Each module in the aforementioned task processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0231] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and databases. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media to run. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a task processing method.

[0232] Those skilled in the art will understand that Figure 7The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0233] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the task processing method described in any of the above embodiments.

[0234] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the task processing method described in any of the above embodiments.

[0235] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the task processing method described in any of the above embodiments.

[0236] 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, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0237] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this 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. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0238] The technical features of the above embodiments can be combined in any way. For the sake of brevity, 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.

[0239] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A task processing method, characterized in that, The method includes: Upon receiving a task to be executed, acquire attribute data for at least one dimension of the task to be executed; Each attribute data is encoded separately to obtain the initial sub-encoder corresponding to each attribute data; For each initial sub-encoder, the initial sub-encoder is written into the initial encoding space at the offset position corresponding to the initial sub-encoder to obtain the intermediate sub-encoder corresponding to the initial sub-encoder; wherein, the initial encoding space is an encoding space of a preset length corresponding to the initial sub-encoder; Perform a bitwise OR operation on each intermediate sub-encoder to obtain the target sub-encoder; The tasks to be executed are sorted in the task queue according to the target sub-encoding.

2. The method according to claim 1, characterized in that, The target sub-encoding includes at least the encoding corresponding to the task execution status of the task to be executed. The step of sorting the tasks to be executed in the task queue according to the target sub-encoding includes: The execution status of the task to be executed is determined based on the code corresponding to the task execution status. Based on the execution status of the task to be executed, add the task to its respective task queue; and, The order in which the tasks to be executed are arranged in the task queue is determined based on the target sub-encoding.

3. The method according to claim 2, characterized in that, The task queue includes a real-time task queue and a delayed task queue; after determining the order of the tasks to be executed in the task queue according to the target sub-encoding, the method further includes: Once the pending tasks in the delayed task queue meet the execution conditions, the pending tasks are transferred to the real-time task queue; and, The order of the tasks to be executed in the real-time task queue is determined based on the target sub-code corresponding to the task to be executed.

4. The method according to claim 3, characterized in that, The method further includes: The code corresponding to the task execution status of the target task in the real-time task queue is updated to the target value; wherein, the target task is the task at the front of the queue, and the target value is used to indicate that the target task is in the execution state; Send the task identifier of the target task to the task execution terminal; wherein the task identifier is used to instruct the task execution terminal to obtain the task execution parameters of the target task and execute the target task based on the task execution parameters.

5. The method according to any one of claims 1-4, characterized in that, Each attribute data includes at least a creation timestamp and an expiration timestamp. The process of encoding each attribute data to obtain an initial sub-encoder for each attribute data includes: Determine the creation offset of the creation timestamp relative to the base time, and encode the creation offset to obtain the initial sub-encode corresponding to the creation offset; and, Determine the failure offset of the failure timestamp relative to the reference time, and encode the failure offset to obtain the sub-code corresponding to the failure offset.

6. The method according to any one of claims 1-4, characterized in that, The step of encoding each attribute data separately to obtain the initial sub-encoder corresponding to each attribute data includes: For each attribute data, determine whether the attribute data satisfies the bit width constraint condition; wherein, the bit width constraint condition includes the attribute data being less than or equal to the constraint value, and the constraint value is determined according to the bit width corresponding to the attribute data; Under the condition that the bit width constraint is met, the attribute data is encoded to obtain the initial sub-encoder corresponding to the attribute data.

7. A task processing device, characterized in that, The device includes: The acquisition module is used to acquire attribute data of at least one dimension of the task to be executed after receiving the task to be executed; The encoding module is used to encode each attribute data separately to obtain the initial sub-encoder corresponding to each attribute data; The writing module is used to write the initial sub-encoder into the initial encoding space at the offset position corresponding to the initial sub-encoder for each initial sub-encoder, thereby obtaining the intermediate sub-encoder corresponding to the initial sub-encoder; wherein, the initial encoding space is an encoding space of a preset length corresponding to the initial sub-encoder; The arithmetic module is used to perform bitwise OR operations on each intermediate sub-encoder to obtain the target sub-encoder; The sorting module is used to sort the tasks to be executed in the task queue according to the target sub-encoding.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

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

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images