分布式-容錯性,2PC

來源:互聯網
上載者:User

《分布式系統原理與範型》

分布式區別於單機系統的一個特性:可能部分失效。

分布式系統設計的一個重要目標:可以從部分失效中自動回復,它能容忍錯誤,在發生錯誤時某種程度上的可以繼續操作。

 

1、可用性,可靠性、安全性、可維護性。

2、故障類型,崩潰性故障、遺漏性故障、隨即故障(拜占庭故障)、等等。

    問題: 當一個伺服器一段時間不響應時,伺服器是崩潰了,還是出現效能問題呢???

3、使用冗餘來掩蓋故障

Lamport在論文中證明在拜占庭故障的系統中,具有m個故障進程的系統中,只有存在2m+1個正確的背景工作處理序才能達成協議,這樣總共有3m+1個進程,也就是當2/3以上的進程正常工作時,才可能達成協議。

 

4、分布式系統中原子性的基礎是分布式提交協議

兩階段交易認可 2PC:

a\ 協調者向所有參與者發送一個vote_request訊息

b\ 當參與者接受到vote_request訊息時,就向協調者發送一個vote_commit訊息通知協調者他已經準備好本地提條事務中屬於它的部分,否則返回一個vote_abort

c\ 協調者收集來自所有參與者的選票,如果全部都表決提交事務,那麼協調者就進行提交,它向所有參與者發送一個global_commit訊息,如果有一個參與者表決取消事務,那麼協調者就決定取消,它向所有參與者發送一個global_abort訊息。

d\ 每個提交表決的參與者 都等待 協調者的最後會有,如果參與者接收到global_commit, 那麼他就提交事務,否則接受到gloabl_abortt訊息時,取消abort.。

表決階段有第一,第二步構成,決定階段有第三、第四步構成。

 

出現的問題:所有協調者、參與者都是阻塞等待訊息,當一個進程崩潰,而其他進程又在等待來自該進程的訊息時,這個協議很容易崩潰。

可以引入定時機制。當協調者崩潰時,參與者不能做出最後的決定。

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.