檢視的原始碼是master分支 時間2018.04.10

這一款分散式事務中介軟體是基於mq進行補償不支援回滾 所以發起rpc操作就意味著成功，注意呼叫的順序

比如現在有一個發起者和兩個提供者，發起者需要呼叫2個提供者暴露的服務

先看發起者

發起者在呼叫帶有@myth註解的事務方法的時候，會先執行aop攔截，建立事務MythTransaction和MythTransactionContext，前者只用於某個服務和日誌持久化，後者用於跨節點，讓提供者知道當前事務的資訊，

提供者建立完事務會扔一個阻塞佇列，有一些work執行緒會不斷的取出，然後持久化事務日誌，持久化支援db，redis，zk等等方式，序列化方式也有很多選擇，使用spi的方式

然後執行業務方法，這時候會發起rpc操作，發起操作會將提供者的資訊儲存到MythTransaction的mythParticipants，每新增一個參與者，就會把相關訊息持久化，用作於傳送mq

這行業務方法完成之後，進入到aop，在finally部分會進行發訊息，當然可能這時候已經掛了，沒有發，沒關係，有一個執行緒池會不斷取出狀態為2即開始狀態的mythParticipants日誌，然後進行發佇列操作，往所有提供者發完訊息之後，會將事務日誌的狀態設定為1即已提交。

再看提供者 提供者先儲存事務日誌 狀態為開始 然後業務方法，然後修改事務日誌狀態為提交。

提供者的方法正常情況下rpc操作會呼叫一次，然後發訊息也會呼叫一次，所以介面要做冪等，比如可能做完業務方法，然後掛了，日誌沒有修改為提交，或者日誌儲存是非同步的，訊息過來還沒有入庫等等。

問題

1 發起者補償操作發佇列是基於日誌的，日誌的入庫是非同步的在阻塞佇列中，要是業務已經發起rpc操作，這時候發起者的日誌還沒有儲存就掛了，由於沒有日誌發起者重啟之後不會補償發訊息。所以我覺得日誌一定要有。

2 需要呼叫本地事務完成 在發起遠端事務，不然本地失敗了 還會發起rpc

3 updateParticipant更新是同步的 ，mythParticipants建立是非同步的，怎麼保證更新的時候資料存在？