章節(jié)歸屬
概述
Seata的核心價值在于 構(gòu)建一個全面解決分布式事務(wù)問題的標(biāo)準(zhǔn)化平臺。
當(dāng)前技術(shù)背景下，不存在一個分布式事務(wù)處理機制可以完美滿足所有場景的需求，系統(tǒng)存在一致性、可靠性、易用性、性能等諸多方面的約束，需要不同的事務(wù)處理機制去滿足。
基于Seata，上層應(yīng)用架構(gòu)可以根據(jù)實際場景的需求，靈活選擇合適的分布式事務(wù)解決方案。
1.TCC模式（2PC、補償型）
據(jù)說螞蟻早期大量采用的分布式事務(wù)方案就是TCC模式，屬于萬金油了。
1.1 優(yōu)點
資源鎖定時間短
使用TCC模式時，在try階段就提交了本地事務(wù)，并不會鎖定資源，所以沒有其他額外的性能開銷
并發(fā)度高
可由其他方式鎖定資源，而不必對數(shù)據(jù)加全局鎖，允許多個事務(wù)同時操作數(shù)據(jù)。
應(yīng)對場景多
- 可在非JDBC方式通信的DB（如Elasticsearch 、Redis）場景使用。
- 可在非DB場景（如三方rest接口）場景使用。
1.2 缺點
業(yè)務(wù)侵入嚴重
服務(wù)提供方必須已手動方式 將業(yè)務(wù)邏輯拆分成2階段，實現(xiàn)try、confirm和cancel 3個方法，遵守分布式事務(wù)所約束的額外的規(guī)則。
開發(fā)維護成本高
try、confirm和cancel 3個固定邏輯，無法通過事務(wù)框架自動生成，設(shè)計、開發(fā)成本高，后續(xù)維護改造的成本也高。
2.AT模式（2PC、補償型）
Seata中默認推薦的模式，官宣能應(yīng)對當(dāng)下80%的分布式場景。
2.1.優(yōu)點：
業(yè)務(wù)無侵入
對業(yè)務(wù)無入侵，開發(fā)者只需正向關(guān)注自己的業(yè)務(wù)邏輯sql（與TCC模式比較，不需要將業(yè)務(wù)拆分并提供try、confirm、cancel方法），快速集成后即使用。
性能尚可
AT解析，一階段提前釋放本地鎖，二階段決議提交時釋放全局鎖，無需將數(shù)據(jù)鎖定持續(xù)到二階段結(jié)束，這里就已經(jīng)相對傳統(tǒng)二階段事務(wù)尤其是XA提升了，TCC 、XA 都需要二階段驅(qū)動，而AT模式在二階段決議提交時分布式事務(wù)就已經(jīng)完成了，無需再次驅(qū)動rm進行二階段動作。
一階段多了幾次DB讀寫操作，有一定的性能損耗。
2.2.缺點：
存在中間狀態(tài)
補償型事務(wù)處理機制構(gòu)建在事務(wù)資源之上（在中間件或者應(yīng)用層，而不是DB層），事務(wù)資源本身對分布式事務(wù)無感知，這就導(dǎo)致無法做到全方位隔離，即中間狀態(tài)可見。在Seata中，要通過應(yīng)用層的鎖機制來達到讀已提交的隔離效果。
依賴全局行鎖
AT需要全局行鎖來保證隔離性，所以無論是單庫的操作還是1-n個服務(wù)都需要開啟全局事務(wù)來保證隔離性。
有一定的適配成本
支持mysql，pgsql，oracle等數(shù)據(jù)庫，需要應(yīng)用層做適配，對復(fù)雜sql的解析成本更大，開發(fā)效率低，支持的sql數(shù)量少；跨語言的需要在應(yīng)用層額外的開發(fā)支持。但一旦是社區(qū)已經(jīng)提供好的則無需考慮這些問題。
3.Seata XA模式（2PC、強一致)
DTP定義TM和RM之間采用XA接口通訊協(xié)議，XA模式就是基于數(shù)據(jù)庫的XA協(xié)議來實現(xiàn)的兩階段提交方案。
3.1.優(yōu)點：
全局一致性
AT模式下數(shù)據(jù)的讀已提交需由額外的應(yīng)用層的全局行鎖機制來保障；而 XA模式下，隔離性由數(shù)據(jù)庫自身保障，資源和全局事務(wù)渾然一體，做到全局一致性
侵入性略低
少于2個服務(wù)的操作，XA僅使用本地事務(wù)即可滿足一致性，不再需要TC的參與。
兼容性好
- XA協(xié)議被主流的db(mysql,pgsql,oracle)支持,沒有sql語法的限制，而AT需要由應(yīng)用層額外的代碼來解析并適配sql.
- XA是協(xié)議層的，多語言支持度高。
3.2.缺點：
鎖粒度大
XA本地數(shù)據(jù)庫可能持有間隙鎖，造成鎖的粒度更大，鎖定更多無辜數(shù)據(jù)
死鎖（協(xié)議阻塞）
準(zhǔn)備階段后，各分支事務(wù)進入阻塞階段，收到 提交\回滾的指令之前必須阻塞等待。而這期間如果有什么異常導(dǎo)致TM無法下達提交\回滾的指令，那么這個沒有提交的xa事務(wù)將會一直 持有鎖，造成死鎖的局面。
性能較差
據(jù)說使用XA分布式事務(wù)跟沒有事務(wù)的情況下有10倍的性能差異，主要原因就是上面的阻塞跟數(shù)據(jù)鎖定造成，因為xa的一階段并非提交，帶來以下2個問題：
- 事務(wù)協(xié)調(diào)過程，增加單個事務(wù)的 RT；
- 并發(fā)事務(wù)數(shù)據(jù)的鎖沖突，降低吞吐。
應(yīng)用場景受限
- 適用于單體應(yīng)用多數(shù)據(jù)源的情況（早期大型機上的金融類單體應(yīng)用用的多）
- 不適用于分布式場景
At模式的一階段提交，AT的性能是優(yōu)于XA，因為它鎖在TC一側(cè)集中釋放，無需多個庫進行本地的鎖釋放
運維成本
在mysql數(shù)據(jù)庫中對XA支持的不太理想，mysql的XA實現(xiàn)，沒有記錄prepare階段日志，主備切換回導(dǎo)致主庫與備庫數(shù)據(jù)不一致（這些是不是MySQL 5.7之前的缺陷，mysql8之后的情況怎樣呢？）運維復(fù)雜，DBA缺少這方面經(jīng)驗；
這段信息有待確認
