透徹！這才是正確的分散式事務的開啟方式
尊重原創版權: https://www.gewuweb.com/hot/18048.html
透徹！這才是正確的分散式事務的開啟方式
前言
關於前面系列的文章已經說到分散式服務之間的通訊，則分散式事務接下來就是我們要一起學習的主題，走起。
資料庫事務在現有大大小小的系統中幾乎是避免不開的，或多或少總會有一些業務關聯在一塊；對於單機事務的應用場景和操作，相信小夥伴已經夠熟練了；隨著分散式、微服務的開發模式普及，分散式事務落地也成為了程式設計師的必備之技，接下來的幾篇一起來學習和實操。
正文
1. 事務回顧
1. 1 事務簡介
通俗一點理解就是 ** 將一組對資料的操作(增、刪、改、查)看做成一個邏輯單元，要麼都執行，要麼都不執行，確保資料一致性 ** 。
1.2 事務特性(ACID)
- 原子性（Atomicity）指事務內所有操作要麼一起執行成功，要麼都一起失敗(或者說是回滾)；如事務經典轉賬案例：A給B轉賬，A把錢扣了，但B沒有收到；可見這種錯誤是不能接受的，最終會回滾，這也是原子性的重要性。
- 一致性（Consistency）指事務執行前後的狀態一致，如事務經典轉賬案例：A給B互相轉賬，不管怎麼轉，最終兩者錢的總和還是不變；
- 永續性（Durability）指事務一旦提交，資料就已經永久儲存了，不能再回滾；
- 隔離性（Isolation）指多個併發事務之間的操作互不干擾，但是事務的併發可能會導致資料髒讀、不可重複讀、幻讀問題，根據業務情況，採用事務隔離級別進行對應資料讀問題處理。
1.3 事務隔離級別
- 都未提交( ** Read uncommitted ** )指一個事務讀取到其他未提交事務的資料。可能導致資料 ** 髒讀 ** 。轉賬案例：A正在給B轉賬，本來轉的1000，A多輸入了個0，變成10000，但此事務還未提交，但此時B查詢到轉入的是10000，但A取消事務回滾之後，B又查詢不到轉入的資料。這種情況就是 ** 髒讀 **
- 都已提交( ** Read committed ** )指一個事務只能讀取到其他事務已提交的資料，從而解決了 ** 髒讀 ** 的問題。但可能導致資料 ** 不可重複讀 ** ；轉賬案例：A要給B轉賬1000，A先查看了一下餘額，有1000，然後開始給B轉錢，但此時A家裡電費通過開啟的自動繳費功能，自動從A賬戶扣除200繳納電費，並提交；當A轉賬準備提交，再次確認餘額時，錢少了200。這樣就導致同一個事務中多次查詢的結果不一致，這種情況就是 ** 不可重複讀 ** ；
- 可重複讀( ** Repeatable read ** )指事務只要一開啟，就不允許其他事務進行修改操作，從而解決了 ** 不可重複讀 ** 問題。但可能導致資料 ** 幻讀 ** ；轉賬案例：A經常給B轉賬，到年底了，需要查賬，然後開啟了一個事務進行查詢統計，剛開始查詢只是10條轉賬記錄，正準備統計時，因為緊急情況A需要給B轉一筆錢應急，從而 ** 新增 ** 了一條新記錄，並提交；而查賬事務正在統計中，最後發現轉賬額和看到的10條轉賬記錄不匹配。這種情況就是 ** 幻讀 **
- 序列化( ** Serializable ** )指事務之間只能序列話執行，就像佇列一樣，排隊進行，這樣就解決了 ** 幻讀 ** 的問題，但是這種級別的併發效能不高，非特殊需求，這種級別一般不用。
2. 分散式事務場景
一個專案對應一個數據庫，這種單機業務是平時處理得比較多的；這裡主要歸納一下會出現分散式事務的場景。
2.1 一個專案多個數據庫
這種情況一般是併發量不大，但資料量比較大的情況，就比如一些採集裝置資料做實時分析的系統，如感測器資料、電機狀態等，經過一段時間，資料量會很多，導致單個數據庫效率變低，所以通常會採用分業務儲存。
如上圖，如果出現需要操作DB1中資料的同時又需要操作DB2資料，確保兩次操作要麼都成功，要麼都失敗，這就需要事務，而這種和單一系統(一個專案，一個數據庫)的事務處理方式不一樣，得分散式事務進行處理。
2.2 多個專案一個數據庫
有些系統需要將業務分開開發和部署，便於程式碼管理和後期維護，在資料庫資源允許的情況下可以共用一個數據庫，在這種情況下如果有事務操作，同樣需要分散式事務進行處理。
2.3 多個專案多個數據庫
這種方式其實就是微服務模式，分業務劃分專案，每個業務對應一個數據庫，這種場景下專案之間的事務肯定是分散式的啦
3. CAP瞭解
3.1 簡介
對於分散式應用場景，有很多因素是不可控的，如網路不通、裝置宕機、自然災害等原因導致服務不可用，這種情況對於分散式而言需要有一定的取捨，不能因為個別服務的不可用，導致整個系統崩掉。通常CAP理論會成為分散式指標的取捨，根據系統業務需求，滿足其中兩個指標即可。如下圖：
** CAP是Consistency(一致性)、Availability(可用性)、PartitionTolerance(分割槽容錯性)三個詞的縮寫 **
，具體含義如下：
- ** C(Consistency-一致性)：是指在寫操作之後，任意節點進行讀取時，都能一致獲取到最新的資料狀態 ** 。為了保證資料一致性，在同步資料時會就資源短時進行鎖定，目的為了避免獲取的老的資料，導致資料不一致情況，但這樣就會導致服務在短時間內不可用。
- ** A(Availability-可用性)：是指發起任何操作時都可以得到響應結果，不會出現響應超時或響應錯誤 ** 。就算是資料在同步過程中也要保證可用，即寧可拿到舊資料也不要報錯。
- ** P(PartitionTolerance-分割槽容錯性)：這裡的分割槽是指網路分割槽 ** ，通常分散式系統，各節點會部署到不同子網，由於網路具有不可控性，可能會導致節點之間的通訊失敗；但在設計此類系統時，應該考慮這種情況，保證提供正常的服務，這其實可以理解為平時咱們說得高可用； ** 這個指標是分散式系統必備的，不然就不能叫高可用系統啦 ** 。
3.2 CAP組合
其實通過上面的概述， ** C(一致性)和A(可用性)是互相排斥的 **
，為了保證一致性，會鎖定資源導致短時間不可用，而可用性的要求就是必須對操作有對應的響應結果，就算得到的資料不是最新的也行，目的是保證可用。 **
而P(分割槽容錯性)是分散式系統中必備指標，所以在分散式系統中經常的組合就是CP和AP ** 。
- ** CP：放棄可用性，注重一致性和分割槽容錯性，其實這就是所謂的強一致性 ** ，可能在銀行跨行轉賬這種強一致業務場景才會用到，具體得根據業務場景做取捨。
- ** AP：放棄強一致性，注重可用性和分割槽容錯性 ** ，這是現在絕大多數分散式業務場景的選擇，只要最後能保證最終一致性(Base理論)即可。
3.3 簡單理解一下BASE理論
** BASE是Basically Available(基本可用)，Soft State（軟狀態）和Eventually
Consistent（最終一致性）三個短語的縮寫，是對AP的一種擴充套件，即當出現故障時允許部分服務不可用，但要保證核心服務正常。對於資料，允許一定時間內不一致，通過中間狀態(軟狀態)過渡，最後保證最終一致即可
** 。
舉例說明：
** Basically Available(基本可用) **
：比如一個系統註冊使用者成功時需要傳送資訊通知，允許傳送資訊不成功，但註冊這個核心功能要保證可用。
** Soft State（軟狀態） ** ：平時見得最多的軟狀態有：“支付中”、“資料處理中”等，這些狀態是為了滿足可用性和最終一致增加的過渡狀態。
** Eventually Consistent（最終一致性） **
：比如在購買商品時，支付的過程中會顯示“支付中”，最終會顯示“支付成功”，這個時候其實就保證最終你的賬戶和收款賬戶這個事務最終一致了，這種事務可以理解為“
** 柔性事務 ** ”。
4. 分散式事務常用的解決方案
- ** 2PC（Two-phase commit protocol） ** ，又稱二階段提交，是一種強一致性解決方案。對其進行補充的還有一個叫 ** 3PC ** 的解決方案。
- ** TCC（Try Confirm Cancel） ** ，補償事務。
- ** 本地訊息表 **
- ** 訊息事務 **
- ** 最大努力通知 **
這裡先不細說，後續逐個擊破，最終還是要用程式碼落地。
總結
這篇只是一個開端，主要是大概回顧一下分散式事務中常遇到的知識點，後續主要是針對各個解決方案的落地，一起擼碼。
。