iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 15
1

前言

今天鐵人30天已經走了一半了!
沒想到我們還在討論ConsistencyAvailability的問題。就知道其實分散式系統最大的問題,便是在保持系統可用性的情況下,使用著讀取資料的一致性,這個tradeoff可以說佔了分散式系統一半以上的篇章,從這30天的內容你大概也可以理解(笑

我們前面針對Consistency,已經介紹了很多的方法,比方說Quorum System2PC\3PCPaxosRaft,每一個都有一定的複雜性,因為要保持一致性必須考量各種可能發生錯誤的情境。今天我們來做一個小整理。

以下的內容整理自2009年的Transactions Across Datacenters演講,更推薦直接看影片了解。

整理

首先我們直接看出自演講統整比較的一張圖

Backups

最基本的備份,就像手幾電腦一樣,每一次有更新就備份起來或是採用週期性備份。

  • Transaction/Consistency: 備份的過程中可能有別的client又更新了資料,因為這個過程並沒有引入什麼協定(E.g. 2PC),此時備份的資料跟系統上的資料是不一樣的,沒辦法全程保持一致。
  • Latency/Throuput: 當然是最好,因為只有一個系統在運作其他是做備份,所以讀寫時不用跑協定,相較於2PC/Paxos要先執行演算法做一致性處理,這邊的效能較好。
  • Data loss: 這邊要說明的是當系統在備份的時候,備份到一半系統失效,則備份系統也還沒備份到,因此會遺失最新的資料,只有前一次備份的snapshot。
  • Failover: 這邊說的是,對於Google來說,如果他一個Datacenter失效,利用將Backup資料搬到另一個Datacenter來做恢復的這段期間系統是不能運作的。

Master-Slave

這種架構下ㄧ般是指Passive Master-Slave架構,也就是讀寫請求皆由Master負責,然後再由Master將更新的資料同步到Slave身上。

  • Transaction/Consistency: 因為讀寫由Master負責,因此Transaction可以完成,連2PC都不用。另外,因為是由Master push資料到Slave身上,或是Slave主動pull資料來做同步,因此slave身上的資料可能不會一直保持一致,這邊的Consistency為Eventual Consistency。
  • Latency/Throuput: 因為讀寫由Master負責,不需等待同步,所以效能也不差。
  • Data loss: 如果Master在同步資料到Slave上時失效,可能造成最新的資料遺失。
  • Failover: 如果Master在同步資料到Slave上時失效
    • 一種做法是讓Slave成為新的Master提供讀寫,則前一個Master最新的資料可能就真的遺失
    • 也可以是等待Master回覆,Slave這時只能提供Read-Only服務

Master-Master

這個通常就是指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/

  • Transaction/Consistency: Transaction可以看Amaozon怎麼在Dynamo實作Transaction,可以做到,但是有限制,一般來說只能在Local的這個Master先實作Transaction在同步到其他的Master。Consistency就像之前提到的是Eventual Consistency
  • Latency/Throuput: 採用Quorum System,因此不需要等待所有的Master執行完某個協定或是取的所有Master的Lock才能讀寫(W/R個數),所以也不差。
  • Data loss: 就像之前提到的使用 Read-Repair 或是 Anti-Entropy 來同步資料到其他的Master上,但是同理,如果同步過程節點失效,則仍然有機會導致資料遺失。
  • Failover: Quorum System 搭配 Hinted Handoff 在有Master失效時仍能正常運作。

2PC

  • Transaction/Consistency: Strong Consistency 且本來就是為了 Transaction 而生的。
  • Latency/Throuput: 很差
  • Data loss: 寫入成功則資料會一致且不會丟失,要不就一開始就2PC失敗導致寫入失敗。
  • Failover: 這邊可以參考之前提到的2PC CoordinatorParticipants失效的情境。這邊比較圖表示仍然可以Read-Write是建立於: 「2PC執行完,就算有節點失效,且Transaction只發生在單一個DB上仍然可以運作。」,而非2PC中間發生失效問題。

Paxos

而Google當年在設計App Engine Datastore的時候,認為Eventual Consistency 在某些使用情境下不是一個很好的特性,因此朝向Strong Consistency設計,而2PC最大的問題便是他的throughput實在是太低了,CoordinatorParticipants必須一來一往兩次的訊息傳遞,已經是跨Datacenters的情況下,這個問題就變得非常嚴重,因此決定使用前面提到的Paxos。每當他們的任何一個服務,要從一個state進入到下一個state,都會使用Paxos在Datacenters間作協調。

另外仔細研究2PCPaxos的過程,其實非常相似,甚至可以說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

  • Transaction/Consistency: Strong Consistency 是一個完整的共識演算法流程,可以拿來在Transaction做協調,保證最終對於v值是一致的。
  • Latency/Throuput: 只要保證半數達成一致,則一致性已經完成。
  • Data loss: 寫入(commited)成功則資料會一致且不會丟失,要不就一就Paxos失敗導致寫入失敗。
  • Failover: 只要還有過半數的節點存活就可以執行Paxos演算法,提供讀寫。

大家可以想想看Raft跟Paxos從本質上是否也是相似的呢?

總結

回到第二篇的分散式系統的開始,我們希望將儲存的資料做replication儲存到多個servers上,來增加系統的Availability。而一個資料被複製到多個servers上,就會出現一致性的問題。而CAP理論的誕生也宣告了沒有一個最佳的解決辦法,因此出現了各種情境應運而生的理論,也就生出這15天的內容。

原本以為寫一個總結的文章,可以輕鬆一點,結果也是一場硬仗...

如果對於到目前為止的整理有哪一個名詞不熟悉的,就再回去前面看一下吧xD

Ref:
原文影片

  1. Transactions Across Datacenters 投影片
  2. 一樣是做總結的文章 https://www.twblogs.net/a/5c652bbebd9eee06ee22ce37

上一篇
Day 14 - 共識演算法 - Paxos太難了所以我發明了Raft(下)
下一篇
Day 16 - 分散式系統溝通的方法 - RPC
系列文
分散式系統 - 在分散的世界中保持一致30

尚未有邦友留言

立即登入留言