Redis怎么防止数据丢失，保证数据安全那些事儿你得知道

主要综合自Redis官方文档的持久化章节、以及技术社区如Redis Labs知识库和多位资深开发者的实践经验分享）

Redis虽然快，但它把数据都存在了内存里，内存这玩意儿，一断电数据就全没了，你要是用Redis存了些丢不得的东西，比如用户购物车、关键的业务状态，那就必须得想办法把内存里的数据找个稳妥的地方存起来，防止服务器突然宕机导致数据丢失，这事儿说白了，就是给Redis上“保险”，Redis自己提供了几种主要的“上保险”方式，你得知道它们分别是咋回事,以及该怎么选。

第一种保险：RDB快照（Snapshotting）

想象一下给Redis的数据拍一张全景照片，RDB就是这个照片，你可以设置一个规则，比如每隔一小时拍一张，或者当数据发生了至少100次变化时拍一张，当满足条件时，Redis会创建一个压缩过的二进制文件（后缀是.rdb）,这个文件就是那个时间点数据的完整备份。

• 好处是什么？

  • 恢复快：如果出问题了，用这个RDB文件恢复数据非常迅速,因为它是整个数据集的加载。
  • 文件紧凑：RDB文件是压缩的，占用的磁盘空间小，方便你把它备份到别的地方，比如阿里云OSS、AWS S3这些云存储上,做容灾备份。
  • 对性能影响小：因为是通过创建子进程来生成RDB文件，主进程还能继续处理命令,不会卡住。

• 坏处是什么？

  • 可能丢数据：这是最要命的缺点，如果离上次拍照片刚过5分钟，服务器宕机了，那这5分钟里新增或修改的数据就全丢了，所以RDB适合那些能容忍丢失几分钟数据的场景，比如存一些排行榜、缓存数据。

第二种保险：AOF日志（Append Only File）

AOF的思路和RDB完全不同，它不拍照片，而是像个记账先生，把你对Redis做的每一个写命令（比如set、hmset）都原原本本地记到一个日志文件里，当Redis重启的时候，它就把这个日志里的命令从头到尾再执行一遍,这样数据就恢复回来了。

• 好处是什么？

  • 数据安全度高很多：你可以配置AOF的刷盘策略，设置为“每秒同步一次”，那最多也就丢一秒的数据，甚至可以设置为“每次写命令都同步”，这样几乎不会丢数据,但性能代价很高。

• 坏处是什么？

  • 文件大：AOF文件记录的是原始命令，日积月累会非常大,比RDB文件大很多。
  • 恢复慢：重启时重放所有命令来恢复数据，如果日志文件很大,这个过程会非常漫长。

为了克服AOF的缺点，Redis有个“重写”机制，简单说，就是Redis会开辟一个子进程，根据当前数据库的状态，反向计算出一个新的、更简洁的AOF文件，比如你先后执行了set a 1和set a 2，重写后新的AOF文件里可能就只记录最后一条set a 2，这样就大大减少了文件体积，这个重写过程可以是自动的,也可以手动触发。

我到底该选哪个？

这得看你的数据有多金贵。

• 如果你追求最高的数据安全，一点都不能丢：那就同时开启RDB和AOF（这是生产环境的常见做法），用AOF来保证数据不丢失，作为主用的恢复手段；同时定期用RDB做一次冷备份，因为RDB的数据恢复速度更快,而且更适合做历史归档和灾难恢复。
• 如果数据丢了也没太大关系，主要是图个快：比如纯粹做缓存，那可以只使用RDB，并设置一个合理的快照周期（比如15分钟一次）,平衡一下性能和丢失数据的风险。
• 如果愿意牺牲一点性能换取更高的安全性，但觉得同时开两个太麻烦：可以只使用AOF，并配置为“每秒同步”的策略,这在很多场景下已经足够安全了。

除了上面这两种“保险”，还有更高级的保障手段：主从复制

光把数据存在本地硬盘上还不够，万一硬盘坏了呢？你可以给Redis搭一个“主从架构”，就是弄一台主Redis服务器（Master），再弄一台或多台从Redis服务器（Slave），主服务器负责写，从服务器会自动、实时地把主服务器上的数据同步过来,这样有几个好处：

1. 数据多了一个备份：主服务器挂了,从服务器上还有一份完整的数据。
2. 可以读写分离：读请求可以发给从服务器,减轻主服务器的压力。
3. 高可用的基础：配合哨兵（Sentinel）这样的工具，主服务器宕机后，哨兵能自动把一个从服务器提升为新的主服务器，让服务继续运行,几乎不停机。

总结一下，保证Redis数据安全不是单一措施就能搞定的,它是个组合拳：

• 持久化（RDB/AOF） 是基础,防止服务器重启数据丢失。
• 主从复制 是扩展，防止单点故障,实现数据异地备份。
• 定期备份 是把RDB或AOF文件拷贝到别的安全地方（比如云存储），这是最后一道防线,防止物理灾难。

你得根据自己的业务对数据安全性和性能的要求，来选择合适的组合策略，别嫌麻烦，等真出了事，你就会觉得这些“保险”买得真值。