不知道是不是最通俗易懂的《資料一致性》剖析了
這次準備開啟一個新的系列來寫了,聊聊分散式系統中的關注點。節奏不會排的太緊湊,計劃兩週一更吧。
本文是本系列的第一篇。從普遍認為的分散式系統中最最最重要的資料一致性開始。內容適合人群>=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。連結:
[2] 《Linearizability:A Correctness Condition for Concurrent Objects》,Maurice P. Herlihy,Jeannette M. Wing, 1990。連結: ~mph/HerlihyW90/p463-herlihy.pdf
作者: Zachary_Fan
出處: https://www.cnblogs.com/Zachary-Fan/p/consistency1.html
覺得回答的不錯就點個【 推薦 】吧~
歡迎掃描下面的二維碼,關注公眾號:跨界架構師,第一時間瞭解作者的思考。
內容包括: 架構設計丨分散式系統丨產品丨運營丨一些深度思考 。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31544142/viewspace-2199901/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 快取與資料庫一致性問題深度剖析快取資料庫
- 為了更好的運營,我剖析了某公眾號的資料
- 我畫了13張圖,用最通俗易懂的話講HTTPS,拿下!HTTP
- 全網最通俗易懂的Kafka入門Kafka
- 最通俗易懂搞定HashMap的底層原理HashMap
- 全網最通俗易懂的Kafka入門!Kafka
- 深度剖析 | 關於資料鎖定和讀取一致性問題
- 圖資料庫|正反向邊的最終一致性——TOSS 介紹資料庫
- MySQL半同步複製資料最終一致性驗證MySql
- cassandra最終一致性相關演算法資料結構演算法資料結構
- 圖解一致性雜湊演算法,全網(小區區域網)最通俗易懂圖解演算法
- 這個mysql資料庫是不是崩潰了啊?請高手指點。MySql資料庫
- 機器學習梯度下降法,最通俗易懂的解釋機器學習梯度
- 這可能是掘金講「原型鏈」,講的最好最通俗易懂的了,附練習題!原型
- RocketMQ系列(七)事務訊息(資料庫|最終一致性)MQ資料庫
- 剖析大資料平臺的資料處理大資料
- 提醒一下技術人,你是不是陷入區域性最優了
- 通俗易懂的Redis資料結構基礎教程Redis資料結構
- 通俗易懂的資料庫三正規化資料庫
- 全網最通俗易懂的【短連結】入門
- 通俗易懂剖析Go Channel:理解併發通訊的核心機制Go
- 資料一致性
- 5000條中醫器械消費資料,剖析5大最火養生神器
- Vue.js原始碼角度:剖析模版和資料渲染成最終的DOM的過程Vue.js原始碼
- ITPUB 的BLOG 是不是出問題了?
- 林三心畫了8張圖,最通俗易懂的Vue3響應式核心原理解析Vue
- 最通俗易懂的解讀比特幣相關原理比特幣
- Promise不會??看這裡!!!史上最通俗易懂的Promise!!!Promise
- 史上最通俗易懂的Android Dagger入門教程Android
- 最通俗易懂的 Swift 函數語言程式設計Swift函數程式設計
- Redis和資料庫的資料一致性問題Redis資料庫
- 資料塊原理深入剖析
- 訊息最終一致性最易用的新架構架構
- 剖析後OpLog訂閱MongoDB的資料變更就沒那麼難了MongoDB
- 如何校驗記憶體資料的一致性,DynamicExpresso 算是幫上大忙了記憶體Express
- MySQL資料一致性MySql
- Redis與資料庫資料一致性Redis資料庫
- 深入剖析分散式事務一致性分散式