Redis缓存容灾怎么帮忙恢复故障，缓存那块的那些事儿和技巧

说到Redis缓存容灾和恢复故障,这事儿其实就跟咱们给家里的贵重物品做备份和想好丢了怎么办的预案是一个道理，你不能等到东西真丢了，才捶胸顿足，下面我就把缓存这块的事儿和技巧，掰开揉碎了说说。

Redis为什么会“挂”？先搞清楚故障从哪来

缓存不是金刚不坏之身,它也会出问题，常见的故障大概有这么几类：

1. Redis服务自己挂了：比如服务器断电了、Redis进程莫名其妙崩溃了、或者服务器本身硬件坏了，这是最直接的一种故障。
2. 网络出问题了：你的应用程序和Redis服务器之间的网络连接不稳定或者干脆断了，就算Redis本身活得好好的，你的应用也用不了它。
3. Redis被“撑死了”：也就是内存不够用了，如果数据一直往里写，又没有设置合理的淘汰策略，或者有大量数据没设置过期时间，内存迟早会爆掉，导致Redis无法写入新数据，甚至崩溃。
4. 人为失误：这个很常见，比如有运维同学不小心执行了FLUSHALL命令，把整个缓存数据都给清空了，这简直是灾难性的。

容灾的核心：备份与副本（主从复制）

容灾,说白了就是“别把鸡蛋放在一个篮子里”，对于Redis，最核心的容灾手段就是主从复制。

• 它是怎么玩的？ 你至少要有两个Redis实例，一个当作“老大”（主节点），专门负责处理写操作；另一个或多个当作“小弟”（从节点），专门从“老大”那里同步数据，主要负责读操作。
• 怎么帮忙恢复故障？ 当“老大”突然挂掉的时候，你不能干等着，这时候，运维人员或者一些自动化工具（例如Redis Sentinel哨兵）会迅速行动，从剩下的“小弟”中选出一个各方面都健康的，把它提拔成新的“老大”，把应用程序的连接指向这个新“老大”，这样，整个系统就能在较短的时间内恢复写服务，因为数据在旧“老大”挂掉之前，已经基本同步到新“老大”那里了。
• 技巧与注意点：
  • 读写分离：平时就可以让从节点分担主节点的读请求压力，这叫一箭双雕。
  • 哨兵模式：强烈建议使用Redis Sentinel，它可以自动监控主从节点的健康状态，并在主节点故障时自动完成切换和通知，大大减少了人工干预的需要和恢复时间。
  • 从节点不是越多越好：每个从节点都会占用资源，而且从节点同步数据也会对主节点和网络造成压力，根据业务需要设置适量的从节点即可。

数据持久化：最后的“救命稻草”

主从复制能解决服务高可用的问题,但如果遇到更极端的情况，比如所有Redis实例所在的数据中心都遭遇了灾难，主从节点全挂了怎么办？这时候就需要用到数据持久化机制了，这相当于给你的缓存数据拍个快照或者记个流水账，存到硬盘上。

Redis主要提供两种方式：

1. RDB（快照）：在特定的时间点，把当前内存中的所有数据生成一个压缩的二进制文件（dump.rdb）保存起来。
   • 优点：文件小，恢复速度快，非常适合做灾难备份。
   • 缺点：可能会丢数据，比如你设置每5分钟保存一次，如果服务器在4分59秒的时候挂了，那这5分钟内的数据就全没了。
2. AOF（追加日志）：把每一次写命令都记录到一个日志文件里，当Redis重启时，会重新执行一遍AOF文件里的所有命令，从而恢复数据。
   • 优点：数据安全性高，最多丢一秒的数据（如果配置为每秒同步一次）。
   • 缺点：文件通常比RDB大，恢复速度慢。

• 怎么帮忙恢复故障？ 当一个新的Redis实例被创建出来（比如换了一台新服务器），你可以把之前备份的RDB文件或者AOF文件放进去，然后启动Redis，Redis就会自动加载这些文件，将数据恢复到内存中。
• 技巧与注意点：
  • 混合使用：生产环境通常建议同时开启RDB和AOF，用RDB做定期的冷备，用AOF保证数据安全性，这样重启时优先用AOF恢复，因为数据更完整。
  • 备份文件要异地存放：不要把备份文件和Redis服务器放在同一台机器或同一个机房，否则机房一断电，备份也跟着没了。

缓存没了怎么办？—— “缓存穿透、击穿、雪崩”的应对技巧

除了Redis本身故障,缓存的使用姿势不对，也会引发严重的“逻辑性故障”。

1. 缓存穿透：有人一直请求一个数据库中根本不存在的数据，因为缓存里没有，所以每次请求都会打到数据库上，导致数据库压力巨大。

   • 技巧：
     • 缓存空对象：即使数据库查不到，也在缓存里存一个空值（并设置一个较短的过期时间），这样下次同样的请求就直接返回空了，不会访问数据库。
     • 布隆过滤器：在缓存之前加一道布隆过滤器，它可以快速判断一个数据“一定不存在”或“可能存在”，对于“一定不存在”的请求，直接拦截掉。

2. 缓存击穿：一个热点数据（比如某个明星的爆款商品信息）在缓存中过期了，此时有海量的请求同时来访问这个数据，这些请求会全部涌向数据库，把它“击穿”。

   • 技巧：
     • 永不过期：对极少数核心热点数据，可以设置成永不过期，由后台服务定期更新。
     • 互斥锁：当缓存失效时，不是所有线程都去查数据库，而是让一个线程去查，然后重建缓存，其他线程等待，这样可以避免对数据库的并发冲击。

3. 缓存雪崩：在同一时间，缓存中大量的数据都过期了，或者Redis集群整体宕机，导致所有请求都落向数据库，造成数据库瞬间压力过大而崩溃，像雪崩一样。

   • 技巧：
     • 设置随机过期时间：给不同的数据设置过期时间时，加上一个随机值，避免大量数据同时失效。
     • 构建高可用集群：这就是我们前面说的主从复制+哨兵模式，确保Redis服务本身尽量不挂。
     • 服务降级和熔断：在应用层面，如果发现数据库压力过大，可以暂时拒绝部分非核心请求，或者返回默认值，保住核心服务。

总结一下

Redis的容灾和故障恢复,是一个系统工程，它需要：

• 事前预防：搭建主从副本、配置合理的持久化策略、设置分散的过期时间。
• 事中监控与切换：依靠哨兵等工具快速发现故障并自动切换。
• 事后恢复：利用备份文件快速重建缓存。

还要结合良好的缓存设计技巧,来应对穿透、击穿、雪崩这些常见问题，把这些“篮子”都准备好了，哪怕真的丢了一两个“鸡蛋”，你的系统也能比较从容地应对。