分布式事務(wù)該如何理解

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

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

3.機(jī)票代理商的機(jī)票預(yù)訂服務(wù)

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

當(dāng)用戶預(yù)訂機(jī)票時(shí)，肯定希望能同時(shí)預(yù)訂這兩趟航班的機(jī)票，只預(yù)訂一趟航班對(duì)用戶來說沒有意義。因此，對(duì)于這樣的業(yè)務(wù)服務(wù)同樣提出了原子性要求，如果其中一趟航班的機(jī)票預(yù)訂失敗，另外一趟需要能夠取消預(yù)訂。

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

網(wǎng)關(guān)服務(wù)在原有邏輯基礎(chǔ)上增加 Compensate 接口，負(fù)責(zé)調(diào)用對(duì)應(yīng)航空公司的取消預(yù)訂接口。

在用戶發(fā)起機(jī)票預(yù)訂請(qǐng)求時(shí)，機(jī)票服務(wù)先通過網(wǎng)關(guān) Do 接口，調(diào)用各航空公司的預(yù)訂接口，如果所有航班都預(yù)訂成功，則整個(gè)分布式事務(wù)直接執(zhí)行成功；一旦某趟航班機(jī)票預(yù)訂失敗，則分布式事務(wù)回滾，由 TCC 事務(wù)框架調(diào)用各網(wǎng)關(guān)的 Compensate 補(bǔ)償接口，其再調(diào)用對(duì)應(yīng)航空公司的取消預(yù)訂接口。通過這種方式，也可以保證多程機(jī)票預(yù)訂服務(wù)的原子性。

4. 場(chǎng)景：網(wǎng)站每個(gè)商品頁(yè)面有個(gè)計(jì)數(shù)器，用于計(jì)算每次訪問量，買家每訪問一次加1.變成數(shù)據(jù)庫(kù)更新的話，就會(huì)直接拖垮數(shù)據(jù)庫(kù)，但是使用cache數(shù)據(jù)的話，輕松解決這個(gè)問題。

5.場(chǎng)景： 賬務(wù)拆分的業(yè)務(wù)場(chǎng)景如下，分別位于三個(gè)不同分庫(kù)的帳戶A、B、C，A和B一起向C轉(zhuǎn)帳共80元：
(1)Try：嘗試執(zhí)行業(yè)務(wù)。

• (2)Confirm：確認(rèn)執(zhí)行業(yè)務(wù)。

• 
  

• (3)Cancel：取消執(zhí)行業(yè)務(wù)

• 
  

• 小結(jié)：到底要不要使用TCC到底要不要使用TCC事務(wù)，取決于以下幾點(diǎn)：

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

• 是否真正有保證跨應(yīng)用業(yè)務(wù)操作的原子性需求。

• 研發(fā)上能否投入資源開發(fā)相對(duì)應(yīng)的TCC接口。

• 當(dāng)然還有最后一點(diǎn)，能否搞定一個(gè)穩(wěn)定的、高可用的、擴(kuò)展性強(qiáng)的TCC事務(wù)管理器。

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

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

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

關(guān)于分布式事務(wù)該如何理解就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。