1為什么要做服務(wù)之間的數(shù)據(jù)一致性

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

2如何實(shí)現(xiàn)服務(wù)之間的數(shù)據(jù)一致性

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

3幾個(gè)核心名詞

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

4方案一：業(yè)務(wù)側(cè)系統(tǒng)保證最終一致性

4.1 核心思想

通過業(yè)務(wù)側(cè)系統(tǒng)的服務(wù)保證數(shù)據(jù)的最終一致性，其核心思想就是業(yè)務(wù)側(cè)系統(tǒng)記錄下來每一次具體業(yè)務(wù)操作的執(zhí)行流水日志信息，并且對(duì)沒有全部成功的變更結(jié)果，觸發(fā)執(zhí)行數(shù)據(jù)一致性的校驗(yàn)核對(duì)工作。

4.2 設(shè)計(jì)原則

平臺(tái)側(cè)系統(tǒng)服務(wù)，提供支持執(zhí)行業(yè)務(wù)操作的基礎(chǔ)服務(wù)能力的接口。特別強(qiáng)調(diào)一點(diǎn)，這里是需要根據(jù)業(yè)務(wù)操作標(biāo)識(shí)和業(yè)務(wù)操作唯一ID來實(shí)現(xiàn)接口的冪等設(shè)計(jì)。為什么我們有了唯一ID，同時(shí)還是需要有業(yè)務(wù)操作標(biāo)識(shí)？因?yàn)樵趯?shí)際的生產(chǎn)實(shí)踐中，在各種內(nèi)因和外因的背景下，需要兼顧系統(tǒng)的穩(wěn)定性和業(yè)務(wù)迭代的靈活性，很難做到絕對(duì)的全局性唯一ID的生成。更多時(shí)候，只需要在某個(gè)業(yè)務(wù)側(cè)系統(tǒng)的內(nèi)部，保證全局唯一性即可，這也是符合實(shí)際情況的系統(tǒng)設(shè)計(jì)。類似的解決問題的思路，在其他的系統(tǒng)設(shè)計(jì)場景，也是有非常高的借鑒價(jià)值的。

平臺(tái)側(cè)系統(tǒng)服務(wù)，提供執(zhí)行業(yè)務(wù)操作后的結(jié)果查詢接口，支持根據(jù)業(yè)務(wù)操作標(biāo)識(shí)和業(yè)務(wù)操作的唯一性ID查詢能力。

業(yè)務(wù)操作記錄表，支持記錄和識(shí)別業(yè)務(wù)操作的標(biāo)識(shí)和每次執(zhí)行的唯一ID。

業(yè)務(wù)側(cè)系統(tǒng)服務(wù)，觸發(fā)對(duì)業(yè)務(wù)操作記錄表的數(shù)據(jù)一致性的檢查核對(duì)工作，執(zhí)行核對(duì)的方式，比如實(shí)時(shí)的同步檢查核對(duì)、準(zhǔn)實(shí)時(shí)的異步檢查核對(duì)、定時(shí)任務(wù)的異步檢查核對(duì)等等，為了保證自己和平臺(tái)側(cè)系統(tǒng)的數(shù)據(jù)最終一致性。

4.3 流程圖

4.3.1 數(shù)據(jù)一致性的校驗(yàn)核對(duì)同步執(zhí)行流程

4.3.2 數(shù)據(jù)一致性的校驗(yàn)核對(duì)異步核對(duì)鏈路

5方案二：平臺(tái)側(cè)系統(tǒng)保證最終一致性

5.1 核心思想

通過平臺(tái)側(cè)系統(tǒng)的服務(wù)保證數(shù)據(jù)的最終一致性，核心思想是平臺(tái)側(cè)系統(tǒng)的每一次的數(shù)據(jù)變更，都主動(dòng)地尋找業(yè)務(wù)側(cè)系統(tǒng)，來確認(rèn)本次數(shù)據(jù)變更結(jié)果是否符合預(yù)期。

5.2 設(shè)計(jì)的基本原則：

平臺(tái)側(cè)系統(tǒng)，提供支持業(yè)務(wù)操作執(zhí)行的基礎(chǔ)服務(wù)能力的接口，需要根據(jù)業(yè)務(wù)操作標(biāo)識(shí)和唯一ID做冪等設(shè)計(jì)。它和方案一的一致性原則類似，省略不再贅述。 平臺(tái)側(cè)系統(tǒng)，提供業(yè)務(wù)操作的執(zhí)行結(jié)果確認(rèn)的回調(diào)SPI，可以方便業(yè)務(wù)側(cè)系統(tǒng)來實(shí)現(xiàn)，根據(jù)業(yè)務(wù)操作標(biāo)識(shí)和業(yè)務(wù)操作的唯一ID。 業(yè)務(wù)側(cè)系統(tǒng)，提供根據(jù)業(yè)務(wù)操作標(biāo)識(shí)和業(yè)務(wù)操作的唯一ID，來判斷兩邊的數(shù)據(jù)是否具備一致性的回調(diào)實(shí)現(xiàn)。

5.3 流程圖

5.3.1 數(shù)據(jù)一致性的校驗(yàn)核對(duì)同步核對(duì)鏈路

5.3.2 數(shù)據(jù)一致性的校驗(yàn)核對(duì)異步核對(duì)鏈路

6實(shí)踐過程中一些經(jīng)驗(yàn)分享

這一部分，我將會(huì)對(duì)平臺(tái)側(cè)系統(tǒng)和業(yè)務(wù)側(cè)系統(tǒng)的接口設(shè)計(jì)的部分細(xì)節(jié)，做一些簡單的擴(kuò)展闡述。希望為大家后續(xù)的研發(fā)工作提供一些思路。后續(xù)的文章中，將會(huì)針對(duì)其中一些具體的解決方案，做更詳細(xì)的闡述。 首先，接口冪等性設(shè)計(jì)，將從如下角度進(jìn)行闡述: 數(shù)據(jù)結(jié)構(gòu)，狀態(tài)存儲(chǔ)，異常處理，返回結(jié)果唯一等等角度做一些總結(jié)分享。

6.1 數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)

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

6.2 狀態(tài)存儲(chǔ)設(shè)計(jì)

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

6.3 異常處理設(shè)計(jì)

第一步，明確導(dǎo)致發(fā)生異常的原因有哪些？一般可以歸為幾個(gè)分類，網(wǎng)路異常，數(shù)據(jù)格式錯(cuò)誤，業(yè)務(wù)邏輯異常。第二步，針對(duì)特定類型的問題，我們做出相應(yīng)處理方案。比如我們重試機(jī)制，控制重試頻次，重試周期的衰減時(shí)間執(zhí)行控制，處理數(shù)據(jù)處理的終態(tài)的異常數(shù)據(jù)的兜底處理機(jī)制等等方式。

6.4 返回結(jié)果唯一

我需要保證接口的返回的數(shù)據(jù)，再多次重復(fù)調(diào)用執(zhí)行，依舊保證完全相同。我們可以基于狀態(tài)機(jī)的流轉(zhuǎn)控制，返回相同的狀態(tài)碼，也可以對(duì)一些核心業(yè)務(wù)參數(shù)做核對(duì)校驗(yàn)，如果不通過返回特定的異常碼等等。 此外，平臺(tái)側(cè)系統(tǒng)的提供給基礎(chǔ)能力接口的設(shè)計(jì)要求我們研發(fā)同學(xué)思考和考慮的更多，比如一致性延遲問題，狀態(tài)機(jī)的設(shè)計(jì)，并發(fā)問題處理，接口不可用解決等等。

6.5 延遲問題的容忍度

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

6.6 基于狀態(tài)機(jī)的設(shè)計(jì)

基于狀態(tài)機(jī)的設(shè)計(jì)中，一定是有初始態(tài)和終態(tài)的，代表數(shù)據(jù)的核對(duì)工作，有始有終。至于中間態(tài)，可以有多個(gè)中間態(tài)，也可以是僅有一個(gè)中間態(tài)，這個(gè)和實(shí)際的需求和背景相關(guān)聯(lián)的，可以靈活地控制。其中的終態(tài)，一般情況下都不會(huì)只有一種，而是有兩大類，一種是成功的終態(tài)表示數(shù)據(jù)實(shí)現(xiàn)最終一致性，一種是失敗的終態(tài)表示不因?yàn)椴豢煽咕艿囊蛩貙?dǎo)致的數(shù)據(jù)不一致產(chǎn)生。失敗的終態(tài)，也是可以設(shè)計(jì)出多種狀態(tài)，根據(jù)實(shí)際需要來設(shè)計(jì)。比如多次重試從初始態(tài)到終態(tài)的耗時(shí)和處于失敗態(tài)的數(shù)據(jù)核對(duì)檢測工作的占比，一定程度上代表著業(yè)務(wù)側(cè)系統(tǒng)對(duì)數(shù)據(jù)一致性延遲的容忍度。這應(yīng)該是我們必須關(guān)注的核心指標(biāo)信息。

6.7 并發(fā)問題

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

6.8 需要解決不可用

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

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

完善告警機(jī)制，比如異常狀態(tài)告警，超出閾值告警等等，讓相關(guān)的業(yè)務(wù)側(cè)系統(tǒng)和平臺(tái)側(cè)系統(tǒng)同學(xué)可以快速感知到問題并且介入解決問題。 建設(shè)監(jiān)控大盤，比如 MySQL，Redis，MQ，以及數(shù)據(jù)核對(duì)工作的狀態(tài)的監(jiān)控等等，都是需要我們?nèi)ヒ徊揭徊浇ㄔO(shè)起來的。 定位和排查問題的工具，拆分后的系統(tǒng)，其系統(tǒng)的復(fù)雜度是指數(shù)增長的，這個(gè)方面也是非常重要的。

7總結(jié)

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

*文/kof wang