etcd是將數據存儲在集羣中的高可用k-v存儲。
允許應用實時監聽存儲中的k-v變化。
能容忍單點故障，能夠應對網絡分區。
(raft是一個分佈式協議，管理的是日誌；etcd管理的是k-v，把k-v放到日誌裏，kv就編程分佈式集羣了)
(調用者寫入請求發給leader請求寫入k-v，leader會將日誌實時向follower們複製，leader不會立即返回給調用者，會馬上往集羣follower做日誌拷貝。當日志被複制給N+1個節點後(即大多數)，本地提交(也就是告訴客戶端提交成功)，返回給調用者(客戶端)，爲什麼複製給N+1,而不是2N+1後就告訴客戶端成功了呢？這就是大多數協議，也就是抽屜理論的重要表現)
(一旦完成提交，leader會週期性把自己的提交信息告訴所有follower，這樣，其他follower也會完成它們的本地提交(這是異步行爲，不需要同步，只需要確保日誌複製給大多數了就可以)。官方給出的寫入性能是:1000次每秒)
(raft協議本身就是在寫日誌。第1行是leader節點的日誌，後面是4個是follower，也就是總共5個節點。日誌是隨着請求順序追加，這裏5個節點的大多數是3個節點。其中1-7已經被複制給了3個節點(大多數)，這些是一定可以被提交不會丟失的，因爲已經複製給大多數了。8總共只有兩個節點有，8後面其他的更誇張。有的連3,4,5都沒有，這一般是leader和follower之間產生了網絡延遲，然而，沒關係，只要複製給大多數就不會丟了。所以真個日誌的提交已經到了第7個日誌)
(
第一個leader幸運是f，f寫入了3條數據(標識爲1的綠色塊)，併成功複製給了所有節點，然後f宕機了又馬上重啓。
因爲宕機，而f曾經是leader，於是重新選舉，踩了狗屎很幸運，f又成了leader。f又提交了3條記錄(標識爲2的紫色塊)，但它沒有複製給集羣中的其他節點(可能f剛成爲leader沒來得及複製給其他節點又掛掉了)。
f宕機後重啓，又踩了狗屎成爲了第三任leader，寫入5條數據(下標爲3的橙色塊)，沒來得及複製有宕了。
然後第四任leader幸運的是e，e寫入了4條數據(下標爲4的×××塊)，但它作爲leader期間，只把前面兩條(下標爲4的×××塊)數據複製給大多數節點，後兩個沒來得及複製就宕了......
)
(leader寫入數據，但只複製給了一個follower，其他由於網絡原因沒複製，所以無法提交，無法給客戶端應答，客戶端繼續等待...)
(raft協議是底層原理，etcd將k-v寫入storage纔是真的。當複製給大多數後，leader就告訴客戶端：你的事已經辦好了)
(當old leader重啓後，它發現已經有了一個新leader，並且它的數據是落後於new leader的，所以new leader會把a=2複製給old leader，而old leader會發現，原來的a=1沒有複製給大多數(未提交狀態)，而a=2已經完成了大多數複製，所以a=2會覆蓋掉a=1。所以在集羣中a=2而不是1)
(etcd支持通用的http+json協議，但性能較低。sdk內置GRPC協議，性能很高。GRPC是谷歌開源的RPC協議，是基於http2協議。我們用的etcd就是基於GRPC的。我們通過sdk操作etcd中的k-v)
(能實現像redis一樣的時間過期)
(用有序的key模擬出目錄的效果。也就是隻要定位到/feature-flags，就能根據它找到類似該目錄下的所有目錄(其實是key))
(即便key1=value3覆蓋了之前的key1=value1，在etcd中也會有key1=value1這個歷史版本(也就是revision=1)。然而我們只關心最新的數據，可以用compact命令完成刪減)
