這是專題的第四篇文章，我們來(lái)了解一下如何保障微服務(wù)架構(gòu)下的數(shù)據(jù)一致性。
隨著微服務(wù)架構(gòu)的推廣，越來(lái)越多的公司采用微服務(wù)架構(gòu)來(lái)構(gòu)建自己的業(yè)務(wù)平臺(tái)。就像前邊的文章說(shuō)的，微服務(wù)架構(gòu)為業(yè)務(wù)開(kāi)發(fā)帶來(lái)了諸多好處的同時(shí)，例如單一職責(zé)、獨(dú)立開(kāi)發(fā)部署、功能復(fù)用和系統(tǒng)容錯(cuò)等等，也帶來(lái)一些問(wèn)題。
例如上手難度變大，運(yùn)維變得更復(fù)雜，模塊之間的依賴關(guān)系更復(fù)雜，數(shù)據(jù)一致性難以保證，等等。但是辦法總是比問(wèn)題多，本篇文章就來(lái)介紹一下我們是如何保障微服務(wù)架構(gòu)的數(shù)據(jù)一致性的。
以電商平臺(tái)為例，當(dāng)用戶下單并支付后，系統(tǒng)需要修改訂單的狀態(tài)并且增加用戶積分。由于系統(tǒng)采用的是微服務(wù)架構(gòu)，分離出了支付服務(wù)、訂單服務(wù)和積分服務(wù)，每個(gè)服務(wù)都有獨(dú)立數(shù)據(jù)庫(kù)做數(shù)據(jù)存儲(chǔ)。當(dāng)用戶支付成功后，無(wú)論是修改訂單狀態(tài)失敗還是增加積分失敗，都會(huì) 造成數(shù)據(jù)的不一致。
為了解決例子中的數(shù)據(jù)一致性問(wèn)題，一個(gè)最直接的辦法就是考慮數(shù)據(jù)的 強(qiáng)一致性。那么如何保證數(shù)據(jù)的強(qiáng)一致性呢？我們從關(guān)系型數(shù)據(jù)庫(kù)的 ACID 理論說(shuō)起。
關(guān)系型數(shù)據(jù)庫(kù)具有解決復(fù)雜事務(wù)場(chǎng)景的能力，關(guān)系型數(shù)據(jù)庫(kù)的事務(wù)滿足 ACID 的特性。
Atomicity：原子性（要么都做，要么都不做）
Consistency：一致性（數(shù)據(jù)庫(kù)只有一個(gè)狀態(tài)，不存在未確定狀態(tài)）
Isolation：隔離性（事務(wù)之間互不干擾）
Durability： 永久性（事務(wù)一旦提交，數(shù)據(jù)庫(kù)記錄永久不變）
具有 ACID 特性的數(shù)據(jù)庫(kù)支持?jǐn)?shù)據(jù)的強(qiáng)一致性，保證了數(shù)據(jù)本身不會(huì)出現(xiàn)不一致。
然而微服務(wù)架構(gòu)下，每個(gè)微服務(wù)都有自己的數(shù)據(jù)庫(kù)，導(dǎo)致微服務(wù)架構(gòu)的系統(tǒng)不能簡(jiǎn)單地滿足 ACID，我們就需要尋找微服務(wù)架構(gòu)下的數(shù)據(jù)一致性解決方案。
微服務(wù)架構(gòu)的系統(tǒng)本身是一種分布式系統(tǒng)，而本文討論的問(wèn)題其實(shí)也就是分布式事務(wù)之?dāng)?shù)據(jù)一致性的問(wèn)題，我們來(lái)聊聊分布式系統(tǒng)的 CAP 理論和 BASE 理論。
CAP 是指在一個(gè)分布式系統(tǒng)下， 包含三個(gè)要素：Consistency（一致性）、Availability（可用性）、Partition tolerance（分區(qū)容錯(cuò)性），并且 三者不可得兼。
C：Consistency，一致性，所有數(shù)據(jù)變動(dòng)都是同步的。
A：Availability，可用性，即在可以接受的時(shí)間范圍內(nèi)正確地響應(yīng)用戶請(qǐng)求。
P：Partition tolerance，分區(qū)容錯(cuò)性，即某節(jié)點(diǎn)或網(wǎng)絡(luò)分區(qū)故障時(shí)，系統(tǒng)仍能夠提供滿足一致性和可用性的服務(wù)。
關(guān)系型數(shù)據(jù)庫(kù) 單節(jié)點(diǎn) 保證了數(shù)據(jù)強(qiáng)一致性（C）和可用性（A），但是卻無(wú)法保證分區(qū)容錯(cuò)性（P）。
然而在分布式系統(tǒng)下，為了保證模塊的分區(qū)容錯(cuò)性（P），只能在數(shù)據(jù)強(qiáng)一致性（C）和可用性（A）之間做平衡。具體表現(xiàn)為在一定時(shí)間內(nèi)，可能模塊之間數(shù)據(jù)是不一致的，但是通過(guò)自動(dòng)或手動(dòng)補(bǔ)償后能夠達(dá)到最終的一致。
BASE 理論主要是解決 CAP 理論中分布式系統(tǒng)的可用性和一致性不可兼得的問(wèn)題。BASE 理論包含以下三個(gè)要素：
BA：Basically Available，基本可用。
S：Soft State，軟狀態(tài)，狀態(tài)可以有一段時(shí)間不同步。
E：Eventually Consistent，最終一致，最終數(shù)據(jù)是一致的就可以了，而不是時(shí)時(shí)保持強(qiáng)一致。
BASE 模型與 ACID 不同，滿足 CAP 理論，通過(guò) 犧牲強(qiáng)一致性來(lái)保證系統(tǒng)可用性。由于犧牲了強(qiáng)一致性，系統(tǒng)在處理請(qǐng)求的過(guò)程中，數(shù)據(jù)可以存在短時(shí)的不一致。
系統(tǒng)在處理業(yè)務(wù)時(shí)，記錄每一步的臨時(shí)狀態(tài)。當(dāng)出現(xiàn)異常時(shí)，根據(jù)狀態(tài)判斷是否繼續(xù)處理請(qǐng)求或者退回原始狀態(tài)，從而達(dá)到數(shù)據(jù)的最終一致。
例如，在上面的案例中，支付成功，訂單也成功，但增加積分失敗，此時(shí)，不應(yīng)回滾支付和訂單，而應(yīng)通過(guò)一些 補(bǔ)償方法 來(lái)讓積分得以正確地增加。后面會(huì)講到具體的實(shí)現(xiàn)方法。
在分享我們的分布式事務(wù)實(shí)踐方案之前，先看看早期解決分布式事務(wù)問(wèn)題的二階段提交協(xié)議。
X/Open DTP（Distributed Transaction Process）是一個(gè)分布式事務(wù)模型，此模型主要使用二階段提交（2PC，Two-Phase-Commit）來(lái)保證分布式事務(wù)的完整性。在這個(gè)模型里面，有三個(gè)角色：
AP：Application，應(yīng)用程序，業(yè)務(wù)層。
RM：Resource Manager，資源管理器，關(guān)系型數(shù)據(jù)庫(kù)或支持 XA 接口（XA 規(guī)范是 X/Open 組織定義的分布式事務(wù)規(guī)范）的組件。
TM： Transaction Manager ，事務(wù)管理器，負(fù)責(zé)各個(gè) RM 的提交和回滾。
當(dāng)應(yīng)用程序（AP）調(diào)用了事務(wù)管理器（TM）的提交方法時(shí)，事務(wù)的提交分為兩個(gè)階段實(shí)行。
TM 通知所有參與事務(wù)的各個(gè) RM，給每個(gè) RM 發(fā)送 prepare 消息。
RM 接收到消息后進(jìn)入準(zhǔn)備階段后，要么直接返回失敗，要么創(chuàng)建并執(zhí)行本地事務(wù)，寫本地事務(wù)日志（redo 和 undo 日志），但是 不提交（此處只保留最后一步耗時(shí)最少的提交操作給第二階段執(zhí)行）。
TM 收到 RM 準(zhǔn)備階段的失敗消息或者獲取 RM 返回消息超時(shí)，則直接給 RM 發(fā)送回滾（rollback）消息，否則發(fā)送提交（commit）消息。
RM 根據(jù) TM 的指令執(zhí)行提交或者回滾，執(zhí)行完成后釋放所有事務(wù)處理過(guò)程中使用的鎖（最后階段釋放鎖）。
優(yōu)點(diǎn)
2PC 提供了一套完整的分布式事務(wù)的解決方案，遵循事務(wù)嚴(yán)格的 ACID 特性。
缺點(diǎn)
TM 通過(guò) XA 接口與各個(gè) RM 之間進(jìn)行數(shù)據(jù)交互，從第一階段的準(zhǔn)備階段，業(yè)務(wù)所涉及的數(shù)據(jù)就被鎖定，并且鎖定跨越整個(gè)提交流程。在高并發(fā)和涉及業(yè)務(wù)模塊較多的情況下 對(duì)數(shù)據(jù)庫(kù)的性能影響較大。
二階段是 反可伸縮模式 的，業(yè)務(wù)規(guī)模越大，涉及模塊越多，局限性越大，系統(tǒng)可伸縮性越差。
在技術(shù)棧比較雜的分布式應(yīng)用中，存儲(chǔ)組件有很多 不支持 XA 協(xié)議。
二階段的諸多弊端，導(dǎo)致分布式系統(tǒng)下無(wú)法直接使用此方案來(lái)解決數(shù)據(jù)一致性問(wèn)題，但它提供了解決分布式系統(tǒng)下數(shù)據(jù)一致性問(wèn)題的思路。。
下面就通過(guò)案例來(lái)分享我們是如何保證微服務(wù)架構(gòu)的數(shù)據(jù)一致性的。
可靠消息最終一致性方案本質(zhì)上是 利用 MQ 組件實(shí)現(xiàn)的二階段提交。此方案涉及 3 個(gè)模塊：
上游應(yīng)用，執(zhí)行業(yè)務(wù)并發(fā)送 MQ 消息。
可靠消息服務(wù)和 MQ 消息組件，協(xié)調(diào)上下游消息的傳遞，并確保上下游數(shù)據(jù)的一致性。
下游應(yīng)用，監(jiān)聽(tīng) MQ 的消息并執(zhí)行自身業(yè)務(wù)。
上游應(yīng)用將本地業(yè)務(wù)執(zhí)行和消息發(fā)送綁定在同一個(gè)本地事務(wù)中，保證要么本地操作成功并發(fā)送 MQ 消息，要么兩步操作都失敗并回滾。
上游應(yīng)用和可靠消息之間的業(yè)務(wù)交互圖如下：
上游應(yīng)用發(fā)送待確認(rèn)消息到可靠消息系統(tǒng)
可靠消息系統(tǒng)保存待確認(rèn)消息并返回
上游應(yīng)用執(zhí)行本地業(yè)務(wù)
上游應(yīng)用通知可靠消息系統(tǒng)確認(rèn)業(yè)務(wù)已執(zhí)行并發(fā)送消息。
可靠消息系統(tǒng)修改消息狀態(tài)為發(fā)送狀態(tài)并將消息投遞到 MQ 中間件。
以上每一步都可能出現(xiàn)失敗情況，分析一下這 5 步出現(xiàn)異常后上游業(yè)務(wù)和消息發(fā)送是否一致：
上游應(yīng)用執(zhí)行完成，下游應(yīng)用尚未執(zhí)行或執(zhí)行失敗時(shí)，此事務(wù)即處于 BASE 理論的 Soft State 狀態(tài)。
下游應(yīng)用監(jiān)聽(tīng) MQ 消息并執(zhí)行業(yè)務(wù)，并且將消息的消費(fèi)結(jié)果通知可靠消息服務(wù)。
可靠消息的狀態(tài)需要和下游應(yīng)用的業(yè)務(wù)執(zhí)行保持一致，可靠消息狀態(tài)不是已完成時(shí)，確保下游應(yīng)用未執(zhí)行，可靠消息狀態(tài)是已完成時(shí)，確保下游應(yīng)用已執(zhí)行。
下游應(yīng)用和可靠消息服務(wù)之間的交互圖如下：
下游應(yīng)用監(jiān)聽(tīng) MQ 消息組件并獲取消息
下游應(yīng)用根據(jù) MQ 消息體信息處理本地業(yè)務(wù)
下游應(yīng)用向 MQ 組件自動(dòng)發(fā)送 ACK 確認(rèn)消息被消費(fèi)
下游應(yīng)用通知可靠消息系統(tǒng)消息被成功消費(fèi)，可靠消息將該消息狀態(tài)更改為已完成。
以上每一步都可能出現(xiàn)失敗情況，分析一下這 4 步出現(xiàn)異常后下游業(yè)務(wù)和消息狀態(tài)是否一致：
通過(guò)分析以上兩個(gè)階段可能失敗的情況，為了確保上下游數(shù)據(jù)的最終一致性，在可靠消息系統(tǒng)中，需要開(kāi)發(fā) 消息狀態(tài)確認(rèn) 和 消息重發(fā) 兩個(gè)功能以實(shí)現(xiàn) BASE 理論的 Eventually Consistent 特性。
可靠消息服務(wù)定時(shí)監(jiān)聽(tīng)消息的狀態(tài)，如果存在狀態(tài)為待確認(rèn)并且超時(shí)的消息，則表示上游應(yīng)用和可靠消息交互中的步驟 4 或者 5 出現(xiàn)異常。
可靠消息則攜帶消息體內(nèi)的信息向上游應(yīng)用發(fā)起請(qǐng)求查詢?cè)摌I(yè)務(wù)是否已執(zhí)行。上游應(yīng)用提供一個(gè)可查詢接口供可靠消息追溯業(yè)務(wù)執(zhí)行狀態(tài)，如果業(yè)務(wù)執(zhí)行成功則更改消息狀態(tài)為已發(fā)送，否則刪除此消息確保數(shù)據(jù)一致。具體流程如下：
可靠消息查詢超時(shí)的待確認(rèn)狀態(tài)的消息
向上游應(yīng)用查詢業(yè)務(wù)執(zhí)行的情況
業(yè)務(wù)未執(zhí)行，則刪除該消息，保證業(yè)務(wù)和可靠消息服務(wù)的一致性。業(yè)務(wù)已執(zhí)行，則修改消息狀態(tài)為已發(fā)送，并發(fā)送消息到 MQ 組件。
消息已發(fā)送則表示上游應(yīng)用已經(jīng)執(zhí)行，接下來(lái)則確保下游應(yīng)用也能正常執(zhí)行。
可靠消息服務(wù)發(fā)現(xiàn)可靠消息服務(wù)中存在消息狀態(tài)為已發(fā)送并且超時(shí)的消息，則表示可靠消息服務(wù)和下游應(yīng)用中存在異常的步驟，無(wú)論哪個(gè)步驟出現(xiàn)異常，可靠消息服務(wù)都將此消息重新投遞到 MQ 組件中供下游應(yīng)用監(jiān)聽(tīng)。
下游應(yīng)用監(jiān)聽(tīng)到此消息后，在保證冪等性的情況下重新執(zhí)行業(yè)務(wù)并通知可靠消息服務(wù)此消息已經(jīng)成功消費(fèi)，最終確保上游應(yīng)用、下游應(yīng)用的數(shù)據(jù)最終一致性。具體流程如下：
可靠消息服務(wù)定時(shí)查詢狀態(tài)為已發(fā)送并超時(shí)的消息
可靠消息將消息重新投遞到 MQ 組件中
下游應(yīng)用監(jiān)聽(tīng)消息，在滿足冪等性的條件下，重新執(zhí)行業(yè)務(wù)。
下游應(yīng)用通知可靠消息服務(wù)該消息已經(jīng)成功消費(fèi)。
通過(guò)消息狀態(tài)確認(rèn)和消息重發(fā)兩個(gè)功能，可以確保上游應(yīng)用、可靠消息服務(wù)和下游應(yīng)用數(shù)據(jù)的最終一致性。
當(dāng)然在實(shí)際接入過(guò)程中，需要引入 人工干預(yù) 功能。比如引入重發(fā)次數(shù)限制，超過(guò)重發(fā)次數(shù)限制的將消息修改為死亡消息，等待人工干預(yù)。
代入開(kāi)篇案例，通過(guò)可靠消息最終一致性方案，第一階段，訂單狀態(tài)更改之前，訂單服務(wù)向可靠消息服務(wù)請(qǐng)求保存待確認(rèn)消息?？煽肯⒎?wù)保存消息并返回。
訂單服務(wù)接收到返回信息后執(zhí)行本地業(yè)務(wù)并通知可靠消息服務(wù)業(yè)務(wù)已執(zhí)行。消息服務(wù)更改消息狀態(tài)并將消息投遞到 MQ 中間件。
第二階段，積分系統(tǒng)監(jiān)聽(tīng)到 MQ 消息，查看積分是否已增加，如果沒(méi)有增加則修改積分，然后請(qǐng)求可靠消息服務(wù)。可靠消息服務(wù)接收到積分系統(tǒng)的請(qǐng)求，將消息狀態(tài)更改為已完成。
到這里，已經(jīng)介紹完如何通過(guò)可靠消息服務(wù)來(lái)保證數(shù)據(jù)的一致性。但由于引入了可靠消息服務(wù)和消息隊(duì)列，帶來(lái)了一定的 復(fù)雜性，所以，它更 適用于跨平臺(tái)技術(shù)棧不統(tǒng)一的場(chǎng)景。
下面再來(lái)介紹在技術(shù)棧統(tǒng)一的情況下，如何通過(guò) TCC 來(lái)解決數(shù)據(jù)一致的方法。
TCC 方案是二階段提交的 另一種實(shí)現(xiàn)方式，它涉及 3 個(gè)模塊，主業(yè)務(wù)、從業(yè)務(wù) 和 活動(dòng)管理器（協(xié)作者）。
下面這張圖是互聯(lián)網(wǎng)上關(guān)于 TCC 比較經(jīng)典的圖示：
第一階段：主業(yè)務(wù)服務(wù)分別調(diào)用所有從業(yè)務(wù)服務(wù)的 try 操作，并在活動(dòng)管理器中記錄所有從業(yè)務(wù)服務(wù)。當(dāng)所有從業(yè)務(wù)服務(wù) try 成功或者某個(gè)從業(yè)務(wù)服務(wù) try 失敗時(shí)，進(jìn)入第二階段。
第二階段：活動(dòng)管理器根據(jù)第一階段從業(yè)務(wù)服務(wù)的 try 結(jié)果來(lái)執(zhí)行 confirm 或 cancel 操作。如果第一階段所有從業(yè)務(wù)服務(wù)都 try 成功，則協(xié)作者調(diào)用所有從業(yè)務(wù)服務(wù)的 confirm 操作，否則，調(diào)用所有從業(yè)務(wù)服務(wù)的 cancel 操作。
在第二階段中，confirm 和 cancel 同樣存在失敗情況，所以需要對(duì)這兩種情況做 異常處理 以保證數(shù)據(jù)一致性。
Confirm 失敗：則回滾所有 confirm 操作并執(zhí)行 cancel 操作。
Cancel 失敗：從業(yè)務(wù)服務(wù)需要提供自動(dòng) cancel 機(jī)制，以保證 cancel 成功。
目前有很多基于 RPC 的 TCC 框架，但是不適用于微服務(wù)架構(gòu)下基于 HTTP 協(xié)議的交互模式。我們這次只討論基于 HTTP 協(xié)議的 TCC 實(shí)現(xiàn)。具體的實(shí)現(xiàn)流程如下：
主業(yè)務(wù)服務(wù)調(diào)用從業(yè)務(wù)服務(wù)的 try 操作，并獲取 confirm/cancel 接口和超時(shí)時(shí)間。
如果從業(yè)務(wù)都 try 成功，主業(yè)務(wù)服務(wù)執(zhí)行本地業(yè)務(wù)，并將獲取的 confirm/cancel 接口發(fā)送給活動(dòng)管理器，活動(dòng)管理器會(huì)順序調(diào)用從業(yè)務(wù) 1 和從業(yè)務(wù) 2 的 confirm 接口并記錄請(qǐng)求狀態(tài)，如果請(qǐng)求成功，則通知主業(yè)務(wù)服務(wù)提交本地事務(wù)。如果 confirm 部分失敗，則活動(dòng)管理器會(huì)順序調(diào)用從業(yè)務(wù) 1 和從業(yè)務(wù) 2 的 cancel 接口來(lái)取消 try 的操作。
如果從業(yè)務(wù)部分或全部 try 失敗，則主業(yè)務(wù)直接回滾并結(jié)束，而 try 成功的從業(yè)務(wù)服務(wù)則通過(guò)定時(shí)任務(wù)來(lái)處理處于 try 完成但超時(shí)的數(shù)據(jù)，將這些數(shù)據(jù)做回滾處理保證主業(yè)務(wù)服務(wù)和從業(yè)務(wù)服務(wù)的數(shù)據(jù)一致。
代入開(kāi)篇提到的案例，通過(guò) TCC 方案，訂單服務(wù)在訂單狀態(tài)修改之前執(zhí)行預(yù)增積分操作（try），并從積分服務(wù)獲取 confirm/cancel 預(yù)增積分的請(qǐng)求地址。
如果預(yù)增積分（try）成功，則訂單服務(wù)更改訂單狀態(tài)并通知活動(dòng)管理器，活動(dòng)管理器請(qǐng)求積分模塊的 confirm 接口來(lái)增加積分。
如果預(yù)增積分（try）失敗，則訂單服務(wù)業(yè)務(wù)回滾。積分服務(wù)通過(guò)定時(shí)任務(wù)刪除預(yù)增積分（try）超時(shí)的數(shù)據(jù)。
另外如果活動(dòng)管理器調(diào)用積分服務(wù)的 confirm 接口失敗，則活動(dòng)管理器調(diào)用積分服務(wù) cancel 接口來(lái)取消預(yù)增積分，從而，保證訂單和積分?jǐn)?shù)據(jù)的最終一致性。
通過(guò)上面的對(duì)可靠消息服務(wù)和 TCC 方案的描述，我們 解決了技術(shù)棧一致和不一致的兩種情況下的數(shù)據(jù)一致性問(wèn)題。
但是，通常在這些核心業(yè)務(wù)上有 很多附加業(yè)務(wù)，比如當(dāng)用戶支付完成后，需要通過(guò)短信通知用戶支付成功。
這一類業(yè)務(wù)的成功或者失敗不會(huì)影響核心業(yè)務(wù)，甚至很多大型互聯(lián)網(wǎng)平臺(tái)在并高并發(fā)的情況下會(huì)主動(dòng)關(guān)閉這一類業(yè)務(wù)以保證核心業(yè)務(wù)的順利執(zhí)行。那么怎么處理這類情況呢，我們來(lái)看看最大努力通知方案。
最大努力通知方案涉及三個(gè)模塊：
上游應(yīng)用，發(fā)消息到 MQ 隊(duì)列。
下游應(yīng)用（例如短信服務(wù)、郵件服務(wù)），接受請(qǐng)求，并返回通知結(jié)果。
最大努力通知服務(wù)，監(jiān)聽(tīng)消息隊(duì)列，將消息存儲(chǔ)到數(shù)據(jù)庫(kù)中，并按照通知規(guī)則調(diào)用下游應(yīng)用的發(fā)送通知接口。
具體流程如下：
上游應(yīng)用發(fā)送 MQ 消息到 MQ 組件內(nèi)，消息內(nèi)包含通知規(guī)則和通知地址
最大努力通知服務(wù)監(jiān)聽(tīng)到 MQ 內(nèi)的消息，解析通知規(guī)則并放入延時(shí)隊(duì)列等待觸發(fā)通知
最大努力通知服務(wù)調(diào)用下游的通知地址，如果調(diào)用成功，則該消息標(biāo)記為通知成功，如果失敗則在滿足通知規(guī)則（例如 5 分鐘發(fā)一次，共發(fā)送 10 次）的情況下重新放入延時(shí)隊(duì)列等待下次觸發(fā)。
最大努力通知服務(wù)表示在 不影響主業(yè)務(wù) 的情況下，盡可能地確保數(shù)據(jù)的一致性。它需要開(kāi)發(fā)人員根據(jù)業(yè)務(wù)來(lái)指定通知規(guī)則，在滿足通知規(guī)則的前提下，盡可能的確保數(shù)據(jù)的一致，以盡到最大努力的目的。
根據(jù)不同的業(yè)務(wù)可以定制不同的通知規(guī)則，比如通知支付結(jié)果等相對(duì)嚴(yán)謹(jǐn)?shù)臉I(yè)務(wù)，可以將通知頻率設(shè)置高一些，通知時(shí)間長(zhǎng)一些，比如隔 5 分鐘通知一次，持續(xù)時(shí)間 1 小時(shí)。
如果不重要的業(yè)務(wù)，比如通知用戶積分增加，則可以將通知頻率設(shè)置低一些，時(shí)間短一些，比如 10 分鐘通知一次，持續(xù) 30 分鐘。
代入上面提到的支付成功短信通知用戶的案例，通過(guò)最大努力通知方案，當(dāng)支付成功后，將消息發(fā)送到 MQ 中間件，在消息中，定義發(fā)送規(guī)則為 5 分鐘一次，最大發(fā)送數(shù)為 10 次。
最大努力通知服務(wù)監(jiān)聽(tīng) MQ 消息并根據(jù)規(guī)則調(diào)用消息通知服務(wù)（短信服務(wù)）的消息發(fā)送接口，并記錄每次調(diào)用的日志信息。在通知成功或者已通知 10 次時(shí)，停止通知。
上面通過(guò)案例詳細(xì)介紹了我們解決微服務(wù)之間數(shù)據(jù)不一致問(wèn)題的三種方案，下面通過(guò)一張簡(jiǎn)單的對(duì)比圖，為大家選擇合適的解決方案提供簡(jiǎn)單依據(jù)。
小羊，青柳云架構(gòu)師，現(xiàn)服務(wù)于神州數(shù)碼青柳云團(tuán)隊(duì)，擅長(zhǎng)大型項(xiàng)目規(guī)劃、微服務(wù)架構(gòu)和分布式架構(gòu)。
蘇槐，微信號(hào) Sulaohuai，青柳云研發(fā)總監(jiān)，現(xiàn)服務(wù)于神州數(shù)碼青柳云團(tuán)隊(duì)，曾就職于 Oracle，新加坡電信等企業(yè)。擅長(zhǎng)容器技術(shù)、微服務(wù)架構(gòu)、敏捷開(kāi)發(fā)及技術(shù)管理。
下篇文章
下篇文章介紹如何 使用 Docker 來(lái)支撐微服務(wù)架構(gòu)部署及運(yùn)維。
點(diǎn)擊下方圖片即可閱讀
沈劍聊微服務(wù)：先做好你的服務(wù)拆分
聯(lián)系客服
