ETCD_簡介+使用
etcd是一個包含服務註冊，監控，發現的分佈式鍵值存儲系統
分佈式：Raft算法實現數據強一致性，進行負載均衡，分佈式部署。
鍵值: store接受到http client 的API進行事務處理
存儲：memory(store) + 硬盤持久化（WAL（預寫入日誌）+snapshot（快照））
1.etcd實現原理
從etcd的架構圖中我們可以看到，etcd主要分爲四個部分。
HTTP Server： 用於處理用戶發送的API請求以及其它etcd節點的同步與心跳信息請求。
Store：用於處理etcd支持的各類功能的事務，包括數據索引、節點狀態變更、監控與反饋、事件處理與執行等等，是etcd對用戶提供的大多數API功能的具體實現。(key-value存儲)
Raft：Raft強一致性算法的具體實現，是etcd的核心。（leader,foller,condidete）
WAL：Write Ahead Log（預寫式日誌），是etcd的數據存儲方式。除了在內存中存有所有數據的狀態以及節點的索引以外，etcd就通過WAL進行持久化存儲。WAL中，所有的數據提交前都會事先記錄日誌。Snapshot是爲了防止數據過多而進行的狀態快照；Entry表示存儲的具體日誌內容。
通常，一個用戶的請求發送過來，會經由HTTP Server轉發給Store進行具體的事務處理，如果涉及到節點的修改，則交給Raft模塊進行狀態的變更、日誌的記錄，然後再同步給別的etcd節點以確認數據提交，最後進行數據的提交，再次同步。
2.經典應用場景
1.服務發現（Service Discovery）
要解決服務發現的問題，需要有下面三大支柱：
1.一個強一致性、高可用的服務存儲目錄。
2.一種註冊服務和監控服務健康狀態的機制。用戶可以在etcd中註冊服務，並且對註冊的服務設置key TTL，定時保持服務的心跳以達到監控健康狀態的效果。
3.一種查找和連接服務的機制。通過在etcd指定的主題下注冊的服務也能在對應的主題下查找到。爲了確保連接，我們可以在每個服務機器上都部署一個Proxy模式的etcd（etcd反代理），這樣就可以確保能訪問etcd集羣的服務都能互相連接。
2.消息發佈與訂閱
3.負載均衡
4.分佈式通知與協調
5.分佈式鎖
6.分佈式隊列
7.集羣監控與Leader競選
8.爲什麼用etcd而不用ZooKeeper？
3.集羣化應用實踐（etcd集羣）
4.數據存儲
etcd的存儲分爲內存存儲和持久化（硬盤）存儲兩部分，內存中的存儲除了順序化的記錄下所有用戶對節點數據變更的記錄外，還會對用戶數據進行索引、建堆等方便查詢的操作。而持久化則使用預寫式日誌（WAL：Write Ahead Log）進行記錄存儲。 內存存儲：store 持久化（硬盤）儲存：WAL+ snapshot（快照）
5.Raft 算法
Leader，Follower，Candidate（候選人），分佈式，負載均衡，各服務器信息同步（:2380），心跳信息（:2380） 單實例節點支持每秒1000次數據寫入。
6. Store
store 處理 client 端（:2379）的http請求。(GET POST PUT DELETE WAIT(監控).....)
Store這個模塊顧名思義，就像一個商店把etcd已經準備好的各項底層支持加工起來，爲用戶提供五花八門的API支持，處理用戶的各項請求。
要理解Store，只需要從etcd的API入手即可。打開etcd的API列表，我們可以看到有如下API是對etcd存儲的鍵值進行的操作，亦即Store提供的內容。API中提到的目錄（Directory）和鍵（Key），上文中也可能稱爲etcd節點（Node）。
爲etcd存儲的鍵賦值
curl http://127.0.0.1:2379/v2/keys/message -XPUT -d value="Hello world"
{
"action": "set",
"node": {
"createdIndex": 2,
"key": "/message",
"modifiedIndex": 2,
"value": "Hello world"
}
}
store 進行具體的事務處理，如果涉及到節點的修改，則交給Raft模塊進行狀態的變更、日誌的記錄，然後再同步給別的etcd節點以確認數據提交，最後進行數據的提交，再次同步。 store對etcd下存儲的數據進行加工，創建出如文件系統般的樹狀結構供用戶快速查詢。它有一個Watcher用於節點變更的實時反饋，還需要維護一個WatcherHub對所有Watcher訂閱者進行通知的推送。同時，它還維護了一個由定時鍵構成的小頂堆，快速返回下一個要超時的鍵。最後，所有這些API的請求都以事件的形式存儲在事件隊列中等待處理。
7.ERCD 端口
2379用於客戶端通信，2380用於節點（集羣內）通信，與原先的（4001 peers / 7001 clients）共用。 配置etcd過程中通常要用到兩種url地址容易混淆，一種用於etcd集羣同步信息並保持連接，通常稱爲peer-urls；另外一種用於接收用戶端發來的HTTP請求，通常稱爲client-urls。 peer-urls：通常監聽的端口爲2380（老版本使用的端口爲7001），包括所有已經在集羣中正常工作的所有節點的地址。 client-urls：通常監聽的端口爲2379（老版本使用的端口爲4001），爲適應複雜的網絡環境，新版etcd監聽客戶端請求的url從原來的1個變爲現在可配置的多個。這樣etcd可以配合多塊網卡同時監聽不同網絡下的請求。
8.總結
ectd 它解決了分佈式場景中最爲常見的一致性問題，爲服務發現提供了一個穩定高可用的消息註冊倉庫，爲以微服務協同工作的架構提供了無限的可能。