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：嘗試執行業務。

完成所有業務檢查(一致性)：檢查A、B、C的帳戶狀態是否正常，帳戶A的餘額是否不少於30元，帳戶B的餘額是否不少於50元。
預留必須業務資源(準隔離性)：帳戶A的凍結金額增加30元，帳戶B的凍結金額增加50元，這樣就保證不會出現其他併發程式扣減了這兩個帳戶的餘額而導致在後續的真正轉帳操作過程中，帳戶A和B的可用餘額不夠的情況。

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

真正執行業務：如果Try階段帳戶A、B、C狀態正常，且帳戶A、B餘額夠用，則執行帳戶A給賬戶C轉賬30元、帳戶B給賬戶C轉賬50元的轉帳操作。
不做任何業務檢查：這時已經不需要做業務檢查，Try階段已經完成了業務檢查。
只使用Try階段預留的業務資源：只需要使用Try階段帳戶A和帳戶B凍結的金額即可。

(3)Cancel：取消執行業務

釋放Try階段預留的業務資源：如果Try階段部分成功，比如帳戶A的餘額夠用，且凍結相應金額成功，帳戶B的餘額不夠而凍結失敗，則需要對帳戶A做Cancel操作，將帳戶A被凍結的金額解凍掉。

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

是否真正有保證跨應用業務操作的原子性需求。
研發上能否投入資源開發相對應的TCC介面。
當然還有最後一點，能否搞定一個穩定的、高可用的、擴充套件性強的TCC事務管理器。

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

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

7.我看這張圖，來來回回研究好多次，終於明白了分散式事務全域性

我對分散式事務理解--創新就在遇到看似不可解決問題時候的靈關閃現

相關文章