etcd和redis的比较和日常使用场景 【置顶】

个人观点：etcd的红火来源于kurbernetes用etcd做服务发现，而redis的兴起则来源于memcache缓存本身的局限性。
etcd是一种分布式存储，更强调的是各个节点之间的通信，同步，确保各个节点上数据和事务的一致性，
使得服务发现工作更稳定，本身单节点的写入能力并不强。

redis更像是内存型缓存，虽然也有cluster做主从同步和读写分离，
但节点间的一致性主要强调的是数据，并不在乎事务，因此读写能力很强，qps甚至可以达到10万+

两者都是k-v存储，但redis支持更多的存储模式，包括KEY，STRING，HMAP，SET，SORTEDSET等等，
因此redis本身就可以完成一些比如排序的简单逻辑。而etcd则支持对key的版本记录和txn操作和client对key的watch，因此适合用做服务发现。

日常使用中，etcd主要还是做一些事务管理类的，基础架构服务用的比较多，容器类的服务部署是其主流。
而redis广泛地使用在缓存服务器方面，用作mysql的缓存，通常依据请求量，甚至会做成多级缓存，当然部分情况下也用做存储型redis做持续化存储。

简单从以下几个方面说一下瑞迪斯为啥在微服务中不能取代 etcd：
1、redis 没有版本的概念，历史版本数据在大规模微服务中非常有必要，对于状态回滚和故障排查，甚至定锅都很重要
2、redis 的注册和发现目前只能通过 pub 和 sub 来实现，这两个命令完全不能满足生产环境的要求，具体原因可以 gg 或看源码实现
3、etcd 在 2.+版本时，watch 到数据官方文档均建议再 get 一次，因为会存在数据延迟，3.+版本不再需要，可想 redis 的 pub 和 sub 能否达到此种低延迟的要求
4、楼主看到的微服务架构应该都是将 etcd 直接暴露给 client 和 server 的，etcd 的性能摆在那，能够承受多少的 c/s 直连呢，更好的做法应该是对 etcd 做一层保护，当然这种做法会损失一些功能
5、redis 和 etcd 的集群实现方案是不一致的，etcd 采用的是 raft 协议，一主多从，只能写主，底层采用 boltdb 作为 k/v 存储，直接落盘
6、redis 的持久化方案有 aof 和 rdb，这两种方案在宕机的时候都或多或少的会丢失数据

总结，瑞迪斯从来没有想过抢 etcd 在服务注册和发现的饭碗，目前的架构来说也抢不动，在缓存方面目前在性能和功能也无出其右； etcd 只关注在服务注册与发现方面，非要当做 k/v 存储来用（丢弃 watch 特性而言）也可以用，性能也不错，但只能说你选错对象了

微服务架构中选择哪种技术，取决于技术决定人的规划理想，非要说 redis 不行当然也是错的，不考虑服务规模和性能需求，用 mongodb 也能搞，mongodb 3.6+版本也有个 oplog watch 的功能

简单总结一下：

高可用的角度，redis 主从是异步复制的机制，这就导致了其有丢失数据的风险。redis 的哨兵或 cluster 解决的是系统的可服务性确保在有单点故障的情况下也能对外提供服务，但是因为异步复制的机制在从升主的过程中或者网络分区的情况下都是有可能丢失数据的。etcd 基于 raft 协议在写入数据的时候需要多数应答确认后才会向客户端返回数据写入成功这就保证了数据的一致性。etcd 除此外还有其他的一些特性优势。