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

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐