閱讀目錄
這次准備開啟一個新的系列來寫了，聊聊分布式系統中的關注點。節奏不會排的太緊湊，計划兩周一更吧。
本文是本系列的第一篇。從普遍認為的分布式系統中最最最重要的數據一致性開始。內容適合人群>=0年技術相關經驗。
一、為什么需要分布式系統？
任何事物能夠被持續的運用和發展，必然有其價值，分布式系統也是一樣。分布式系統的產生我認為主要的目的就是“快”和“海量”。這個“快”可以分為兩個方面：
-
第一個是系統的處理速度快。
-
第二個是開發的速度快（歷時短）。
這2點本質都是相同的，把一個動作或者一件事情拆成兩部分或者多個部分去同時進行，使得整體的耗時縮短。比如：原本一件事情要一個人做的話要兩分鍾。那么我雇佣兩個人幫我各自做一部分，那么最理想情況下一分鍾就可以完成了。
當然這兩個方面中第二項從某種意義上來說是可以克服的，但是第一項是無法克服的。因為沒有一個程序或者說一台計算機，它的性能是無窮大的，如果有，那分布式系統也不會像現在這么普遍了（很多時候用錢能解決的問題都不是問題了）。
“海量”則是由於不存在無窮大的硬盤，所以我們需要把數據分別存儲到不同的硬盤上，才能滿足需求。這些硬盤可能在不同主機、不同機房、不同地域，未來可能會在不同的星球吧。
二、分布式系統的副作用
所謂每個事物都是矛盾統一的結合體，都具有兩面性。分布式系統再帶來了前面提到的好處的同時，也帶來了業界普遍認為最大的問題 —— 數據一致性問題。
系統是給人用的，構成使用場景的概念叫業務。業務是核心，對一個系統來說，業務的發展歸根到底是建立在數據之上的。我可以慢、可以宕機、可以搞得很復雜，這些都能忍，但唯獨不能忍的就是數據問題，數據錯誤、數據不一致等等。
分布式就意味着分治與協作，一件事一個人只負責一部分。生活中這樣的例子也無處不在，就拿舉辦一個Party來說：一部分人去准備吃的，一部分人去准備喝的，一部分人去准備場地布置。這些事情大家都可以同時進行，但是任一環節掉鏈子了，或者說不符合Party主題的話，都是失敗的。（不知道為什么，腦子里浮現的是一場發布會，大家喊着cheers，一口干了高腳杯里的二鍋頭。。。）。
再舉個電商場景中的程序案例：
這里的4個操作以目標來看，其實先后順序並不重要，重要的是要么都成功，要么都失敗，其中任意一個程序不一致那么就會出問題。這個問題本質上和人與人之間的溝通問題是類似的，之前寫過一篇文章也專門聊過溝通問題，有興趣的可以擴展閱讀下：《就簡單聊聊溝通效率問題》，上面的Party的例子也是這個道理。與溝通唯一的不同在於，對程序來說，不一定都要得到響應，都沒響應也是一致。當一個事情分成100個部分去做的時候，很可怕，從概率的角度來看，達到一致的概率是2/5050。
這里舉的程序例子並不是嚴謹，因為實際的分布式系統中因為除了“write”操作還有“read”操作，所以一致性問題比這個更復雜，后面會有更詳細的說明。
三、產生數據不一致的原因
那么是什么原因導致了數據不一致的產生呢？一是程序設計問題，或者說代碼寫錯了。這點很好理解，也很容易想到解決方案，多做測試，驗證是否符合預期咯。常見的單元測試、接口測試、自動化測試、集成測試等等都是為了更具性價比的將BUG降低到無限接近於0，也造就了“測試工程師”這個崗位更大的作用。
但是，假設真的沒有BUG，但還是會產生數據不一致，因為軟件是運行在硬件之上的，所以還有硬件的因素存在。並且對我們這里的大部分人來說，硬件相比軟件，我們的掌控力更弱。這其中，最為嚴重的屬網絡問題，網絡相比其它的來說是一個更大、更復雜的組織，未知性會隨着局域網、廣域網這樣范圍越大越嚴重。想象一下，每一台主機僅僅是一張大網中的一個渺小的連接點，它所承載的鏈接越多越容易出現問題。
可能有的小伙伴會有疑問，其它像硬盤、電源斷電什么的，也有出現問題的可能性，為什么網絡問題最為嚴重呢？其實硬盤、電源好比是你身體的一部分，如手和腳。而網絡是人與人之間溝通的渠道，比如手機通話，雖然你沒有主動掛斷電話，但是整個通話過程是有很多可能性導致中斷的，對方的主觀意願也好、信號不好也罷，甚至被第三者給攔截了。相信大家也能認可，打電話出現異常的概率相比自己的手腳不聽使喚是高很多的吧。
現實中網絡的特點，常遇到的問題如：延遲、丟包、亂序等問題。為了解決這些問題，從互聯網第一次出現的1969年（當年美軍在ARPA制定的協定下用網絡連接了4所大學）到現在，幾十年間出了很多的理論和解決方案，這些會在后續的文章中給大家一一做梳理。本文先和大家具體剖析下什么是一致性。
四、詳解一致性
首先什么叫達成一致了？說起來很簡單：
在任意時間、任意位置看到的同一個事物是完全一致的。
比如一場足球賽。我們不管在現場還是在電視機前，看到足球從球員A傳給球員B，這個信息都是一樣的。但是嚴格意義上來說，這個並稱不上真正的一致，因為電視機接收到這個信息需要經過衛星信號、網絡等的傳輸，我們看到的時候相比現場的人肯定要晚。哪怕在現場的人，根據他所處的位置理論上看到的信息也存在延遲差，只是因為光速非常快，使得在相差幾百米之內，這個延遲小到完全感受不到而已。
能得出的結論是：在考慮時間維度的情況下，不存在真正意義上的一致。
況且我們在分布式系統中，也沒有必要去達到真正的意義上的一致。因為越趨近於一致，系統相當於又歸一成一個單體了，在某一個時刻，只能做一件事，完全喪失了分布式系統的兩個目的之一“快”的優勢。也因此衍生出多種一致性的變種，分別適用於不同的場景。為了便於理解，我們從嚴格程度的低到高來說。
大多數情況下，為了盡可能的“快”，系統中使用的大部分方案都是所謂的最終一致性，也就容忍一定條件下的不一致，優先保證局部一致，然后再通過一系列復雜的狀態同步達到全局的一致。最終一致性很多可實現的分支，列出幾種常見的，拋磚引玉一下：
-
因果一致性：僅要求有因果關系的操作順序得到保證。比如朋友圈的回復功能。問“飯吃了嗎？”肯定得在回答“吃了”之前。
-
讀你所寫一致性：文字看着別扭，但很好解釋。比如你在朋友圈下面回復一句話，其它好友可以不用馬上看到你的回復，但是你自己必須得馬上看到，要不然回復到哪去了？
-
會話一致性：與人的一次聊天可以理解為一次會話。聊天雖然也有一定的因果關系，但是大部分場景下更多的是邏輯上的先后關系。比如你闡述一個事情，分為3條信息：首先...，然后...，最后...。如果這里的一致性得不到保證那么可能會變成：最后...，首先...，然后...。
比局部一致更嚴格一些的就是全局的順序一致性[附錄1,1979年提出]，保證所有進程看到的全局執行順序一致，並且每個進程自身的執行順序和實際發生順序一致。像上面提到的足球賽，比如實際發生的事情是①梅西把球傳給了C羅，②C羅又把球回傳給了梅西，那么每個人看到順序都應該是這樣。哪怕現場觀眾已經看到②了，電視機前的我們還沒看到①，但是沒關系，這個事情發生的順序，對全世界來說都是一樣的。
再嚴格一些，就是在全局的順序一致性基礎上再增加一個相對時間的一致性要求，業界稱之為線性一致性[附錄2,1990年提出]。還是用上面梅西和C羅相互傳球的例子來做個比喻，相當於梅西傳出球給C羅之后，整個球場“暫停”了，要等所有在觀看這場球賽的人都接收到這個傳球信息之后，C羅才能做下一個回傳。這里需要一個上帝（全局時鍾）來“暫停”。這是我們實際可以做到的極限了，滿足這類要求的系統中，名氣最大的就屬Google的Spanner了。
對不同級別的一致性匯總概述如下：
五、結語
這篇就到這吧，原本還想一次性寫完的，發現內容實在太多，上萬字的文章，估計很多人都沒有看下去的勇氣了。
如何解決一致性問題，且聽下回分解~
論文附錄：
[1]《How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs》,Leslie Lamport,1979。鏈接：http://research.microsoft.com/en-us/um/people/lamport/pubs/multi.pdf
[2] 《Linearizability：A Correctness Condition for Concurrent Objects》,Maurice P. Herlihy,Jeannette M. Wing, 1990。鏈接：http://cs.brown.edu/~mph/HerlihyW90/p463-herlihy.pdf
作者：Zachary
出處：https://zacharyfan.com/archives/356.html
▶關於作者：張帆（Zachary，個人微信號：Zachary-ZF）。堅持用心打磨每一篇高質量原創。歡迎掃描右側的二維碼~。
定期發表原創內容：架構設計丨分布式系統丨產品丨運營丨一些思考。
如果你是初級程序員，想提升但不知道如何下手。又或者做程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關注我的公眾號「跨界架構師」，回復「技術」，送你一份我長期收集和整理的思維導圖。
如果你是運營，面對不斷變化的市場束手無策。又或者想了解主流的運營策略，以豐富自己的“倉庫”。歡迎關注我的公眾號「跨界架構師」，回復「運營」，送你一份我長期收集和整理的思維導圖。