儘管etcd和redis都是鍵值儲存，隨著技術的演進，二者在功能上也有逐漸相似的趨勢，但二者在許多方面都有很大區別。
etcd的紅火來源於k8s用etcd做服務發現，而redis的興起則來源於memcache快取本身的侷限性。
etcd的重點是利用raft演算法做分散式一致性，強調各個節點之間的通訊、同步，確保各節點資料和事務的一致性，使得服務發現工作更穩定；
redis也可以做主從同步和讀寫分離，但節點一致性強調的是資料，不是事務。redis的註冊和發現只能通過pub和sub實現，安全性不能保證（斷線重連之後不會將歷史資訊推送給客戶端，需要自己做一個定時輪詢），延時也比etcd v3高。
etcd v3的底層採用boltdb做儲存，value直接持久化；redis是一個記憶體資料庫，它的持久化方案有aof和rdb，在當機時都或多或少會丟失資料。
etcd v3只能通過gRPC訪問，而redis可以通過http訪問，因此etcd的客戶端開發工作量高很多。
redis的效能比etcd強。
redis的value支援多種資料型別。
etcd是用go開發的，和k8s在同一個生態下
本作品採用《CC 協議》，轉載必須註明作者和本文連結