Redis坏了怎么办？

前几天半夜和一位朋友讨论他们集群的问题。我本人大概7年前干过一次集群报废的事情（好在是实验环境摸索）一下重启了所有节点（当时安装在一台机器上了）。这种情况下机器已重启所有节点都重启，cluster大的特点是要半数以上存活。这种情况下开了持久化，他集群也组合不起来了。（也许有高人有其他办法，我当时是没办法，重建的）。

    当年我就在想一个问题，如果redis万一坏了或者奔溃了。我们日子还过不过了？必然是要过的啊。redis没发明出来之前难道系统不做了？

    这里首先要看redis存什么？存日志，出去。  一般来说我们都说两个场景A保持会话，还有B缓存。其他的我个人观点不用了。A场景如果说redis坏了，再起一个就行，这种信息也不需要持久化，没了就没了，不影响什么。B场景其实有点要命的，我们通常为了减轻RDBMS的压力，即让NoSQL来打辅助，关系数据库集中精力做在线交易。所以高频次读取的放到Redis中减轻访问关系数据库的压力。  

  这里的缓存有B1这种来源是关系型数据库的一条记录，反复读取（但是一致性不要求那么高），那么就放到Redis中，差一点也没关系，比如点赞数量。B2场景是把关系型数据库的统计结果放到Redis中。这种一旦遇到redis坏了，或者缓存被击穿了。那么有两种现象，一种是直接就报错不能提供服务。还有一种就是玩命去关系型数据库中去聚合，结果是马上关系型数据库也不行了。

   所以我一直主张是B2的场景再关系型数据库中落地，redis一旦出问题了，查关系型数据库的表，因为是点查，所以压力其实也还好。毕竟是直接读的结算结果，而不是实时计算。这个有本质的差别。而且Redis单线程，关系数据库要么是多线程要么是多进程的。数据库服务器的配置一定是能抗住的。

  即redis坏了也不影响主流程走下去，最多是给关系型数据库增加了一点不愉快的压力。而redis日常是把这些辅助的压力拿去承担了。我们不能本末倒置，让redis成为核心环节，这样全压在单线程上，不科学。除非业务量实在是小，单线程妥妥支持，另当别论。

   一定要有他万一不能正常使用了，我们还要能继续用下去。要相信Oracle、MySQL、PG还有TiDB等等交易数据库处理缓存的能力是足够的，只是这些不是核心竞争力，分包一下给了一个优秀的集成商。当集成商出现问题时候，甲方自己也要能上。不能说集成商不做了，甲方自己也关门了。个人愚见。