（第四章）容器化思維(續)

文章目錄

1.etcd原理簡介

etcd作爲一個分佈式鍵值存儲系統，解決了分佈式場景中的數據一致性問題，爲服務發現提供了一個穩定、高可用的消息註冊倉庫，爲以微服務協同工作的架構提供了無限的可能。
etcd的架構，如圖4-24
（1）HTTP Server：處理用戶的API請求，處理其它etcd節點的同步與心跳信息請求
（2）Store：是etcd對用戶提供的大多數API功能的具體實現
（3）Raft：強一致性算法的具體實現，是etcd的核心
（4）WAL：即Write Ahead Log(預寫式日誌)，他是etcd的數據存儲方式，除了在內存中存有所有數據的狀態以及節點的索引日誌外，etcd還通過WAL進行持久化存儲。
（5）Entry是存儲的具體日誌的內容，Snapshot是爲了防止數據過多而進行的狀態快照；

一個用戶的請求會由HTTP server轉發給Store進行具體的事務處理。
若是節點的修改，則交給Raft模塊進行狀態的變更、日誌的記錄；
然後再同步給別的etcd節點以確認數據提交，最後進行數據的提交，再次同步；

集羣化應用與實現原理
（1）etcd是一個高可用的鍵值存儲系統，天生就是爲集羣化而設計的。
etcd一般部署集羣推薦奇數個點
（2）集羣啓動的3種方案：靜態配置啓動，etcd自身服務發現，通過DNS進行服務發現
（3）運行時重構使得etcd集羣無須重啓即可修改集羣的配置；在配置etcd集羣數量時，至少配置3個核心節點，配置述目越多，可用性越強；
（4）etcd的節點都是實時同步的，每個節點上都存儲了所有的信息
（5）Proxy模式下的etcd作爲一個反向代理把客戶的請求轉發給可用的etcd集羣。
Proxy並不是直接加入到符合強一致性的etcd集羣中的，它沒有增加集羣的可靠性，也沒有降低集羣的寫入性能。
爲什麼要有Proxy模式而不是直接增加etcd核心節點呢？
因爲etcd每增加一個核心節點peer，都會給Leader節點增加一定程度的負擔(網絡，CPU，負載)。每次增加信息的變化都需要進行同步備份，增加一個輕量級的Proxy模式etcd節點就是對直接增加etcd節點的一個有效的替代。

2.etcd數據存儲原理

etcd存儲分爲內存存儲和持久化(硬盤)存儲兩部分。
（1）內存中的存儲：順序化地記錄所有用戶對節點數據變更的記錄，對數據進行索引，建堆等方便查詢的操作
（2）WAL：對數據進行持久化的存儲
etcd的持久化存儲目錄有2個：
（1）WAL：存儲着所有事務的變化記錄，在數據的修改提交之前，都要先寫入到WAL中。使用WAL進行數據的存儲，使得etcd能夠故障快速恢復，數據回滾或重做
（2）Snapshot：用於存儲某一個時刻etcd所有目錄的數據

3.Raft算法關鍵內容理解

Raft中的一個任期是啥意思？
定義：從某一次競選開始到下一次競選開始。
若Follower接收不到Leader節點心跳，就會結束當前任期，變爲Candidate發起競選
Raft狀態機是如何切換的？
Raft剛剛開始運行時，節點默認進入到Follower的狀態，等待Leader發來心跳信息
如何保證最短時間內競選出Leader，以防止競選衝突
在Candidate狀態下有個心跳超時，這是個隨機值。在時間差內，若Candidate1收到的競選信息比自己發起的競選信息的任期要大，那麼Candidate1就會投票給Candidate2
如何防止遺漏數據的節點成爲Leader？
若發起競爭的節點在上一個任期中保存的已提交的數據不完整，節點就會拒絕投票給他
Raft某個節點宕機後會如何？
（1）若是Follower節點宕機，集羣基本不受影響
（2）若是Leader節點宕機，則開啓競選機制
爲什麼Raft短髮在確定可用節點數量時不需要考慮拜占庭將軍問題？
（1）拜占庭將軍問題指出：允許n個節點宕機還能提供正常服務的分佈式架構，需要的總結點數量爲3n+1，而raft只需要2n+1。
原因是：拜占庭將軍問題中存在數據欺騙的現象，而etcd中假設的所有節點都是誠實的
（2）etcd嚴格限制Leader到Follower這樣的數據流向，以保證數據一致性不出錯
用戶從集羣中哪個節點讀寫數據？
所有用戶更新的數據請求都是最先由Leader獲得並保存下來，然後通知其它節點將其保存，等到大多數節點反饋時，一個已提交的數據項纔是Raft真正穩定存儲下來的數據項。
etcd實現的Raft算法的性能？
單實例節點每秒1千次數據寫入。
節點增加，網絡延遲會對數據同步造成影響；由於每個節點都能處理用戶的讀請求，所以讀性能會提升。
etcd的API
etcd中處理API的包稱之爲Store，該API都是對etcd存儲的鍵值進行操作。