## 傳統事務與柔性事務  柔性事務.png 柔性事務之前我們先來回歸傳統事務 ##### 傳統事務 第一次接觸事務的時候，被人告知事務是原子的，要么都成功要么都失敗。再進一步就有ACID這四個屬性，原子性（Atomictiy）、一致性（Consistency）、隔離性（Isolation）、持久性（Durabilit）。 我們首先看下一些書籍中的官方描述： * 原子性：事務是一個包含一系列操作的原子操作。事務的原子性確保這些操作全部完成或者全部失敗。 * 一致性：一旦事務的所有操作結束，事務就被提交。然后你的數據和資源將處于遵循業務規則的一直狀態。 * 隔離性：因為同時在相同數據集上可能有許多事務處理，每個事務應該與其他事務隔離，避免數據破壞。 * 持久性：一旦事務完成，他的結果應該能夠承受任何系統錯誤（想象一下在事務提交過程中機器的電源被切斷的情況）。通常，事務的結果被寫入持續性存儲。 --《Spring攻略》 原子性：在一個事務李，動作序列的每一個步驟都必須是要么全部成功，要么所有的工作都將回滾。部分完成不是一個事務的概念。 一致性：在事務開始和完成的時候，系統的資源都必須處于一致的、沒有被破壞的狀態。 隔離性：一個事務，直到它被成功提交之后，它的結果對于任何其他的事務才是可見的。 持久性：一個已提交事務的任何結果都必須是永久性的，即“在任何系統崩潰的情況下都能保存下來”。 --《企業應用架構模式》 為什么列舉的是這兩本書中的描述呢，《spring攻略》是關于spring的書籍，因為我們都知道spring有很好的對事務支持的接口及組件，《企業應用架構模式》是我看過的較早的一本書籍，迄今還記得這本書中關于這四個屬性的描述，同時這兩本書的作者都是世界頂級的技術專家。（《企業應用架構模式》 和《重構-改善既有代碼的設計》是同一位作者） OK，那這四個屬性，我們自己到底該如何理解呢。個人理解如下： 如果給事務下一個定義：事務是一個有邊界的工作序列，開始和結束都有明確的定義。 1. 原子性 舉例1-比如現在有一個事務，包含3個sql語句（工作序列，或者是指令序列），sql-1，sql-2，sql-3，這3個sql語句，每一個在執行的時候，都是一個單元，這個單元的執行結果，有且僅有兩種可能：成功和失敗。 舉例2-再比如，我從賬戶1中轉出1000人民幣到賬戶2，當我從賬戶1中把錢轉出來之后，系統就崩潰了。那么系統應該將我的賬戶狀態置成我還沒有轉出錢之前的狀態。 2. 一致性 舉例1-有一個在線商務網站系統，有兩張表，一張用戶賬戶表（用戶名、個人余額），一張商品庫存表（商品ID，庫存數量），用戶花費30元購買1件商品，商品庫存減1，賬戶余額減30.那么這樣的結果就是一致的。否則，如果商品庫存減1，賬戶余額沒有變化，那么這樣的結果就是不一致的。 舉例2-銀行賬戶轉賬的例子，也一樣，賬戶1中的錢減少1000，賬戶2中的錢就增加1000，這樣的是一致的，否則不一致。 3. 隔離性 沒有隔離性就沒有一致性 舉例1-我們現在有兩個事務方法，一個方法是查詢數據的庫存，一個是購買下單，那么這兩個事務方法應該互不影響，不然會造成一系列的問題，個人一直認為，事務造成的下面這些問題是跟并發密不可分的，沒有并發操作，單一的請求事務是不會有這樣的問題的。并發事務產生的問題可以分為4類 讀臟數據 不可重復讀 幻讀 更新丟失 是不是跟并發導致的問題一直的呢。其實在《企業應用架構模式》一書中，有一句話描述就是：處理并發最主要的工具就是事務。 4. 持久性 對于數據庫來講，我的理解是這樣，當我把sql-1、sql-2、sql-3提交之后，這個結果就一定會保存到數據庫中，那如果提交-到寫入這中間，突然斷電，也沒有關系，數據庫服務器在重新啟動之后一樣會把數據寫入磁盤，應該是通過日志的方式-僅個人理解。 數據庫一般都是通過事務日志的方式，write-ahead transaction log來保證持久性。write-ahead transaction log的意思是，事務中對數據庫的改變在寫入到數據庫之前，首先寫入到事務日志中。而事務日志是按照順序排號的（LSN）。當數據庫崩潰或者服務器斷點時，重啟動數據庫，首先會檢查日志順序號，將本應對數據庫做更改而未做的部分持久化到數據庫，從而保證了持久性. ##### 柔性事務 在電商領域等互聯網場景下，傳統的事務在數據庫性能和處理能力上都暴露出了瓶頸。在分布式領域基于CAP理論以及BASE理論，有人就提出了 柔性事務 的概念。CAP（一致性、可用性、分區容忍性）理論大家都理解很多次了，這里不再敘述。說一下BASE理論，它是在CAP理論的基礎之上的延伸。包括 基本可用（Basically Available）、柔性狀態（Soft State）、最終一致性（Eventual Consistency）。 基本可用：分布式系統出現故障的時候，允許損失一部分可用性。比如，京東618大促的時候，對一些非核心鏈路的功能進行降級處理。 柔性狀態：允許系統存在中間狀態，這個中間狀態又不會影響系統整體可用性。比如，數據庫讀寫分離，寫庫同步到讀庫（主庫同步到從庫）會有一個延時，這樣實際是一種柔性狀態。 最終一致性：那上面數據庫主從復制的例子，經過數據同步延時之后，最終數據能達到一致。 ACID是傳統數據庫常用的設計思想，它追求的是強一致性。BASE是大型分布式系統場景下的設計思想，通過犧牲強一致性獲得高可用性。 柔性事務是在互聯網的各種應用場景下產生的，互聯網最核心的需求是什么？高可用。比如每年的京東618大促，交易高峰期間如果有10S不可用，那么損失的訂單量大家可想而知。 老的方式實現分布式事務是通過兩階段提交來實現的。分為準備階段和提交階段。兩階段事務的關鍵是在準備階段，在這個階段所有參與者必須完成約束檢查，達成關于分布式事務一致性的共識。第二階段，根據之前達成的共識，完成相應的操作。提交事務的過程中需要在很多個資源節點之間進行協調，而且每個節點對鎖資源的釋放必須等到事務最終提交的時候。這樣兩階段事務提交會耗費更長的時間。事務執行時間長意味著鎖資源發生沖突的概率增加，當事務的并發量積累到一定數量的時候，很可能出現事務積壓甚至出現死鎖。系統的性能和吞吐量就會下降。 柔性事務針對分布式事務的解決方法： 1、記錄日志+補償 記錄事務的開始和結束狀態。事務根據日志記錄找回事務的當前執行狀態，并根據狀態決定重試異常步驟，也就是正向補償，或者回滾上一次執行步驟，也就是反向補償。 2、消息 多次重試，也就是發送多次消息，由于要多次重發，所以程序必須是冪等（同一操作反復執行多次結果不變），這是非常具有互聯網特征的一種模式。 3、“無鎖”設計 放棄鎖是一個解決問題的思路。比如通過樂觀鎖，大多數是基于版本號來實現。 update goods set?`name`=#{name}, remaining_number=#{remainingNumber}, version=version+1 where id=#{id} and version=#{version} ##### 總結 從理念上梳理了傳統事務和柔性事務。在現在的電商領域里絕大部分場景下，我們都不會使用兩階段提交這樣低效的方式來實現分布式事務。我們都會采取上面柔性事務的方式來實現分布式事務來保證系統的性能和業務的最終一致。柔性事務的實現需要有下面2點作為保證： 1、應用程序一定要做冪等實現，特別是對數據庫進行數據修改操作的時候。 2、遠程模塊之間采用異步消息驅動，異步消息還可以起到檢查點的作用。 參考資料《spring攻略》《企業應用架構模式》《企業IT架構轉型之道》 轉載請注明出處，并附上鏈接[http://www.jianshu.com/p/ab1a1c6b08a1](https://www.jianshu.com/p/ab1a1c6b08a1) * * * * * 來源：https://www.jianshu.com/p/ab1a1c6b08a1 * * * * * last update：2018-7-3 12:50:27