分佈式系統的事務處理簡析

編者按：數據服務的高可用是全部企業都想擁有的，可是要想讓數據有高可用性，就須要冗餘數據寫多份。寫多份的問題會帶來一致性的問題，而一致性的問題又會帶來性能問題，這就會陷入一個無解的死循環！這裏所謂數據一致性，就是當多個用戶試圖同時訪問一個數據庫時，若是它們的事務同時使用相同的數據，可能會發生如下四種狀況：丟失更新、未肯定的相關性、不一致的分析和幻像讀。阿里巴巴北京研發中心、商家業務部任資深專家陳皓的博客《分佈式系統的事務處理》一文對此作了詳細的描述，推薦給你們。如下是做者原文：

在生產線上用一臺服務器來提供數據服務的時候，常常會遇到以下的兩個問題：

• 一臺服務器的性能不足以提供足夠的能力服務於全部網絡請求。
• 擔憂服務器宕機，形成服務不可用或是數據丟失。

面對這些問題,咱們不得不對服務器進行擴展，加入更多的機器來分擔性能問題，以及解決單點故障問題。一般，咱們會經過兩種手段來擴展咱們的數據服務：

• 數據分區：就是把數據分塊放在不一樣的服務器上（如：uid % 16，一致性哈希等）。
• 數據鏡像：讓全部的服務器數據同步，提供無差異的數據服務。

使用第一種方案，沒法解決數據丟失問題，單臺服務器出問題時，必定會有部分數據丟失。因此，數據服務的高可用性只能經過第二種方法來完成——數據的冗餘存儲（通常工業界認爲比較安全的備份數應該是3份，如：Hadoop和Dynamo）。 可是，加入的機器越多數據就會變得越複雜，尤爲是跨服務器的事務處理，也就是跨服務器的數據一致性。這個是一個很難的問題！讓咱們用最經典的Use Case：「A賬號向B賬號匯錢」來講明一下，熟悉RDBMS事務的都知道從賬號A到賬號B須要6個操做：

1. 從A賬號中把餘額讀出來；
2. 對A賬號作減法操做；
3. 把結果寫回A賬號中；
4. 從B賬號中把餘額讀出來；
5. 對B賬號作加法操做；
6.  把結果寫回B賬號中。

爲了數據的一致性，這6件事，要麼都成功作完，要麼都不成功，並且這個操做的過程當中，對A、B賬號的其它訪問必需鎖死，所謂鎖死就是要排除其它的讀寫操做，否則會有髒數據問題，這就是事務。可是，在加入了多個機器後，這個事情會變得複雜起來：

1. 在數據分區的方案中：若是A賬號和B賬號的數據不在同一臺服務器上怎麼辦？咱們須要一個跨機器的事務處理。也就是說，若是A的扣錢成功了，但B的加錢不成功，咱們還要把A的操做給回滾回去。在不一樣的機器上實現，就會比較複雜。
2. 在數據鏡像的方案中：A賬號和B賬號間的匯款是能夠在一臺機器上完成的，可是別忘了咱們有多臺機器存在A賬號和B賬號的副本。若是對A賬號的匯錢有兩個併發操做（要匯給B和C），這兩個操做發生在不一樣的兩臺服務器上怎麼辦？也就是說，在數據鏡像中，在不一樣的服務器上對同一個數據的寫操做怎麼保證其一致性，保證數據不衝突？

同時，咱們還要考慮性能因素，若是不考慮性能的話，事務完成並不困難，系統慢一點就好了。除了考慮性能外，咱們還要考慮可用性，也就是說，一臺機器沒了，數據不丟失，服務可由別的機器繼續提供。 因而，咱們須要重點考慮下面的這麼幾個狀況：

• 容災：數據不丟、結點的Failover
• 數據的一致性：事務處理
• 性能：吞吐量 、 響應時間

前面說過，要解決數據不丟，只能經過數據冗餘的方法，就算是數據分區，每一個區也須要進行數據冗餘處理。這就是數據副本：當出現某個節點的數據丟失時能夠從副本讀到，數據副本是分佈式系統解決數據丟失異常的惟一手段。因此，在這篇文章中，咱們只討論在數據冗餘狀況下考慮數據的一致性和性能的問題。簡單說來：

• 要想讓數據有高可用性，就得寫多份數據。
• 寫多份的問題會致使數據一致性的問題。
• 數據一致性的問題又會引起性能問題

這就是軟件開發，按下了葫蘆起了瓢。

一致性模型

提及數據一致性來講，簡單說有三種類型（固然，若是細分的話，還有不少一致性模型，如：順序一致性，FIFO一致性，會話一致性，單讀一致性，單寫一致性，但爲了本文的簡單易讀，我只說下面三種）：

1. Weak 弱一致性：當你寫入一個新值後，讀操做在數據副本上可能讀出來，也可能讀不出來。好比：某些cache系統，網絡遊戲其它玩家的數據和你沒什麼關係，VOIP這樣的系統，或是百度搜索引擎。
2. Eventually 最終一致性：當你寫入一個新值後，有可能讀不出來，但在某個時間窗口以後保證最終能讀出來。好比：DNS，電子郵件、Amazon S3，Google搜索引擎這樣的系統。
3. Strong 強一致性：新的數據一旦寫入，在任意副本任意時刻都能讀到新值。好比：文件系統，RDBMS，Azure Table都是強一致性的。

從這三種一致型的模型上來講，咱們能夠看到，Weak和Eventually通常來講是異步冗餘的，而Strong通常來講是同步冗餘的，異步的一般意味着更好的性能，但也意味着更復雜的狀態控制；同步意味着簡單，但也意味着性能降低。

插入一條筆記：

以前看多阿里大神程立的一個關於分佈式事務的文檔，目前使用較多的分佈式事務解決方案有幾種： 1、結合MQ消息中間件實現的可靠消息最終一致性 2、TCC補償性事務解決方案 3、最大努力通知型方案         第一種方案：可靠消息最終一致性，須要業務系統結合MQ消息中間件實現，在實現過程當中須要保證消息的成功發送及成功消費。即須要經過業務系統控制MQ的消息狀態         第二種方案：TCC補償性，分爲三個階段TRYING-CONFIRMING-CANCELING。每一個階段作不一樣的處理。 TRYING階段主要是對業務系統進行檢測及資源預留 CONFIRMING階段是作業務提交，經過TRYING階段執行成功後，再執行該階段。默認若是TRYING階段執行成功，CONFIRMING就必定能成功。 CANCELING階段是回對業務作回滾，在TRYING階段中，若是存在分支事務TRYING失敗，則須要調用CANCELING將已預留的資源進行釋放。         第三種方案：最大努力通知xing型，這種方案主要用在與第三方系統通信時，好比：調用微信或支付寶支付後的支付結果通知。這種方案也是結合MQ進行實現，例如：經過MQ發送http請求，設置最大通知次數。達到通知次數後即再也不通知。 具體的案例你也能夠參考下這篇博客，它上面的這個案例就是結合電商支付作的系統分佈式事務實現案例：http://www.roncoo.com/article/detail/124243