hmily原理？

這一篇不想談論Hmily源碼的技術實現，而是想在過了一遍hmily的實現后把hmily的工作思路單獨地整理出來再進行一次總結。看看能不能進一步有所得。

以hmily-demo-springcloud為例，它的實現思路如下。

Hmily事務工作流程

首先它是基于切面編程來實現分布式事務的操作，及通過日志記錄TCC事務的信息以保證最終一致性。

前端發起的一個請求，第一次進入一個@Hmily注解的函數的時候，就進入Hmily的事務管理了。

這時會進入切面方法，生成一個日志實例（HmilyTransaction實例）。日志實例里面存儲了所有后續需要操作的信息，比如流轉狀態，執行函數信息等等，并在后續的操作中會根據需要加入新的信息。

日志實例 有一個執行狀態，一開始時是PRE_TRY（開始執行try），并會通過一個并發隊列異步存儲到數據庫中。順便說一句，每個微服務都有一個日志表，存儲著對應的日志。

關于異步存儲要多說一句，hmily在設計的時候把許多操作，尤其是對日志表的刪改查操作都改用異步操作的方式，這也是hmily如此高效的一個原因，值得重點分析。

剛才說到日志實例被異步存儲到數據庫的日志表中了，而另一邊就開始執行我們的業務函數。

如果函數內部再調用的函數仍有@Hmily注解，這時候切面里面不做其他任何操作。

如果調用的函數有@Hmily注解且是RPC函數，也就是調用其他微服務的代理接口，這時候會把事務id(transId 是事務唯一的，一個分布式事務id只有一個，且被用于日志主鍵)，及當前的角色狀態一起作為請求頭的參數。

被調用的微服務接收到請求后，如果執行到帶有@Hmily的函數，會根據傳遞過來的transId 的事務信息生成又一個事務日志信息，狀態為PRE_TRY（開始執行try），并異步存儲到數據庫中對應該微服務的日志表中。

接著繼續執行該微服務的主體方法

如果該微服務又調用了其它微服務，則同第7步到第12步。

如果執行成功，修改 事務日志的流轉狀態為TRYING（TRY階段完成），如果失敗了則刪除日志拋出異常。

現在回到第一個微服務，如果調用成功，會把該rpc接口信息存儲到日志信息里面。

如果還有調用其他微服務，則同第7步到13步。

如果所有的執行都沒問題，這時候會把日志的狀態改為TRYING（TRY階段完成），然后發起異步任務執行confirm操作。

confirm操作里會把狀態改為CONFIRMING(“confirm階段”)，并異步存儲到數據庫中，然后通過反射存儲在日志里面的confirmMethod方法，及調用rpc接口，將執行confirm的命令發送給對應的微服務。

其它微服務接收到confirm消息后，會根據該微服務的事務日志中存儲的confirmMethod集合，一一執行，或再把該命令發送給被調用的下一層微服務，重復17步驟。

如果各個微服務在執行confirmMethod時，有失敗的案例，會將失敗的confirmMethod重新存儲到對應的事務日志中，然后隔一定時間通過定時再次執行confirmMethod。直到一一成功或超過重試次數發出信息給維護人員處理。confirmMethod失敗后的定時執行的這一步各個微服務已經是各自為政了，不用再自上而下的從第一個微服務發起任務。

cancel方法同16步到18步。它的觸發條件是，只要在try階段里有哪個try出問題了，異常會層層拋出到最上層，后面的try都不執行。而前面執行過的try信息或調用過的rpc接口信息都會存儲在事務日志中間。后面只要同confirm階段一樣，根據這些信息執行cancelMethod方法或對RPC接口發起cancel請求