一、Seata （Simple Extensible Autonomous Transaction Architecture | 簡單、易擴展的自治事務框架）
三、啥玩意：分布式事務的解決方案，通過提供多種模式來覆蓋不同的用戶場景。簡單易用，但就是出了問題就麻煩咯
四、理論依據：二階段提交的演變
五、重要理念：
- 二階段提交協議
- 全局鎖和本地鎖（隔離性問題，主要為了避免分布式事務產生臟數據）
- 寫隔離和讀隔離，不同級別的一致性要求；一般數據敏感的要求到寫隔離，比較不敏感的數據可以只要求寫隔離
六、不同的事務模式
1、AT：與一般兩段提交協議的差異處，在提交本地事務的時候釋放資源（優點），並采用並行異步機制優化速度，全局鎖機制保證數據隔離性和一致性
- 全局鎖保證數據的一致性和寫隔離
- 通過及時釋放連接資源來提高性能，這點是相對LCN而言。
2、TCC：一般用於不支持ACID的非關系型數據庫，Try Confirm Cancel三個步驟都自行定義
- cancel 空回滾，用於處理try實際未執行成功，調用了cancel的情況 - 本地事務表（通過在不同階段插入不同狀態的本地事務表記錄，控制是否回滾，是否已處理，是否多次處理）
- cancel 冪等，多次執行結果一致（多次cancel） - 本地事務表
- cancel 懸掛，cancel執行在try之前（try成功執行）- 本地事務表
3、SAGA：一階段無鎖；基於事件驅動，參與者可異步執行，高吞吐。就是太麻煩，要寫一堆
4、XA：基於與AT一致，只是需要支持XA分布式事務的數據庫才可以（mysql應該是5.0之后開始支持XA事務）
七、示例Demo (懶得弄，直接在原來lcn的項目弄一個新分支;我這邊故意把seata server啟動端口改了，看eureka是否能自動追蹤到，因為默認都是從本地端口獲取，這個說明你都還不知道從哪里可以配置。。。我是大概跟了源碼有個地方用到了vgroup.mapping，就隨手改了，說實話我也還沒拎清，后面徹底搞懂了再調整吧)
- server下載地址：
http://seata.io/zh-cn/blog/download.html - 關鍵配置：registry.conf、file.conf
- server需要執行的腳本（客戶端tm和rm的也都在這里下載，at模式也需要一個表），上面有比如mysql對應需要執行的腳本，mysql是自己在上面文件中配置的，地址：
https://github.com/seata/seata/tree/1.2.0/script - 客戶端也可以配置：registry.conf、file.conf
八、性能問題，老話題：CAP。seata有多種應用模式，相應的也是在這C和A之間取平衡，簡單易用侵入性低的AT模式，自然A會弱點（性能上面差些）；TCC這種及時釋放資源，且沒有引入全局鎖機制的，自然會快些，但是要自己寫很多業務邏輯（當然有些公司的業務比較簡單，但是用戶量並發高，那也是可以使用的）