微服務架構中的數據一致性解決方案與實踐

1為什么要做服務之間的數據一致性

作為互聯網公司的研發工程師，微服務的架構思想對于各位讀者朋友來說，已經不是陌生東西。我們當中的大多數人，或多或少經歷過從單體應用到微服務化的系統拆分和演進過程。我們按照龐大系統的業務功能和特征，將其從一個單體的大應用，逐漸地拆分成很多的子系統的協同配合完成業務功能，甚至拆分后的某些子系統服務，還可能再拆分出來更多的更細顆粒度的子系統服務。拆分后的服務之間，采用PRC調用方式的通信，也就越來越多。隨之而來的，跨系統服務之間的數據一致性的問題就會越來越突出了。比如電商系統中營銷活動系統的積分和優惠券的發放和扣減，比如電商系統的核心下單核心鏈路上，首頁瀑布流，商詳頁，下單頁等等商品價格全鏈路一致性等等，支撐這些業務功能的實現，往往可能需要依賴來自N個不同的業務系統服務提供的數據讀寫服務能力來完成。

2如何實現服務之間的數據一致性

說到數據一致性這個話題，我們可以想到的最常用最熟悉的解決問題的方式就是事務處理了。它存在的意義是為了保證系統中所有的數據都是符合預期的，并且存在關聯關系的數據之間不會產生矛盾，即數據狀態一致性。事務的概念，起源于數據庫，發展到今天，幾乎在每一個業務系統中都會涉及到。尤其在一些大型復雜的分布式系統中，事務的概念已經不僅局限于數據庫，還可以延伸為一切需要保證數據一致性的應用場景，包括但不限于數據庫、事務內存、緩存、消息隊列、分布式存儲等等，這些都有可能會用到事務處理。 今天我們探討的主題是服務之間數據一致性問題。當然，實際生產落地中，在不同業務背景下，具備可行性的方案也是非常多的，各有優劣和適用場景。我們從中選擇一兩個具體實現，聊一些相關的設計和實踐。

3幾個核心名詞

為了方便正在閱讀本篇文章的同學對后續內容的閱讀和理解，我們先對文章中使用到的幾個名詞的語義做一些解釋和約定： 業務側系統：指的是發起執行業務操作的一方系統服務，可以簡單理解為消費方。 平臺側系統：指的是為發起執行業務操作而提供基礎能力的一方系統服務，可以簡單理解為服務方。 執行業務操作：指的是對數據的讀寫操作需要依賴多個系統服務的協同完成，業務側系統發起，平臺側系統執行最終的數據讀寫操作。這樣場景中就普遍存在著服務之間的數據一致性問題（備注 ：業務側系統和平臺側系統是一個邏輯概念，并非一定要存在具體的應用服務與之對應）。 業務操作標識：指的是業務操作應該歸屬的業務類型或者業務場景的標識，它是平臺側系統創建并且統一管理的，然后發放給業務側系統，在業務側系統的服務調用平臺側系統提供服務能力的身份信息。業務標識可以設計為單層結構，也可以設計為多層結構，符合當前系統和業務的需求即可。 業務操作唯一ID：指的是某個具體業務操作在某一次或者多次重復執行的唯一性標識。生產實踐中，它一般是由業務側系統的服務自定義實現和管理的，也可以是基于平臺側系統提供有約束性質和方便管理的規則限制下，再由業務側系統的服務自定義實現，后者是比較推薦的方式。 業務操作記錄表：指的是記錄業務操作的日志流水表。生產實踐中，一般是由業務側系統的服務創建并且管理。

4方案一：業務側系統保證最終一致性

4.1 核心思想

通過業務側系統的服務保證數據的最終一致性，其核心思想就是業務側系統記錄下來每一次具體業務操作的執行流水日志信息，并且對沒有全部成功的變更結果，觸發執行數據一致性的校驗核對工作。

4.2 設計原則

平臺側系統服務，提供支持執行業務操作的基礎服務能力的接口。特別強調一點，這里是需要根據業務操作標識和業務操作唯一ID來實現接口的冪等設計。為什么我們有了唯一ID，同時還是需要有業務操作標識？因為在實際的生產實踐中，在各種內因和外因的背景下，需要兼顧系統的穩定性和業務迭代的靈活性，很難做到絕對的全局性唯一ID的生成。更多時候，只需要在某個業務側系統的內部，保證全局唯一性即可，這也是符合實際情況的系統設計。類似的解決問題的思路，在其他的系統設計場景，也是有非常高的借鑒價值的。

平臺側系統服務，提供執行業務操作后的結果查詢接口，支持根據業務操作標識和業務操作的唯一性ID查詢能力。

業務操作記錄表，支持記錄和識別業務操作的標識和每次執行的唯一ID。

業務側系統服務，觸發對業務操作記錄表的數據一致性的檢查核對工作，執行核對的方式，比如實時的同步檢查核對、準實時的異步檢查核對、定時任務的異步檢查核對等等，為了保證自己和平臺側系統的數據最終一致性。

4.3 流程圖

4.3.1 數據一致性的校驗核對同步執行流程

4.3.2 數據一致性的校驗核對異步核對鏈路

5方案二：平臺側系統保證最終一致性

5.1 核心思想

通過平臺側系統的服務保證數據的最終一致性，核心思想是平臺側系統的每一次的數據變更，都主動地尋找業務側系統，來確認本次數據變更結果是否符合預期。

5.2 設計的基本原則：

平臺側系統，提供支持業務操作執行的基礎服務能力的接口，需要根據業務操作標識和唯一ID做冪等設計。它和方案一的一致性原則類似，省略不再贅述。 平臺側系統，提供業務操作的執行結果確認的回調SPI，可以方便業務側系統來實現，根據業務操作標識和業務操作的唯一ID。 業務側系統，提供根據業務操作標識和業務操作的唯一ID，來判斷兩邊的數據是否具備一致性的回調實現。

5.3 流程圖

5.3.1 數據一致性的校驗核對同步核對鏈路

5.3.2 數據一致性的校驗核對異步核對鏈路

6實踐過程中一些經驗分享

這一部分，我將會對平臺側系統和業務側系統的接口設計的部分細節，做一些簡單的擴展闡述。希望為大家后續的研發工作提供一些思路。后續的文章中，將會針對其中一些具體的解決方案，做更詳細的闡述。 首先，接口冪等性設計，將從如下角度進行闡述: 數據結構，狀態存儲，異常處理，返回結果唯一等等角度做一些總結分享。

6.1 數據結構設計

接口冪等性設計，是基于業務操作的標識(這里是稱之為Tag)和業務操作的唯一ID來實現的。業務操作標識的設計，可以是單層的設計，也可以是多層的設計。其中，多層的設計是為了滿足業務側系統的存在復雜并且多業務場景的訴求。業務操作的唯一ID的生成方式，可以是沒有任何業務含義的自增趨勢的不可重復的ID，比如MySQL的自增主鍵ID，分布式ID生成器等等方式，也可以是業務側系統的某些特定的業務字段 ，比如用戶的userId，訂單的orderId，商品的spuId，skuId等等。在實際實踐中，后者是我們比較推薦的常用方式，可以實現在不增加系統復雜度和額外依賴資源的同時，又可以和業務側系統達到高度的契合。

6.2 狀態存儲設計

在一般情況下，建議把MySQL存儲當做我們首選的存儲，MySQL提供非常完善的數據一致性保證能力，最簡單的方式是基于數據庫的聯合唯一索引設計，多次層Tag + 唯一ID的業務唯一鍵。但是也是有缺陷的，比如MySQL自身的性能瓶頸和昂貴的存儲成本。性能上的瓶頸，可以通過訪問MySQL的冪等校驗之前，增加訪問Redis的冪等校驗，校驗不通過拋出異常，在MySQL冪等校驗通過以后，異步刷數據到Redis中，這樣保證Redis校驗通過的同時MySQL校驗一定是通過的。我們可以接受Redis的冪等校驗的不準確性，僅僅是期望它成為流量漏斗的上層，為MySQL承擔起流量過濾作用，當然你可以有其他的更多的方案來做這件事，甚至組合起來使用。也可以增加分庫分表的策略，來解決MySQL的性能瓶頸。在MySQL的存儲成本是相對比較高的，我們可以對歷史的數據做歸檔處理，只保留一部分的熱數據，原則上保持單表的數據行數在500w~1000w之間，同時也可以有能支持一定量的歷史數量查詢。同時這個過程也需要考慮無鎖處理問題和MySQL空間碎片的問題等等。

6.3 異常處理設計

第一步，明確導致發生異常的原因有哪些？一般可以歸為幾個分類，網路異常，數據格式錯誤，業務邏輯異常。第二步，針對特定類型的問題，我們做出相應處理方案。比如我們重試機制，控制重試頻次，重試周期的衰減時間執行控制，處理數據處理的終態的異常數據的兜底處理機制等等方式。

6.4 返回結果唯一

我需要保證接口的返回的數據，再多次重復調用執行，依舊保證完全相同。我們可以基于狀態機的流轉控制，返回相同的狀態碼，也可以對一些核心業務參數做核對校驗，如果不通過返回特定的異常碼等等。 此外，平臺側系統的提供給基礎能力接口的設計要求我們研發同學思考和考慮的更多，比如一致性延遲問題，狀態機的設計，并發問題處理，接口不可用解決等等。

6.5 延遲問題的容忍度

能否在業務側系統服務期望的時間點，完成數據一致性的校驗核對工作？若有延遲，延遲是多少？尤其是極端場景下的延遲是多少？ 案例：如果使用定時任務，做數據一致性校驗核對工作。比如一個周期（假設1min），還有很多數據未完成核對工作，剩余多少，以及對業務側系統的影響。解決思路：1. 評估和設計一個合理的周期大??；2. 選擇全量核對和增量核對的選擇；3. 增加核對的掃描的數據范圍的策略；4. 增量核對確保不丟失未核對過的數據，等等。 案例：如果使用MQ消息，我們可能面臨的問題是消息堆積，消息丟失等等場景MQ問題帶來的數據不一致問題。 案例：如果使用同步等待方式，是可以將數據一致性的延遲降低為0，但是系統吞吐能力和可用性等等，都是無法保證，這也是選擇權衡的結果。

6.6 基于狀態機的設計

基于狀態機的設計中，一定是有初始態和終態的，代表數據的核對工作，有始有終。至于中間態，可以有多個中間態，也可以是僅有一個中間態，這個和實際的需求和背景相關聯的，可以靈活地控制。其中的終態，一般情況下都不會只有一種，而是有兩大類，一種是成功的終態表示數據實現最終一致性，一種是失敗的終態表示不因為不可抗拒的因素導致的數據不一致產生。失敗的終態，也是可以設計出多種狀態，根據實際需要來設計。比如多次重試從初始態到終態的耗時和處于失敗態的數據核對檢測工作的占比，一定程度上代表著業務側系統對數據一致性延遲的容忍度。這應該是我們必須關注的核心指標信息。

6.7 并發問題

我們在創建一個初始化態的流水日志記錄的時候，是一個MySQL的insert操作（假設你選擇了MySQL作為存儲），需要避免創建多條的業務操作唯一ID的記錄。最簡單粗暴的方式，依賴DB的聯合唯一索引是可以實現的。但是需要考慮在并發比較多的時候，帶來的性能和吞吐問題，甚至導致創建初始化態就失敗的問題。 對于相同數據并發寫的問題，我們成功執行一條insert語句，大多數情況可以滿足我們業務側系統的預期。我們可以采用加鎖，排隊等待，分組等待排隊等等手段，限制類似場景的并發數來解決。這種方式，隨著業務的發展擴張，可能會面臨系統的吞吐量不足以支撐業務的問題。 解決上述的吞吐量下降的問題，我們可能又會想到采用MQ的方式來削峰填谷，因為實際生產實踐中，并發寫問題的往往都是一個特點 瞬時性發生的系統尖刺。采用MQ的方式，可以保證平臺側系統創建初始化態的流水日志的系統吞吐量。 在以上的基礎之上，我們還是可以采用隔離拆分的方式，比如服務接口拆分層面的隔離，MQ的topic拆分的隔離等等，配合不同的限流熔斷等等系統保護策略的方式以及不同的系統資源傾斜等等，解決平臺側系統的性能問題。

6.8 需要解決不可用

熔斷限流，資源隔離，多元化的降級策略等等，這些是大家都非常熟悉的系統可用性保障的手段，這部分相關的內容，就不再展開敘述了。

6.9 需要提供可視化和可觀測

完善告警機制，比如異常狀態告警，超出閾值告警等等，讓相關的業務側系統和平臺側系統同學可以快速感知到問題并且介入解決問題。 建設監控大盤，比如 MySQL，Redis，MQ，以及數據核對工作的狀態的監控等等，都是需要我們去一步一步建設起來的。 定位和排查問題的工具，拆分后的系統，其系統的復雜度是指數增長的，這個方面也是非常重要的。

7總結

在本篇文章中，闡述了兩種處理數據一致性問題的解決方案，從核心思想，設計原則，系統交互流程等等做了詳細的闡述，比對兩種方案，各有優劣和各自的適用場景。方案一，業務側系統來保證數據的一致性，更適用于對數據的一致性有相對比較強的耦合依賴關系的業務場景，需要依賴業務操作的執行結果做出判斷，執行不同后續業務邏輯分支的執行。案例: 同一個商品在不同修改商品信息(變更不同的字段，變更不同表的字段)的入口觸發異步更新C端緩存的單品維度的商品全量緩存數據構建，變更的事務是在成功完成提交以后，方可執行本次變更對應的后續緩存構建。方案二，平臺側系統來保證數據的一致性，更適用于業務側系統，關注點是數據的最終執行結果的業務場景，案例: 不同業務場景入口的庫存扣減和庫存回滾執行結果。最后，提到在生產實踐過程中一些經驗和解決方案的總結分享，每個點都是值得繼續深入探討。

*文/kof wang