在oie的時代， 上層應用開發人員總是認為資料庫足夠強大， 所以很多業務可以做的非常簡單。 比如a轉賬50元給b這個過程， 只要寫乙個簡單sql語句塊就ok了。
開始事務；
a賬戶減去50
b賬戶增加50
提交事務。
這個實現簡單明瞭， a賬戶錢減少的同時b賬戶的錢得到增加。但是當系統規模逐步擴大的時候， 只能不斷要求使用更好的硬體以及買更貴的資料庫lincence。 這種系統在超過一定規模後所需要的成本是指數增長的。為了獲得近乎線性的擴充套件能力， 好的解決方案當然是分庫分表。在分庫後， 這個事務就變成了乙個分布式事務。不要看到多庫事務就想到xa， 如果資料庫是架構在廉價伺服器上， xa會帶來高昂的運維成本。 這裡介紹一下ebay的方法，就是用訊息佇列實現這種分布式事務。
首先是業務分析， 系統是否必須在a賬戶減少的同時增加b賬戶。比如延遲50ms，在極端情況下，延遲秒級， 是否是可接受的。
其實這個延遲基本都是可接受的。 相當於資金有了乙個在途的過程。支付寶就是這麼幹的！
接受這個延遲後， 我們在a賬戶所在的資料庫建立乙個日誌表， 在b賬戶所在資料庫再建立乙個日誌表。把事務分成兩個部分。
a庫：1 開始事務
a賬戶減去50
a日誌表記錄要給b賬戶增加50， 同時生成全域性唯一交易id
提交事務。
b庫：2 開始事務
b賬戶上應用a日誌表的要求（也就是給b賬戶增加50）。
b日誌表記錄操作完成的交易id
提交事務。
3 更新a日誌表， 標記這個交易完成。
這裡， 兩個日誌表其實相當於乙個訊息機制。 有些中介軟體可以完全代替這兩個日誌表功能。比如阿里內部使用的notify。
我們來分析上面這個過程。因為每個事務內涉及的賬戶表和日誌表都在同乙個資料庫中， 所以上述兩個事務都是本地事務。
假設步驟1完成， 2完成前中斷， 那麼修復程式只要掃瞄a日誌表， 然後重新從步驟2開始做就ok。
假設步驟2完成， 步驟3完成前中斷。 那麼按照上面提到的方式修復程式可能會給b賬戶多加了50. 所以修復程式在修復時要先在b的日誌表裡查詢該交易id是否執行過， 如果已經執行過， 則跳過步驟2直接步驟3。
在應用層上想辦法解決規模問題， 降低對資料庫的要求， 甚至能用kv系統實現的可以完全用kv系統解決； 降低對伺服器可靠性的要求， 應用自動處理錯誤恢復，這些實質上把伺服器和資料庫的價值轉移到了應用層。 所以每次看到乙個系統大部分價值被伺服器廠商和資料庫廠商賺走而心存不甘的應用開發者們， 多想想辦法把價值留在自己手中吧。
0
給主人留下些什麼吧！~~
訊息佇列實現分布式事務
訊息佇列中的 事務 主要解決的是訊息生產者和訊息消費者的資料一致性問題。電商下單步驟 1 生成訂單 2 刪除購物車 在分布式系統中，任何乙個步驟都有可能失敗，可能出現訂單資料與購物車資料不一致的情況，比如說 1 建立了訂單，沒有清理購物車 2 訂單沒建立成功，購物車裡面的商品卻被清掉了。訂單系統給訊...
分布式訊息佇列
以下是訊息佇列以下的大綱，本文主要介紹訊息佇列概述，訊息佇列應用場景和訊息中介軟體示例 電商，日誌系統 訊息佇列概述 訊息佇列應用場景 訊息中介軟體示例 jms訊息服務 見第二篇 大型 架構系列 分布式訊息佇列 二 常用訊息佇列 見第二篇 大型 架構系列 分布式訊息佇列 二 參考 推薦 資料 見第二...
分布式訊息佇列
訊息佇列中介軟體是分布式系統中重要的元件，主要解決應用耦合，非同步訊息，流量削鋒等問題。實現高效能，高可用，可伸縮和最終一致性架構。是大型分布式系統不可缺少的中介軟體。目前在生產環境，使用較多的訊息佇列有activemq，rabbitmq，zeromq，kafka，metamq，rocketmq等。...