強一致事務要求在任意時刻各節點數據在任意時刻都是一致的。強一致事務的解決方案主要有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實戰...