大家使用 redis 的时候，有考虑 redis 挂的场景？
hackingwu · hackingwu · 2021-05-13 17:51:27 +08:00 · 6432 次点击这是一个创建于 1290 天前的主题，其中的信息可能已经有所发展或是发生改变。
大家使用 redis 的时候，有考虑 redis 挂的场景吗？比如挂了走本地缓存，但是感觉想一想实现的好复杂，大家都是怎么处理的？
 |
1
kop1989 2021-05-13 17:54:10 +08:00
Redis 集群？
|
 |
2
RedisMasterNode 2021-05-13 17:55:27 +08:00
考虑呀但是没有特别去做降级，按目前的 SLA 看起来只需要简单返回错误就够了宕机时间太短
|
 |
3
aptupdate 2021-05-13 17:58:07 +08:00 via iPhone
肯定有人考虑过啊，所以才有了集群吗不是。
|
 |
4
cominghome 2021-05-13 17:58:50 +08:00
看 SLA 要求，不是特别变态的话 redis 做了集群就不用太考虑挂掉这个场景
|
 |
5
chenqh 2021-05-13 18:34:32 +08:00
小项目，从来没挂过。
|
 |
6
Jooooooooo 2021-05-13 18:37:46 +08:00
redis 本身也有 HA 啊
整个集群都挂的场景一般不考虑 (成本很大, 除非有很强的理由要不然做容灾也需要考虑性价比的 |
|
7
RedisMasterNode 2021-05-13 18:38:33 +08:00
@aptupdate 它这意思说的就是不管是单点 redis 还是 cluster 还是什么，外部的 cache 出问题不可用的时候，应用内要怎么处理
|
 |
8
leonme 2021-05-13 18:44:16 +08:00 via iPhone  1
1. 单点 redis 挂了，可以走 sentinel 2. 集群本身有高可用 3. 应用层，缓存不可访问就查库，或者直接 error 告警
|
 |
9
shawlib 2021-05-13 18:47:08 +08:00 1
脱离场景谈技术都是刷流氓
|
 |
10
40EaE5uJO3Xt1VVa 2021-05-13 18:53:26 +08:00
项目不大，话没考虑挂掉的情况。写了个自动快照脚本，每一小时打个快照，哪里有问题迅速回滚
|
|
11
cominghome 2021-05-13 19:09:25 +08:00
@RedisMasterNode
讲道理这个问题的思考方向应该是：我怎么不让强依赖的中间件挂掉，而不是：中间件挂掉了我业务怎么处理 |
 |
12
yeqizhang 2021-05-13 19:42:56 +08:00 via Android
挂了立马重启🙈
|
 |
13
Kaciras 2021-05-13 19:45:49 +08:00
挂了邮件通知，赶紧重启
|
 |
14
westoy 2021-05-13 19:47:56 +08:00
做好本地缓存方案又要考虑多个节点的本地缓存一致性了， 然后又要考虑内存出错、IO 出错之类的场景了
它挂就让它挂 let it crash 也是一种极好的解决方案 |
 |
15
nielinjie 2021-05-13 19:49:44 +08:00
彻底挂了还好，redis 有时也会僵死，才叫麻烦。
|
|
16
RedisMasterNode 2021-05-13 20:34:11 +08:00 3
@cominghome 你可以问下楼主，我看楼主意思就是大家平时设计的时候有没有在应用层内考虑中间件挂掉了怎么降级和保持可用性；
你说的完全是另一个事情，而且每个使用的中间件都会考虑，也就没有必要单独问了，比如如何防止 Redis 挂掉 |
 |
17
misaka19000 2021-05-13 21:32:23 +08:00
HA 加哨兵啊
|
 |
18
GoLand 2021-05-13 21:43:29 +08:00
Redis 做好告警，引入任何依赖都会考虑不可用的情况，尽可能在依赖挂掉的情况下，影响面小一点。
但是如果强依赖的话，那也没办法，一处挂处处挂。 |
 |
19
miao1007 2021-05-13 21:49:15 +08:00
上高斯 Redis，N-1 级别高可用
|
 |
20
opengps 2021-05-13 22:10:50 +08:00
redis 作为缓存，本来就应该做到完全不依赖的程度，redis 是用来提速的，不是用来硬性依赖的
|
 |
21
mreasonyang 2021-05-13 23:11:52 +08:00 via iPhone
主从集群加多机房异地，不行再上单元化，这要是都挂了就认命吧。如果单说降级这一点，那可以再来一套分布式缓存方案做冷备
|
 |
22
jinliming2 2021-05-14 00:55:29 +08:00
redis 官网都曾经几次因为 redis 挂了导致官网几小时内无法访问，直接把错误信息都打出来了
|
 |
23
liuliancao 2021-05-14 08:23:45 +08:00
提前做好挂掉一台或者多台的准备，增加 HA 的健康检查，redis 搞集群，分级告警出来，未雨绸缪，一个好的架构一台或者几台挂掉都不会影响核心服务。
|
 |
24
leafre 2021-05-14 08:56:44 +08:00
主从+Sentinel or Cluster，反对上面说的不依赖 redis，redis 能做的不仅仅是缓存，再说缓存崩了，那是会雪崩的！ HA 一定要保证
|
 |
25
polymerdg 2021-05-14 08:58:15 +08:00
KEEPALIVED VIP 漂移
|
 |
26
iseki 2021-05-14 09:07:16 +08:00
感觉与其给 redis 做 HA，不如给整个机房做 HA
|
 |
27
sirius1024 2021-05-14 09:24:43 +08:00
必然会。而且需要从两方面考虑，一是从 Redis 运维的角度部署 Cluster，保障集群本身的高可用；二是从应用角度编写逻辑，当集群真的不可用时，转为从数据库中捞数据或是有预期内的异常暴露。
|
 |
28
palmers 2021-05-14 14:24:12 +08:00
首先讨论 redis 挂的情况， 这种情况 会自动降级，比如兜底方案或不展示某些边缘信息，因为这个过程不会持续很长时间的，否则也没有必要做 redis 挂了的假设或处理；
其次是 redis 不会挂，原因有：1. redis 现在本身已经是做了高可用，比如集群； 2.再者服务部署多主多从，多机房，尤其是多机房，在高可用里是有要求的，比如 两个机房不能在一个城市，距离上有严格的要求否则形同虚设， 这是为了应对那种极端的灾难， 例如地震 山洪 等。 |
 |
29
ljzxloaf 2021-05-14 16:02:56 +08:00
redis 的功能太多了，导致 ha 方案很难兼顾所有功能。比如说，如果只作为缓存使用的话，用主备就够了，最多是数据不太新鲜而已。而如果作为分布式锁（建议别用），或者一些计数的功能，主备之间的延迟就会影响数据的一致性，必须要保证强一致，不知道目前有没有能保证强一致的方案。这两种场景所要解决的数据访问特征是完全不同的，前者全是读，后者也有一部分写，甚至读写差不多频率，前者更关注的是负载，后者更关注数据的一致和高可用。其实后者不建议使用 redis 了，有更适合的方案，比如 etcd 。
|
Select Language