分佈式原理概括

分佈式原理

知識點1

• 分佈式與集羣的區別:

  集羣:多個人在一起作同樣的事 。

  分佈式 :多個人在一起作不同的事 。

• CAP理論和base理論

  CAP 理論含義是，一個分佈式系統不可能同時滿足一致性(C:Consistency)，可用性(A: Availability)和分區容錯 性(P:Partition tolerance)這三個基本需求，最多隻能同時滿足其中的2個。

  選項	描述
  C 一致性	分佈式系統當中的一致性指的是所有節點的數據一致，或者說是所有副本的數據一致
  A 可用性	Reads and writes always succeed. 也就是說系統一直可用，而且服務一直保持正常
  P 分區容錯性	系統在遇到一些節點或者網絡分區故障的時候，仍然能夠提供滿足一致性和可用性的服務

• BASE是對CAP中一致性和可用性權衡的結果，BASE理論的核心思想是:即使無法做到強一致性，但每個應用都可 以根據自身業務特點，採用適當的方式來使系統達到最終一致性。

• 3PC協議（CanCommit、PreCommit和doCommit三個階段 ）

  注意:一旦進入階段三，可能會出現 2 種故障:

  1. 協調者出現問題
  2. 協調者和參與者之間的網絡故障

  如果出現了任一一種情況，最終都會導致參與者無法收到 doCommit 請求或者 abort 請求，針對這種情況，參與者都會在等待超時之後，繼續進行事務提交，如果本來是要發送中斷的，此時提交的話，會造成數據不一致問題；

Paxos算法

• Paxos算法
  • 解決了分佈式系統一致性問題。
  • Client:客戶端—>Proposer:提案發起者(重點理解)—>Acceptor:決策者，可以批准提案—>Learners:最終決策的學習者

• 階段一:

  (a) Proposer選擇一個提案編號N，然後向半數以上的Acceptor發送編號爲N的Prepare請求。

  (b) 如果一個Acceptor收到一個編號爲N的Prepare請求，且N大於該Acceptor已經響應過的所有Prepare請求 的編號，那麼它就會將它已經接受過的編號最大的提案(如果有的話)作爲響應反饋給Proposer，同時該 Acceptor承諾不再接受任何編號小於N的提案。

• 階段二:

  (a) 如果Proposer收到半數以上Acceptor對其發出的編號爲N的Prepare請求的響應，那麼它就會發送一個針對[N,V]提案的Accept請求給半數以上的Acceptor。注意:V就是收到的響應中編號最大的提案的value，如果 響應中不包含任何提案，那麼V就由Proposer自己決定。

  (b) 如果Acceptor收到一個針對編號爲N的提案的Accept請求，只要該Acceptor沒有對編號大於N的Prepare 請求做出過響應，它就接受該提案。

• 階段三：

  假設存在這樣一種極端情況，有兩個Proposer依次提出了一系列編號遞增的提案，導致最終陷入死循環，沒有 value被選定,具體流程如下:

  解決:通過選取主Proposer，並規定只有主Proposer才能提出議案。這樣一來只要主Proposer和過半的Acceptor 能夠正常進行網絡通信，那麼但凡主Proposer提出一個編號更高的提案，該提案終將會被批准，這樣通過選擇一個 主Proposer，整套Paxos算法就能夠保持活性;

一致性算法-Raft

• 分佈式理論:一致性算法 Raft

  三個身份：

  • 領導者(leader):處理客戶端交互，日誌複製等動作，一般一次只有一個領導者
  • 候選者(candidate):候選者就是在選舉過程中提名自己的實體，一旦選舉成功，則成爲領導者
  • 跟隨者(follower):類似選民，完全被動的角色，這樣的服務器等待被通知投票

  而影響他們身份變化的則是**選舉，Raft使用心跳機制來觸發選舉**。當server啓動時，初始狀態都是follower。每一個server都有一個定時器，超時時 間爲election timeout(一般爲150-300ms)，如果某server沒有超時的情況下收到來自領導者或者候選者的任何 消息，定時器重啓，如果超時，它就開始一次選舉。

  日誌複製(保證數據一致性) :

  4 個步驟:

  • 客戶端的每一個請求都包含被複制狀態機執行的指令。

  • leader把這個指令作爲一條新的日誌條目添加到日誌中，然後並行發起 RPC 給其他的服務器，讓他們複製這 條信息。

  • 跟隨者響應ACK,如果 follower 宕機或者運行緩慢或者丟包，leader會不斷的重試，直到所有的 follower 最終 都複製了所有的日誌條目。

  • 通知所有的Follower提交日誌，同時領導人提交這條日誌到自己的狀態機中，並返回給客戶端。

    可以看到，直到第四步驟，整個事務纔會達成。中間任何一個步驟發生故障，都不會影響日誌一致性。

    注意：只有正在運行的節點數量大於一半的情況下，事務纔會真正的提交，不然只是記錄在本地數據，不會進行提交；

rpc

• 基本原理

  • 在底層層面去看，網絡通信需要做的就 是將流從一臺計算機傳輸到另外一臺計算機，基於傳輸協議和網絡IO來實現，其中傳輸協議比較出名的有tcp、 udp等等，tcp、udp都是在基於Socket概念上爲某類應用場景而擴展出的傳輸協議，網絡IO，主要有bio、nio、 aio三種方式，所有的分佈式應用通訊都基於這個原理而實現，只是爲了應用的易用，各種語言通常都會提供一些 更爲貼近應用易用的應用層協議。

• 例子

  • 老張煮開水。 老張，水壺兩把(普通水壺，簡稱水壺;會響的水壺，簡稱響水壺)。
    1 老張把水壺放到火上，站立着等水開。(同步阻塞-BIO)
    2 老張把水壺放到火上，去客廳看電視，時不時去廚房看看水開沒有。(同步非阻塞)
    3 老張把響水壺放到火上，立等水開。(異步阻塞)
    4 老張把響水壺放到火上，去客廳看電視，水壺響之前不再去看它了，響了再去拿壺。(異步非阻塞)

• RPC架構

  一個完整的RPC架構裏面包含了四個核心的組件，分別是Client，Client Stub，Server以及Server Stub，這個Stub 可以理解爲存根

  
  

Netty 模型

• Netty 抽象出兩組線程池， BossGroup 專門負責接收客 戶端連接， WorkerGroup 專門負責網絡讀寫操作。 NioEventLoop 表示一個不斷循環執行處理 任務的線程， 每個 NioEventLoop 都有一個 selector， 用於監聽綁定 在其上的 socket 網絡通道。 NioEventLoop 內部採用串行化設計， 從消息的讀取->解碼->處理->編碼->發送， 始 終由 IO 線 程 NioEventLoop 負責