Transaction processing method and apparatus, electronic device, and medium

Abstract

The application provides a transaction processing method and device, electronic equipment and medium, wherein, according to the feature vector of the to-be-processed transaction and the feature vector of each current work thread, the similarity between the to-be-accessed data and the data accessed by all transactions in each work thread is calculated, and the transaction processing request is dispatched to the work thread corresponding to the data accessed by all transactions with the highest similarity, so that the transaction abortion rate is reduced and the transaction processing efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a transaction processing method, apparatus, electronic device, and medium. Background Technology

[0002] A transaction is a sequence of operations that access and potentially manipulate various types of data. These operations can either all be executed or none of them can be executed; it is an indivisible unit of work. To improve transaction processing speed, CPUs are configured with multiple worker threads to support parallel transaction processing.

[0003] However, concurrent transactions may access the same data, leading to transaction conflicts. Due to the atomicity of transactions, when a conflict occurs, the transaction will roll back the operations already executed and wait for re-execution. This renders the previous operations invalid, thus reducing transaction processing efficiency. Summary of the Invention

[0004] This application provides a transaction processing method, apparatus, electronic device, and medium, aimed at improving transaction processing efficiency.

[0005] In a first aspect, this application provides a method for configuring page components, comprising: generating a feature vector of a transaction to be processed based on a transaction processing request; wherein the feature vector of the transaction to be processed represents the data to be accessed that the transaction to be processed needs to access; calculating the similarity between the data to be accessed and the data to be accessed by all transactions in each of the current worker threads based on the feature vector of the transaction to be processed and the feature vectors of each current worker thread; wherein the feature vector of each worker thread represents the data to be accessed by all transactions in the worker thread; and scheduling the transaction processing request to the worker thread corresponding to the data to be accessed by all transactions with the highest similarity to the data to be accessed, so as to perform response processing to the transaction processing request under the worker thread.

[0006] Optionally, the feature vector of the data to be processed is generated based on the data to be accessed and the feature vector template, and the feature vector of each worker thread is generated based on the data that all transactions in the worker thread need to access and the feature vector template; the elements in the feature vector template correspond to at least one piece of data in the database, the database includes the data corresponding to all elements in the feature vector template, and the value of each element in the feature vector represents whether the corresponding data needs to be accessed; the step of calculating the similarity between the data to be accessed and the data that all transactions in each worker thread need to access based on the feature vector of the transaction to be processed and the feature vector of each current worker thread includes: obtaining the similarity between the data to be accessed and the data that all transactions in each worker thread need to access by calculating the similarity between the feature vector of the transaction to be processed and the feature vector of each current worker thread respectively.

[0007] Optionally, the transaction processing request includes the primary key of the data to be accessed; generating the feature vector of the transaction to be processed based on the transaction processing request includes: establishing an initial vector based on a feature vector template, wherein the current value of each element in the initial vector is a first value; obtaining a calculation result based on a hash algorithm according to the primary key of each data to be accessed, and taking the calculation result modulo the length of the initial vector to obtain a first remainder; and assigning a second value to the element corresponding to the first remainder in the initial vector to obtain the feature vector of the transaction to be processed; wherein the first value and the second value are different.

[0008] Optionally, the method further includes: for each worker thread, obtaining the feature vector of each transaction under the worker thread; performing an OR operation on the feature vectors of all transactions under the worker thread to obtain the feature vector of the worker thread.

[0009] Optionally, the step of obtaining the similarity between the data to be accessed and the data that all transactions in each of the working threads need to access by calculating the similarity between the feature vector of the transaction to be processed and the feature vector of each current working thread includes: performing an AND operation on the feature vector of the transaction to be processed and the feature vector of each working thread to obtain the intermediate feature vector corresponding to each working thread; multiplying the current weight feature vector by the intermediate feature vector corresponding to each working thread to obtain the similarity between the feature vector of the transaction to be processed and the feature vector of each working thread; wherein, the weight feature vector is generated based on the suspended transactions and feature vector templates within a predetermined time period, and the element values ​​in the weight feature vector represent the probability of access conflict of the corresponding data in each working thread.

[0010] Optionally, the method further includes: for each worker thread, establishing an initial weight vector based on a feature vector template, wherein the current value of each element in the initial weight vector is zero; counting the suspended transactions that occurred under the worker thread within a predetermined time period before the current time, and for each suspended transaction, adding a third value to the element corresponding to the data in the current initial weight vector that corresponds to the suspended transaction to obtain the weight vector of the worker thread; calculating the suspension rate of transactions within the predetermined time period before the current time, and if the suspension rate is greater than the suspension rate in the previous time period, summing the weight vectors of each worker thread to obtain the current weight feature vector; wherein the suspension rate is the proportion of all suspended transactions under each worker thread to all transactions under each worker thread.

[0011] Secondly, this application provides a transaction processing apparatus, comprising: a generation module, configured to generate a feature vector of a transaction to be processed based on a transaction processing request; wherein the feature vector of the transaction to be processed represents the data to be accessed by the transaction to be processed; a calculation module, configured to calculate the similarity between the data to be accessed and the data to be accessed by all transactions in each of the current working threads based on the feature vector of the transaction to be processed and the feature vectors of each current working thread; wherein the feature vector of each working thread represents the data to be accessed by all transactions in the working thread; and a processing module, configured to schedule the transaction processing request to the working thread corresponding to the data to be accessed by all transactions with the highest similarity to the data to be accessed, so as to perform response processing to the transaction processing request under the working thread.

[0012] Optionally, the feature vector of the data to be processed is generated based on the data to be accessed and the feature vector template, and the feature vector of each worker thread is generated based on the data that all transactions in the worker thread need to access and the feature vector template; the elements in the feature vector template correspond to at least one piece of data in the database, the database includes the data corresponding to all elements in the feature vector template, and the value of each element in the feature vector represents whether the corresponding data needs to be accessed; the calculation module is specifically used to obtain the similarity between the data to be accessed and the data that all transactions in each worker thread need to access by calculating the similarity between the feature vector of the transaction to be processed and the feature vector of each current worker thread respectively.

[0013] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor.

[0014] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described above.

[0015] The transaction processing method, apparatus, electronic device, and medium provided in this application calculate the similarity between the data to be accessed and the data that all transactions in each of the current working threads need to access, based on the feature vector of the transaction to be processed and the feature vector of each current working thread. The transaction processing request is then scheduled to the working thread corresponding to the data that all transactions need to access with the highest similarity. This avoids parallel processing of the transaction to be processed and conflicting transactions that may access similar data, thereby avoiding transaction termination due to simultaneous access to data, reducing the transaction termination rate, and thus improving the transaction processing efficiency. Attached Figure Description

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

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

[0018] Figure 1 A flowchart illustrating the transaction processing method provided in Embodiment 1 of this application;

[0019] Figure 2 A flowchart illustrating the transaction processing method provided in Embodiment 2 of this application;

[0020] Figure 3 A flowchart illustrating a method for obtaining the feature vector of a transaction to be processed, provided as an example;

[0021] Figure 4 A flowchart illustrating a method for obtaining the feature vector of a worker thread as an example;

[0022] Figure 5 A flowchart illustrating the similarity calculation method provided as an example;

[0023] Figure 6 A flowchart illustrating a method for obtaining weighted feature vectors is provided as an example.

[0024] Figure 7 This is a schematic diagram of the structure of a transaction processing device provided in Embodiment 3 of this application;

[0025] Figure 8 This is a schematic diagram of the structure of the electronic device provided in Embodiment 5 of this application.

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

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

[0028] A transaction is a sequence of operations that access and potentially manipulate various types of data. These operations can either all be executed or none of them can be executed; it is an indivisible unit of work. To improve transaction processing speed, CPUs are configured with multiple worker threads to support parallel transaction processing.

[0029] However, concurrent transactions may access the same data, leading to transaction conflicts. Due to the atomicity of transactions, when a conflict occurs, the transaction will abort subsequent operations and roll back the already executed operations, waiting to be re-executed. This renders the previous operations invalid, thus reducing the efficiency of transaction processing.

[0030] To address this, related technologies divide the data in the database into multiple datasets and establish a mapping from these datasets to worker threads. Based on the mapping relationship between the data to be accessed by a transaction and the worker threads, the transaction request is sent to the corresponding worker thread for processing.

[0031] However, when multiple transactions have different data to access belonging to the same dataset, these transactions can only be queued in one corresponding worker thread, while other worker threads may be idle, which reduces the efficiency of transaction processing.

[0032] The technical solutions of this application will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. In the description of this application, unless otherwise expressly specified and limited, the terms should be broadly understood within the art. The embodiments of this application will now be described with reference to the accompanying drawings.

[0033] Example 1

[0034] Figure 1A flowchart illustrating the transaction processing method provided in Embodiment 1 of this application is shown below. Figure 1 As shown, the transaction processing method provided in this embodiment includes:

[0035] S101: Generate the feature vector of the transaction to be processed based on the transaction processing request;

[0036] S102: Based on the feature vector of the transaction to be processed and the feature vector of each current working thread, calculate the similarity between the data to be accessed and the data that all transactions in each working thread need to access;

[0037] S103: Schedule the transaction processing request to the worker thread corresponding to the data that all transactions need to access that has the highest similarity to the data to be accessed, so as to perform the response processing of the transaction processing request under the worker thread.

[0038] In this embodiment, the transaction processing request includes relevant information about the data to be processed that the transaction needs to access. Based on this information, a feature vector of the transaction is generated. The feature vector of the transaction represents the data to be accessed that the transaction needs to access, and access includes reading and modifying the data.

[0039] After generating the feature vectors of the transactions to be processed, the similarity between the data to be accessed and the data accessed by all transactions in each worker thread is calculated based on the feature vectors of the transactions to be processed and the feature vectors of the worker threads. The feature vector of a worker thread represents the data accessed by all transactions in that worker thread, and all transactions under a worker thread include unprocessed transactions and transactions currently being processed. In practical applications, the transactions within a worker thread are dynamic, causing the feature vectors corresponding to the worker threads to also change. Therefore, it is necessary to obtain the feature vector of the current worker thread when calculating the similarity.

[0040] It's understandable that higher similarity indicates a greater likelihood and frequency of conflicts between the pending transaction and transactions within a worker thread. Therefore, transaction processing requests are scheduled to the worker threads corresponding to the data accessed by all transactions with the highest similarity to the data to be accessed. This ensures that the pending transaction and the transaction with the highest probability of conflict are queued in the same worker thread, and transactions within that worker thread are executed sequentially. This avoids conflicts between the pending transaction and transactions within its respective worker thread, thereby reducing the number of conflicts and improving transaction processing efficiency.

[0041] Furthermore, compared to related technologies that establish a mapping from data to worker threads, this embodiment schedules transactions based on similarity. This similarity is obtained from the feature vector of the current worker thread, which reflects the actual status of each worker thread. This demonstrates that the similarity-based scheduling scheme in this embodiment can adapt to changes in transactions within each worker thread, rather than relying on pre-set and unchangeable fixed worker threads. Therefore, this embodiment improves the rationality of transaction scheduling, thereby increasing transaction processing efficiency.

[0042] It is worth noting that when multiple worker threads have the same similarity, transaction processing requests can be scheduled to any worker thread with the same similarity.

[0043] After scheduling, the response to the transaction processing request is executed under this worker thread. In practical applications, the metadata of the transaction processing request can be sent to the worker thread with the highest similarity. The metadata includes the storage location of the transaction data to be processed, and the transaction data mainly includes the operation content of the data to be processed. The worker thread reads the transaction data based on the metadata and processes the transaction.

[0044] In practical applications, the method of this embodiment can be implemented based on a smart network interface card (NIC). The specific process is as follows: the user sends a transaction processing request through a client; after receiving the request, the smart NIC generates a first feature vector based on the transaction request. The smart NIC calculates the similarity between the data to be accessed and the data accessed by all transactions in each working thread based on the feature vector of the transaction to be processed and the feature vectors of each current working thread. It then schedules the transaction processing request to the working thread of the CPU with the highest similarity to the data to be accessed, and processes the transaction in that working thread. The smart NIC has a computing unit that can undertake part of the CPU's computing tasks, thus further improving the efficiency of transaction processing.

[0045] In this embodiment, based on the feature vector of the transaction to be processed and the feature vector of each current working thread, the similarity between the data to be accessed and the data that all transactions in each working thread need to access is calculated. The transaction processing request is then scheduled to the working thread corresponding to the data that all transactions need to access with the highest similarity. This avoids parallel processing of the transaction to be processed and conflicting transactions that may access similar data, thereby avoiding transaction termination due to simultaneous access to data, reducing the transaction termination rate, and thus improving the transaction processing efficiency.

[0046] Example 2

[0047] Figure 2 This is a flowchart illustrating the transaction processing method provided in Embodiment 2 of this application, as shown below. Figure 2As shown, based on the above embodiments, in the method provided in this embodiment, the feature vector of the data to be processed is generated based on the data to be accessed and the feature vector template, and the feature vector of each working thread is generated based on the data that all transactions in the working thread need to access and the feature vector template; the elements in the feature vector template correspond to at least one piece of data in the database, the database includes the data corresponding to all elements in the feature vector template, and the value of the element in the feature vector represents whether the corresponding data needs to be accessed; S102 includes:

[0048] S201: By calculating the similarity between the feature vector of the transaction to be processed and the feature vector of each current working thread, the similarity between the data to be accessed and the data that all transactions in each working thread need to access is obtained.

[0049] In this embodiment, the feature vector of the transaction to be processed and the feature vector of the worker thread are both generated based on the feature vector template. It can be understood that the feature vector of the transaction to be processed and the feature vector of the worker thread have the same length, which is the number of elements in the feature vector, and the data corresponding to the same bit are also the same.

[0050] Based on this, the similarity between the feature vector of the transaction to be processed and the feature vectors of each current worker thread is calculated. It can be understood that elements with the same bits in the feature vectors correspond to the same data. Therefore, obtaining the similarity between feature vectors can be approximated as obtaining the similarity between the data to be accessed and the data accessed by all transactions in each worker thread. In other words, this embodiment transforms the similarity reading between data into the similarity reading between feature vectors, which simplifies the calculation.

[0051] The following is an exemplary description of the feature vector generation process for the transaction to be processed. In one example, the transaction processing request includes the primary key of the data to be accessed; S101 includes:

[0052] An initial vector is established based on the feature vector template, wherein the current value of each element in the initial vector is the first value;

[0053] Based on the primary key of each piece of data to be accessed, a calculation result is obtained using a hash algorithm, and the calculation result is modulo the length of the initial vector to obtain the first remainder;

[0054] Furthermore, the element corresponding to the first remainder in the initial vector is assigned a second value to obtain the feature vector of the transaction to be processed; wherein the first value and the second value are different.

[0055] In this example, an initial vector is created based on the feature vector template, with each element taking the first value. In practical applications, transaction requests carry information about the data to be accessed, including the primary key. The primary key is unique and can be a string. Based on the primary key of the data to be accessed, a hash algorithm is used to obtain a numerical result. This result is then modulo the length of the feature vector template to obtain the first remainder.

[0056] Next, the elements in the initial vector corresponding to the first remainder are assigned the second value to generate the feature vector of the transaction to be processed. It can be understood that the data corresponding to the elements in the feature vector with the first value is not accessed, while the data corresponding to the elements with the second value is accessed. The second value is different from the first value; for example, the first value is 0 and the second value is 1.

[0057] It's worth noting that in practical applications, different data may have the same first remainder. This indicates that data with the same first remainder correspond to the same element. It's understandable that even if two feature vectors have the same element value, the data accessed by these two transactions may be different. Therefore, when computational power allows, the length of the feature vector template should be set as large as possible.

[0058] The following will provide an example of this solution in a specific scenario: Figure 3 The following is a flowchart illustrating a method for obtaining the feature vector of a transaction to be processed, as provided in the example. Figure 3 As shown, the feature vector template has a length of 10, and the elements in the feature vector are numbered from 0 to 9. An initial vector 37 is established based on the feature vector template, where each element has a value of zero. The transaction processing request includes the first primary key 31 (Key) of the first data. A ) and the second primary key 32 (Key) of the second data B Based on the hash function Hash, with the first primary key 31 as input, the first calculation result 33 is obtained, and the specific value of the first calculation result 33 is 267; with the second primary key 32 as input, the second calculation result 34 is obtained, and the value of the second calculation result 34 is 332.

[0059] Next, the first calculation result 33 is modulo the initial vector length (10) to obtain the first remainder 35 corresponding to the first calculation result 33. The specific value of the first remainder 35 is 7, and the element at position 7 is assigned the value 1. The second calculation result 34 is modulo the initial vector length (10) to obtain the first remainder 36 corresponding to the second calculation result 34. The specific value of the first remainder 36 is 2, and the element at position 2 is assigned the value 1 to obtain the feature vector 38 of the transaction to be processed. The feature vector 38 is (0,0,1,0,0,0,0,1,0,0,).

[0060] This example provides a method for generating feature vectors of transactions to be processed. It cleverly uses mathematical algorithms to associate data with feature vectors, thereby transforming the access status of data into feature vectors that are easy to calculate, so that similarity can be calculated based on the feature vectors later.

[0061] The following will provide an exemplary description of the feature vector generation process for worker threads, based on the above example. In one example, the transaction processing method further includes:

[0062] For each worker thread, obtain the feature vector of each transaction under that worker thread;

[0063] Perform an OR operation on the feature vectors of all transactions under the worker thread to obtain the feature vector of the worker thread.

[0064] In this example, for each worker thread, the feature vector of each transaction under that worker thread is obtained. The process of generating the feature vector of a transaction is the same as that of generating the feature vector of the transaction to be processed, and will not be repeated here. It is worth noting that after the transaction to be processed is scheduled to the corresponding worker thread, it becomes a transaction under that worker thread. During this process, the feature vector of the transaction to be processed remains unchanged. Therefore, in practical applications, the feature vector of the transaction to be processed can be stored, and when it is necessary to obtain the feature vector of the transaction under the worker thread, the corresponding feature vector can be directly extracted.

[0065] After obtaining the feature vector of each transaction under the worker thread, an OR operation is performed on the feature vectors of all transactions under the worker thread to obtain the feature vector of the worker thread. For the feature vector of the worker thread, it can be regenerated based on the current transaction when the transaction under the worker thread changes, and this feature vector can be stored and directly retrieved when calculating similarity. Alternatively, it can be generated based on the transactions under the current worker thread when calculating similarity.

[0066] The solution in this example will be explained below with reference to a specific scenario: Figure 4 This is a flowchart illustrating the feature vector generation process of the worker thread in Embodiment 2 of this application, as shown below. Figure 4As shown. There are a total of 4 transactions under a worker thread. The first feature vector 41, the second feature vector 42, the third feature vector 43 and the fourth feature vector 44 corresponding to the 4 transactions are obtained respectively. The corresponding bit elements of the 4 feature vectors are ORed to obtain the feature vector 45 of the worker thread.

[0067] In this example, an OR operation is performed on the feature vectors of all transactions under the worker thread to obtain the feature vector of the worker thread. This allows the feature vector of the worker thread to represent the data that all transactions under the worker thread need to access, thus providing a basis for subsequent similarity calculations.

[0068] The following will provide an exemplary description of the calculation process for the similarity between the feature vector of the transaction to be processed and the feature vector of the worker thread in this embodiment, based on the above example.

[0069] In one example, S201 includes:

[0070] Perform a bitwise AND operation on the feature vector of the transaction to be processed and the feature vector of each worker thread to obtain the intermediate feature vector corresponding to each worker thread.

[0071] The current weighted feature vector is multiplied by the intermediate feature vector corresponding to each worker thread to obtain the similarity between the feature vector of the transaction to be processed and the feature vector of each worker thread.

[0072] In this example, a bitwise AND operation is performed between the feature vector of the transaction to be processed and the feature vector of each worker thread to obtain an intermediate feature vector for each worker thread. This intermediate feature vector represents data accessed by both the transaction to be processed and the transactions within the worker threads; it is also known as conflicting data. However, more conflicting data does not necessarily mean that the transaction to be processed and the worker thread may conflict more frequently.

[0073] For example, a transaction needs to access four pieces of data, corresponding to a feature vector of (0,1,0,0,1,1,0,0,1,0). The feature vector of the first worker thread is (0,1,1,0,1,1,0,1,0,0). After performing a bitwise AND operation, the first intermediate feature vector is (0,1,0,0,1,1,0,0,0,0). The feature vector of the second worker thread is (0,0,1,0,1,0,0,0,0,1). After performing a bitwise AND operation, the second intermediate vector is (0,0,1,0,1,0,0,0,0,0). It can be seen that there are three conflicting data points between the transaction and the first worker thread, and two conflicting data points between the transaction and the second worker thread. However, in the first worker thread, the data corresponding to the second, fifth, and sixth elements each needs to be accessed once. In the second worker thread, the data corresponding to the third element needs to be accessed three times, and the data corresponding to the fifth element needs to be accessed twice. In other words, the transaction to be processed may conflict with the transaction in the first worker thread 3 times. The transaction to be processed may conflict with the transaction in the second worker thread 6 times. Therefore, the worker thread corresponding to the intermediate feature vector with the most duplicate data cannot be simply taken as the worker thread with the highest similarity to the transaction to be processed.

[0074] Therefore, this example introduces a weighted feature vector. This feature vector is generated based on the number of transaction interruptions within a predetermined time period and a feature vector template. The values ​​of the elements in the weighted feature vector represent the probability of access conflicts occurring in different worker threads for the corresponding data. It can be understood that the larger the value of an element in the weighted feature vector, the more times the data is accessed within the predetermined time period, and the more conflicts occur, indicating that the data is more popular.

[0075] In this example, the current weighted feature vector is multiplied by the intermediate feature vector corresponding to each worker thread to obtain the similarity between the feature vector of the transaction to be processed and the feature vectors of each worker thread. This method of obtaining similarity takes into account the popularity of the data and makes the calculated similarity more reasonable.

[0076] The following section will provide a detailed explanation of this example using specific scenarios: Figure 5 Here is a flowchart illustrating a similarity calculation method for an example, as follows: Figure 5As shown, the feature vector 52 of the transaction to be processed is (0,1,0,0,1,1,0,0,0,0), the feature vector 51 of the worker thread is (1,1,1,1,1,1,1,1,1,0,0), and the intermediate feature vector 53 obtained by performing a bitwise AND operation is (0,1,0,0,1,0,0,0,0,0), and the current weight feature vector 54 is (0.3,0.5,0,0.1,0.8,0.2,0.3,0,0.1,0). The intermediate feature vector is multiplied by the weight feature vector to obtain the corresponding similarity 55, which is 1.8.

[0077] In this example, the intermediate feature vector is used to represent the data that the transaction to be processed and the transactions of each worker thread need to access together. The weighted feature vector is then multiplied by each intermediate feature vector to obtain the similarity between the feature vector of the transaction to be processed and the feature vector of each worker thread. This example takes into account the different probabilities of data access conflicts corresponding to each element in the intermediate feature vector, which makes the obtained similarity more accurate and the worker thread to which the transaction to be processed is scheduled more reasonably, thereby avoiding conflicts between the transactions to be processed and improving the processing efficiency of the transactions.

[0078] Building upon the examples above, one example of the method also includes:

[0079] For each worker thread, an initial weight vector is established based on the feature vector template, and the current value of each element in the initial weight vector is zero.

[0080] The system counts the suspended transactions that occurred under the worker thread within a predetermined time period before the current time, and for each suspended transaction, it adds a third value to the element corresponding to the data of the suspended transaction in the current initial weight vector to obtain the weight vector of the worker thread.

[0081] Calculate the abort rate of transactions within a predetermined time period prior to the current time. If the abort rate is greater than the abort rate in the previous time period, sum the weight vectors of each worker thread to obtain the current weight feature vector. The abort rate is the proportion of all aborted transactions under each worker thread to all transactions under each worker thread.

[0082] This example provides a method for obtaining a weighted feature vector. In this example, before the statistics begin, an initial weight vector with each element set to zero is created for each worker thread based on a feature vector template. Then, stopped transactions occurring within a predetermined time period prior to the current moment are counted, and for each stopped transaction, a third value is added to the element in the current initial weight vector corresponding to the data from the stopped transaction, to obtain the weight vector for that worker thread.

[0083] Aborted transactions are those whose operations were stopped due to access conflicts. It's important to note that a transaction can be counted repeatedly based on the number of abortions. For example, when processing transaction A, if it's found that the data it needs to access conflicts with data in another ongoing transaction, transaction A's operation is aborted and rolled back to await re-execution, counting as one aborted transaction. When transaction A is processed a second time, if it still conflicts with other transactions, transaction A is aborted again, thus transaction A is counted twice. In other words, the counting of aborted transactions needs to be based on the number of conflicts.

[0084] The scheduled time can be set based on the computing power of the computing entity and the amount of transactions. For example, the scheduled time can be set to 1 second.

[0085] It is understandable that the weighted feature vector plays a crucial role in similarity calculation. In this example, the number of suspended transactions within a predetermined time period prior to the current moment is counted, and the accuracy of each element in the current weighted feature vector is judged based on the suspension rate of transactions in the historical time period. If the suspension rate within the predetermined time period prior to the current moment is greater than the suspension rate of the previous time period, that is, if the suspension rate is increasing, it indicates that the current weighted feature vector needs to be adjusted. Therefore, under this condition, the weighted vectors of each worker thread obtained above are summed to obtain the current weighted feature vector. Of course, if the suspension rate is not increasing, it means that the current weighted feature vector can meet the requirements of the current transaction processing. To reduce related calculations, the current weighted feature vector does not need to be updated.

[0086] The solution in this example will be explained below in conjunction with specific application scenarios: Figure 6 A flowchart illustrating a method for obtaining weighted feature vectors is provided as an example. Figure 6As shown, the CPU has 4 worker threads. For each worker thread, an initial weight vector 61 is created with all elements having a value of zero, and the third value is set to 0.2. There are 6 aborted transactions within the last second prior to the current time. Two of these aborted transactions occur in the first worker thread, with the corresponding conflicting data being the data corresponding to elements 4 and 6 of the initial weight vector. The values ​​of elements 4 and 6 of the corresponding initial weight vectors are increased by 0.2 to obtain the weight vector 62 (0,0,0,0,0.2,0,0.2,0,0,0,0,0) for the first worker thread. There are 0 aborted transactions in the second worker thread, so its corresponding weight vector is 63 (0,0,0,0,0,0,0,0,0,0,0). There are 3 aborted transactions in the third worker thread. The corresponding conflicting data consists of two instances of data corresponding to element 1 and one instance of data corresponding to element 2. The value of element 1 in the initial weight vector is increased by 0.2x2, and the value of element 2 is increased by 0.2, resulting in the weight vector 64 (0,0.4,0.2,0,0,0,0,0,0,0) for the third worker thread. The fourth worker thread has one aborted transaction, with the corresponding conflicting data being the data corresponding to element 8. The value of element 8 in the initial weight vector is increased by 0.2, resulting in the weight vector 65 (0,0,0,0,0,0,0,0,0,0.2,0) for the fourth worker thread. If the total number of transactions across all worker threads in the 1 second prior to the current time is 100, the abort rate is 6%, and the abort rate in the previous predetermined time period (1 second) is 2%. As can be seen, the abort rate is increasing. Therefore, the weight vectors corresponding to the four working threads are added together to obtain the current weight feature quantity 66 (0,0.4,0.2,0,0.2,0,0.2,0,0.2,0,0.2,0).

[0087] It is worth noting that when obtaining the weight vector of each worker thread in this example, the corresponding element value can be increased by a third value each time a transaction is aborted; alternatively, the corresponding element can be increased by the corresponding third value at the end of a predetermined time period.

[0088] In this example, the current weight feature vector is evaluated based on the statistics of suspended transactions within a predetermined time period before the current moment to determine whether it meets the requirement of a low suspension rate. If it does not meet the requirement, the weight feature vector is updated. Therefore, this example ensures the rationality of the values ​​of each element in the weight feature vector, reduces the suspension rate of transactions, and further improves the processing efficiency of transactions.

[0089] In this embodiment, the feature vectors of the transaction to be processed and the feature vectors of each working thread are all generated based on the same feature vector template. Therefore, these feature vectors have the same length, and the data corresponding to the same bit is also the same. In other words, the similarity between the feature vector of the transaction to be processed and the feature vectors of each working thread can be approximately equivalent to the similarity between the data to be accessed and the data that all transactions in each working thread need to access. This makes it easier to calculate the similarity between the data to be accessed and the data that all transactions in each working thread need to access.

[0090] Example 3

[0091] Figure 7 This is a schematic diagram of the transaction processing apparatus provided in Embodiment 3 of this application, as shown below. Figure 7 As shown, the transaction processing apparatus provided in this embodiment includes:

[0092] The generation module 71 is used to generate a feature vector of a transaction to be processed based on the transaction processing request; wherein the feature vector of the transaction to be processed represents the data to be accessed that the transaction to be processed needs to access.

[0093] Calculation module 72: The user calculates the similarity between the data to be accessed and the data that all transactions in each of the current working threads need to access, based on the feature vector of the transaction to be processed and the feature vectors of each current working thread; wherein, the feature vector of the working thread represents the data that all transactions in the working thread need to access;

[0094] The processing module 73 is used to schedule the transaction processing request to the worker thread corresponding to the data that all transactions need to access that has the highest similarity to the data to be accessed, so as to perform the response processing of the transaction processing request under the worker thread.

[0095] In this embodiment, the transaction processing request includes relevant information about the data to be processed that the transaction needs to access. The generation module 71 generates a feature vector of the transaction based on this information. The feature vector of the transaction represents the data to be accessed that the transaction needs to access, and access includes reading and modifying the data.

[0096] After the generation module 71 generates the feature vector of the transaction to be processed, the calculation module 72 calculates the similarity between the data to be accessed and the data to be accessed by all transactions in each of the worker threads, based on the feature vector of the transaction to be processed and the feature vector of the worker thread. The feature vector of the worker thread represents the data to be accessed by all transactions in the worker thread, and all transactions under the worker thread include unprocessed transactions and transactions currently being processed. In practical applications, the transactions in a worker thread are dynamic, causing the feature vector corresponding to the worker thread to also change; therefore, it is necessary to obtain the feature vector of the current worker thread when calculating the similarity.

[0097] It's understandable that higher similarity indicates a greater likelihood and frequency of conflicts between the pending transaction and transactions within a worker thread. Therefore, transaction processing requests are scheduled to the worker threads corresponding to the data accessed by all transactions with the highest similarity to the data to be accessed. This ensures that the pending transaction and the transaction with the highest probability of conflict are queued in the same worker thread, and transactions within that worker thread are executed sequentially. This avoids conflicts between the pending transaction and transactions within its respective worker thread, thereby reducing the number of conflicts and improving transaction processing efficiency.

[0098] Furthermore, compared to related technologies that establish a mapping from data to worker threads, this embodiment schedules transactions based on similarity. This similarity is obtained from the feature vector of the current worker thread, which reflects the actual status of each worker thread. This demonstrates that the similarity-based scheduling scheme in this embodiment can adapt to changes in transactions within each worker thread, rather than relying on pre-set and unchangeable fixed worker threads. Therefore, this embodiment improves the rationality of transaction scheduling, thereby increasing transaction processing efficiency.

[0099] It is worth noting that when multiple worker threads have the same similarity, transaction processing requests can be scheduled to any worker thread with the same similarity.

[0100] After scheduling, processing module 73 executes the response processing of the transaction processing request under the worker thread. In practical applications, the metadata of the transaction processing request can be sent to the worker thread with the highest similarity. The metadata includes the storage location of the transaction data of the transaction to be processed, and the transaction data mainly includes the operation content of the data to be processed. The worker thread reads the transaction data according to the metadata and processes the transaction.

[0101] In this embodiment, the calculation module calculates the similarity between the data to be accessed and the data that all transactions in each of the current working threads need to access, based on the feature vector of the transaction to be processed and the feature vector of each current working thread. The transaction processing request is then scheduled to the working thread corresponding to the data that all transactions need to access with the highest similarity. This avoids parallel processing of the transaction to be processed and conflicting transactions that may access similar data, thereby avoiding transaction termination due to simultaneous access to data, reducing the transaction termination rate, and thus improving the transaction processing efficiency.

[0102] Example 4

[0103] Based on Embodiment 3, in the device provided in this embodiment, the feature vector of the data to be processed is generated based on the data to be accessed and the feature vector template, and the feature vector of each working thread is generated based on the data that all transactions in the working thread need to access and the feature vector template; the elements in the feature vector template correspond to at least one piece of data in the database, the database includes the data corresponding to all elements in the feature vector template, and the value of the element in the feature vector represents whether the corresponding data needs to be accessed;

[0104] The calculation module 72 is specifically used to obtain the similarity between the data to be accessed and the data that all transactions in each of the current working threads need to access by calculating the similarity between the feature vector of the transaction to be processed and the feature vector of each current working thread.

[0105] In this embodiment, the feature vector of the transaction to be processed and the feature vector of the worker thread are both generated based on the feature vector template. It can be understood that the feature vector of the transaction to be processed and the feature vector of the worker thread have the same length, which is the number of elements in the feature vector, and the data corresponding to the same bit are also the same.

[0106] Based on this, the calculation module 72 calculates the similarity between the feature vector of the transaction to be processed and the feature vectors of each current working thread. It can be understood that elements with the same bits in the feature vectors correspond to the same data. Therefore, obtaining the similarity between feature vectors can be approximated as obtaining the similarity between the data to be accessed and the data accessed by all transactions in each working thread. In other words, this embodiment transforms the similarity reading between data into the similarity reading between feature vectors, thus simplifying the calculation.

[0107] In this embodiment, the feature vectors of the transaction to be processed and the feature vectors of each working thread are all generated based on the same feature vector template. Therefore, these feature vectors have the same length, and the data corresponding to the same bit is also the same. In other words, the similarity between the feature vector of the transaction to be processed and the feature vectors of each working thread can be approximately equivalent to the similarity between the data to be accessed and the data that all transactions in each working thread need to access. This makes it easier to calculate the similarity between the data to be accessed and the data that all transactions in each working thread need to access.

[0108] Example 5

[0109] Figure 8 This is a schematic diagram of the structure of the electronic device provided in Embodiment 5 of this application, as shown below. Figure 8 As shown, the electronic device includes:

[0110] The electronic device includes a processor 291 and a memory 292; it may also include a communication interface 293 and a bus 294. The processor 291, memory 292, and communication interface 293 can communicate with each other via the bus 294. The communication interface 293 can be used for information transmission. The processor 291 can invoke logical instructions stored in the memory 292 to execute the methods of the above embodiments.

[0111] Furthermore, the logic instructions in the aforementioned memory 292 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0112] The memory 292, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this application. The processor 291 executes functional applications and data processing by running the software programs, instructions, and modules stored in the memory 292, thereby implementing the methods in the above-described method embodiments.

[0113] The memory 292 may include a program storage area and a data storage area. The program storage area may store the operating system and application programs required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 292 may include high-speed random access memory and may also include non-volatile memory.

[0114] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods described in any of the embodiments.

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

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

Claims

1. A method for processing transactions, characterized in that, include: Based on the transaction processing request, a feature vector of the transaction to be processed is generated; wherein, the feature vector of the transaction to be processed represents the data to be accessed that the transaction to be processed needs to access. Based on the feature vector of the transaction to be processed and the feature vector of each current worker thread, the similarity between the data to be accessed and the data that all transactions in each worker thread need to access is calculated; wherein, the feature vector of the worker thread represents the data that all transactions in the worker thread need to access. The transaction processing request is scheduled to the worker thread corresponding to the data that all transactions need to access that has the highest similarity to the data to be accessed, so that the response processing of the transaction processing request is performed under the worker thread; The feature vector of the pending transaction is generated based on the data to be accessed and the feature vector template. The feature vector of each worker thread is generated based on the data that all transactions in the worker thread need to access and the feature vector template. Each element in the feature vector template corresponds to at least one piece of data in the database, which includes the data corresponding to all elements in the feature vector template. The value of each element in the feature vector represents whether the corresponding data needs to be accessed. The step of calculating the similarity between the data to be accessed and the data that all transactions in each worker thread need to access, based on the feature vector of the pending transaction and the feature vectors of each current worker thread, includes: By calculating the similarity between the feature vector of the transaction to be processed and the feature vector of each current worker thread, the similarity between the data to be accessed and the data that all transactions in each worker thread need to access is obtained.

2. The method according to claim 1, characterized in that, The transaction processing request includes the primary key of the data to be accessed; generating the feature vector of the transaction to be processed based on the transaction processing request includes: An initial vector is established based on the feature vector template, wherein the current value of each element in the initial vector is the first value; Based on the primary key of each piece of data to be accessed, a calculation result is obtained using a hash algorithm, and the calculation result is modulo the length of the initial vector to obtain a first remainder; and the element corresponding to the first remainder in the initial vector is assigned a second value to obtain the feature vector of the transaction to be processed; wherein the first value and the second value are different.

3. The method according to claim 2, characterized in that, The method further includes: For each worker thread, obtain the feature vector of each transaction under that worker thread; Perform an OR operation on the feature vectors of all transactions under the worker thread to obtain the feature vector of the worker thread.

4. The method according to claim 3, characterized in that, The step of obtaining the similarity between the data to be accessed and the data that all transactions in each of the worker threads need to access by calculating the similarity between the feature vector of the transaction to be processed and the feature vector of each current worker thread includes: Perform a bitwise AND operation on the feature vector of the transaction to be processed and the feature vector of each worker thread to obtain the intermediate feature vector corresponding to each worker thread. The current weight feature vector is multiplied by the intermediate feature vector corresponding to each worker thread to obtain the similarity between the feature vector of the transaction to be processed and the feature vector of each worker thread; wherein, the weight feature vector is generated based on the suspended transactions and feature vector templates within a predetermined time period, and the element values ​​in the weight feature vector represent the probability of access conflict of the corresponding data in each worker thread.

5. The method according to claim 4, characterized in that, The method further includes: For each worker thread, an initial weight vector is established based on the feature vector template, and the current value of each element in the initial weight vector is zero. The system counts the suspended transactions that occurred under the worker thread within a predetermined time period before the current time, and for each suspended transaction, it adds a third value to the element corresponding to the data of the suspended transaction in the current initial weight vector to obtain the weight vector of the worker thread. Calculate the abort rate of transactions within a predetermined time period prior to the current time. If the abort rate is greater than the abort rate in the previous time period, sum the weight vectors of each worker thread to obtain the current weight feature vector. The abort rate is the proportion of all aborted transactions under each worker thread to all transactions under each worker thread.

6. A transaction processing apparatus, characterized in that, include: The generation module is used to generate a feature vector of a transaction to be processed based on the transaction processing request; wherein the feature vector of the transaction to be processed represents the data to be accessed that the transaction to be processed needs to access. The calculation module allows the user to calculate the similarity between the data to be accessed and the data that all transactions in each of the current worker threads need to access, based on the feature vector of the transaction to be processed and the feature vectors of each current worker thread; wherein, the feature vector of each worker thread represents the data that all transactions in the worker thread need to access. The processing module is used to schedule the transaction processing request to the worker thread corresponding to the data that all transactions need to access that have the highest similarity to the data to be accessed, so as to perform response processing to the transaction processing request under the worker thread; The feature vector of the pending transaction is generated based on the data to be accessed and the feature vector template. The feature vector of each worker thread is generated based on the data that all transactions in the worker thread need to access and the feature vector template. The elements in the feature vector template correspond to at least one piece of data in the database. The database includes the data corresponding to all elements in the feature vector template. The value of each element in the feature vector represents whether the corresponding data needs to be accessed. The calculation module is specifically used to obtain the similarity between the data to be accessed and the data that all transactions in each of the current working threads need to access by calculating the similarity between the feature vector of the transaction to be processed and the feature vector of each current working thread.

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

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

Images