etcd和mysql_etcd和redis比较
尽管etcd和redis都是键值存储，随着技术的演进，二者在功能上也有逐渐相似的趋势，但二者在许多方面都有很大区别。etcd的红火来源于k8s用etcd做服务发现，而redis的兴起则来源于memcache缓存本身的局限性。etcd的重点是利用raft算法做分布式一致性，强调各个节点之间的通信、同步，确保各节点数据和事务的一致性，使得服务发现工作更稳定；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在同一个生态下
本作品采用《CC 协议》，转载必须注明作者和本文链接
你还差得远呐！
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)