分布式事務該如何理解

這篇文章給大家介紹分布式事務該如何理解，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

1.先上場景：壓力測試，同時1萬個買家在店鋪Shang1購買東西，每個買家賬戶向shang1賬戶付錢。
      這個例子中，有這么幾個步驟：買家創建商品訂單=>發送到交易系統=>交易收到支付請求創建交易訂單=>判斷買家賬戶余額是否足夠=>扣除買家余額=>增加商戶shang1賬戶余額=>記賬=>返回支付成功信息。
     壓力測試后，調出oracle等待事件，發現瓶頸在扣除客戶余額這個步驟，明顯，只有一個店鋪，余額更新必須排隊。1萬個客戶買東西可以并發買東西，扣除客戶余額可以并發，但是更新店鋪余額只能一個個來。怎么解決？
     解決辦法：分兩個步驟，第一步驟，扣除買家余額后同時增加買家凍結資金，然后馬上返回提示，返回支付成功信息。但是商戶沒有收到錢。第二步驟，在系統低峰時期，扣除買家凍結資金=>增加商戶shang1賬戶余額=>記賬=>返回更新成功。只要提前告知商戶，高峰期交易資金不是實時到賬，但保證在一定時間之內結算完成，商戶應該也是可以理解的。
2.場景：一臺oracle數據庫最多能支撐多少個連接？4000個。如果超出這些連接后怎么辦還需要連接，怎么辦？
       解答：把系統分成2個業務，變成2oracle 實例提供業務，就變成8000個連接，就可以了。

3.機票代理商的機票預訂服務

該機票服務提供多程機票預訂服務，可以同時預訂多趟行程航班機票，比如從北京到圣彼得堡，需要第一程從北京到莫斯科，以及第二程從莫斯科到圣彼得堡。

當用戶預訂機票時，肯定希望能同時預訂這兩趟航班的機票，只預訂一趟航班對用戶來說沒有意義。因此，對于這樣的業務服務同樣提出了原子性要求，如果其中一趟航班的機票預訂失敗，另外一趟需要能夠取消預訂。

但是，由于航空公司相對于機票代理商來說屬于外部業務，只提供訂票接口和取消預訂接口，想要推動航空公司改造是極其困難的。因此，對于此類業務服務，可以使用補償型 TCC 分布式事務解決方案，如下：

網關服務在原有邏輯基礎上增加 Compensate 接口，負責調用對應航空公司的取消預訂接口。

在用戶發起機票預訂請求時，機票服務先通過網關 Do 接口，調用各航空公司的預訂接口，如果所有航班都預訂成功，則整個分布式事務直接執行成功；一旦某趟航班機票預訂失敗，則分布式事務回滾，由 TCC 事務框架調用各網關的 Compensate 補償接口，其再調用對應航空公司的取消預訂接口。通過這種方式，也可以保證多程機票預訂服務的原子性。

4. 場景：網站每個商品頁面有個計數器，用于計算每次訪問量，買家每訪問一次加1.變成數據庫更新的話，就會直接拖垮數據庫，但是使用cache數據的話，輕松解決這個問題。

5.場景： 賬務拆分的業務場景如下，分別位于三個不同分庫的帳戶A、B、C，A和B一起向C轉帳共80元：
(1)Try：嘗試執行業務。

• (2)Confirm：確認執行業務。

• 
  

• (3)Cancel：取消執行業務

• 
  

• 小結：到底要不要使用TCC到底要不要使用TCC事務，取決于以下幾點：

• <ul class="list-paddingleft-2"  font-size:16px;white-space:normal;background-color:#ffffff;"="">

• 是否真正有保證跨應用業務操作的原子性需求。

• 研發上能否投入資源開發相對應的TCC接口。

• 當然還有最后一點，能否搞定一個穩定的、高可用的、擴展性強的TCC事務管理器。

       一個問題，如果TCC事務在Try階段所有參與方(從業務服務)成功了，但是Confirm階段部分參與方(從業務服務)成功，如何處理？

6.支付寶是怎么誕生的？
在架構的進化過程中，業務的進化也非常迅猛。最早的時候，買家打錢給賣家都是通過銀行轉賬匯款，有些騙子收了錢卻不發貨，干脆逃之夭夭。這是一個很嚴重的問題，一個人這么干了之后，很快就有更多的人學會了（這就是傳說中的“病毒傳播”）。然而魔高一尺，道高一丈，淘寶網這伙人開始研究防騙子的解決方案，他們看了PayPal的支付方式，發現不能解決問題。研究了類似QQ幣的東西，想弄個“淘寶幣”出來，發
現也不行。后來這幾個聰明的腦袋把這些想法糅合起來，突然想到了“擔保交易”這種第三方托管資金的辦法。于是在2003年10月，淘寶網上線了一個功能，叫做“安全交易”，賣家如果選擇支持這種功能，買家就會把錢交給淘寶網，等他收到貨之后，淘
寶網再把錢給賣家，這就是現在的“支付寶”。這個功能最早是讓賣家可選的，因為這會延遲他收款的周期。但一旦賣家用了這個之后，就發現交易量猛增，一年之后，幾乎所有的賣家都選擇擔保交易，到后來干脆所有的交易都必須走擔保交易。在2012年
支付寶的年會上，支付寶公布2011年的交易筆數已經是PayPal的兩倍。這個劃時代的創新，其實就是在不斷思索過程中的一個靈光乍現.

7.我看這張圖，來來回回研究好多次，終于明白了分布式事務全局

關于分布式事務該如何理解就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。