作為一名程序員，你是不是經常在很多場景，例如看博客、聊天吹水等等時候聽到這樣一個詞"系統數據一致性"，是不是有時候感覺到了迷糊，不知道這個"系統數據一致性"到底是在說什么？其實，你可能只是不明白這個詞，但是你肯定在實際工作中發現、解決過這樣的問題。

單體架構下系統數據一致性問題

在傳統的系統應用中，一般都是使用單體架構來構建系統的。即所有的功能模塊都放在一起實現，打成一個WAR包部署在Tomcat中，數據一般存放在關系型數據庫中，如MySQL數據庫。

前面我說過即使這種單體架構的系統也是數據一致性的問題的，舉一個電商下單的例子，用戶提交完訂單，系統，系統在訂單表order表中寫入訂單金額、用戶等相關數據，在訂單明細order_item表中寫入商品價格、購買的數量等數據，最后更新商品的庫存sku信息。用戶下單成功之后，系統操作了order、order_item、sku這三個數據表，對于這三個表的操作無論成功與失敗，都應該是原子的，操作成功則都要成功，失敗則都要一起失敗。不然就會出現臟數據，數據一致性被破壞。

1、如果操作order和order_item表成功，操作sku表失敗，則會導致本應該扣減的庫存沒有扣減，則商品有可能出現超賣。

2、如果操作order和order_item表失敗，操作sku表成功，則會導致本不應該扣減的庫存扣減了，則商品有可能出現少賣。

3、如果操作order和sku表成功，order_item操作失敗，則這個訂單數據丟失，訂單后續的操作肯定也是操作不了了。

上面只是簡單的舉了三種可能出現的情況，也可能會有其他的情況發生。那我們怎么避免這些情況的發生呢？其實這種問題稍微有的開發經驗的同學都會想到解決方案，那就是使用數據庫的事務，事務的原子性保證上述的步驟成功則一起成功，失敗則一起失敗。

BEGIN;
INSERT INTO order;
INSERT INTO order_item;
UPDATE sku;
COMMIT; # ROLLBACK

在單體架構的系統下解決內部模塊的數據一致性的問題，用數據庫的ACID特性就能保證。

單體架構的優點就是相對分布式來說開發簡單，功能可以集中管理，模塊之間通信沒有損耗。但隨著業務越來越復雜、需求越來越龐大，人們對系統響應時間、吞吐量和出現故障的時候的系統可用性的要求也越來越高！傳統的單體架構系統在這種情況下暴露的缺點也越來越多，人們開始尋求轉變。既然部署在一個服務器上的單體架構系統搞不定，那就多部署幾臺，即用多臺單機節點組成集群，再用負載均衡向外提供服務。

但是這樣做還是解決不了單體架構存在的一些問題：

只能使用同種語言開發，不能針對不同業務場景利用不同語言的優勢開發對應的模塊。
系統模塊耦合性太強，系統中某一個模塊出現問題，例如高并發、大數據場景或者出現bug，整個系統都會受到牽連。
某個模塊發布，整個系統都要停機發布，系統所有模塊都不能對外提供服務，這樣無法快速響應市場需求。
集群負擔大，如果想要集群，只能對整個系統進行集群，即使只有一個模塊有壓力。

集群(Cluster)：系統單機部署對外服務能力出現瓶頸，則將系統進行多機部署，這些系統對外提供相同的服務，每個單機系統我們稱之為節點，多個節點統一起來則可以稱之為集群。

分布式架構下系統數據一致性問題

天下大事分久必合、合久必分！既然單體架構解決不了問題，那我們就嘗試拆分系統，讓專業的人做專業的事，那如何進行拆分呢？拆分一般分為水平拆分和垂直拆分。這里說的拆分并不單指數據庫拆分，而是所有模塊都進行拆分，每個模塊都有自己的緩存、數據庫等等。

水平拆分指的是單一的節點無法滿足性能的需求，需要進行數量上的擴展。每一個節點都具有相同的功能，每一個節點都負責一部分請求，節點們組成一個集群，對外進行提供服務。
垂直拆分指的是按照功能進行拆分，秉著"專業的人干專業的事"，把復雜的系統拆分成各個模塊。模塊之間通過RPC進行通信，可以做到高內聚、低耦合，每個模塊獨立部署和維護，可以快速迭代響應市場需求。

因此，分布式架構在這種背景下應運而生。

分布式(Distributed)架構：分布式系統是由集中式系統逐漸演變而來。所謂的集中式系統，就是把系統中所用的功能都集中到一起，從而向外提供服務的單體應用。

軟件行業是沒有銀彈的，每一個被發明出來的新技術，都是一把雙刃劍，都是在特定的領域解決了某些老問題，但是同時也會帶來新的問題。那么微服務這種分布式架構解決了什么老問題？同時它又帶來了哪些新問題呢？

解決了老問題

微服務這種分布式架構主要解決了單體架構存在的一些問題。

各個服務可以使用不同的語言開發，可以利用不同語言的優勢開發不同模塊。
服務之間可以做到高內聚、低耦合。每個服務可以獨立維護、部署，可以快速響應市場需求。
可以單獨對某個有高并發、大流量的服務單獨進行優化，不浪費資源。

帶來了新問題

系統的監控難度加大。
數據的一致性成為問題。
系統的復雜度提高，系統的維護、設計成本增加，調試、糾錯難度加大。

新問題中的數據一致性問題才是本文接下來的重點。

為啥會有這個數據一致性問題呢？

單體架構按照文中的說法，是一種不太時髦的架構方式，都能輕松解決數據一致性問題，新發明的分布式架構卻又成了一個棘手的問題，這個到底是技術的進步還是技術在退步呢？哈哈(我的一點點吐槽)！！接下來我來解釋一下為啥分布式系統會有這樣的問題。分布式系統每個功能大都部署在不同的服務器上，部署在不同國家和地區的服務器中，部署在不同的網絡中，部署在不同國家和地區的網絡中。這樣一個需要大量的服務器共同協作，向外提供服務的系統，面臨著諸多的挑戰：

良莠不齊的服務器和系統能力

分布式系統中的服務器，可能配置不一樣，其上部署的系統可能也是由不同的程序語言、架構實現，因此處理請求的能力也就不一樣。

不可靠的網絡

如上文所說，系統中各個服務可能部署在不同國家和地區，各個服務通過網絡進行通信，但是網絡是不可靠的。網絡經常會出現抖動、延時、分割、丟包等問題。網絡通信中最讓人頭痛的是因為網絡抖動、延時等問題導致系統之間的通信出現超時：A服務向B服務發出請求，A服務沒有在約定的時間內接受到B服務的響應，你不能確定B服務到底有沒有處理完A服務的請求，這樣的不確定性就需要我們進行重試處理，那么B服務就要解決請求冪等性問題。

服務器的機房發生火災、斷電等事故。支付寶出現過服務器的電纜被挖斷的問題。

普遍存在的單點故障

分布式系統為了保證故障發生的時候，系統仍然保證可用，每個模塊都采用集群部署。單個節點的故障概率較低，但是節點數量達到一定規模時，系統中的節點出現故障的概率可能就變高了。

分布式系統就是這樣一些處在不同區域、有著不同能力和擁有單一功能的服務組成，他們通力合作才能向外提供服務，那如何保證他們的狀態、信息一致并且協調有序就成了一個難題。

分布式系統就是要解決解決集中式的單體架構系統的各種缺陷，實現整個系統的高性能、高可用、可擴展,但是要實現這三個目標并不容易，將系統進行拆分的過程中會出現上文中說到的問題，為了解決這些問題，誕生了很多關于分布式的基本理論，比如CAP、BASE等等。

分布式架構有很多相關的理論和算法，這里我只說了CAP、BASE理論，其他諸如Paxos算法、Raft算法、ZAB協議等等，這些大家自己找資料看看吧！

我們先來說說CAP理論

這個CAP理論相信很多人都聽說過，下面請允許我寫下教科書般的理論內容：

CAP原則又稱CAP定理，指的是在一個分布式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。

一致性（C）：在分布式系統中的所有數據備份，在同一時刻是否同樣的值，也就是等同于所有節點訪問同一份最新的數據副本。可用性（A）：保證每個請求不管成功或者失敗都有響應，即使數據不是最新的。分區容忍性（P）：系統中的某個節點或者網絡分區出現了故障的時候，整個系統仍然能對外提供的服務。

什么情況？這個CAP理論上來就給出三個概念或者說是指標，還說分布式系統只能滿足上面兩個指標。大家是不是經常聽到CAP理論，但是卻又不是很理解為什么CAP三個指標只能滿足其中的兩個，那么接下來我給大家解釋一下：

就如前面的“分布式架構圖”展示的一樣，系統一個對外的服務涉及到多個節點通訊和交互，節點所處的網絡發生分區故障的問題又無法避免，所以分布式系統中分區容錯性必須要考慮，那么系統自然也不可能同時滿足上面說的三個指標。

分布式系統中CAP如何抉擇？

在分布式系統內，各種因素導致分區是必然的會發生的，不考慮分區容忍性（P），一旦發生分區錯誤，整個分布式系統就完全無法使用了，這其實和最開始的單體應用一樣有單點問題，這樣的系統是和分布式架構理論是相違背的，同時也是不符合實際需要的。所以，對于分布式系統，我們只能能考慮當發生分區錯誤時，如何選擇一致性（C）和可用性（A）。

根據一致性和可用性的選擇不同，開源的分布式系統往往又被分為 CP 系統和 AP 系統。當系統在發生分區故障后，客戶端的任何請求都被阻塞或者超時，但是，系統的每個節點總是會返回一致的數據，則這樣的系統就是 CP 系統，經典的比如 Zookeeper。當系統發生分區故障后，客戶端依然可以訪問系統，但是獲取的數據是不一致的，有的是新的數據，有的還是老數據，那么這樣系統就是 AP 系統，經典的比如 Eureka。

前面說分布式系統不考慮分區容忍性（P）為啥分區錯誤發生，系統就不能用了，這里我再解釋一下：不考慮分區容忍性（P），那就是選擇CA。假設發生了分區錯誤，系統由于可用性（A）的要求，即使系統發生分區故障也要提供服務，那系統就仍然向外提供服務，因為服務肯定的包含對數據的讀取、寫入、更新、刪除，可是由于一致性（C）的要求，系統中所有的節點數據都要保持一致，因為分區錯誤發生，節點的數據同步肯定無法進行，數據副本的一致性就無法保證，那就不能像對外提供服務。那這樣CA就相互矛盾，系統無法保證可用性（A）和一致性（C），系統自然是不能使用了，也就是說沒有選擇CA的分布式系統，而且這分區容忍性（P）必須要考慮！而且，不是一個系統選擇了可用性（A）或者一致性（C），可以是其中的模塊選擇了可用性（A）和一致性（C）

Zookeeper常常有人用它作為dubbo的注冊中心，Eureka作為Spring Cloud體系中的注冊中心，其實對于注冊中心角色來說，我覺得Eureka比Zookeeper更適合！

還有一點這里我說一下，其實大部分情況下分布式系統是沒有問題的，C和A兩個指標都是同時滿足的，只是在分區問題發生的情況下，才需要我們考慮到底是選擇C還是A。

前文說到解決單點故障的問題，我們引入了集群。在分布式系統中我們為了提高系統的可用性，也是不可避免的使用副本的機制，引入了副本則就需要同步數據到不同的副本，從而引發了副本一致性的問題。就如前面展示的“分布式架構圖”中，會員、訂單和產品服務都是獨立部署且分別使用不同的數據庫，每個服務內部又是使用數據庫集群，數據在服務與服務之間、在某個服務的數據庫集群中間等等的流轉、同步，這些過程都是有網絡、時間消耗的，一個數據從最開始的產生到它應該到的地方不會瞬時完成，而CAP理論是基于瞬時，在同一時刻任意節點都保持著最新的數據副本，它是忽略網絡延遲、節點處理數據的速度的，這個在目前的技術下是不可能做到的，從這個角度來看，CAP理論實在是樂觀主義了。

CAP理論的缺點是什么？

CAP理論其實是有缺點的，前文也提到一些，具體的缺點如下：

理論忽略網絡延遲、節點處理數據的速度

CAP的理論的作者布魯爾在定義一致性時，并沒有將上述的問題考慮進去。即當事務提交之后，數據能夠瞬間復制到所有節點。但實際情況下，數據從產生到復制到各個服務、各個節點，總是需要花費一定時間的。如果在相同機房可能是幾毫秒，如果跨地域、跨機房，可能是幾十毫秒甚至是一百多毫秒。這也就是說，CAP理論中的C在實踐中是不可能完美實現的，在數據副本的同步的過程中，節點之間的數據在一個短時間內并不一致。

理論中的一致性是強一致性

CAP理論中的一致性的概念是，在分布式系統中的所有數據備份，在同一時刻是否同樣的值，也就是等同于所有節點訪問同一份最新的數據副本。在某些場景下這種強一致性要求并不是那么高。在一個日志搜集系統，在高并發、大數據的情況下，一條日志寫入需要稍后一會才能在ELK中展示出來，這樣是沒有問題的。通過犧牲強一致性獲得可用性，在一定時間之后最終數據達成一致性即可。

理論中的指標的選擇和放棄并不是三選二的關系

CAP理論告訴我們三者只能取兩個，需要放棄另外一個，這里的放棄是有一定誤導作用的，因為“放棄”讓很多人理解成什么也不做。實際上，CAP理論的“放棄”只是說在系統分區錯誤過程中，我們無法同時保證C和A，但并不意味著什么都不做。分區期間放棄C或者A，并不意味著永遠放棄C和A，我們可以在分區期間進行一些操作，從而讓分區故障解決后，系統能夠重新達到CA的狀態。最典型的就是主從數據庫中主數據掛了，后面進行修復，使得重新達到CA狀態。

CAP理論的改進版BASE理論

由于CAP理論在定義時過于的樂觀，導致他有些缺陷，于是又有大神改進了CAP理論，從而引申出理論改進版本：BASE理論。eBay的架構師Dan Pritchett根據他自身在大規模分布式系統的實踐經驗，提出了BASE理論。BASE理論是對CAP理論的延伸和補充，它滿足CAP理論，通過犧牲強一致性獲得可用性，在一定的時間窗口內，達到數據的最終一致性。

BASE理論模型包含如下三個元素：

BA：Basically Available，基本可用。
S：Soft State,軟狀態，狀態可以在一定時間內不同步。
E：Eventually Consistent，最終一致性，在一定的時間窗口內，最終數據達成一致即可。

Basically Available 基本可用

BASE理論中的Basically Available 基本可用，就是系統在出現問題的時候，犧牲一部分的功能，來保障核心功能正常。這其實就是一種妥協，相當于壁虎斷臂求生。就像前幾年的雙十一淘寶，訂單支付、退款直接崩掉了，后面就進行改進限流需要你多試幾次才能付款、退款，再后來雙十一那幾天是不能申請退款的，直接就把你這個功能給關閉了，相當于服務熔斷了。這就是犧牲非核心的功能，將所有的資源都用來保障核心的支付功能。

Soft State,軟狀態

允許系統在一定時間內的狀態不同步，允許系統處于軟狀態，這個軟狀態其實就是中間狀態。比如采用分布式架構的電商系統，用戶下單完成并付款，是否支付成功，是支付系統完成的，訂單系統不會等支付系統返回是否支付成功再把結果返回給客戶的，而是先把訂單狀態設置為付款中，返回給客戶，然后支付系統收到異步通知確定支付成功成功，再把狀態設置為付款完成，再把付款完成信息推送給訂單系統。這樣，就可以提高系統的響應速度。即使這支付系統出現故障宕機了，系統重啟之后可以通過定時任務補償處理未完成的數據，然后根據數據所處的狀態進行補償處理，最終完成數據處理。付款中這個狀態，就是軟狀態即中間狀態。

Eventually Consistent，最終一致性

數據不會一直處在中間狀態，就如上面的例子所說，處于中間狀態的數據會有采用類似定時任務一樣的補償處理，將數據修復成正確的狀態，最終數據達成一致。

重說“帶來了新問題”

前文說到分布式架構解決了單體架構的一些問題，但是同時也帶來了一些新的問題，這里我們著重說一下，本來不是大問題的“數據一致性”問題。前面舉了一個電商系統中的經典案例：下訂單與扣庫存。單體架構的應用我們直接用數據庫事務的ACID特性就可解決，但是采用分布式架構的系統就沒有那么好解決了，我們先說一下在分布式架構下的系統是如何完成“下訂單與扣庫存”的，這里就不畫圖了直接用偽代碼來展示：

public void buildOrder(OrderDto orderDto) {
  
  // 1.保存訂單
  orderService.saveOrder(orderDto);
  // 2.扣除產品庫存
  inventoryService.deductInventory(orderDto);
}

這步驟一保存訂單是在訂單系統中執行，步驟二扣除產品庫存是在庫存系統執行，這個下訂單與扣庫存兩個步驟分別涉及到了兩個系統，使用RPC的方式和兩個系統進行交互。由于這兩個步驟不是原子的，不能保持一致的話會導致很多的問題：