etcd和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在同一个生态下

etcd和redis比较

本作品采用《CC 协议》,转载必须注明作者和本文链接
你还差得远呐!
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!