Redis数据备份那些事儿，怎么才能不丢数据又安全还靠谱

Redis数据备份那些事儿,怎么才能不丢数据又安全还靠谱

想把Redis里的数据保管好,不让它丢，还能在出问题时马上恢复，这事儿得花点心思，你不能只靠一种方法，得几种方法结合起来用，才算得上稳妥。

第一招：用好Redis自带的“拍照”和“记日记”功能 Redis自己就有两种看家本领，叫做RDB和AOF。 RDB好比是“拍照”，隔一段时间，Redis就把内存里所有的数据完整地拍一张快照，存成一个文件，这个文件很小，恢复起来也飞快，如果上次“拍照”之后服务器突然坏了，那之后新来的数据可就全丢了，你可以在配置文件里（根据Redis官方文档的说明）用“save”指令来设置拍照频率，save 900 1”意思是900秒内至少有1个键被改动就拍一次，为了更安全，你可以设得勤快点，比如每分钟甚至每几秒拍一次，但这可能会稍微影响点性能。 AOF就好比是“记日记”，Redis会把每一个写操作命令，都原原本本地记到一个日志文件里，服务器重启时，把日记重新执行一遍，数据就全回来了，这样数据丢失的风险极低，最多也就是丢日记最后没写完的那一条命令，你可以设置日记同步到硬盘的频率（appendfsync参数），选“everysec”是每秒同步一次，在速度和安全性之间比较平衡，但日记文件会越来越大，恢复起来也慢，所以Redis还提供了“AOF重写”功能，会自动把日记里重复、无效的操作压缩掉，相当于把日记本誊写精简一遍。

第二招：把“照片”和“日记”副本存到别处 光靠Redis自己存文件在本地硬盘上，万一硬盘坏了，或者整个服务器没了，那备份也就跟着没了，你必须定期把RDB快照文件和AOF日志文件拷贝到别的地方去，这叫做“异地备份”。 你可以写个简单的脚本，定时（比如每天半夜）把备份文件复制到另一台不同的物理服务器、或者云存储（比如阿里云的OSS、腾讯云的COS）上，这样就算生产服务器彻底故障，你手里还有一份昨天的备份可以用，这是最朴素也最关键的一步。

第三招：主从复制，找个“备胎” Redis的主从复制功能，可以让你实时地拥有一个完全一样的“副本”数据库，你设置一台从服务器（slave），让它从主服务器（master）那里实时同步数据，这样即使主服务器宕机，你可以手动（或通过工具自动）把从服务器切换成主服务器，服务就能很快恢复，数据也基本没丢，根据《Redis设计与实现》中的原理，从服务器连接后，主服务器会先传一个完整的RDB快照给它，之后再把所有新的写命令实时传过去，你可以甚至搞个“从链”，让从服务器再有自己的从服务器，这样更安全，但记住，主从复制主要是为了高可用，它不能完全替代备份，因为万一你误操作删了主库的数据，从库也会立刻跟着删掉。

第四招：混合持久化，取长补短 从Redis 4.0开始，有了一个叫“混合持久化”的好东西，它结合了RDB和AOF的优点，当进行AOF重写时，它不再只是把命令记到新AOF文件里，而是先把当前数据用RDB格式完整地存到文件开头，然后把重写期间产生的新命令用AOF格式追加在后面，这样恢复的时候，既能有RDB的快速恢复基础数据，又能有AOF的精细数据完整性，你可以通过设置“aof-use-rdb-preamble”为yes来开启这个功能，很多线上环境都推荐这么做。

第五招：定期“演习”，验证备份能不能用 这是很多人会忽略，但极其重要的一步：定期恢复演练，你备份的文件，到底能不能用？恢复过程要多久？不试不知道，你应该定期（比如每季度）找一台测试服务器，把最新的备份文件拿出来，真实地恢复一个Redis实例，然后检查数据是否完整、服务是否正常，只有经过验证的备份，才是真正的备份，不然，真到出事那天，可能发现备份文件是坏的或者恢复流程根本走不通，那就为时已晚了。

最后唠叨几句 想真的不丢数据，你得根据自己能承受的数据丢失程度（比如是最多丢1秒数据，还是完全不能丢）来组合这些策略，一个比较靠谱的实践是：开启AOF每秒同步，同时开启混合持久化；配置合理频率的RDB快照；设置一个从服务器做实时副本；每天把备份文件自动传输到远端的云存储上，并且定期做恢复演练。 别怕麻烦，数据无价，多上一道保险，睡觉才能更安稳，这些方法在Redis官方文档和许多互联网公司的运维实践中都有据可查，是经过时间考验的可靠方案。