查看的源碼是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創建是異步的，怎麼保證更新的時候數據存在？