（转）如何保障微服务架构下的数据一致性？
轉自： https://cloud.tencent.com/developer/article/1459734
【1】寫在前面
隨著微服務架構的推廣，越來越多的公司采用微服務架構來構建自己的業務平臺。就像前邊的文章說的，微服務架構為業務開發帶來了諸多好處的同時，例如單一職責、獨立開發部署、功能復用和系統容錯等等，也帶來一些問題。
例如上手難度變大，運維變得更復雜，模塊之間的依賴關系更復雜，數據一致性難以保證，等等。但是辦法總是比問題多，本篇文章就來介紹一下我們是如何保障微服務架構的數據一致性的。
【2】微服務架構的數據一致性問題
以電商平臺為例，當用戶下單并支付后，系統需要修改訂單的狀態并且增加用戶積分。由于系統采用的是微服務架構，分離出了支付服務、訂單服務和積分服務，每個服務都有獨立數據庫做數據存儲。當用戶支付成功后，無論是修改訂單狀態失敗還是增加積分失敗，都會造成數據的不一致。
?為了解決例子中的數據一致性問題，一個最直接的辦法就是考慮數據的 強一致性。那么如何保證數據的強一致性呢？我們從關系型數據庫的 ACID 理論說起。
ACID
關系型數據庫具有解決復雜事務場景的能力，關系型數據庫的事務滿足 ACID 的特性。
- Atomicity：原子性（要么都做，要么都不做）
- Consistency：一致性（數據庫只有一個狀態，不存在未確定狀態）
- Isolation：隔離性（事務之間互不干擾）
- Durability：永久性（事務一旦提交，數據庫記錄永久不變）
具有 ACID 特性的數據庫支持數據的強一致性，保證了數據本身不會出現不一致。
然而微服務架構下，每個微服務都有自己的數據庫，導致微服務架構的系統不能簡單地滿足 ACID，我們就需要尋找微服務架構下的數據一致性解決方案。
微服務架構的系統本身是一種分布式系統，而本文討論的問題其實也就是分布式事務之數據一致性的問題，我們來聊聊分布式系統的 CAP 理論和 BASE 理論。
方案1：CAP
CAP 是指在一個分布式系統下， 包含三個要素：Consistency（一致性）、Availability（可用性）、Partition tolerance（分區容錯性），并且三者不可得兼。
- C：Consistency，一致性，所有數據變動都是同步的。
- A：Availability，可用性，即在可以接受的時間范圍內正確地響應用戶請求。
- P：Partition tolerance，分區容錯性，即某節點或網絡分區故障時，系統仍能夠提供滿足一致性和可用性的服務。
關系型數據庫單節點保證了數據強一致性（C）和可用性（A），但是卻無法保證分區容錯性（P）。
然而在分布式系統下，為了保證模塊的分區容錯性（P），只能在數據強一致性（C）和可用性（A）之間做平衡。犧牲一致性或可用性。
具體表現為在一定時間內，可能模塊之間數據是不一致的，但是通過自動或手動補償后能夠達到最終的一致（無法保證數據實時性一致，可以保證延時性一致或最終一致）。
方案2：BASE
BASE 理論主要是解決 CAP 理論中分布式系統的可用性和一致性不可兼得的問題。BASE 理論包含以下三個要素：
- BA：Basically Available，基本可用。
- S：Soft State，軟狀態，狀態可以有一段時間不同步。
- E：Eventually Consistent，最終一致，最終數據是一致的就可以了，而不是時時保持強一致。
BASE 模型與 ACID 不同，滿足 CAP 理論，通過犧牲強一致性來保證系統可用性。由于犧牲了強一致性，系統在處理請求的過程中，數據可以存在短時的不一致（因為可以手動或自動補償或重試）。
系統在處理業務時，記錄每一步的臨時狀態。當出現異常時，根據狀態判斷是否繼續處理請求或者退回原始狀態，從而達到數據的最終一致。
例如，在上面的案例中，支付成功，訂單也成功，但增加積分失敗，此時，不應回滾支付和訂單，而應通過一些補償方法來讓積分得以正確地增加。后面會講到具體的實現方法。
在分享我們的分布式事務實踐方案之前，先看看早期解決分布式事務問題的二階段提交協議。
【3】二階段提交協議
X/Open DTP（Distributed Transaction Process）是一個分布式事務模型，此模型主要使用二階段提交（2PC，Two-Phase-Commit）來保證分布式事務的完整性。在這個模型里面，二階段提交協議有三個角色：
- AP：Application，應用程序，業務層。
- RM：Resource Manager，資源管理器，關系型數據庫或支持 XA 接口（XA 規范是 X/Open 組織定義的分布式事務規范）的組件。
- TM：Transaction Manager ，事務管理器，負責各個 RM 的提交和回滾。
當應用程序（AP）調用了事務管理器（TM）的提交方法時，事務的提交分為兩個階段實行。
第一階段（準備階段）
TM 通知所有參與事務的各個 RM，給每個 RM 發送 prepare 消息。
RM 接收到消息后進入準備階段后，要么直接返回失敗，要么創建并執行本地事務，寫本地事務日志（redo 和 undo 日志），但是不提交（此處只保留最后一步耗時最少的提交操作給第二階段執行）。
我的理解為：TM 調用 RM，TM線程阻塞；RM開啟事務，處理數據寫入db，但是不提交事務；RM向TM發送請求，說我已經完成，RM線程阻塞，等待TM的回復；
第二階段（提交 / 回滾階段）
TM 收到 RM 準備階段的失敗消息或者獲取 RM 返回消息超時，則TM直接給 RM 發送回滾（rollback）消息，否則TM發送提交（commit）消息給RM。
RM 根據 TM 的指令執行提交或者回滾，執行完成后釋放所有事務處理過程中使用的鎖（最后階段釋放鎖）。
2pc（2-phrase commit）兩階段提交協議中，要理解到：
1）第一階段中，TM與RM在通信過程中，兩者線程均是阻塞狀態，即RM沒有提交事務；
2）第二階段中，RM提交事務，發送OK到TM后， 線程才算執行完成；
二階段提交的利弊
優點
2PC 提供了一套完整的分布式事務的解決方案，遵循事務嚴格的 ACID 特性。
缺點
- 缺點1，db并發性低，數據被鎖定跨越整個流程：TM 通過 XA 接口與各個 RM 之間進行數據交互，從第一階段的準備階段，業務所涉及的數據就被鎖定，并且鎖定跨越整個提交流程（db并發性能低）。在高并發和涉及業務模塊較多的情況下對數據庫的性能影響較大。
- 缺點2，模塊多TM，RM，擴展性低：二階段是反可伸縮模式的，業務規模越大，涉及模塊越多，局限性越大，系統可伸縮性越差（涉及模塊多如TM，RM，故擴展性低）。
- 缺點3，不是所有組件都支持XA協議：在技術棧比較雜的分布式應用中，存儲組件有很多不支持 XA 協議（各個服務間可能不屬于同一個技術框架，封裝的網絡協議不同）。
二階段的諸多弊端，導致分布式系統下無法直接使用此方案來解決數據一致性問題，但它提供了解決分布式系統下數據一致性問題的思路。
【4】微服務數據同步一致性案例
下面就通過案例來分享我們是如何保證微服務架構的數據一致性的。
方案1——可靠消息最終一致性（微服務組件技術棧不同時使用）
可靠消息最終一致性方案本質上是利用 MQ 組件實現的二階段提交。此方案涉及 3 個模塊：
- 上游應用，執行業務并發送 MQ 消息。
- 可靠消息服務和 MQ 消息組件，協調上下游消息的傳遞，并確保上下游數據的一致性。
- 下游應用，監聽 MQ 的消息并執行自身業務。
上游應用執行業務并發送 MQ 消息（第一階段）
上游應用將本地業務執行和消息發送綁定在同一個本地事務中，保證要么本地操作成功并發送 MQ 消息，要么兩步操作都失敗并回滾。
上游應用和可靠消息之間的業務交互圖如下：
以上每一步都可能出現失敗情況，分析一下這 5 步出現異常后上游業務和消息發送是否一致：
| 失敗步驟 | 現象 | 一致性 |
| 第1步 | 上游應用未執行，mq消息未發送； | 一致 |
| 第2步 | 上游應用未執行，mq消息未發送； | 一致 |
| 第3步 | 上游應用回滾，mq消息未發送； | 一致 |
| 第4步 | 上游應用執行，mq消息未發送； | 不一致 |
| 第5步 | 上游應用執行，mq消息未發送； | 不一致 |
上游應用執行完成，下游應用尚未執行或執行失敗時，此事務即處于 BASE 理論的 Soft State 狀態。
下游應用監聽 MQ 消息并執行業務（第二階段）
下游應用監聽 MQ 消息并執行業務，并且將消息的消費結果通知可靠消息服務。
可靠消息的狀態需要和下游應用的業務執行保持一致，可靠消息狀態不是已完成時，確保下游應用未執行，可靠消息狀態是已完成時，確保下游應用已執行。
下游應用和可靠消息服務之間的交互圖如下：
以上每一步都可能出現失敗情況，分析一下這 4 步出現異常后下游業務和消息狀態是否一致：
| 失敗步驟 | 現象 | 一致性 |
| 第1步 | 下游應用未執行，消息狀態為已發送； | 一致 |
| 第2步 | 下游應用回滾，消息狀態為已發送； | 一致 |
| 第3步 | 下游應用回滾，消息狀態為已發送； | 一致 |
| 第4步 | 下游應用已執行，消息狀態為已發送； | 不一致 |
通過分析以上兩個階段可能失敗的情況，為了確保上下游數據的最終一致性，在可靠消息系統中，需要開發? 消息狀態確認和消息重發? 兩個功能以實現 BASE 理論的 Eventually Consistent 特性。
補充：可靠性消息數據一致性方案，上游+可靠消息服務+MQ+下游整體時序圖（匯總）
可靠消息一致性方案補償機制1：消息狀態確認
可靠消息服務定時監聽待確認消息（通過調度線程或定時任務實現），如果存在狀態為待確認并且超時的消息，則表示上游應用和可靠消息交互中的步驟 4 或者 5 出現異常。
可靠消息則攜帶消息體內的信息向上游應用發起請求查詢該業務是否已執行。上游應用提供一個可查詢接口供可靠消息追溯業務執行狀態，如果業務執行成功則更改消息狀態為已發送，否則刪除此消息確保數據一致。具體流程如下：
可靠消息一致性方案補償2：消息重發
消息已發送則表示上游應用已經執行，接下來則確保下游應用也能正常執行。
可靠消息服務發現可靠消息服務中存在消息狀態為已發送并且超時的消息，則表示可靠消息服務和下游應用中存在異常的步驟，無論哪個步驟出現異常，可靠消息服務都將此消息重新投遞（重發）到 MQ 組件中供下游應用監聽。
下游應用監聽到此消息后，在保證冪等性的情況下重新執行業務并通知可靠消息服務此消息已經成功消費，最終確保上游應用、下游應用的數據最終一致性。具體流程如下：
通過消息確認和消息重發兩個功能，可以確保上游應用、可靠消息服務和下游應用數據的最終一致性。（補充——消息確認保證了上游應用成功執行業務，消息重發保證了下游應用成功消費數據）
當然在實際接入過程中，需要引入人工干預功能。比如引入重發次數限制，超過重發次數限制的將消息修改為死亡消息，等待人工干預。
回到業務場景： 代入開篇案例，通過可靠消息最終一致性方案，
第一階段，訂單狀態更改之前，訂單服務向可靠消息服務請求保存待確認消息（消息狀態為待確認）。可靠消息服務保存消息并返回。訂單服務接收到返回信息后執行本地業務并通知可靠消息服務業務已執行。消息服務更改消息狀態并將消息投遞到 MQ 中間件（消息狀態為已發送）。
第二階段，積分系統監聽到 MQ 消息，查看積分是否已增加，如果沒有增加則修改積分，然后請求可靠消息服務?？煽肯⒎战邮盏椒e分系統的請求，將消息狀態更改為已完成（消息狀態為已完成）。
到這里，已經介紹完如何通過可靠消息服務來保證數據的一致性。但由于引入了可靠消息服務和消息隊列，帶來了一定的復雜性，所以，它更適用于跨平臺技術棧不統一的場景。
下面再來介紹在技術棧統一的情況下，如何通過 TCC 來解決數據一致的方法。
【5】方案2——TCC（Try-Confirm-Cancel）（微服務組件技術棧相同時使用）
TCC 方案是二階段提交的另一種實現方式，它涉及 3 個模塊，主業務、從業務和活動管理器（協作者）。
下面這張圖是互聯網上關于 TCC 比較經典的圖示：
第一階段：主業務服務分別調用所有從業務服務的 try 操作，并在活動管理器中記錄所有從業務服務。當所有從業務服務 try 成功或者某個從業務服務 try 失敗時，進入第二階段。
第二階段：活動管理器根據第一階段從業務服務的 try 結果來執行 confirm 或 cancel 操作。如果第一階段所有從業務服務都 try 成功，則協作者調用所有從業務服務的 confirm 操作，否則，調用所有從業務服務的 cancel 操作。
在第二階段中，confirm 和 cancel 同樣存在失敗情況，所以需要對這兩種情況做 異常處理 以保證數據一致性。
- Confirm 失敗：則回滾所有 confirm 操作并執行 cancel 操作。
- Cancel 失敗：從業務服務需要提供自動 cancel 機制，以保證 cancel 成功。
目前有很多基于 RPC 的 TCC 框架，但是不適用于微服務架構下基于 HTTP 協議的交互模式。我們這次只討論基于 HTTP 協議的 TCC 實現。具體的實現流程如下：
代入開篇提到的案例，通過 TCC 方案，訂單服務在訂單狀態修改之前執行預增積分操作（try），并從積分服務獲取 confirm/cancel 預增積分的請求地址。
如果預增積分（try）成功，則訂單服務更改訂單狀態并通知活動管理器，活動管理器請求積分模塊的 confirm 接口來增加積分。
如果預增積分（try）失敗，則訂單服務業務回滾。積分服務通過定時任務刪除預增積分（try）超時的數據。
另外如果活動管理器調用積分服務的 confirm 接口失敗，則活動管理器調用積分服務 cancel 接口來取消預增積分，從而，保證訂單和積分數據的最終一致性。
通過上面的對可靠消息服務和 TCC 方案的描述，我們解決了技術棧一致和不一致的兩種情況下的數據一致性問題。
但是，通常在這些核心業務上有很多附加業務，比如當用戶支付完成后，需要通過短信通知用戶支付成功。
這一類業務的成功或者失敗不會影響核心業務，甚至很多大型互聯網平臺在并高并發的情況下會主動關閉這一類業務以保證核心業務的順利執行。那么怎么處理這類情況呢，我們來看看最大努力通知方案。
【6】方案三——最大努力通知（數據一致性要求低）
最大努力通知方案涉及三個模塊：
- 上游應用，發消息到 MQ 隊列。
- 下游應用（例如短信服務、郵件服務），接受請求，并返回通知結果。
- 最大努力通知服務，監聽消息隊列，將消息存儲到數據庫中，并按照通知規則調用下游應用的發送通知接口。
具體流程如下：
最大努力通知服務表示在不影響主業務的情況下，盡可能地確保數據的一致性。它需要開發人員根據業務來指定通知規則，在滿足通知規則的前提下，盡可能的確保數據的一致，以盡到最大努力的目的。
根據不同的業務可以定制不同的通知規則（通知頻率和最大通知次數），比如通知支付結果等相對嚴謹的業務，可以將通知頻率設置高一些，通知時間長一些，比如隔 5 分鐘通知一次，持續時間 1 小時。
如果不重要的業務，比如通知用戶積分增加，則可以將通知頻率設置低一些，時間短一些，比如 10 分鐘通知一次，持續 30 分鐘。
代入上面提到的支付成功短信通知用戶的案例，通過最大努力通知方案，當支付成功后，將消息發送到 MQ 中間件，在消息中，定義發送規則為 5 分鐘一次，最大發送數為 10 次。
最大努力通知服務監聽 MQ 消息并根據規則調用消息通知服務（短信服務）的消息發送接口，并記錄每次調用的日志信息。在通知成功或者已通知 10 次時，停止通知。
總 * 結
上面通過案例詳細介紹了我們解決微服務之間數據不一致問題的三種方案，下面通過一張簡單的對比圖，為大家選擇合適的解決方案提供簡單依據。
| 分布式事務方案對比 | |||
| 方案 | 一致性 | 復雜程度 | 適用范圍 |
| 可靠消息 | 最終一致性 | 難 | 跨平臺業務，對數據一致性要求高 |
| TCC-try-confirm-cancel | 最終一致性 | 難 | 平臺內容，技術棧一致，對數據一致性要求高 |
| 最大努力通知 | 最終一致性 | 中 | 附屬功能，對一致性要求低； |
總結
以上是生活随笔為你收集整理的（转）如何保障微服务架构下的数据一致性？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 微信刷脸设置(微信刷脸设置在哪里设置)
- 下一篇： （转）漫画：什么是分布式事务？