今天鐵人30天已經走了一半了!
沒想到我們還在討論Consistency與Availability的問題。就知道其實分散式系統最大的問題,便是在保持系統可用性的情況下,使用著讀取資料的一致性,這個tradeoff可以說佔了分散式系統一半以上的篇章,從這30天的內容你大概也可以理解(笑
我們前面針對Consistency,已經介紹了很多的方法,比方說Quorum System
、2PC\3PC
、Paxos
與Raft
,每一個都有一定的複雜性,因為要保持一致性必須考量各種可能發生錯誤的情境。今天我們來做一個小整理。
以下的內容整理自2009年的Transactions Across Datacenters演講,更推薦直接看影片了解。
首先我們直接看出自演講統整比較的一張圖
最基本的備份,就像手幾電腦一樣,每一次有更新就備份起來或是採用週期性備份。
這種架構下ㄧ般是指Passive Master-Slave架構,也就是讀寫請求皆由Master負責,然後再由Master將更新的資料同步到Slave身上。
這個通常就是指Leaderless的系統,每一個replica servers都可以進行讀寫,以前面提到的DynamoDB為例。
回想DynamoDB,使用Quorum system
,當讀的時候必須設定W/R參數來在Consistency/Availbility做取捨。發現有多個版本就必須Reconcile,你要有方法可以做serilaized,常見方法就是可以用Vector Clock
來做,選出一個最新的事件並且merge,很像git的branch與merge。前面提到的幾種做法是最典型常見的做法,當然還有很多其他的方法。
如果你今天的系統大到橫跨好幾個州與好幾個Datacenter,其中資料會被備份到別的Datacenter,一來可以做備份,二來可以讓使用者直接選擇較近的Datacenter做讀寫避免傳輸的latency。
但是也因此,兩個Datacenters的writes操作幾乎是獨立,你沒辦法保證這邊針對資料的writes不會互相影響到另一邊的writes,也就是說你雖然橫跨了好幾個Datacenters,反而 增加了global transaction的難度 。
也因此你會發現DynamoDB這樣的NoSQL DB沒辦法提供以前RDBMS那種等級的ACID Transaction。
不過Amazon也是不斷修正,在近期提供了Transaction操作,雖然有很一些限制,可以感覺是在他的設計底下做了一點workaround來提供transaction,可以去看看他們的文件確認一下這個等級的Transaction符不符合你的需求。
https://aws.amazon.com/tw/blogs/aws/new-amazon-dynamodb-transactions/
Quorum System
,因此不需要等待所有的Master執行完某個協定或是取的所有Master的Lock才能讀寫(W/R個數),所以也不差。Read-Repair
或是 Anti-Entropy
來同步資料到其他的Master上,但是同理,如果同步過程節點失效,則仍然有機會導致資料遺失。Quorum System
搭配 Hinted Handoff
在有Master失效時仍能正常運作。2PC
Coordinator與Participants失效的情境。這邊比較圖表示仍然可以Read-Write是建立於: 「2PC
執行完,就算有節點失效,且Transaction只發生在單一個DB上仍然可以運作。」,而非2PC中間發生失效問題。而Google當年在設計App Engine Datastore的時候,認為Eventual Consistency 在某些使用情境下不是一個很好的特性,因此朝向Strong Consistency設計,而2PC
最大的問題便是他的throughput實在是太低了,Coordinator和Participants必須一來一往兩次的訊息傳遞,已經是跨Datacenters的情況下,這個問題就變得非常嚴重,因此決定使用前面提到的Paxos
。每當他們的任何一個服務,要從一個state進入到下一個state,都會使用Paxos
在Datacenters間作協調。
另外仔細研究2PC
與Paxos
的過程,其實非常相似,甚至可以說Paxos
是優化了2PC
後得到的最佳解。最一開始都是由一個節點提出了Prepare,得到大家的回覆後,再進行下一輪的確認一致性。只是Paxos
考量了更多細節,比方說Proposers可以有很多個,並且使用Proposal Number來協調多個Proposers。
也因此Google Chubby
的作者 Mike Burrows (我們以後會提到他)說到:
"There is only one consensus protocol, and that's Paxos. Others are either Paxos, or Paxos with cruft, or broken." 多霸氣的發言XD
大家可以想想看Raft跟Paxos從本質上是否也是相似的呢?
回到第二篇的分散式系統的開始,我們希望將儲存的資料做replication儲存到多個servers上,來增加系統的Availability。而一個資料被複製到多個servers上,就會出現一致性的問題。而CAP理論
的誕生也宣告了沒有一個最佳的解決辦法,因此出現了各種情境應運而生的理論,也就生出這15天的內容。
原本以為寫一個總結的文章,可以輕鬆一點,結果也是一場硬仗...
如果對於到目前為止的整理有哪一個名詞
不熟悉的,就再回去前面看一下吧xD
Ref:
原文影片