【第2章】Seata1.3.0原始碼編譯+引數設定+啟動執行
GitHub專案地址：seata-spring-boot-demos
一、什麼是Seata？
官網地址：https://seata.io
提煉關鍵詞：
特性：
1、一致性（這個是痛點，解決的就是微服務分散式事務一致性的問題）
2、高效能（這個是賣點，如果用了反而拖累整個微服務架構的效能，試問誰還會用呢？）
3、易用性（這個是亮點，大家開發時引入新技術，都希望簡單好用，如果技術太過於複雜，反而會提升使用門檻，嚇跑使用者）
事務模式
- AT （Automatic Transaction，對業務系統無侵入，省去了用的人很多編碼的工作）
- TCC（Try-Confirm-Cancel，對業務系統有侵入，用的時候需要自己寫大量的程式碼）
- Saga （Long Live Transaction，長事務解決方案，對業務系統有侵入，同TCC）
- XA （ X/Open 組織提出的分散式事務處理的規範，對業務系統無侵入，只需要DB實現了XA協定即可）
文章推薦：帶你讀透 SEATA 的 AT 模式
這篇文章講的很好，很適合結合著Seata官方檔案細細品讀，下面放幾張文中的關鍵圖
- 每個應用服務對應一個本地資料庫，即database per service；
- 每個應用服務之間互相共同作業，呼叫介面；
- 每個應用服務執行自己的SQL指令碼；
- 每個應用服務執行自己的SQL語句時，是基於本地事務的；
- 每個應用服務對應的本地庫中，都存在一個UNDO Log（回滾紀錄檔記錄）；
- 每個應用服務實現自己的事務提交，如果有一個事務提交失敗，則全域性回滾；
- 發生全域性事務回滾時，則每個分支（本地）事務按照UNDO log內容對資料集進行反向補償（反向SQL）
搞懂上圖，需要知道Seata的三個角色概念：
- TC（Trasaction Cordornator，事務協調器）
- TM（Transaction Manager，事務管理器）
- RM （Resource Manager，資源管理器）
其中TC對應的應用服務就是seata-server
TC角色主要用來和TM和RM進行「交流」的，通過rpc（Netty）+服務註冊發現（nacos等），實現與各個微服務模組之間的通訊
其中TM對應的應用服務就是開啟了@GlobalTransactional註解的業務方法所在的微服務模組，即seata-business-server
TM角色主要定義了全域性事務的邊界，用來向TC開啟一個全域性事務，拿到全域性事務唯一的XID，並在呼叫的微服務之間的上下文中進行傳遞，同時，該服務還掌握著是否全域性提交還是全域性回滾的決議權！
TM端呼叫結束，我們接下來看下TC端
執行完後，看下資料庫
全域性提交的條件是：各個微服務的分支事務均提交成功；
全域性回滾的條件是：只要有一個微服務的分支事務提交失敗，就會觸發整個全域性事務的回滾！
其中RM對應的應用服務就是在業務上存在SQL語句執行的微服務模組，如order-server
RM角色主要用來向TC註冊分支事務（儲存到seata庫對應的branch_table表中），並上報分支事務提交和回滾的狀態給TC，TC根據分支事務提交和回滾的狀態來驅動TM最終進行全域性的提交或全域性的回滾；
（關於RM和TC互動的程式碼偵錯就不放了，下面放幾張和分支事務有關的截圖吧，有問題的可以留言）
庫存服務（RM）對應的初始化商品的庫存記錄如下：
TC分支事務表記錄如下：
庫存服務（RM）在TM開啟全域性事務後，執行減庫存操作但事務未提交時的分支事務記錄如下：
庫存服務（RM）在TM開啟全域性事務後，執行減庫存操作但事務未提交時的分支回滾記錄如下：
每個分支事務都對應一條undo_log記錄，我們匯出減庫存的log後，檢視其內容如下：
最後執行成果後，相應的undo_log記錄會被刪除，重新整理庫存的undo_log表記錄如下：
最終，我們可以看到，水杯的庫存量為：
如果TM發起全域性提交，則TC會分別呼叫各個微服務，並對各個RM中的undo_log表中的XID記錄進行非同步刪除；
如果TM發起全域性回滾，則TC會分別呼叫各個微服務，並對各個RM中的undo_log表中的XID記錄進行反向SQL，恢復事務操作前的資料；
二、Seata原始碼編譯
未完待續,.................
三、Seata服務引數設定
未完待續,.................
四、Seata服務啟動
未完待續,.................