作者 | bdseeker
來源 | BigData之路（ID:bigdata3186）
頭圖 | CSDN 下載自視覺中國
前言
上一篇《CAP》寫完之后，我又反復回看了多次，發現最后的一部分表達CAP、ACID、BASE、“BACP(自造)”關系時有一些問題，并且不是很嚴謹，但是無奈已經發送過的內容，無法支持修改，并且有挺多小伙伴都在私聊我確認細節，這里我來重新更新下，直接上圖！
也有一部分小伙伴跟我說覺得CAP有點冷門，建議我換點大眾能接受的，其實我也不得不承認，大家可能更喜歡具體的技術棧。但我從個人視角來說，這些大數據的基礎知識非常重要。等我寫完大數據基礎系列，會逐漸開始轉戰具體技術棧，莫急！大數據之路很長，我們慢慢走。就像我每篇文章里都會提到的，相信堅持總會有所收獲。
話不多說，進入正題，在很多小伙伴認知里或多或少都知道那么兩三種一致性，比如強一致性、最終一致性等。但是你以為一致性只有這些嘛？本篇帶來一致性詳解，講透一致性。歡迎大家指正～
強一致性
一致性大家庭中，雖然細分種類很多，但是實際上只有兩大類，其中之一就是上篇《CAP》中我們已經介紹過的強一致性，其具體包含了嚴格一致性(也叫原子一致性或者線性一致性)和順序一致性。
1、嚴格(原子/線性)一致性
嚴格一致性代表著，當數據更新后，所有Client的讀寫都是在數據更新的基礎上。如下圖所示，我們假設每份數據有三個副本，分別落到三個節點上。當Client1嘗試將X的值置為1時，嚴格一致性要求當Client1完成更新操作以后，所有Client都要在最新值的基礎上進行讀寫，這里的Client10讀取到的值是x=1，在同一時刻Client100的更新操作也是在x=1的基礎上進行x+=1操作，在下一個時刻Client1000讀到的任意一個副本，X的值都會是2。
此時你會發現一切似乎都是很完美的。但是仔細想想，嚴格一致性的背后有什么潛臺詞呢？
數據同步復制
嚴格一致性代表著，所有數據在寫入操作的時候是同步復制的，即寫多副本都成功，才算寫入成功，HDFS是不是就是最好的例子。并且具有原子性，對于寫入操作來說，結果要么寫成功，要么寫失敗，不存在中間狀態。這也是為什么稱為原子一致性的原因。
嚴格一致性不考慮客戶端
在網上有很多人在解釋一致性時，嘗試從客戶端和服務端分別解析；但是在上一篇我們分析CAP的時候，也有提到不要帶Client玩，那么究竟誰對誰錯呢？
這里我們再來看下，在考慮分布式系統的一致性時我們更關注什么？是多個Client發送讀寫請求到達后端的時間和先后順序嘛？不，我們真正關注的是每個請求，對應服務端完成時間點的先后順序。還是參考上面的例子，Client1000讀取到x=2這個結果，實際上是以Client100這個寫操作完成為基礎的，如果Client100寫操作一直不完成，那么強一致性要求Client1000讀取到的X是1而不是2。因此我們更需要關注的是完成操作的具體時間點，而不是操作發起的時間點，對于一致性來說考慮Client的意義就不大了。當然在同一時刻多個Client操作的冪等性還是一定要保證的。
換個角度，Client才是一致性需求的甲方，不是嘛。而分布式系統端作為乙方，只能滿足甲方需求，或者拒絕甲方需求，而不是要求甲方作出任何改變！
基于嚴格的全局時鐘
上面我們提到操作行為完成時間點的順序是十分重要的。再仔細看一下上面舉例的內容，相信你會發現一切的行為都在時間這個維度上，行為順序是：Client1更新x=1 -> Client10讀取x=1/Client100在x=1的基礎上更新x+=1 -> Client1000讀取x=2。所以每個操作都是在前一個操作完成的基礎上進行的，在分布式服務中，需要有一個基準時間來衡量每個操作行為的順序。此時你會問了，機器上不是都有NTP做時間校準嘛？現在的問題就是無法保證每一臺機器的時間都是絕對相同的。
舉個例子，數據D2所在的節點相比D1節點時間提前了幾秒，當Client1的更新請求完成后(用時500ms)，Client10的請求開始執行并完成，如果將機器時間作為基準就會發現Client10的讀取操作竟然在Client1的更新操作之前，這顯然是違背強一致性的。
我們一般我們會如何保證全局時鐘？這里簡單聊聊三種種常見解法。
混合邏輯時鐘 Hybrid Logic Clock
在混合邏輯時鐘中同時比較了節點本地的物理時間、邏輯時間和其他節點發送消息中的物理時間。kudu和Cockroachdb也都是使用的這個方法，HLC雖然加上了物理時間，但是仍然強依賴于機器的NTP，并不是嚴格意義上精確的時鐘，在HLC中需要為時鐘定義一個邊界，比如kudu中定義了maximum check error(最大時鐘錯誤)，如果本地NTP沒啟動，kudu在啟動的時候就直接失敗了；如果誤差超過了maximum check error，依舊會報錯，這也就意味著當超過HLC所設定的偏差邊界，HLC就不能正常工作了。
在看HLC的實現邏輯時，發現步驟比較多，邏輯時間存在的意義就是在時間比對時，當作中間值或者備份值。這里由于不是本篇重點，不再贅述了，感興趣的小伙伴可以看下論文：https://cse.buffalo.edu/tech-reports/2014-04.pdf。
True Time
上一篇文章中也有講到，谷歌依賴強大的基建實力降低了網絡分區發生的概率，而面全局時鐘問題，google的Spanner采用的是GPS + Atomic Clock(原子時鐘的含義可以百度一下)這種純硬件方式來對集群的機器進行校時，其精度在ms級別，這里我們用ε來表示時間精度的誤差，時間的精度誤差的范圍也就是[t-ε,t+ε]這個范圍之間。此時回到上面的操作中，按照此種方式Client10的機器時間相比Client1的機器時間最多提前或者滯后2個ε的時間，因此Spanner引入了commit wait time這個方案，說白了就是操作執行完成后多等一會，等過了這個精度誤差的范圍自然就全局有序了，Google將精度誤差控制在幾ms級別，當然對于Spanner這種全球性、跨地域的分布式系統來說，多等個幾ms問題也不大。
但很遺憾，Google的這套硬件解決方案，并沒有開源出來，適用性有限，我們就望梅止渴吧。
授時中心 TimeStamp Oracle
在生活中也有”授時中心“的存在，貌似在陜西，具體位置可以查查，他的作用是什么呢？為中國各種基建、系統提供了一個準確的時間，避免誤差。（個人YY：萬一打起仗，總不能因為其他國家干擾了基準時間，咱們所有基建就癱瘓吧，因此授時中心的意義巨大。）
在分布式服務中，實際上也有類似的方案。這里以Tidb舉例，Tidb為了校準時間，就是采用了TSO這個方案，對于Tidb來說所有行為事件統一由PD節點分配時間，雖然這種方案會產生非常高頻的互相調用，但是按照Tidb官方介紹，在同IDC網絡環境下網絡傳輸開銷非常低，只有0.xms。當然如果面對跨IDC的網絡，就可以嘗試將PD節點和Tidb節點混部(Tikv依然需要獨立部署，為的是存儲計算分離)。這就不需要走網絡的開銷了，當然如果是Client端跨IDC的話，還是沒有太好的方法。
2、順序一致性
上面我們說到了嚴格一致性(線性/原子)，想做到全局時鐘下的全局絕對有序是有難度的，HLC實現比較復雜，谷歌的原子鐘+GPS又沒有開源出來，TSO又增加了系統的復雜度。想實現全局時鐘好難！
這里我們是否可以退一步，舍棄“時間”這個有序的計數器，嘗試構造一個更好維護的計數器，不保證全局行為絕對有序，只保證分布式服務全局相對有序？
如下圖所示，D1先后更新了x=1，x=2，D3先后更新了a=1，a=2。當Client讀取到D2節點時，按照順序一致性要求，所有節點的操作相對順序都是相同的，一定是x=1在x=2之前，a=1在a=2之前，下圖舉例的是順序一致性的其中一種情況。
邏輯時鐘 Logic Clock
邏輯時鐘Logic Clock，這個名字你陌生的話，或許他的另一個名字Lamport Timestamp會讓你浮想連連，如果你還是沒啥印象的話，那么Paxos你是否知道呢？（如果做大數據的你不知道paxos，那你需要好好補習下基礎了
