在詳細介紹本說明書提供的方案之前，先結合傳統技術給出如下優化思路：
圖1所示的分布式事務處理方法的資訊交互圖可以如圖2所示。從圖2可以看出，在預處理階段，事務管理器對各個參與者的調用本質上沒有必然的依賴關係。此外，無論是在提交階段還是在轉返階段，上述調用過程也沒有必然的依賴關係。因此，在分布式環境中，事務管理器對各個參與者之間的調用是可以採用併發的方式進行的。也即各個分支事務是可以並行處理的。通過上述並行的方式，在參與者越多的情況下，分布式事務處理的時間並不會線性增加。舉例來說，若一次服務交互時間是T，則有N個參與者的情況下，若採用傳統的分布式事務處理的方式，兩個階段的處理開銷都是NT。而採用並行的方式，能夠基本保證處理時間為T。
下面結合上述優化思路，對本說明書提供的方案進行詳細描述。
本說明書一個實施例提供的分布式事務處理方法可以應用於如圖3所示的場景中，圖3中，業務系統用於根據業務請求，將分布式事務劃分為多個分支事務。此處的分支事務可以是指分布式事務的一次行為。以業務需求為：“從帳戶A轉帳100元給帳戶B”為例來說，則可以將分布式事務劃分為兩個分支事務，該兩個分支事務分別用於作如下處理：“A-100”和“B+100”。之後，業務系統可以將劃分的多個分支事務發送給事務管理器。事務管理器在接收到上述多個分支事務之後，可以對該多個分支事務進行解析，以確定各自的處理對象(如，帳戶等)以及對處理對象對應的資源(如，帳戶餘額、黃金等)的處理方式。之後，可以根據處理對象和處理方式，確定多個分支事務之間的依賴關係。並根據該依賴關係，並行及/或串行處理多個分支事務。最後，事務管理器將多個分支事務的處理結果資訊返回給業務系統。
需要說明的是，圖3中，事務管理器具體是通過調用參與者來處理分支事務的，其中，參與者可以是指事務管理器在處理分支事務時所調用的服務。如前述例子，一個參與者可以認為是財務庫A，而另一個參與者可以認為是財務庫B。具體地，在上述兩個分支事務的處理過程中，事務管理器可以調用財務庫A從帳戶A中轉出100元，可以調用財務庫B給帳戶B轉入100元。由此，就保了帳戶A扣款和帳戶B加款的一致性。在上述分支事務的處理過程中，若有任何異常，則失敗轉返，並反饋轉帳失敗。
圖4為本說明書一個實施例提供的分布式事務處理方法流程圖。所述方法的執行主體可以為圖3中的事務管理器。如圖4所示，所述方法具體可以包括：
步驟410，事務管理器獲取分布式事務對應的多個分支事務。
在一種實現方式中，業務系統可以根據業務需求，將分布式事務劃分為多個分支事務。以業務需求為：“從帳戶A轉帳100元給帳戶B，從帳戶B分潤5元給帳戶C”為例來說，則可以將分布式事務劃分為四個分支事務，該四個分支事務分別用於作如下處理：“A-100”、“B+100”、“B-5”和“C+5”。之後，業務系統可以將劃分的多個分支事務發送給事務管理器。
步驟420，對多個分支事務進行解析，以確定多個分支事務各自的處理對象以及對處理對象對應的資源的處理方式。
此處的處理對象可以包括使用者的帳戶等。處理對象對應的資源可以包括但不限於帳戶餘額(也稱資金)以及黃金等。而對處理對象對應的資源的處理方式可以包括資源增加和資源消耗等。以處理對象為帳戶，處理對象對應的資源為帳戶餘額為例來說，可以根據對帳戶的帳戶餘額的增減情況，確定對資源的處理方式。具體地，當增加帳戶中的帳戶餘額時，對資源的處理方式可以為資源增加；而當減少帳戶中的帳戶餘額時，對資源的處理方式可以為資源消耗。
如前述例子，四個分支事務各自的處理對象分別為：“帳戶A”、“帳戶B”、“帳戶B”和“帳戶C”。此外，由於第一個分支事務用於從帳戶A的帳戶餘額中扣除100元，也即第一個分支事務用於減少帳戶A中的帳戶餘額，所以其對資源的處理方式為：“資源消耗”。同理可以確定出其它三個分支事務對資源的處理方式分別為：“資源增加”、“資源消耗”和“資源增加”。
步驟430，根據處理對象和處理方式，確定多個分支事務之間的依賴關係。
在一種實現方式中，可以根據處理方式，對多個分支事務進行分類。在對分支事務進行分類後，根據處理對象，確定不同類別的分支事務之間的依賴關係。具體地，對多個分支事務中的每個分支事務，判斷該分支事務對處理對象對應的資源的處理方式是否為資源增加。若是，則確定該分支事務的類別為資源增加類。若否，則確定該分支事務的類別為資源消耗類。對資源增加類的分支事務，可以直接將該類別的分支事務確定為不存在依賴關係的分支事務。對資源消耗類的分支事務，判斷該資源消耗類的分支事務的處理對象是否與資源增加類的分支事務的處理對象相同。若是，則確定該資源消耗類的分支事務為存在依賴關係的分支事務。若否，則確定該資源消耗類的分支事務為不存在依賴關係的分支事務。
如前述例子，由於第二個分支事務(對應於“B+100”的分支事務)和第四個分支事務(對應於“C+5”的分支事務)對處理對象對應的資源的處理方式均為“資源增加”，所以可以確定該兩個分支事務的類別為資源增加類。由於第一個分支事務(對應於“A-100”的分支事務)和第三個分支事務(對應於“B-5”的分支事務)對處理對象對應的資源的處理方式均為“資源消耗”，所以可以確定該兩個分支事務的類別為資源消耗類。
對於資源增加類的兩個分支事務，可以確定該兩個分支事務為不存在依賴關係的分支事務。對資源消耗類的兩個分支事務，由於第三個分支事務與第二個分支事務的處理對象(帳戶B)相同，所以可以確定第三個分支事務為存在依賴關係的分支事務。而第一個分支事務與資源增加類的兩個分支事務的處理對象均不同，所以確定第一個分支事務為不存在依賴關係的分支事務。
步驟440，根據依賴關係，並行及/或串行處理多個分支事務。
在一種實現方式中，可以將不存在依賴關係的分支事務劃分到第一分組，將存在依賴關係的分支事務劃分到第二組。並行處理第一分組中的分支事務。在第一分組中的分支事務處理結束後，並行處理第二分組中的分支事務。
如前述例子，可以將第二個分支事務、第四個分支事務以及第一個分支事務劃分到第一分組。將第三個分支事務劃分到第二分組。之後，並行處理第二個分支事務、第四個分支事務以及第一個分支事務。在該三個分支事務處理結束後，處理第三個分支事務。此處，也可以理解為，第三個分支事務是串行處理的。
通過本說明書上述實施例提供的分布式事務處理方法，可以既提高分布式事務的處理效率，又能保證其處理的正確性。如前述例子，在對應於“A-100”、“B+100”和“C+5”的分支事務先並行處理，之後在串行處理對應於“B-5”分支事務的情況下，可以避免當對應於“B-5”分支事務先處理時，如果帳戶B的帳戶餘額為0，則會處理失敗的問題。也即，本說明書實施例中，當分支事務的處理對象相同時，可以通過設定處理順序的方式，來保證其處理的正確性。
可以理解的是，在本說明書上述實施例提供的事務處理方法中，假設事務管理器調用一次服務(或者參與者)的時間為T，且假設分布式事務被劃分為N個分支事務。那麼在N個分支事務之間不存在依賴關係的情況下，分布式事務的處理時間開銷為T。而在N個分支事務之間存在依賴關係的情況下，分布式事務的處理時間開銷為2T。由此，可以看出，在分布式事務不存在依賴關係的情況下，本說明書提供的方案可以將分布式事務處理時間控制在單分支事務處理時間範圍內，不會因為參與者增加而使得整個分布式事務處理時間增加。即便自分支事務之間存在依賴的情況下，處理時長依然可控，且不隨著參與者規模擴大而導致處理時間增長。
與上述分布式事務處理方法對應地，本說明書一個實施例還提供的一種分布式事務處理裝置，如圖5所示，該裝置包括：
獲取單元501，用於獲取分布式事務對應的多個分支事務。
解析單元502，用於對獲取單元501獲取的多個分支事務進行解析，以確定多個分支事務各自的處理對象以及對處理對象對應的資源的處理方式。
此處，處理對象可以為使用者的帳戶等。處理對象對應的資源可以為帳戶餘額等。
確定單元503，用於根據解析單元502解析得到的處理對象和處理方式，確定多個分支事務之間的依賴關係。
可選地，確定單元503具體可以用於：
根據處理方式，對多個分支事務進行分類；
根據處理對象，確定不同類別的分支事務之間的依賴關係。
可選地，確定單元503還具體可以用於：
對多個分支事務中的每個分支事務，判斷分支事務對處理對象對應的資源的處理方式是否為資源增加。
若是，則確定分支事務的類別為資源增加類。
若否，則確定分支事務的類別為資源消耗類。
將資源增加類的分支事務確定為不存在依賴關係的分支事務。
對資源消耗類的分支事務，判斷資源消耗類的分支事務的處理對象是否與資源增加類的分支事務的處理對象相同。
若是，則確定資源消耗類的分支事務為存在依賴關係的分支事務。
若否，則確定資源消耗類的分支事務為不存在依賴關係的分支事務。
處理單元504，用於根據確定單元503確定的依賴關係，並行及/或串行處理多個分支事務。
可選地，處理單元504具體可以用於：
將不存在依賴關係的分支事務劃分到第一分組，將存在依賴關係的分支事務劃分到第二組。
並行處理第一分組中的分支事務。
在第一分組中的分支事務處理結束後，並行處理第二分組中的分支事務。
本說明書上述實施例裝置的各功能模組的功能，可以通過上述方法實施例的各步驟來實現，因此，本說明書一個實施例提供的裝置的具體工作過程，在此不復贅述。
本說明書一個實施例提供的分布式事務處理裝置，獲取單元501獲取分布式事務對應的多個分支事務。解析單元502對多個分支事務進行解析，以確定多個分支事務各自的處理對象以及對處理對象對應的資源的處理方式。確定單元503根據處理對象和處理方式，確定多個分支事務之間的依賴關係。處理單元504根據依賴關係，並行及/或串行處理多個分支事務。由此，可以提高分布式事務的處理效率。
本領域技術人員應該可以意識到，在上述一個或多個示例中，本說明書所描述的功能可以用硬體、軟體、韌體或它們的任意組合來實現。當使用軟體實現時，可以將這些功能儲存在電腦可讀媒介中或者作為電腦可讀媒介上的一個或多個指令或代碼進行傳輸。
以上所述的具體實施方式，對本說明書的目的、技術方案和有益效果進行了進一步詳細說明，所應理解的是，以上所述僅為本說明書的具體實施方式而已，並不用於限定本說明書的保護範圍，凡在本說明書的技術方案的基礎之上，所做的任何修改、等同替換、改進等，均應包括在本說明書的保護範圍之內。Before introducing the solutions provided in this manual in detail, the following optimization ideas are given in combination with traditional technologies:
The information interaction diagram of the distributed transaction processing method shown in FIG. 1 can be shown in FIG. 2. As can be seen from Figure 2, in the pre-processing stage, the transaction manager's call to each participant has essentially no necessary dependency. In addition, no matter whether it is in the submission phase or in the reversion phase, the above-mentioned calling process also has no inevitable dependency relationship. Therefore, in a distributed environment, the transaction manager can call each participant in a concurrent manner. That is, each branch transaction can be processed in parallel. Through the above parallel method, in the case of more participants, the time of distributed transaction processing does not increase linearly. For example, if the service interaction time is T, and there are N participants, if the traditional distributed transaction processing method is adopted, the processing cost of both stages is NT. In parallel, the processing time can be basically guaranteed to be T.
The solution provided in this specification will be described in detail in conjunction with the above optimization ideas.
The distributed transaction processing method provided by an embodiment of this specification can be applied to the scenario shown in FIG. 3. In FIG. 3, the business system is used to divide the distributed transaction into multiple branch transactions according to the business request. The branch transaction here may refer to a behavior of the distributed transaction. Taking the business requirement as: "transfer 100 yuan from account A to account B", for example, the distributed transaction can be divided into two branch transactions, and the two branch transactions are used for the following processing: "A-100 "And "B+100". After that, the business system can send the divided branch transactions to the transaction manager. After receiving the multiple branch transactions, the transaction manager can parse the multiple branch transactions to determine the respective processing objects (such as accounts, etc.) and the resources corresponding to the processing objects (such as account balance, gold, etc.) ). Afterwards, the dependency relationship between multiple branch transactions can be determined according to the processing object and processing method. According to the dependency, multiple branch transactions are processed in parallel and/or serially. Finally, the transaction manager returns the processing result information of multiple branch transactions to the business system.
It should be noted that, in FIG. 3, the transaction manager specifically handles branch transactions by invoking participants, where participants may refer to services that the transaction manager calls when processing branch transactions. As in the previous example, one participant can be regarded as financial bank A, while another participant can be regarded as financial bank B. Specifically, during the processing of the above two branch transactions, the transaction manager can call financial bank A to transfer out 100 yuan from account A, and can call financial bank B to transfer 100 yuan to account B. As a result, the consistency of account A deduction and account B increase is guaranteed. In the process of the above branch transaction, if there is any abnormality, it will fail back, and feedback transfer failure.
4 is a flowchart of a distributed transaction processing method provided by an embodiment of the present specification. The execution subject of the method may be the transaction manager in FIG. 3. As shown in FIG. 4, the method may specifically include:
Step 410: The transaction manager obtains multiple branch transactions corresponding to the distributed transaction.
In one implementation, the business system can divide the distributed transaction into multiple branch transactions according to business requirements. Taking the business requirement as follows: "Transfer 100 yuan from account A to account B, and divide 5 yuan from account B to account C." For example, the distributed transaction can be divided into four branch transactions, and the four branch transactions Used for the following processing: "A-100", "B+100", "B-5" and "C+5". After that, the business system can send the divided branch transactions to the transaction manager.
Step 420: Analyze the multiple branch transactions to determine the respective processing objects of the multiple branch transactions and the processing method of the resources corresponding to the processing objects.
The processing object here may include the user's account and so on. The resources corresponding to the processing object may include but are not limited to account balance (also called funds) and gold. The processing method of the resource corresponding to the processing object may include resource increase and resource consumption. Taking the processing object as the account and the resource corresponding to the processing object as the account balance as an example, the processing method of the resource can be determined according to the increase and decrease of the account balance of the account. Specifically, when the account balance in the account is increased, the processing method for the resource may be increased for the resource; and when the account balance in the account is decreased, the processing method for the resource may be for resource consumption.
As in the previous example, the processing objects of the four branch transactions are: "Account A", "Account B", "Account B" and "Account C". In addition, because the first branch transaction is used to deduct 100 yuan from the account balance of account A, that is, the first branch transaction is used to reduce the account balance in account A, so its treatment of resources is: "resource consumption ". Similarly, it can be determined that the other three branch transactions deal with resources as follows: "resource increase", "resource consumption" and "resource increase".
Step 430, according to the processing object and the processing method, determine the dependency relationship between the multiple branch transactions.
In one implementation, multiple branch transactions can be classified according to processing methods. After classifying branch transactions, according to the processing object, determine the dependency relationship between different types of branch transactions. Specifically, for each branch transaction among the plurality of branch transactions, it is determined whether the processing manner of the branch transaction on the resource corresponding to the processing object is a resource increase. If yes, the category of the branch transaction is determined to be a resource increase category. If not, the category of the branch transaction is determined to be the resource consumption category. For the branch transaction of the resource addition category, the branch transaction of this category can be directly determined as a branch transaction that does not have a dependency relationship. For the branch transaction of the resource consumption class, it is determined whether the processing object of the branch transaction of the resource consumption class is the same as the processing object of the branch transaction of the resource increase class. If yes, it is determined that the branch transaction of the resource consumption class is a branch transaction with a dependency relationship. If not, it is determined that the branch transaction of the resource consumption class is a branch transaction that does not have a dependency relationship.
As in the previous example, the second branch transaction (corresponding to the "B+100" branch transaction) and the fourth branch transaction (corresponding to the "C+5" branch transaction) both deal with the resources corresponding to the processing object. It is "resource increase", so the category of the two branch transactions can be determined as the resource increase category. Because the first branch transaction (corresponding to the "A-100" branch transaction) and the third branch transaction (corresponding to the "B-5" branch transaction) deal with the resources corresponding to the processing object are "resource consumption ", so the category of the two branch transactions can be determined as the resource consumption category.
For the two branch transactions of the resource increase category, it can be determined that the two branch transactions are branch transactions that do not have a dependency relationship. For the two branch transactions of the resource consumption class, since the third branch transaction and the second branch transaction have the same processing object (account B), it can be determined that the third branch transaction is a branch transaction with a dependency relationship. The first branch transaction and the two branch transactions of the resource increase class have different processing objects, so it is determined that the first branch transaction is a branch transaction that does not have a dependency relationship.
Step 440: Process multiple branch transactions in parallel and/or serially according to the dependency relationship.
In an implementation manner, branch transactions that do not have a dependency relationship may be divided into a first group, and branch transactions that have a dependency relationship may be divided into a second group. The branch transactions in the first group are processed in parallel. After the branch transaction processing in the first packet ends, the branch transaction in the second packet is processed in parallel.
As in the previous example, the second branch transaction, the fourth branch transaction, and the first branch transaction can be divided into the first group. The third branch transaction is divided into the second group. After that, the second branch transaction, the fourth branch transaction, and the first branch transaction are processed in parallel. After the three branch transaction processing ends, the third branch transaction is processed. Here, it can also be understood that the third branch transaction is processed serially.
Through the distributed transaction processing method provided by the above embodiments of the present specification, the processing efficiency of the distributed transaction can be improved while the correctness of its processing can be ensured. As in the previous example, in the case where the branch transactions corresponding to "A-100", "B+100", and "C+5" are processed in parallel first, and then in the case of serial processing corresponding to the "B-5" branch transaction, To avoid the problem of processing failure if the account balance of account B is 0 when the branch transaction corresponding to "B-5" is processed first. That is, in the embodiments of the present specification, when the processing objects of the branch transactions are the same, the processing order can be set to ensure the correctness of the processing.
It can be understood that, in the transaction processing method provided in the above embodiment of the present specification, it is assumed that the time for the transaction manager to call a service (or participant) is T, and it is assumed that the distributed transaction is divided into N branch transactions. Then, when there is no dependency relationship between N branch transactions, the processing time overhead of the distributed transaction is T. When there are dependencies between N branch transactions, the processing time overhead of distributed transactions is 2T. From this, it can be seen that in the case where distributed transactions do not have dependencies, the solution provided in this specification can control the distributed transaction processing time within the single branch transaction processing time range, and will not cause the entire increase due to the increase in participants. Distributed transaction processing time increased. Even if there is a dependency between self-branch transactions, the processing time is still controllable, and the processing time does not increase as the size of the participants expands.
Corresponding to the foregoing distributed transaction processing method, an embodiment of this specification further provides a distributed transaction processing apparatus. As shown in FIG. 5, the apparatus includes:
The obtaining unit 501 is used to obtain multiple branch transactions corresponding to the distributed transaction.
The parsing unit 502 is configured to parse the multiple branch transactions acquired by the obtaining unit 501 to determine the respective processing objects of the multiple branch transactions and the processing manner of the resources corresponding to the processing objects.
Here, the processing object may be the user's account or the like. The resource corresponding to the processing object may be an account balance, etc.
The determining unit 503 is configured to determine the dependency relationship between multiple branch transactions according to the processing object and processing mode obtained by the parsing unit 502.
Optionally, the determining unit 503 may be specifically used for:
According to the processing method, classify multiple branch transactions;
According to the processing object, determine the dependency relationship between different types of branch transactions.
Optionally, the determining unit 503 may also be specifically used for:
For each branch transaction among multiple branch transactions, it is determined whether the branch transaction processes the resource corresponding to the processing object as a resource increase.
If it is, the category of the branch transaction is determined to be the resource increase category.
If not, the category of the branch transaction is determined to be the resource consumption category.
Determine the branch transaction of the resource increase class as a branch transaction that does not have a dependency relationship.
For the branch transaction of the resource consumption class, it is determined whether the processing object of the branch transaction of the resource consumption class is the same as the processing object of the branch transaction of the resource increase class.
If yes, it is determined that the branch transaction of the resource consumption class is a branch transaction with a dependency relationship.
If not, it is determined that the branch transaction of the resource consumption class is a branch transaction that does not have a dependency relationship.
The processing unit 504 is configured to process multiple branch transactions in parallel and/or serially according to the dependency relationship determined by the determining unit 503.
Optionally, the processing unit 504 may be specifically used to:
The branch transactions that do not have a dependency relationship are divided into the first group, and the branch transactions that have a dependency relationship are divided into the second group.
The branch transactions in the first group are processed in parallel.
After the branch transaction processing in the first packet ends, the branch transaction in the second packet is processed in parallel.
The functions of the functional modules of the device in the above embodiments of the present specification can be implemented by the steps of the above method embodiments. Therefore, the specific working process of the device provided by an embodiment of the present specification will not be repeated here.
In the distributed transaction processing apparatus provided in an embodiment of this specification, the obtaining unit 501 obtains multiple branch transactions corresponding to the distributed transaction. The parsing unit 502 analyzes the multiple branch transactions to determine the respective processing objects of the multiple branch transactions and the processing manner of the resources corresponding to the processing objects. The determining unit 503 determines the dependency relationship between multiple branch transactions according to the processing object and the processing method. The processing unit 504 processes multiple branch transactions in parallel and/or serially according to the dependency relationship. Thus, the processing efficiency of distributed transactions can be improved.
Those skilled in the art should be aware that in the above one or more examples, the functions described in this specification can be implemented by hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on the computer-readable medium.
The specific embodiments described above further describe the purpose, technical solutions, and beneficial effects of this specification in detail. It should be understood that the above are only specific implementations of this specification and are not intended to limit the scope of this specification. The scope of protection, any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of this specification, shall be included in the scope of protection of this specification.
