etcd vs redis方案对比

尽管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在同一个生态下。