悟已往之不諫知來者之可追
記錄一下自己學習Raft演算法的程序
文章目錄
- 悟已往之不諫知來者之可追
- 前言
- 一、引入？
- 二、CAP定理
- 1.概念
- 2.共識演算法
- 總結
前言
你能造什么樣的火箭，決定你能去擰什么樣的螺絲，
一、引入？
在進行演算法的學習之前，如果有機會，你會怎么樣去設計一個分布式系統？
一般來說，單機系統資料一般都是放在本地的，基本不需要與外部通信，比如單機資料庫錫系統，但是，當有一天你的系統遇到了單機系統難以維持的高請求量，為了防止系統宕機，也為了系統有更高的可用性，可用搭建類似master-slave結構的系統，并允許請求落到slave服務器上面，
但實際上當你去深入思考之后，卻發現這個東西并沒有你想象的那么容易設計，
首先，相比較于單機系統，分布式系統需要和多臺設備進行通信，而且通信也會潮師的可能，此時發送方也無法確定通信是成功還是失敗，
其次，一份資料被放在多臺服務器，資料的更新也是有延遲的，
最后，當master服務器宕機了，沒有一個自動機制可以立馬提升slave服務器為master服務器，
這個時候你可能會想，我可以用某些方法解決上述問題，或者是用xxx框架？講道理，一開始我也以為會有解決方法，但實際上是 沒有！！！
依據就是分布式領域中CAP定理，
二、CAP定理
1.概念
基本概念：
- Consistency：一致性
- Availability：可用性
- Partition-tolerance：磁區容錯性
我想只要稍微懂一點分布式的同學都知道 ，在異步網路模型中 ，不可能同時滿足上述三個 屬性，只能 同時滿足兩個，
在前言中說了， 通信超時 和 更新延遲 都是屬于一致性 的問題，原因是存在多臺服務器，而每臺服務器都有自己的資料，資料冗余雖然可以提高系統的可用性 和 磁區容錯性，但是相應的難以滿足一致性，但是想解決的話，就是要達到強一致性，比如把所有的請求全部通過單臺服務器進行處理，那這個樣子的話，其實就很難滿足高可用性
根據經驗來說一般都是可用性或者一致性是被榷訓的物件，
但是對于高可用的系統而言，往往會保留強一致性，典型的就是延遲處理，利用訊息佇列的 中間件，在后臺逐一處理佇列中的請求，處理完畢的時候，就是達到了強一致性狀態 ，
但是要求強一致性的系統，比如元資料系統，分布式資料庫系統，他們的可用性往往是有限的，
解決上述的問題，就要用到 共識演算法
2.共識演算法
基礎概念：
共識演算法
“共識”的意思就是保證所有的參與者都有相同的認知（這個地方可以理解為強一致性），共識演算法本身可以依據是否有惡意節點分為兩類，大部分的時候共識演算法都指向沒有惡意節點的那一類，即系統節點不會向其他節點發送惡意請求，比如欺騙請求，共識演算法中有名的有paxos演算法，raft演算法，zab演算法，
總結
簡單描述了下cap問題， 相比較Paxos演算法相比，Raft演算法在保持正確性的同時更容易理解，我認為偏向于入門， 接下來就開卷！！！轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/357191.html
標籤：區塊鏈