先看看資料庫事務的定義：單個邏輯工作單元執行的一系列操作，要麼完全地執行，要麼完全地不執行
這個比較容易了解，操作過資料庫的一般都懂，既是業務需求涉及到多個資料表操作的時候，需要用到事務
要麼一起更新，要麼一起不更新，不會出現隻更新了部分資料表的情況，下邊看看資料庫事務的使用
上執行個體在小型項目中一般是問題不大的，因為小型項目一般是單機系統，資料庫、Web服務大都在一台伺服器上，甚至可能隻有一個資料庫檔案，
這種情況下使用本地事務沒有一點問題；
但是本地事務有很大的缺陷，因為開啟事務一般是鎖表的，事務執行期間會一直鎖着，其他的操作一般都要排隊等待，對性能要求比較高的系統是不能忍受的。
特别是涉及改動不同資料庫的操作，這會造成跨庫事務，性能更加低
如果還涉及到不在同一台伺服器、甚至不同網段部署的資料庫，那本地事務簡直是系統運作的災難，是首先需要丢棄的解決方案。
那如果遇到上述情況，該怎麼做呢，這就涉及到分布式事務了
如果有海量資料需要處理、或者要求高并發請求的話，同步的事務機制已經是不現實的了，這種情況下必須采用異步事務機制，既分段式的事務
分段式事務一般做法就是把需求任務分段式地完成，通過事務補償機制來保證業務最終執行成功，補償機制一般可以歸類為2種：
1 ）定時任務補償：
通過定時任務去跟進後續任務，根據不同的狀态表确定下一步的操作，進而保證業務最終執行成功，
這種辦法可能會涉及到很多的背景服務，維護起來也會比較麻煩，這是應該是早期比較流行的做法
2） 消息補償：
通過消息中間件觸發下一段任務，既通過實時消息通知下一段任務開始執行，執行完畢後的消息回發通知來保證業務最終完成；
當然這也是異步進行的，但是能保證資料最終的完整性、一緻性，也是近幾年比較熱門的做法
定時任務補償就不說了，這篇文章我們來讨論一下通過消息補償來完成分布式事務的一般做法
0）我們以簡單的産品下單場景來說明，（不要較真哈）
1）先來看看分布式異步事務處理流程示意圖，APP1與APP2需要互相訂閱對方消息
2）首先看資料庫，2個，一個庫存庫，一個已下單成功的庫
3）項目架構Demo
資料底層通路使用的是Dapper、使用redis作為消息中間件
4）實體層代碼
5）服務接口層代碼
6）庫存、消息通知
7）下單、下單成功消息
8）下單減庫存測試
9）下單成功及消息回發測試
10）好了，到了最後檢驗成果的時候了
先打開Demo.Sell.App.exe、然後打開Demo.Reserve.App.exe
大功告成！