強一致事務要求在任意時刻各節點資料在任意時刻都是一致的。強一致事務的解決方案主要有DTP模型（全域性事務模型）、2PC、3PC。
強一致性資料一致性較高，但是存在效能問題，在分散式事務未完全提交和回滾之前，查詢不到新的資料，犧牲了可用性，實現也比較複雜，不適合高併發場景。
基於DTP模型典型的解決方案是分散式通訊協議的XA規範。Mysql Connector在5.x開始提供對XA規範的支援。XA事務支援不同的資料庫，但是需要其都支援XA規範。
1.DTP模型
DTP中幾個重要的概念，全域性事務，分支事務
全域性事務：由事務管理器管理的事務，能夠一次操作多個資源管理器
分支事務：每個資源管理器中的獨立事務
AP：應用程式
RM：資源管理器，可以理解為資料庫
TM：事務管理器，負責協調和管理DTP模型中的事務，提供應用程式程式設計介面，同時管理資源管理器
2.2PC
2PC模型是指兩階段提交模型，它將事務流程分為prepare階段和commit階段。
prepare階段：事務管理器給參與全域性事務的資源管理器傳送prepare訊息，資源管理器要麼返回失敗，要麼在本地執行本地事務，將事務寫入本地的redolog檔案和undolog檔案，此時事務並沒有真正提交。
commit階段：事務管理器收到所有參與事務的資源管理器返回的訊息來決定是進行全域性事務提交或者回滾
2PC存在的問題
1.同步阻塞：事務執行過程，參與事務的節點都會對其佔用的公共資源枷鎖，導致其他訪問受阻
2.單點故障：事務管理器發生故障，會導致資源一致阻塞
3.資料不一致：如果在commit階段由於網路或部分資源管理器發生故障，會導致部分資源管理器未收到commit訊息，導致資料不一致
4.無法解決的問題：如果如果commit階段，事務管理器發出commit訊息後當機，並且唯一收到commit訊息的資源管理器也當機了，則無法確認事務是否已經提交
3.3PC
3PC是三階段提交是2PC的改進版本，它將prepare分成了兩個階段多出了一個canCommit階段，是否可以提交，再執行doCommit/doRollback。
3PC模型中資源管理器無法收到來自事務管理器發出的訊息，資源管理會自己執行事務的提交，不會一致持有造成阻塞，但是這也會導致資料的不一致。
以上主要的問題還是會存在資料的不一致，如果解決這個問題。我們可以記錄日誌，每個分支事務執行流程中的狀態資訊。以供發生異常情況之後可以恢復事務。比如Atomikos框架。
後續Atomikos實戰...