A multi-account concurrent processing management system and method

Abstract

This application provides a multi-account concurrent processing management system and method, applied in the field of multi-account high-concurrency business processing technology. It parses multiple received account operation requests into a set of micro-operations, encapsulating each micro-operation into an operation object identifier, operation type, and dependency relationship, including resource dependency, granular dependency, and business logic dependency. Based on the operation object identifier, operation type, and dependency relationship, a lock execution path is determined. A dependency tensor model is constructed and conflict density mapping is performed to form a conflict density distribution. Tensor conflict operations are performed on the micro-operations in conjunction with the lock execution path to obtain conflict intensity values. Based on the conflict density distribution, high-conflict regions are identified and a potential deadlock graph is constructed to generate a directed acyclic graph of micro-operations. Nodes with both in-degree and out-degree of zero are identified to form a first execution sequence. A second execution sequence is then constructed based on the remaining micro-operations, and these sequences are concatenated to form a micro-operation execution sequence, achieving efficient parallel scheduling and improved throughput.

Description

Technical Field

[0001] This application relates to the field of multi-account high-concurrency business processing technology, and in particular to a multi-account concurrent processing management system and method. Background Technology

[0002] As online trading systems, financial clearing platforms, smart payment gateways, and multi-node business processing systems continue to expand in scale, individual users or institutions often need to maintain multiple business accounts simultaneously and initiate high-frequency and independent operation requests within a short period of time. This makes multi-account concurrent processing management a key technological foundation for maintaining business continuity, security, and processing efficiency.

[0003] Existing technologies for multi-account concurrent processing management typically manage operation requests from multiple accounts concurrently through thread pool scheduling, multi-queue distribution, locking mechanisms, and task sharding. After receiving operation instructions from different accounts, the system allocates an execution thread for each instruction and uses global locks or account-level locks to prevent conflicts between operations from the same account. At the same time, it uses queue scheduling strategies to maintain task order and resource allocation. Some systems also supplement this with lightweight caching, session identifier verification, and asynchronous callback processing to improve instruction processing speed and reduce resource blocking caused by account contention, thereby achieving basic concurrent scheduling and execution effects.

[0004] The above solutions still have some problems in practical applications. Existing multi-account concurrent processing management usually implements lock control at the account as the smallest granularity and relies on serial queues and pessimistic locking strategies to treat all operations of the same account as mutually exclusive operations. This causes read operations that could originally be parallel and some read-write operations to be executed sequentially. At the same time, a single long-running write operation may block the entire queue, resulting in inefficient use of thread resources. As a result, in high-concurrency scenarios, the system throughput capacity decreases, the operation latency increases, and further affects business continuity and response efficiency. Summary of the Invention

[0005] This application provides a multi-account concurrent processing management system and method, which breaks through the limitations of traditional account-level lock control in multi-account high-concurrency business scenarios. By performing micro-operation-level semantic decomposition, dependency tensor modeling, conflict intensity calculation, and sequence optimization generation based on dependency closed-loop units on operation requests, it achieves efficient concurrent scheduling of multi-account operations at a fine-grained dimension, thereby significantly improving overall throughput and reducing unnecessary sequential blocking.

[0006] To achieve the above objectives, this application adopts the following technical solution:

[0007] This application provides a method for managing concurrent multi-account processing. The method includes: parsing multiple received account operation requests into multiple micro-operations to form a micro-operation set. Each micro-operation is encapsulated as an operation object identifier, operation type, and dependency relationship, whereby the dependency relationship includes resource dependency, granularity dependency, and business logic dependency. Semantic analysis is performed on the micro-operations in the micro-operation set based on the operation object identifier, operation type, and dependency relationship to determine the lock execution path of each micro-operation. A dependency tensor model is constructed based on the resource dependency, granularity dependency, and business logic dependency, and conflict density mapping is performed on the micro-operations in the dependency tensor model based on the lock execution path to form a conflict density distribution. Tensor conflict operations are performed on the micro-operations based on the lock execution path and the conflict density distribution to obtain a conflict intensity value. High-conflict regions of the dependency tensor model are identified based on the conflict density distribution, and a potential deadlock graph is constructed by combining the conflict intensity value. Dependency loop-closing units are obtained by performing cycle detection on the potential deadlock graph. A directed acyclic graph of micro-operations is generated based on the micro-operation set and dependency loop-closing units, and micro-operation nodes with zero in-degree and zero out-degree are identified from the directed acyclic graph of micro-operations to form a first execution sequence. At least one candidate execution sequence is generated based on the micro-operation nodes with non-zero in-degree or out-degree and their corresponding dependencies in the directed acyclic graph of micro-operations, and the performance of the candidate execution sequence is evaluated based on the conflict intensity value. The candidate execution sequence with the best performance is selected as the second execution sequence. The second execution sequence is naturally concatenated after the first execution sequence to form a micro-operation execution sequence, and the execution of the micro-operation execution sequence is controlled.

[0008] In some possible implementations, the step of performing semantic analysis on micro-operations in the micro-operation set based on operation object identifier, operation type, and dependency to determine the lock execution path of the micro-operation includes: for each micro-operation in the micro-operation set, determining the resource entity corresponding to the micro-operation based on the operation object identifier, and determining the lock mode required by the micro-operation based on the operation type; inferring the sequence constraints and potential conflicts between the micro-operation and other micro-operations based on the resource entity and the lock mode, combined with the dependency, generating the complete lock sequence required by the micro-operation during execution, forming a lock execution path, wherein the lock execution path includes lock type, lock granularity, and lock resource identifier.

[0009] In some possible implementations, constructing a dependency tensor model based on the resource dependencies, granular dependencies, and business logic dependencies includes: in the resource space dimension, analyzing the resource entities accessed by the micro-operation based on the resource dependencies, and labeling each resource entity to form a resource mapping, which reflects the correspondence between the resource entities of the micro-operation and the lock resource identifiers; in the lock mode space dimension, analyzing the lock type and lock granularity of the micro-operation based on the granular dependencies, and mapping it to the lock mode space to form a lock mode mapping, which reflects the lock type and lock granularity used by the micro-operation during execution; in the time window dimension, analyzing the sequential constraints between the micro-operations based on the business logic dependencies of the micro-operations, and generating a time window mapping, which reflects the execution order of the micro-operations; and fusing the resource mapping, the lock mode mapping, and the time window mapping in three-dimensional coordinates to form a dependency tensor model, which provides a unified coordinate system for the positioning of the micro-operation in the concurrency space.

[0010] In some possible implementations, the step of mapping the micro-operations in the dependency tensor model based on the lock execution path to form a conflict density distribution includes: performing time window analysis on the micro-operation set to generate a micro-operation execution order; combining the micro-operation execution order with the lock type, lock granularity, and lock resource identifier of the lock execution path to project the micro-operations onto the resource space dimension, lock mode space dimension, and time window dimension of the dependency tensor model to determine the spatial coordinates of each micro-operation in the micro-operation set; calculating the conflict clustering score of the intersection region of each dimension in the dependency tensor model based on the spatial coordinates of all micro-operations, and using the conflict clustering score to generate a conflict density distribution.

[0011] In some possible implementations, the step of performing tensor conflict operations on micro-operations based on the lock execution path and the conflict density distribution to obtain a conflict intensity value includes: constructing a lock compatibility matrix between micro-operations based on the lock type and lock granularity of the lock execution path; obtaining the lock compatibility state between the micro-operations from the lock compatibility matrix, and identifying lock incompatible pairs reflecting micro-operation conflicts based on the lock compatibility state; for each lock incompatible pair, obtaining the conflict aggregation score of the lock incompatible pair in the intersection region of each dimension from the conflict density distribution; and accumulating the conflict aggregation score to obtain the tensor conflict value of the micro-operation, wherein the tensor conflict value is used to quantify the competition and waiting relationship between micro-operations.

[0012] In some possible implementations, the step of identifying high-conflict regions of the dependency tensor model based on conflict density distribution and constructing a potential deadlock graph by combining conflict intensity values, and obtaining dependency loop-closing units by performing loop detection on the potential deadlock graph, includes: analyzing the conflict aggregation scores of the micro-operations in the intersection regions of each dimension of the dependency tensor model based on the conflict density distribution, marking the micro-operations corresponding to conflict aggregation scores exceeding a preset threshold as high-conflict regions; constructing a potential deadlock graph using the micro-operations in the high-conflict regions and the tensor conflict values ​​corresponding to the micro-operations, wherein the nodes of the potential deadlock graph are micro-operations and the edges are waiting relationships between micro-operations; performing loop detection on the potential deadlock graph to identify indivisible potential deadlock loops, and using the potential deadlock loops as dependency loop-closing units, wherein the dependency loop-closing units are used to characterize the dependency structure of non-concurrent micro-operations.

[0013] In some possible implementations, the dependency closure unit includes cyclic dependency constraints. The step of generating a directed acyclic graph of micro-operations based on the micro-operation set and the dependency closure unit, and identifying micro-operation nodes with both in-degree and out-degree zero from the directed acyclic graph of micro-operations to form a first execution sequence, includes: constructing a preliminary directed graph of micro-operations using all micro-operations in the micro-operation set as nodes, the dependencies between micro-operations as edges, and incorporating the cyclic dependency constraints of the dependency closure unit; locating the dependency closure unit in the preliminary directed graph of micro-operations, and disassembling the dependency edge with the highest tensor conflict value in the closure unit, transforming the preliminary directed graph of micro-operations into a directed acyclic graph of micro-operations; and identifying all micro-operation nodes with both in-degree and out-degree zero from the directed acyclic graph of micro-operations to form the first micro-operation execution sequence.

[0014] In some possible implementations, generating at least one candidate execution sequence based on the micro-operation nodes with non-zero in-degree or out-degree and their corresponding dependencies in the directed acyclic graph of micro-operations includes: arranging the order of micro-operations based on the micro-operation nodes with non-zero in-degree or out-degree and their corresponding dependencies, combined with the lock execution path of the micro-operations, to generate at least one candidate execution sequence, wherein the candidate execution sequence is used to reflect the feasible execution order of micro-operations under the dependency constraint agreement.

[0015] In some possible implementations, the step of evaluating the performance of the candidate execution sequences based on the conflict intensity values ​​and selecting the candidate execution sequence with the best performance as the second execution sequence includes: cumulatively calculating the tensor conflict intensity values ​​of each micro-operation in the candidate execution sequence to obtain the total conflict amount of the candidate execution sequences; sorting the candidate execution sequences based on the total conflict amount and selecting the candidate execution sequence with the smallest total conflict amount as the second execution sequence, wherein the second execution sequence reflects the optimal performance of micro-operation execution under the condition of satisfying dependency constraints.

[0016] A multi-account concurrent processing management system includes: a micro-operation parsing module, used to receive multiple account operation requests and parse them into a set of micro-operations, wherein the micro-operations in the set are encapsulated as operation object identifiers, operation types, and dependencies, the dependencies including resource dependencies, granular dependencies, and business logic dependencies; a lock path analysis module, used to perform semantic analysis on the micro-operations in the set of micro-operations based on the operation object identifiers, operation types, and dependencies to determine the lock execution path of the micro-operations; a conflict intensity analysis module, including a dependency tensor model construction unit and a tensor conflict operation unit, specifically: the dependency tensor model construction unit is used to construct a dependency tensor model based on the resource dependencies, granular dependencies, and business logic dependencies, and to perform conflict density mapping on the micro-operations in the dependency tensor model based on the lock execution path to form a conflict density distribution; the tensor conflict operation unit is used to perform tensor conflict operation on the micro-operations based on the lock execution path and the conflict density distribution to obtain a conflict intensity value; and a micro-operation directed acyclic graph generation module, used to identify the dependency tensor model based on the conflict density distribution. In high-conflict regions, a potential deadlock graph is constructed based on conflict intensity values. Dependency loop units are obtained by performing cycle detection on the potential deadlock graph, and a micro-operation directed acyclic graph (DAG) is generated based on the micro-operation set and dependency loop units. A micro-operation execution sequence generation module, comprising a first execution sequence generation unit, a candidate execution sequence generation unit, a second execution sequence generation unit, and a sequence combination unit, specifically: the first execution sequence generation unit identifies micro-operation nodes with zero in-degree and zero out-degree from the DAG to form a first execution sequence; the candidate execution sequence generation unit generates at least one candidate execution sequence based on micro-operation nodes with non-zero in-degree or out-degree and their corresponding dependencies in the DAG; the second execution sequence generation unit evaluates the performance of the candidate execution sequences based on the conflict intensity values ​​and selects the best-performing candidate execution sequence as the second execution sequence; the sequence combination unit naturally concatenates the second execution sequence after the first execution sequence to form a micro-operation execution sequence; and a sequence execution control module executes the micro-operations sequentially according to the micro-operation execution sequence.

[0017] As can be seen from the above technical solution, this application has the following beneficial effects:

[0018] 1. This application decomposes multi-account operation requests into a set of micro-operations and constructs a dependency tensor model based on resource dependency, granular dependency and business logic dependency. This allows for the quantification and identification of the conflict density and intensity of each micro-operation at a fine-grained level. The system can determine the range of parallelizable micro-operations based on tensor conflict operations and avoid forced serialization caused by high-conflict operations. This breaks through the traditional limitation of using accounts as the smallest lock granularity and significantly improves the overall parallelism and lock resource utilization efficiency.

[0019] 2. This application identifies potential deadlock structures based on conflict density distribution and generates a directed acyclic graph of micro-operations, enabling the system to accurately eliminate dependent closed-loop units that cause execution blocking and form an optimized execution sequence composed of a first execution sequence and a second execution sequence. This reduces the sequential execution cost caused by read-write conflicts and improves the system throughput and response efficiency in high-concurrency scenarios while satisfying dependency constraints. Attached Figure Description

[0020] Figure 1 This is a flowchart of a multi-account concurrent processing management method according to this application;

[0021] Figure 2 This is an example diagram illustrating the composition of a multi-account concurrent processing management system according to this application. Detailed Implementation

[0022] The terms "first," "second," and "third," etc., used in this application specification, claims, and drawings are used to distinguish different objects, not to limit a specific order.

[0023] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0024] Research has revealed that existing multi-account concurrent processing management solutions still have significant limitations in practical applications. The root cause lies in the fact that they generally use accounts as the smallest concurrency control unit, treating all operations from the same account as necessarily mutually exclusive through serial queues and pessimistic locking strategies. However, in application scenarios involving high-frequency trading, batch clearing, or mixed business triggers, the operation types, access resources, and dependencies within an account are often inconsistent. This forces many read operations that do not originally have resource conflicts, as well as some parallelizable read and write operations, into the same serial queue, unnecessarily lengthening the execution path. When the queue contains time-consuming write operations, these operations will occupy lock resources and block the execution of all subsequent operations, significantly extending thread occupancy time. This further reduces the overall system throughput and accumulates queuing delays, ultimately resulting in reduced business continuity and degraded response efficiency under high-concurrency business traffic. This reflects that the existing lock model centered on account granularity cannot adapt to the parallelization requirements under complex business semantics.

[0025] To address the aforementioned issues, this application provides a method for managing concurrent multi-account processing. The method includes: parsing multiple received account operation requests into multiple micro-operations, forming a micro-operation set. Each micro-operation is encapsulated as an operation object identifier, operation type, and dependency relationship, whereby the dependency relationship includes resource dependency, granularity dependency, and business logic dependency; performing semantic analysis on the micro-operations in the micro-operation set based on the operation object identifier, operation type, and dependency relationship to determine the lock execution path of each micro-operation; constructing a dependency tensor model based on the resource dependency, granularity dependency, and business logic dependency, and mapping the micro-operations to conflict density in the dependency tensor model based on the lock execution path to form a conflict density distribution; and performing tensor conflict operation on the micro-operations based on the lock execution path and the conflict density distribution to obtain a conflict intensity value. Based on the conflict density distribution, high-conflict regions of the dependency tensor model are identified, and a potential deadlock graph is constructed by combining conflict intensity values. Dependency loop units are obtained by performing cycle detection on the potential deadlock graph. A directed acyclic graph of micro-operations is generated based on the set of micro-operations and the dependency loop units, and micro-operation nodes with zero in-degree and zero out-degree are identified from the directed acyclic graph of micro-operations to form a first execution sequence. Based on the micro-operation nodes with non-zero in-degree or out-degree and their corresponding dependencies in the directed acyclic graph of micro-operations, at least one candidate execution sequence is generated, and the performance of the candidate execution sequence is evaluated based on the conflict intensity values. The candidate execution sequence with the best performance is selected as the second execution sequence. The second execution sequence is naturally concatenated after the first execution sequence to form a micro-operation execution sequence, and the execution of the micro-operation execution sequence is controlled.

[0026] Example 1: As Figure 1 As shown, this application provides a method for managing concurrent multi-account processing, the specific steps of which are as follows:

[0027] S1, the received multiple account operation requests are parsed into multiple micro-operations to form a micro-operation set. The micro-operations are encapsulated as operation object identifiers, operation types and dependencies. The dependencies include resource dependencies, granular dependencies and business logic dependencies.

[0028] Specifically, in S101, the system receives operation requests from multiple accounts and inputs each operation request as a business instruction to be processed into the system.

[0029] It should be noted that operation requests may originate from online trading systems, financial clearing platforms, or payment gateways, and may include operation types such as account transactions, order processing, and fund transfers.

[0030] S102, each received operation request is parsed and broken down into independently executable micro-operation units. Each micro-operation unit corresponds to a specific account operation action, such as account balance inquiry, order submission, or fund transfer.

[0031] S103, each micro-operation is encapsulated into a data structure containing an operation object identifier, operation type, and dependencies. The operation object identifier is used to uniquely identify the resource entity that the micro-operation affects, such as an account number, order number, or business data object.

[0032] S104 defines the operation type for each micro-operation, which describes how the micro-operation accesses resources, such as read, write, or modify operations, so that lock management and conflict analysis can be performed later.

[0033] S105 establishes dependencies for each micro-operation, including resource dependencies, granular dependencies, and business logic dependencies. Resource dependencies represent conflicts in the micro-operation's occupation or access to shared resources. Granular dependencies represent the scope of lock constraints, such as account-level locks, order-level locks, or field-level locks. Business logic dependencies represent the sequential constraints of micro-operations in the business process, such as the requirement that a funds freeze operation must be completed before a payment operation.

[0034] S106 combines all micro-operation units into a micro-operation set, providing a unified data structure for subsequent micro-operation semantic analysis, lock execution path construction, and dependency tensor model calculation, in order to support conflict identification and execution optimization in high-concurrency environments.

[0035] It should be noted that this set of micro-operations provides the basic data structure for the subsequent construction of dependency tensor models, conflict density mapping, and deadlock detection, ensuring the efficient execution of the system when multiple accounts are processed concurrently.

[0036] It should be noted that the following is a brief introduction to the relevant terms used in this embodiment:

[0037] Micro-operation: refers to the smallest independently executable unit obtained by breaking down a single account operation request;

[0038] Operation object identifier: Used to uniquely identify the resource entity to which the micro-operation is applied, such as an account, order, or business data object;

[0039] Operation type: Used to describe how a micro-operation accesses a resource, including reading, writing, or modifying;

[0040] Resource dependency: refers to the conflicting relationship between micro-operations and the occupation or access of shared resources;

[0041] Granularity dependency: refers to the scope of constraints of micro-operations or locks, such as account level, order level, or field level;

[0042] Business logic dependency: refers to the sequential constraints that micro-operations must follow in a business process.

[0043] This application parses multiple received account operation requests into a set of micro-operations and encapsulates the operation object identifier, operation type, and dependencies for each micro-operation, including resource dependencies, granular dependencies, and business logic dependencies. This enables precise identification of resource conflicts and execution constraints between operations at the micro-operation granularity, thus providing an accurate data foundation for subsequent lock execution path analysis, dependency tensor model construction, and conflict density mapping. By clearly defining the resource consumption and sequential dependencies of each micro-operation, the system can avoid the sequential blocking problem caused by the original account-level locks, achieve parallel scheduling and conflict optimization, thereby improving the system's throughput and the execution efficiency of high-concurrency operations.

[0044] S2, based on the operation object identifier, operation type and dependency relationship, perform semantic analysis on the micro-operations in the micro-operation set to determine the lock execution path of the micro-operation.

[0045] Specifically, in S201, for each micro-operation in the received micro-operation set, the system locates the corresponding resource entity in the account database, order management system, or business data storage based on its operation object identifier, and records the resource status and access permissions.

[0046] S202, combined with the operation type of the micro-operation, determines the required lock mode, including read lock, write lock and escalable lock, and adjusts the lock mode with reference to historical access records and current concurrency to balance access efficiency and data consistency.

[0047] S203, the system infers the sequential constraints and potential conflicts between micro-operations based on the resource dependencies, granular dependencies and business logic dependencies of micro-operations. For example, write operations on the same account are mutually exclusive with other operations, and fund freezing operations must be completed before payment operations.

[0048] S204 combines the resource entity, lock mode, and inferred dependencies to generate a complete lock sequence for each micro-operation, forming a lock execution path.

[0049] It should be noted that the lock execution path includes lock type, lock granularity, and lock resource identifier, which are used for subsequent conflict identification, lock compatibility analysis, and tensor conflict operation to support efficient concurrent scheduling of micro-operations.

[0050] It should be noted that the following is a brief introduction to the relevant terms used in this embodiment:

[0051] Lock execution path: refers to the sequence and order of locks that each micro-operation needs to acquire during execution, including lock type, lock granularity and lock resource identifier, used to control concurrent access and conflict analysis;

[0052] Lock type: describes the lock mode required for micro-operations to access resources, including read locks, write locks, and scalable locks;

[0053] Lock granularity: refers to the scope of a lock, such as account-level locks, order-level locks, or field-level locks;

[0054] Lock resource identifier: Used to uniquely identify the resource entity to which the lock operates, such as account number, order number, or business data object;

[0055] Potential conflicts: refer to data access conflicts or sequential blocking that may occur between micro-operations in a high-concurrency environment;

[0056] Sequence constraints: refer to the execution order that must be followed between micro-operations, used to ensure the correctness of business logic.

[0057] This application performs semantic analysis on each micro-operation in the micro-operation set based on the operation object identifier, operation type, and dependency relationship. This determines the complete lock sequence required for each micro-operation during execution, forming a lock execution path. It can accurately identify potential resource conflicts and sequence constraints at the micro-operation granularity, thereby avoiding the sequence blocking problems caused by the original account-level or operation-level locks. By clarifying the lock type, lock granularity, and lock resource identifier, the system can identify lock compatibility and plan the lock acquisition order in advance before execution, realizing safe concurrent scheduling between micro-operations. Therefore, it significantly improves the system's throughput and execution efficiency in a multi-account high-concurrency operation environment.

[0058] S3. Construct a dependency tensor model based on the resource dependency, granular dependency, and business logic dependency, and perform conflict density mapping on the micro-operations in the dependency tensor model based on the lock execution path to form a conflict density distribution.

[0059] Specifically, S301 iterates through each micro-operation in the micro-operation set, accesses the account database, order management system, and business data storage based on the operation object identifier, and establishes an index record for each resource entity, including resource ID, current status, access count, and lock occupancy information, so as to accurately locate resources and match locks in the future.

[0060] S302 reads the operation type and granularity dependency of each micro-operation, determines the required lock mode, such as generating a shared lock for a read operation and an exclusive lock for a write operation, and sets the lock scope according to the operation granularity, such as account level, order level or field level. At the same time, it records the lock duration and possible lock upgrade paths to perform lock compatibility analysis in high-concurrency environments.

[0061] S303 generates a time series table based on the sequential constraints of micro-operations in the business process, arranging the involved micro-operations in the order of business logic. For example, the fund freezing operation must be completed before the payment operation, and the dependencies are marked in the time series table to analyze potential conflicts when micro-operations are executed simultaneously.

[0062] S304 organizes the resource entity identifier, corresponding lock type and lock granularity of each micro-operation, as well as the execution order index of the micro-operation in the business process, into three-dimensional coordinate data to form a dependency tensor model. The resource entity corresponds to the resource dimension, the lock type and lock granularity correspond to the lock mode dimension, and the execution order index corresponds to the time window dimension. By assigning a specific position to each micro-operation in the three-dimensional coordinate system, the micro-operation is located in the concurrency space, providing a directly usable data structure for conflict analysis and scheduling optimization.

[0063] S305, combined with the lock execution path, maps the three-dimensional position of micro-operations in the dependency tensor model to a specific execution order and lock acquisition order. It calculates the number of micro-operations that access the same resource at the intersection point, generates a conflict aggregation value for each intersection point, and forms a conflict density distribution based on the conflict aggregation value. This is used to identify micro-operations that may conflict on the same time and resource, and provides a basis for subsequent micro-operation scheduling and lock acquisition order optimization.

[0064] It should be noted that the dependency tensor model is used to determine a unified coordinate system for micro-operations in the resource space, lock mode space, and time window dimensions, and to quantify potential conflicts and identify high-risk operation areas through conflict aggregation values.

[0065] It should be noted that the following is a brief introduction to the relevant terms used in this embodiment:

[0066] Dependency tensor model: refers to mapping the information of micro-operations in the resource space, lock mode space and time window dimensions into three-dimensional coordinates to form a unified coordinate system, which is used to quantify potential conflicts between micro-operations and support scheduling optimization.

[0067] Conflict clustering value: In a dependency tensor model, the number of micro-operations that are accessed simultaneously at the intersection of a resource, lock mode, and time window is used to characterize the potential conflict risk at that point.

[0068] Time series table: refers to a sequence of micro-operations arranged in the order of business logic according to their sequential constraints in the business process, with dependencies marked in the sequence, used to analyze the execution order and potential conflicts of micro-operations under high concurrency conditions;

[0069] Resource dimension: A one-dimensional dimension in the dependency tensor model, used to represent the resource entity accessed by the micro-operation, such as an account, order, or business data object;

[0070] Lock mode dimension: a one-dimensional dimension in the dependency tensor model, used to represent the lock type and lock granularity required for micro-operations, such as read locks, write locks, and account-level, order-level, or field-level locks;

[0071] Time window dimension: a one-dimensional dimension in the dependency tensor model, used to represent the execution order and dependencies of micro-operations in the business process.

[0072] This application constructs a dependency tensor model for each micro-operation in the micro-operation set based on resource dependency, granular dependency, and business logic dependency. Combined with the lock execution path, the micro-operations are mapped to the resource space, lock mode space, and time window dimension to form a three-dimensional coordinate system. For micro-operations that access the same resource simultaneously at the intersection point, conflict aggregation values ​​are calculated to form a conflict density distribution. This quantifies potential conflict areas and provides an accurate data basis for micro-operation scheduling, thereby optimizing the execution order and lock allocation, reducing mutual exclusion waiting between micro-operations, improving concurrent execution efficiency, and significantly enhancing system throughput and the overall execution performance of high-concurrency operations.

[0073] S4. Based on the lock execution path and the conflict density distribution, perform tensor conflict operation on the micro-operation to obtain the conflict intensity value.

[0074] Specifically, in S401, the locking and unlocking requests triggered by micro-operations during access to shared data resources are unfolded chronologically. Each lock request is written into the lock access sequence table in the order of triggering, and the list entries record the lock type, lock granularity, resource identifier, micro-operation identifier, and trigger timestamp. The lock access sequence table, as a structured data collection ordered by time in memory, provides the basis for subsequent identification of conflict relationships and resource access trajectories.

[0075] It should be noted that lock types can include shared locks, exclusive locks, intention locks, etc., and lock granularity can include record-level granularity, page-level granularity, and table-level granularity, etc.

[0076] S402: Based on the lock access sequence list obtained in step S401, a lock compatibility matrix is ​​constructed by traversing the lock request entries and according to predefined lock compatibility rules. The lock compatibility matrix is ​​used to record the compatibility relationship of different lock type combinations. The matrix cell contains a Boolean flag indicating whether the lock combination can be executed concurrently. When the matrix cell records a mutual exclusion relationship, the corresponding two lock requests are grouped into a lock incompatible pair, and their trigger time interval, contention resource location, and access overlap range are recorded to form a set of lock incompatible pairs to be quantified and calculated.

[0077] S403. Taking each lock incompatible pair in the lock incompatible pair set as an independent analysis object, retrieve the multi-dimensional data block corresponding to its resource identifier and time interval from the conflict density distribution dataset. Statistically calculate the cumulative number of conflicts, the cumulative value of lock request waiting time, and the access path disturbance offset in the dimensions of time, resource access, access path depth, and business impact scope. Use the above statistical values ​​as input to perform weighted cumulative calculation to obtain a conflict aggregation score that reflects the degree of conflict aggregation, which is used to measure the degree of competition and blocking impact caused by the lock incompatible pair during execution.

[0078] S404: The obtained conflict aggregation score is written into a multidimensional tensor structure. Accumulation and compression are performed along the time, resource, granularity, and path depth dimensions using tensor operations. This aggregates the tensors representing the impact of local conflicts into scalar tensor conflict values. These tensor conflict values ​​describe the waiting depth, blocking intensity, and scheduling cost that micro-operations may generate during the overall execution process, providing a quantitative basis for decision-making in the subsequent execution sequence generation module.

[0079] It should be noted that tensor conflict operation, by quantifying the degree of resource contention and the waiting relationship of execution order, can reflect the conflict risk between micro-operations in the form of continuous values ​​rather than logical labels, thereby improving the computability and optimizability of scheduling strategies.

[0080] It should be noted that the following is a brief introduction to the relevant terms used in this embodiment:

[0081] Lock access sequence list: A data set that stores lock and unlock requests triggered by micro-operations in chronological order. Each record contains lock type, lock granularity, resource identifier, micro-operation identifier, and trigger time, used to reconstruct the resource access trajectory of micro-operations.

[0082] Lock compatibility matrix: A two-dimensional data structure used to record whether different combinations of lock types and lock granularities allow concurrent execution. Each matrix cell contains a Boolean flag indicating the compatibility or mutual exclusion state of the lock combination.

[0083] Lock incompatibility pairs: Lock combinations marked as mutually exclusive in the lock compatibility matrix, recording the trigger time interval, resource location, and access overlap range, used to quantify potential conflicts between micro-operations.

[0084] Conflict Cluster Score: A weighted cumulative value of conflict events in the corresponding region of the conflict density distribution for lock incompatibility, reflecting the blocking and competition impact of the lock combination during execution.

[0085] Multidimensional tensor structure: A data structure built around time dimension, resource dimension, granularity dimension and access path depth dimension. It is used to carry conflict aggregation scores and facilitates tensor operations and dimensional compression.

[0086] Tensor conflict value: A scalar obtained by summing up the multidimensional tensor structure along each dimension, used to describe the waiting depth, blocking intensity and scheduling cost that may occur during the execution of micro-operations.

[0087] This application expands the lock access behavior during micro-operation execution in step S4 at a temporal level and constructs a lock access sequence list structure by combining lock type, lock granularity, and resource access range. This allows for the accurate identification of potential access overlap relationships between different micro-operations. Furthermore, a lock compatibility matrix constructed based on this sequence list structure identifies lock incompatibility pairs that cannot be executed concurrently. Using conflict density distribution as a statistical basis, multi-dimensional aggregation calculations are performed on the time dimension, resource dimension, access path depth dimension, and business operation range dimension involved in the lock incompatibility pairs, forming a conflict aggregation score to quantify the degree of execution blocking and waiting dependency. Finally, the conflict aggregation score is used to generate a tensor conflict value that continuously quantifies the level of competition risk through tensor accumulation operations, achieving numerical identification of conflict relationships. This allows for more refined scheduling strategy decisions during the scheduling phase based on continuous numerical indicators rather than discrete conflict markers, realizing the computability and controllability of execution sequence optimization. This avoids scheduling imbalances and resource bottlenecks that may result from judging solely based on structural topology relationships, providing a reliable quantitative evaluation basis for subsequently generating micro-operation execution sequences with low waiting costs.

[0088] S5. Based on the conflict density distribution, identify the high conflict region of the dependency tensor model, and construct a potential deadlock graph by combining the conflict intensity value. Obtain the dependency closed-loop unit by performing loop detection on the potential deadlock graph.

[0089] Specifically, in S501, in the dependency tensor model, a multidimensional index is built for each micro-operation along the time dimension, resource dimension, granularity dimension, and access path depth dimension. For each index unit, conflict events are retrieved from the conflict density distribution dataset, and the cumulative number of conflicts, cumulative waiting time, and access path disturbance offset are counted. The statistical values ​​are weighted and accumulated to generate a conflict clustering score, and micro-operations with conflict clustering scores exceeding a preset threshold are marked as high-conflict areas.

[0090] S502 combines micro-operations in high-conflict regions with their corresponding tensor conflict values ​​to construct a potential deadlock graph. Each micro-operation serves as a graph node, and the waiting dependencies between micro-operations are mapped to directed edges, with tensor conflict values ​​appended as weights. Nodes record the resource identifier, lock type, and trigger time of each micro-operation. The potential deadlock graph is stored using an adjacency list, and each node maintains a list of edges pointing to dependent micro-operations, facilitating cycle detection.

[0091] S503 performs cycle detection in the potential deadlock graph. It traverses nodes using a depth-first search combined with a backtracking strategy to identify all indivisible closed-loop paths. Each closed-loop path contains multiple micro-operation nodes and their interdependent edges. The closed-loop path is output as a dependent closed-loop unit, and the resource identifier, lock type, trigger time, and conflict intensity information of the micro-operations within the loop are recorded to constrain the micro-operation scheduling order, reduce deadlock risk, and optimize execution efficiency.

[0092] It should be noted that, through high-conflict region identification, potential deadlock graph construction, and loop detection, this embodiment can quantify potential deadlock relationships between micro-operations and form dependency closed-loop units that can be used for scheduling constraints, thereby achieving control over the execution order of high-risk micro-operations and optimization of overall execution efficiency.

[0093] It should be noted that the following is a brief introduction to the relevant terms used in this embodiment:

[0094] High-conflict region: A multidimensional index unit that depends on micro-operations in the tensor model. Its conflict clustering score exceeds a preset threshold, indicating that the micro-operations in this region have a high risk of resource contention and waiting dependencies during execution.

[0095] Conflict Cluster Score: A weighted cumulative value calculated from the conflict events, lock wait time and access path disturbance offset of micro-operations in high-conflict regions, used to quantify the degree of competition and blocking between micro-operations.

[0096] Potential deadlock graph: A graph structure constructed with micro-operations in high-conflict regions as nodes and the waiting dependencies between micro-operations as directed edges. Each edge is assigned a tensor conflict value as a weight to represent potential deadlock relationships.

[0097] Adjacency list format: a storage method for potential deadlock graphs, where each node maintains a list of edges that point to micro-operations, facilitating loop detection and loop closure identification.

[0098] Ring detection: In a potential deadlock graph, all indivisible closed-loop paths are identified by traversing nodes and using backtracking strategies to determine the potential deadlock structure between micro-operations.

[0099] Dependency closed-loop unit: The closed-loop path identified by loop detection contains multiple micro-operation nodes and their interdependent edges. It records the resource identifier, lock type, trigger time and conflict intensity information of the nodes to constrain the execution order of micro-operations and prevent deadlock from occurring.

[0100] This application identifies high-conflict regions by performing conflict clustering analysis on micro-operations in a dependency tensor model. It then constructs a potential deadlock graph by combining these high-risk micro-operations with their corresponding tensor conflict values ​​and identifies dependency loop units through loop detection. This creates explicit constraints on non-concurrent operations before the micro-operation execution sequence is generated, enabling the scheduling order of micro-operations to avoid potential deadlock risks. At the same time, it quantifies the waiting dependencies and blocking intensity between micro-operations, thereby optimizing the execution order and improving overall scheduling efficiency.

[0101] S6. Generate a directed acyclic graph of micro-operations based on the set of micro-operations and the dependent closed-loop unit, and identify micro-operation nodes with zero in-degree and zero out-degree from the directed acyclic graph of micro-operations to form a first execution sequence.

[0102] Specifically, in S601, all micro-operations in the micro-operation set are used as graph nodes, the dependencies between micro-operations are used as directed edges, and the cyclic dependency constraint information in the dependency closure unit is integrated into the initial micro-operation directed graph. The micro-operation identifier, resource usage, and tensor conflict value are recorded in the graph nodes, and execution order constraints and conflict weights are attached to the edges. The initial micro-operation directed graph is stored using an adjacency list structure, and each node maintains a list of edges pointing to dependent micro-operations, which facilitates subsequent graph operations.

[0103] S602 identifies the dependency loop units in the initial micro-operation directed graph, calculates the tensor conflict value corresponding to each dependency edge in the loop for each loop unit, determines the dependency edge with the highest conflict value by comparison, and disassembles the edge from the loop to eliminate circular dependencies, transforming the initial micro-operation directed graph into a micro-operation directed acyclic graph, while retaining the original micro-operation nodes and most dependency constraints to ensure that the graph structure reflects the real business logic as much as possible.

[0104] S603: Traverse all nodes in the generated directed acyclic graph of micro-operations, identify micro-operation nodes with both in-degree and out-degree of zero. These nodes represent micro-operations that can be executed immediately under the current dependency constraints, and write them into the first execution sequence according to the node identifier and resource occupancy order for the generation and scheduling decision of subsequent candidate execution sequences.

[0105] It should be noted that by constructing a directed graph of preliminary micro-operations, decomposing dependency closed-loop units, and identifying zero-in-degree and zero-out-degree nodes, this embodiment can eliminate potential circular dependencies while retaining business dependency logic, providing a reliable set of starting nodes for subsequent execution sequence generation, and achieving the security and controllability of micro-operation execution scheduling.

[0106] It should be noted that the following is a brief introduction to the relevant terms used in this embodiment:

[0107] Micro-operation directed graph: A graph structure with micro-operations as nodes and the dependencies between micro-operations as directed edges, used to represent the constraints on the execution order of micro-operations;

[0108] Micro-operation directed acyclic graph: By decomposing the edge with the highest conflict in the dependency loop unit, the micro-operation directed graph is transformed into a graph structure without cyclic dependencies, which facilitates the generation of execution sequences;

[0109] Micro-operation nodes with both in-degree and out-degree of zero: In a directed acyclic graph of micro-operations, a node that neither depends on nor is depended upon by other nodes represents a micro-operation that can be executed immediately and is used to form the first execution sequence.

[0110] This application constructs a directed acyclic graph of micro-operations based on a set of micro-operations and dependency loop units, and identifies micro-operation nodes with both in-degree and out-degree of zero to form the first execution sequence. This effectively decomposes potentially existing circular dependencies while retaining most business logic constraints. Thus, while ensuring the integrity of micro-operation dependencies, it obtains a set of micro-operations that can be scheduled immediately, providing a reliable starting point for the generation of subsequent candidate execution sequences. This achieves the safety and controllability of execution scheduling, naturally reduces the risk of potential deadlock, and improves overall scheduling efficiency.

[0111] S7. Based on the micro-operation nodes with non-zero in-degree or out-degree in the directed acyclic graph of micro-operations and their corresponding dependencies, generate at least one candidate execution sequence, evaluate the performance of the candidate execution sequence based on the conflict intensity value, and select the candidate execution sequence with the best performance as the second execution sequence.

[0112] Specifically, in S701, all micro-operation nodes with non-zero in-degree or out-degree are selected from the directed acyclic graph of micro-operations as starting nodes for generating candidate execution sequences. At least one candidate execution sequence is generated by traversing the directed dependency edges of these nodes using a depth-first search or breadth-first search strategy. During the generation process, each micro-operation is arranged in executable order, and the sequence entry fully records the micro-operation identifier, resource usage, lock type, tensor conflict value, and trigger timestamp for subsequent conflict assessment and sequence optimization calculations.

[0113] S702: For each candidate execution sequence, the tensor conflict values ​​of the micro-operations are accumulated sequentially, and a weighted sum is used to obtain the total conflict amount of the sequence. Weights can be set for different dimensions, such as time, resource, lock granularity, or access path depth, to comprehensively quantify the resource contention, waiting blocking, and execution latency that may occur during the actual execution of the candidate sequence. The weighted sum can be implemented programmatically, such as calculating the multi-dimensional tensor conflict contribution of each micro-operation during sequence traversal and accumulating it to obtain the total conflict amount.

[0114] S703: Based on the calculated total conflict amount of each candidate execution sequence, all candidate sequences are sorted, and the sequence with the smallest total conflict amount is selected as the second execution sequence. In this sequence, each micro-operation still strictly follows the dependency constraint relationship, while minimizing resource contention and waiting blocking during sequence execution, thereby optimizing the micro-operation execution performance and providing a stable and reliable quantitative basis for subsequent execution sequence generation and scheduling strategies.

[0115] It should be noted that the following is a brief introduction to the relevant terms used in this embodiment:

[0116] Candidate execution sequence: A list of micro-operations generated based on nodes with non-zero in-degree or out-degree in the directed acyclic graph of micro-operations. Each sequence stores the micro-operation identifier, resource usage, lock type, tensor conflict value and trigger timestamp in the order of execution, for subsequent performance evaluation and optimization.

[0117] Total Conflict Count: The accumulated tensor conflict values ​​of all micro-operations in the candidate execution sequence according to preset weights, used to quantify the resource contention, waiting blocking and execution delay that may occur in the actual execution of the entire sequence.

[0118] Weighted dimensions: These are the dimensions used to allocate the degree of influence of tensor conflict values ​​when calculating the total conflict amount. They include time dimension, resource dimension, lock granularity dimension, and access path depth dimension, in order to comprehensively reflect the conflict risk of micro-operations during execution.

[0119] The second execution sequence is selected from the candidate execution sequences to minimize the total number of conflicts. This ensures that all micro-operations in the sequence satisfy the dependency constraints and minimizes resource contention and waiting blocking during execution, thus guiding subsequent scheduling and execution strategies.

[0120] Performance evaluation: The process of quantitatively judging the execution efficiency of a sequence based on the total number of conflicts in the candidate execution sequences. The optimal sequence is selected by accumulating and sorting the conflict values ​​of the micro-operation tensors in the sequence, thereby optimizing the execution performance.

[0121] This application selects nodes with non-zero in-degree or out-degree in a directed acyclic graph of micro-operations as the starting point of candidate execution sequences, and generates at least one candidate execution sequence along the micro-operation dependencies. Then, it calculates the total conflict amount by weighted accumulation based on the tensor conflict values ​​of each micro-operation in the sequence, and sorts all candidate sequences to select the sequence with the smallest total conflict amount as the second execution sequence. Through this derivation process, resource contention, waiting blocking, and latency in the execution process can be systematically quantified and minimized while ensuring that the micro-operation dependency constraints are satisfied. This ensures that the selected second execution sequence has higher execution performance and controllability in actual scheduling, thereby providing a reliable quantitative basis for subsequent micro-operation scheduling and sequence optimization.

[0122] S8, the second execution sequence is naturally concatenated after the first execution sequence to form a micro-operation execution sequence, and the execution of the micro-operation execution sequence is controlled.

[0123] Specifically, in S801, during the micro-operation execution sequence generation phase, the micro-operations in the first and second execution sequences are merged sequentially according to their respective sequence order to form a complete micro-operation execution sequence. During the merging process, the execution attributes of each micro-operation remain intact, including micro-operation identifier, lock type, lock granularity, resource identifier, trigger timestamp, tensor conflict value, and the scope of the business operation to which it belongs. The position of the micro-operation in the sequence is its planned execution order, and it is stored in memory in the form of a linear queue or linked list. Each node represents a micro-operation and saves the above attributes and the sequential relationship with the preceding and following micro-operation nodes to ensure that the execution order is traceable.

[0124] S802 triggers the execution of micro-operations step by step according to the micro-operation execution sequence. For each micro-operation, it first determines whether the required resources are idle and whether the lock state allows execution. If the lock is not occupied or is compatible with other locks, the micro-operation is executed. If the resources are occupied or there is a lock conflict, the waiting priority is calculated based on the micro-operation's tensor conflict value and a preset threshold, and the execution order is appropriately delayed in the sequence to reduce the overall waiting and blocking risks. During execution, a micro-operation status table is maintained. Each record includes the micro-operation identifier, resource occupancy status, lock holding and release time, actual execution start and end time, and the conflict impact of the micro-operation on the overall execution sequence, used to monitor the execution status and for subsequent optimization.

[0125] S803 After the micro-operation is completed, the execution status information of each micro-operation is updated to the status table, including the completion time, lock release time, and the number or intensity of actual conflict events. Based on this information, the order of unexecuted micro-operations can be dynamically adjusted or the performance evaluation of candidate execution sequences can be updated to form a closed-loop optimization. This ensures that the micro-operation execution order minimizes resource consumption, minimizes blocking risk, and optimizes overall execution efficiency while satisfying dependency constraints and lock constraints.

[0126] It should be noted that the following is a brief introduction to the relevant terms used in this embodiment:

[0127] Micro-operation execution sequence: A linear set of micro-operations formed by sequentially concatenating the first and second execution sequences. It is used to guide the sequential execution of micro-operations, and its order reflects the planned execution order of the micro-operations.

[0128] Micro-operation status table: A structured data set that records the execution status of micro-operations during execution, including resource usage, lock holding / releasing time, actual start and end times of execution, and the impact of conflicts. It is used to monitor the execution status and support dynamic optimization.

[0129] Execution order control: Micro-operations are triggered in the order of execution sequence, and the execution order is delayed or adjusted based on the lock state and tensor conflict value to reduce the risk of waiting and blocking.

[0130] This application merges the first and second execution sequences sequentially to form a complete linear set of micro-operations during the micro-operation execution sequence generation stage. During execution, micro-operations are triggered sequentially, and the execution order is dynamically adjusted based on lock status and tensor conflict values. This approach minimizes resource consumption and reduces blocking risk while preserving micro-operation dependencies and lock constraints. Furthermore, the application records the actual conflict situation during execution through a micro-operation status table and performs closed-loop optimization, thereby smoothly and naturally improving overall execution efficiency.

[0131] This embodiment parses multiple account operation requests into a set of micro-operations and determines the lock execution path based on the operation object identifier, operation type, and dependency relationship, thus clearly expressing the dependency structure and lock competition relationship between micro-operations. Furthermore, it constructs a dependency tensor model based on resource dependency, granular dependency, and business logic dependency, and performs conflict density mapping and tensor conflict operation in the tensor space, making the conflict intensity value quantifiable. Based on this, it uses the conflict density distribution to identify high-conflict regions and constructs a potential deadlock graph. Through loop detection, it obtains dependency closed-loop units, achieving a structured decomposition of non-parallel dependencies. Subsequently, it generates a directed acyclic graph of micro-operations and extracts nodes with both in-degree and out-degree of zero to form a first execution sequence. Simultaneously, it evaluates the performance of candidate execution sequences based on the conflict intensity value and determines a second execution sequence. The second execution sequence is then naturally concatenated with the first execution sequence to form the final micro-operation execution sequence, making the execution order verifiable and optimizable. Therefore, under the premise of satisfying dependency constraints, this embodiment can significantly reduce the blocking risk caused by conflicts and waiting, and improve execution throughput efficiency and overall concurrent processing performance.

[0132] Example 2: As Figure 2 As shown in Embodiment 1, the multi-account concurrent processing management system described in this application embodiment is used to parse, manage locks, analyze conflicts, and schedule the execution of operation requests from multiple accounts in a high-concurrency environment, achieving efficient and secure execution at the micro-operation level. The system includes several collaborative functional modules, as follows:

[0133] The system includes a micro-operation parsing module, which receives operation requests from multiple accounts and parses them into a set of micro-operations. Each micro-operation in the set is encapsulated as an operation object identifier, operation type, and dependencies, where dependencies include resource dependencies, granular dependencies, and business logic dependencies, so as to obtain resource usage information and sequence constraints at the micro-operation granularity.

[0134] The system further includes a lock path analysis module, which performs semantic analysis on each micro-operation in the micro-operation set based on the operation object identifier, operation type, and dependency relationship to determine the lock sequence, lock type, and lock granularity required by the micro-operation during execution, providing an accurate basis for subsequent conflict identification and lock compatibility analysis.

[0135] The system also includes a conflict intensity analysis module, comprising a dependency tensor model construction unit and a tensor conflict calculation unit. The dependency tensor model construction unit constructs a three-dimensional dependency tensor model based on the resource dependency, granular dependency, and business logic dependency of micro-operations, and maps the micro-operations into the model in conjunction with the lock execution path, forming a conflict density distribution. The tensor conflict calculation unit calculates the potential conflicts between micro-operations based on the lock execution path and the conflict density distribution, generating conflict intensity values ​​to guide the optimization of the micro-operation execution order.

[0136] The micro-operation directed acyclic graph generation module identifies high-conflict regions based on conflict density distribution and constructs a potential deadlock graph by combining conflict intensity values. It obtains dependent closed-loop units through loop detection and finally generates a micro-operation directed acyclic graph by combining the micro-operation set, providing a structural basis for execution sequence generation.

[0137] The micro-operation execution sequence generation module includes multiple functional units: the first execution sequence generation unit is used to identify micro-operation nodes with zero in-degree and zero out-degree from the acyclic graph to form an initial execution sequence; the candidate execution sequence generation unit generates multiple candidate execution sequences based on the remaining micro-operation nodes and their dependencies; the second execution sequence generation unit evaluates the candidate sequences based on the conflict intensity value and selects the best-performing sequence as the second execution sequence; the sequence combination unit concatenates the second execution sequence with the first execution sequence to form a complete micro-operation execution sequence.

[0138] The system also includes a sequence execution control module, which executes micro-operations sequentially according to the generated micro-operation execution sequence, so as to achieve orderly, efficient and secure execution of multiple account operation requests.

[0139] This application parses multiple account operation requests into a set of micro-operations, and performs lock path analysis and semantic inference at the micro-operation granularity by combining operation object identifiers, operation types, and dependencies. It constructs a dependency tensor model and calculates conflict density, identifies high-conflict regions through a directed acyclic graph of micro-operations, and optimizes the execution sequence. This enables the system to accurately identify resource occupancy and sequence constraints, and pre-plan the lock acquisition order and scheduling execution order in a high-concurrency environment, thereby effectively reducing potential conflicts and deadlock risks, and improving the concurrency of micro-operation execution and the overall system throughput.

[0140] The foregoing has shown and described the basic principles, main features, and advantages of this application. Those skilled in the art should understand that this application is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of this application. Various changes and modifications can be made to this application without departing from the spirit and scope thereof, and all such changes and modifications fall within the scope of this application as claimed. The scope of protection of this application is defined by the appended claims and their equivalents.

Claims

1. A method for managing concurrent multi-account processing, characterized in that, The method includes: The received multiple account operation requests are parsed into multiple micro-operations, forming a micro-operation set. Each micro-operation is encapsulated as an operation object identifier, operation type, and dependency relationship. The dependency relationship includes resource dependency, granularity dependency, and business logic dependency. For each micro-operation in the micro-operation set, the resource entity corresponding to the micro-operation is determined according to the operation object identifier, and the lock mode required for the micro-operation is determined according to the operation type. Based on the resource entity and the lock mode, and combined with the dependency relationship, the sequential constraints and potential conflicts between the micro-operation and other micro-operations are inferred, and a complete lock sequence required by the micro-operation during execution is generated to form a lock execution path. The lock execution path includes lock type, lock granularity and lock resource identifier. In the resource space dimension, the resource entities accessed by the micro-operation are analyzed according to the resource dependency analysis, and each resource entity is labeled to form a resource mapping. The resource mapping is used to reflect the correspondence between the resource entities of the micro-operation and the lock resource identifier. In the lock mode space dimension, the lock type and lock granularity of the micro-operation are analyzed in conjunction with the granularity dependency analysis and mapped to the lock mode space to form a lock mode mapping. The lock mode mapping is used to reflect the lock type and lock granularity used by the micro-operation during execution. In the time window dimension, the sequential constraints between micro-operations are analyzed based on the business logic dependency of the micro-operations to generate a time window mapping, which is used to reflect the execution order relationship of the micro-operations. The resource mapping, the lock mode mapping, and the time window mapping are fused in three-dimensional coordinates to form a dependency tensor model, which is used to provide a unified coordinate system for the positioning of micro-operations in the concurrency space. Perform time window analysis on the set of micro-operations to generate the micro-operation execution order; By combining the micro-operation execution order and the lock type, lock granularity, and lock resource identifier of the lock execution path, the micro-operations are projected onto the resource space dimension, lock mode space dimension, and time window dimension of the dependency tensor model to determine the spatial coordinates of each micro-operation in the micro-operation set. Calculate the conflict clustering score of the intersection region of each dimension in the dependent tensor model based on the spatial coordinates of all micro-operations, and generate a conflict density distribution using the conflict clustering score; Based on the lock execution path and the conflict density distribution, tensor conflict operation is performed on the micro-operation to obtain the conflict intensity value; Based on the conflict density distribution, high conflict regions of the dependency tensor model are identified, and a potential deadlock graph is constructed by combining the conflict intensity value. Dependency closed-loop units are obtained by performing loop detection on the potential deadlock graph. Based on the micro-operation set and the dependency closed-loop unit, a micro-operation directed acyclic graph is generated, and micro-operation nodes with zero in-degree and zero out-degree are identified from the micro-operation directed acyclic graph to form a first execution sequence. Based on the micro-operation nodes with non-zero in-degree or out-degree and their corresponding dependencies in the directed acyclic graph of micro-operations, at least one candidate execution sequence is generated, and the performance of the candidate execution sequence is evaluated based on the conflict intensity value. The candidate execution sequence with the best performance is selected as the second execution sequence. The second execution sequence is naturally concatenated after the first execution sequence to form a micro-operation execution sequence, and the execution of the micro-operation execution sequence is controlled.

2. The method according to claim 1, characterized in that, The step of performing tensor conflict operations on micro-operations based on the lock execution path and the conflict density distribution to obtain a conflict intensity value includes: Based on the lock type and lock granularity of the lock execution path, a lock compatibility matrix is ​​constructed between micro-operations; The lock compatibility state between the micro-operations is obtained from the lock compatibility matrix, and lock incompatibility pairs reflecting micro-operation conflicts are identified based on the lock compatibility state. For each lock incompatible pair, obtain the conflict clustering score of the lock incompatible pair in the intersection region of each dimension from the conflict density distribution; The conflict aggregation scores are accumulated to obtain the tensor conflict value of the micro-operation, which is used to quantify the competition and waiting relationship between micro-operations.

3. The method according to claim 2, characterized in that, The process of identifying high-conflict regions in the dependency tensor model based on conflict density distribution, constructing a potential deadlock graph by combining conflict intensity values, and obtaining dependency closed-loop units by performing loop detection on the potential deadlock graph includes: Based on the conflict density distribution analysis, the conflict clustering score of the micro-operations in the intersection region of each dimension of the dependent tensor model is analyzed, and the micro-operations corresponding to the conflict clustering score exceeding the preset threshold are marked as high conflict regions. A potential deadlock graph is constructed using the micro-operations in the high-conflict region and the tensor conflict values ​​corresponding to the micro-operations. The nodes of the potential deadlock graph are micro-operations, and the edges are waiting relationships between micro-operations. Cycle detection is performed on the potential deadlock graph to identify irremovable potential deadlock cycles, and these cycles are used as dependency loop units to characterize non-concurrent micro-operation dependency structures.

4. The method according to claim 3, characterized in that, The dependency closure unit includes cyclic dependency constraints. The step of generating a directed acyclic graph of micro-operations based on the micro-operation set and the dependency closure unit, and identifying micro-operation nodes with both in-degree and out-degree of zero from the directed acyclic graph of micro-operations to form a first execution sequence, includes: Using all micro-operations in the micro-operation set as nodes, the dependencies between micro-operations as edges, and incorporating the cyclic dependency constraints of the dependency loop unit, a preliminary directed graph of micro-operations is constructed. In the preliminary micro-operation directed graph, the dependent closed-loop unit is located, and the dependent edge with the highest tensor conflict value in the closed-loop unit is disassembled, transforming the preliminary micro-operation directed graph into a micro-operation directed acyclic graph. Identify all micro-operation nodes with zero in-degree and zero out-degree from the micro-operation directed acyclic graph to form the first micro-operation execution sequence.

5. The method according to claim 4, characterized in that, The step of generating at least one candidate execution sequence based on micro-operation nodes with non-zero in-degree or out-degree and their corresponding dependencies in the directed acyclic graph of micro-operations includes: Based on the micro-operation nodes with non-zero in-degree or out-degree and their corresponding dependencies, the micro-operation order is arranged in conjunction with the lock execution path of the micro-operation to generate at least one candidate execution sequence. The candidate execution sequence is used to reflect the feasible execution order of the micro-operations under the dependency constraint agreement.

6. The method according to claim 5, characterized in that, The step of evaluating the performance of the candidate execution sequences based on the conflict intensity value and selecting the candidate execution sequence with the best performance as the second execution sequence includes: The total number of conflicts in the candidate execution sequence is obtained by cumulatively calculating the tensor conflict intensity values ​​of each micro-operation in the candidate execution sequence. The candidate execution sequences are sorted based on the total number of conflicts, and the candidate execution sequence with the smallest total number of conflicts is selected as the second execution sequence. The second execution sequence reflects the optimal performance of micro-operation execution under the condition of satisfying dependency constraints.

7. A multi-account concurrent processing management system, characterized in that, The system includes: The micro-operation parsing module is used to receive multiple account operation requests and parse them into a set of micro-operations. The micro-operations in the set of micro-operations are encapsulated as operation object identifiers, operation types, and dependencies. The dependencies include resource dependencies, granular dependencies, and business logic dependencies. The lock path analysis module is used to determine the resource entity corresponding to each micro-operation in the micro-operation set based on the operation object identifier, and determine the lock mode required by the micro-operation based on the operation type; based on the resource entity and the lock mode, and combined with the dependency relationship, infer the order constraints and potential conflicts between the micro-operation and other micro-operations, generate the complete lock sequence required by the micro-operation during execution, and form a lock execution path, wherein the lock execution path includes lock type, lock granularity and lock resource identifier; The conflict intensity analysis module includes a dependency tensor model construction unit and a tensor conflict operation unit. Specifically, the dependency tensor model construction unit is used to analyze the resource entities accessed by the micro-operation based on the resource dependencies in the resource space dimension, and to label each resource entity to form a resource mapping. The resource mapping is used to reflect the correspondence between the resource entities of the micro-operation and the lock resource identifiers. In the lock mode space dimension, it combines the granularity dependency analysis of the lock type and lock granularity of the micro-operation and maps it to the lock mode space to form a lock mode mapping. The lock mode mapping is used to reflect the lock type and lock granularity used by the micro-operation during execution. In the time window dimension, it analyzes the sequential constraints between the micro-operations based on the business logic dependencies of the micro-operations and generates a time window mapping. The time window mapping is used to reflect the execution order of the micro-operations. The resource mapping and the lock mode mapping are then combined. The mapping and time window are fused in three dimensions to form a dependency tensor model. This dependency tensor model provides a unified coordinate system for the positioning of micro-operations in the concurrent space and performs time window analysis on the micro-operation set to generate a micro-operation execution order. Combining the micro-operation execution order with the lock type, lock granularity, and lock resource identifier of the lock execution path, the micro-operations are projected onto the resource space dimension, lock mode space dimension, and time window dimension of the dependency tensor model to determine the spatial coordinates of each micro-operation in the micro-operation set. Based on the spatial coordinates of all micro-operations, the conflict aggregation score of the intersection region of each dimension in the dependency tensor model is calculated, and the conflict aggregation score is used to generate a conflict density distribution. The tensor conflict operation unit is used to perform tensor conflict operation on the micro-operations according to the lock execution path and the conflict density distribution to obtain a conflict intensity value. The micro-operation directed acyclic graph generation module is used to identify high-conflict regions dependent on the tensor model based on the conflict density distribution, construct a potential deadlock graph by combining the conflict intensity value, obtain dependent closed-loop units by performing loop detection on the potential deadlock graph, and generate a micro-operation directed acyclic graph based on the micro-operation set and dependent closed-loop units. The micro-operation execution sequence generation module comprises a first execution sequence generation unit, a candidate execution sequence generation unit, a second execution sequence generation unit, and a sequence combination unit. Specifically, the first execution sequence generation unit is used to identify micro-operation nodes with both in-degree and out-degree of zero from the micro-operation directed acyclic graph to form a first execution sequence; the candidate execution sequence generation unit is used to generate at least one candidate execution sequence based on micro-operation nodes with non-zero in-degree or out-degree and their corresponding dependencies in the micro-operation directed acyclic graph; the second execution sequence generation unit is used to perform performance evaluation on the candidate execution sequences based on the conflict intensity value and select the candidate execution sequence with the best performance as the second execution sequence; the sequence combination unit is used to naturally concatenate the second execution sequence after the first execution sequence to form a micro-operation execution sequence. The sequence execution control module is used to execute the micro-operations sequentially according to the micro-operation execution sequence.

Images