大家使用 redis 的时候，有考虑 redis 挂的场景？

Redis 集群？

考虑呀但是没有特别去做降级，按目前的 SLA 看起来只需要简单返回错误就够了宕机时间太短

肯定有人考虑过啊，所以才有了集群吗不是。

看 SLA 要求，不是特别变态的话 redis 做了集群就不用太考虑挂掉这个场景

小项目，从来没挂过。

redis 本身也有 HA 啊

整个集群都挂的场景一般不考虑 (成本很大, 除非有很强的理由要不然做容灾也需要考虑性价比的

@aptupdate 它这意思说的就是不管是单点 redis 还是 cluster 还是什么，外部的 cache 出问题不可用的时候，应用内要怎么处理

1. 单点 redis 挂了，可以走 sentinel 2. 集群本身有高可用 3. 应用层，缓存不可访问就查库，或者直接 error 告警

脱离场景谈技术都是刷流氓

项目不大，话没考虑挂掉的情况。写了个自动快照脚本，每一小时打个快照，哪里有问题迅速回滚

@RedisMasterNode
讲道理这个问题的思考方向应该是：我怎么不让强依赖的中间件挂掉，而不是：中间件挂掉了我业务怎么处理

挂了立马重启

挂了邮件通知，赶紧重启

做好本地缓存方案又要考虑多个节点的本地缓存一致性了， 然后又要考虑内存出错、IO 出错之类的场景了

它挂就让它挂

let it crash 也是一种极好的解决方案

彻底挂了还好，redis 有时也会僵死，才叫麻烦。

@cominghome 你可以问下楼主，我看楼主意思就是大家平时设计的时候有没有在应用层内考虑中间件挂掉了怎么降级和保持可用性；

你说的完全是另一个事情，而且每个使用的中间件都会考虑，也就没有必要单独问了，比如如何防止 Redis 挂掉

HA 加哨兵啊

Redis 做好告警，引入任何依赖都会考虑不可用的情况，尽可能在依赖挂掉的情况下，影响面小一点。

但是如果强依赖的话，那也没办法，一处挂处处挂。

上高斯 Redis，N-1 级别高可用

redis 作为缓存，本来就应该做到完全不依赖的程度，redis 是用来提速的，不是用来硬性依赖的

主从集群加多机房异地，不行再上单元化，这要是都挂了就认命吧。如果单说降级这一点，那可以再来一套分布式缓存方案做冷备

redis 官网都曾经几次因为 redis 挂了导致官网几小时内无法访问，直接把错误信息都打出来了

提前做好挂掉一台或者多台的准备，增加 HA 的健康检查，redis 搞集群，分级告警出来，未雨绸缪，一个好的架构一台或者几台挂掉都不会影响核心服务。

主从+Sentinel or Cluster，反对上面说的不依赖 redis，redis 能做的不仅仅是缓存，再说缓存崩了，那是会雪崩的！ HA 一定要保证

KEEPALIVED VIP 漂移

感觉与其给 redis 做 HA，不如给整个机房做 HA

必然会。而且需要从两方面考虑，一是从 Redis 运维的角度部署 Cluster，保障集群本身的高可用；二是从应用角度编写逻辑，当集群真的不可用时，转为从数据库中捞数据或是有预期内的异常暴露。

首先讨论 redis 挂的情况， 这种情况 会自动降级，比如兜底方案或不展示某些边缘信息，因为这个过程不会持续很长时间的，否则也没有必要做 redis 挂了的假设或处理；
其次是 redis 不会挂，原因有：1. redis 现在本身已经是做了高可用，比如集群； 2.再者服务部署多主多从，多机房，尤其是多机房，在高可用里是有要求的，比如 两个机房不能在一个城市，距离上有严格的要求否则形同虚设， 这是为了应对那种极端的灾难， 例如地震 山洪 等。

redis 的功能太多了，导致 ha 方案很难兼顾所有功能。比如说，如果只作为缓存使用的话，用主备就够了，最多是数据不太新鲜而已。而如果作为分布式锁（建议别用），或者一些计数的功能，主备之间的延迟就会影响数据的一致性，必须要保证强一致，不知道目前有没有能保证强一致的方案。这两种场景所要解决的数据访问特征是完全不同的，前者全是读，后者也有一部分写，甚至读写差不多频率，前者更关注的是负载，后者更关注数据的一致和高可用。其实后者不建议使用 redis 了，有更适合的方案，比如 etcd 。