分散式系統小筆記

weixin_34124651發表於2017-07-31
6560153-dccccbcd4f868dd8.png

容錯性是一個非常重要的概念,比如說disk裡的東西丟了有沒有什麼辦法恢復呢?有幾種辦法。 比如說同樣的資料存在好幾個disk裡,雖然有點浪費,但是起碼保證可以恢復。

6560153-dec0565918688317.png


6560153-93574fac1f24cb05.png


只靠RAID 並不一定就能保護所有的突發情況。比如說如果有人write a bad write, 這樣直接就備份了不好的東西。

6560153-cefd5316d1f35010.png

這邊又回到了database裡的概念。 比如說用Lock,來保證誰先誰後。用2PL 來保證可以Roll Back...用Log, undo, redo來處理crash.

6560153-5d4fdcc7beb10dae.png


分散式系統有好多機器一起處理東西。

6560153-3f971469c2f4ae85.png

用分散式系統的好處是: 蠻簡單造一大堆simple computers。 

6560153-0c33103ab39d406d.png
6560153-307df1b5786e1d69.png

Flow Control: 為了處理髮資訊的人頻率太快,收資訊的收不了那麼快。加一個Buffer在receiver, 還沒來得及收的資訊先存buffer裡。

6560153-549d84c0acf846a2.png


6560153-c10d3aa6d9fdbfc8.png


6560153-2b551cacbf80e05e.png



6560153-645ac8cff0a1f79a.png


6560153-8fa3212f8111afe8.png


General's Paradox, 紅色的為將軍們, 中間藍色的為敵人。 兩個將軍可以傳信,但是有可能被中間的敵人攔截。 如果兩個將軍沒能同時攻擊敵人,倆都死。 如果能夠默契的同時進攻,將軍獲勝。

問題: 在一個不可信賴的網路中,傳輸的資訊能夠保證兩方同時做一件什麼事情嗎?答案:不行。即便資訊成功的傳送。

6560153-3823499cb8317c75.png

Two Phase Commit [不是2PL哦]

有一個log 來跟蹤commit 發生沒有。如果一個機器炸了,當他重新啟動的時候,他會先check log to recover state of world at time of crash.

Prepare Phase:

全域性coordinator 要求所有的參與者保證要麼commit,要麼rollback。當一個人投票說abort, 全域性coordinator 寫'abort'進log, 然後告訴大家都abort吧。每個人的log裡這時候都會寫一個"Abort". 

Commit Phase:

當所有人都說準備好啦,coordinator 將"Commit"寫入log。 然後告訴大家可以commit了。 所有人恢復一個ACK。 當coordinator 收到ACKs,代表所有人表示收到了叫他們可以commit的資訊了,這時候coordinator 寫"got commit" to Log.

6560153-5e9186cbc6b2d5dc.png
6560153-165569e115150b66.png


6560153-284c6dcd11f0bef1.png

Coordinator在等待回覆的時候,等固定的多少時間,到時間沒收到全員的資訊,send "Global-Abort".

6560153-921538c6be566465.png


6560153-c0a6b655ad4c1e38.png


每一個distributed nodes 使用stable Storage 來儲存current state。A working在等待Global decision的時候,可以問問身邊的同學他們處在什麼state。如果旁邊的人爆炸了, 或者commit了。那麼久表示coordinator肯定發了一個Global message,只是自己沒收到。這個時候跟著旁邊哥們爆炸或者commit就好了。


Blocking問題:如果其他所有worker都處於ready 狀態,但是這個人自己是處於waiting for global decision的狀態。那麼會Block, 因為不知道其他人的ready是等著爆炸還是等著commit。

6560153-6ed087e5da533bed.png

Paxos 不會有Blocking的問題。

6560153-35f7336d3be2859d.png

RPC: 



6560153-7f27b37826ee3173.png



6560153-4625a9958207e825.png


6560153-3a19c90a4b3349ba.png
6560153-2f08dd3f5c7738ef.png
6560153-5c2d0c8d502a7574.png



6560153-ff0408eb06a933a9.png


6560153-8e5b7cb65377e660.png



6560153-84b2924747cb461e.png


Paxos: 摘自知乎大神 GRAYLAMB

6560153-73cc454a6aa16e24.png


6560153-7078ee705d0d7de4.png



6560153-4582c6b0b8b9590c.png


6560153-6e44cb1edbd0a8e1.png


6560153-eac55c00111e1d1e.png


6560153-12f2463b33cead71.png



6560153-a01630f60ad7f676.png


6560153-11d623153298c298.png


6560153-0b4375ff3d9e0567.png


6560153-69f9820cd0fedc4f.png


6560153-1e2447037e61b619.png


6560153-1cc5155da71dd810.png


6560153-a69fcc8359ce3d8c.png


6560153-10a0fd2c4f50ce96.png


reference: http://blog.brucefeng.info/post/what-is-rpc

ZooKeeper 參考文章:http://cailin.iteye.com/blog/2014486/

Paxors: http://blog.csdn.net/chdhust/article/details/50539545  這篇最好!

https://www.quora.com/Distributed-Systems-What-is-a-simple-explanation-of-the-Paxos-algorithm Quora上這篇也不錯

資料庫到底是要非同步還是強行同步

6560153-d08163e827e6a71b.png


我粗淺的理解是,為了解決資料備份的瞬時性,採用分散式Paxos。 當大部分節點同意這個node的值應該是這樣,代表少數node可能miss存了updated 的值。所以最後還是全體update成新的value。

6560153-41c4eddc92cfc722.png

2PC解決此類問題的不足。node只能同意或者否決另一個node propose的東西,如果他自己想要建議一個別的solution,得重新發起一個2PC。

6560153-6788bc746088fee3.png

3PC的不足:



6560153-c38d02198e866167.png

Paxos:


6560153-8ea82e17eb9e9940.png

跟2PC最大的不同在於,Paxos不需要所有node都同意才ok。只要多數派同意,proposal 就通過。

6560153-eb2b4b1eb96b0cd6.png

當然,Leader Node自己也可能會fail。所以Paxos 不是Single Leader制度。 每秒鐘都可能有node搶著當Leader。

6560153-2c415a3347ac45f3.png

相關文章