(1)分佈式事務理論基礎
一、服務架構演進
1.單體應用：
最初的所有業務全部融合在一起，我們最初接觸到的一個java應用開發完成之後打成一個war包進行部署。
優點：
1）架構簡單，所有項目模塊部署在一起，對於小型項目來說方便維護
缺點：
1）所有模塊耦合在一起，對於大型項目來說不易與開發和維護
2）耦合度過高，一旦一個模塊出現問題，會導致整個項目不可用
3）無法針對某個具體的模塊來提升性能
4）無法進行水平擴展
2.垂直應用：
為滿足業務需求，將單體應用部署多份到不同服務器上。但是無法根據某個模塊來進行優化和性能提升，比如有些模塊屬於CPU密集型的，有些屬於IO密集型的。無法進行針對性的優化。垂直應用架構就是將單體應用拆分未及格互不相干的應用，來提升整個系統的性能。比如針對C端的部署成一個應用，管理後台部署成一個服務，C端一般流量大，這個時候只需要把C端的服務多部署幾個節點，而管理後台訪問量則不需要。
優點：
1）可以根據不同系統的訪問情況進行針對性優化
2）能夠實現水平擴展
3）各系統分擔流量，解決並發量問題
4）子系統故障，不影響其他子系統運行，提高整體的容錯率
缺點：
1）拆分後各系統相對獨立，無法進行相互調用
2）難免存在重疊的業務，重複開發，增加維護成本
3.分佈式應用
垂直應用越來越多，重複的的代碼也會越來越多，這個時候就講重複的業務抽離出來形成單獨的服務，提供給其他業務某塊調用。這個時候一般拆分成表現層和服務層，服務層負責處理業務邏輯，提供給表現層調用，表現層負責和前端進行交互。
優點：
1）重複代碼抽離，提高代碼復用
2）可以針對性的進行優化
缺點：
1）系統之間調用關係，依賴關係變得複雜
2）系統維護成本變高
4.SOA（面向服務）架構
分佈式架構下，當服務部署越來越多的時候，服務之間的關係，調用越來越複雜，這個時候我們需要增加統一的調度中心，對所有服務進行管理。增加註冊中心，解決各個服務之間的依賴和調用關係，使其自動註冊與發現。這個時候服務的粒度任然比較粗。
缺點：
1）某個服務出現問題，可能造成服務不可用
2）增加測試、運維成本
5.微服務架構
微服務架構是在SOA基礎上進一步的擴展和拆分。將一個大項目拆分成一個個小的可獨立部署的微服務，每個服務有自己的數據庫。
優點：
1）服務徹底拆分，各個服務獨立打包部署，獨立升級維護
2）每個服務複雜的業務清晰，利於後期擴展升級、維護
3）服務之間採用REST或者RPC協議通信
缺點：
1）開發成本高（對開發人員要求更高）
2）成本更高，每個服務都需要機器來部署
3）涉及各個服務的容錯性問題
4）涉及數據一致性問題
5）涉及分佈式事務問題
二、分佈式事務場景
1.跨JVM進程
因為服務拆分之後，要完成一個完整業務流程就可能涉及到多個服務之間調用。
2.跨數據庫實例
分庫導致或者本身業務就是操作不同的庫
3.多個服務訪問單數據庫
三、數據一致性解決方案
ACID特性：利用數據庫事務的ACID（原子性、一致性、隔離性、持久性）特性。有些分佈式事務解決方案其實最終也是要依賴數據庫的此特性。比如阿里seata中的AT模式。還有DTP模型、2PC模型（兩階段提交）、3PC（三階段提交）、TCC模型、可靠消息最終一致性模型、最大努力通知模型
四、分佈式事務基本理論
分佈式事務的兩大基本理論：CAP理論和Base理論
CAP（consistency一致性、可用性availability、分區容錯性partition tolerance）
要滿足一致性那麼我們在各個節點之間同步數據的時候，需要對資源進行鎖定等所有節點都同步完成之後再返回數據。防止在同步過程中應用程序從從節點讀取到不一致的數據。
可用性所有請求都會被響應，不會存在響應超時或錯誤的情況。
分區容錯，如果將系統部署在一個節點，那麼當節點出現故障時，整個系統將不可用。
因此需要多個節點部署，一個節點掛掉，其他節點也能對外提供服務。分區容錯時一個分佈式系統必須具備的基礎能力。
AP：放棄一致性，但是一般都會考慮最終一致性。允許多個節點在一定時間內數據存在差異，一定時間之後達到一致。比如eureka，節點之間同步數據是一個定時任務從其他節點去同步數據的，定時任務沒有觸發的這個時間內，節點之間的數據是不一致的。
CP：放棄可用性。當系統對一致性要求比較高的時候使用。比如ZK，寫入數據時需要保證過半的節點寫入之後，leader才會提交結果並返回。以此來保證數據的一致性。
CA：放棄分區容錯性，此時系統不會進行分區，也不用考慮網絡不通，節點掛掉等情況，嚴格來說此時的系統已經不是一個分佈式系統了。
Base理論是對AP的一個擴展，它犧牲了強一致性來獲得可用性。Basically Available(基本可用)，Soft State（軟狀態）和Eventually Consistent（最終一致性）的縮寫。
軟狀態比如訂單中可以設計「支付中」，「退款中」這種中間狀態，過一段時間之後變成「支付成功」「退款成功」。
後續：
強一致性分佈式事務解決方案、最終一致性分佈式事務解決方案
