这是一个创建于 2153 天前的主题，其中的信息可能已经有所发展或是发生改变。
etcd 是一个开源的、分布式的键值对数据存储系统，提供共享配置、服务的注册和发现。
以上是 etcd 的介绍。关于共享配置，redis 可以实现，如果从高可用的角度 redis 现在也有 cluster 集群方案。
服务的注册和发现，etcd 利用了其租约特性，我认为 redis 也可以实现类似逻辑。
我在网上也有搜到 redis 做服务发现和注册的方案，但是视乎没引起大家的注意。
希望有大佬解答一下我的疑惑，如果用 redis 去做会存在什么问题和风险？
 |
1
passerbytiny 2018-12-24 11:01:03 +08:00
redis 做服务发现，我只看到 dubbo 用过，明确告知没经过测试，目的是方便学习。
redis 压根就不是用来做服务发现的，它只是数据库。偷懒临时用用还可以，想在生产环境中用，还是洗洗睡吧。 |
 |
2
loveCoding 2018-12-24 11:08:39 +08:00
理论上只要是你实现了服务注册与发现的接口 ,存储层是可以替换的.用 redis/mysql 也不是不可以~
选 etcd 这种类型只因它更适合做这个 |
 |
3
xkeyideal 2018-12-24 11:15:20 +08:00  21
简单从以下几个方面说一下瑞迪斯为啥在微服务中不能取代 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 的功能 |
|
5
xkeyideal 2018-12-24 11:24:59 +08:00
@enenaaa 最简单直接的一点就是，redis pub 和 sub 在断线重连之后是否会将历史数据再推送给 client ？
|
 |
6
leriou 2018-12-24 11:29:57 +08:00
@enenaaa pubsub 不会保留历史信息, 收到就行, 收不到也不会重复通知, 换句话说, 你必须客户端永远在线, 才能收到 sub 的信息, 一旦客户端网络短时间出问题, 就收不到变更通知了, redis 可以做, 但是不是用 pubsub 做, 而是要自己做一个定时的轮询, 时刻保持客户端信息最新
|
 |
7
pifuant 2018-12-24 11:39:04 +08:00
保证高可用的前提下，redis 提供方案，safety 不能保证， 慎用！！！
|
 |
8
kaxi OP |
 |
9
wqlin 2018-12-24 12:17:15 +08:00
服务注册和发现 自身要保证高可用、数据不丢吧。这些 redis 做不了保证，etcd 可以保证。
不过既然考虑 etcd，为啥不考虑 consul，直接支持服务注册和发现 |
 |
11
RubyJack 2018-12-24 13:10:22 +08:00
redis 会丢数据，哪怕是每个 cmd 都落盘也是不安全的。
|
 |
12
Ipopker 2018-12-24 13:24:37 +08:00 via iPhone
对 etcd 等了解不够深入，和 zookeeper 区别大吗？
|
 |
13
fuyufjh 2018-12-24 13:39:57 +08:00
完全不是一个东西
etcd 的目的是做分布式锁以及集群核心配置，核心特性是高可用，多副本 Paxos 全是为了高可用，性能不重要 redis 的目的是分布缓存，容量要大，响应要快，可用性差不多就行了 |
|
15
pifuant 2018-12-24 13:54:36 +08:00
@kaxi， 如果高可用为前提， 那么就要搞分布式， 那么一致性协议少不了， 现在那些分布式协议， 或多或少都是 paxos 变体， 如果和 paxos 不相关， 基本说白缺乏 safety 保证 （ paxos 就是这么吊）
|
|
17
pifuant 2018-12-24 13:58:42 +08:00
redis 的问题就是支持功能太多了， 踏踏实实搞缓存不好吗， 一些鸡肋功能， 就是坑害小白开发者的， 比如(redlock)
|
 |
18
XiLiGe 2018-12-24 14:06:02 +08:00
redis 有可能丢数据，保证不了高可用把。
|
 |
19
jimrok 2018-12-24 14:10:44 +08:00
分布式系统最重要的就是一致性协议，redis 是不支持的。如果发生脑裂，可能两个微服务都会声称自己对某段 IP 的请求负责。
|
|
20
kaxi OP 多谢各位。
简单总结一下： 高可用的角度，redis 主从是异步复制的机制，这就导致了其有丢失数据的风险。redis 的哨兵或 cluster 解决的是系统的可服务性确保在有单点故障的情况下也能对外提供服务，但是因为异步复制的机制在从升主的过程中或者网络分区的情况下都是有可能丢失数据的。etcd 基于 raft 协议在写入数据的时候需要多数应答确认后才会向客户端返回数据写入成功这就保证了数据的一致性。etcd 除此外还有其他的一些特性优势。 |
 |
22
Raymon111111 2018-12-24 16:57:14 +08:00
CAP 中 redis 不是 C 的. 还是老老实实用 zk 吧
|
Select Language