redis引发的小事故

项目内部环境的数据库采用的是Redis + Mysql模式，由于其他原因，测试环境的服务器宕机，重启后惊喜发现redis中的数据全不见了！！直接导致测试环境的崩溃。之前虽知道redis数据存在内存中，但仍然是有办法可以备份和恢复数据的。

Redis一种有两种方式存储数据，分别是：

AOF （append-only file）和 RDB（Redis DataBase）

搜索一番之后决定先用AOF模式进行数据恢复。 先说一下为什么不用RDB模式进行存储：RDB是在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。

优点：使用单独子进程来进行持久化，主进程不会进行任何IO操作。可以保证Redis的高性能。

缺点：RDB是隔一段时间进行持久化，如果持久化之间redis发生故障，则数据可能会丢失。所以这种模式更适合对数据要求不严谨的时候。

AOF将“操作”和“数据”以格式化指令的方式追见到操作日志文件的尾部，在append操作返回后（已经写入文件或者即将写入），才进行实际的数据变更，“日志文件”保存了历史所有的操作过程，当server需要数据恢复时，可以直接replay此日志文件，即可还原所有的操作过程，它和mysql中的bin.log、apache.log功能类似。

优点：可以保持更高的数据完整性，如果设置追加file的时间是1s，如果redis发生故障，最多会丢失1s的数据；且如果日志写入不完整支持redis-check-aof来进行日志修复；AOF文件没被rewrite之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的flushall）。

缺点：AOF文件比RDB文件大，而且恢复速度慢。

我们可以简单粗暴地认为AOF就是一个日志文件，此文件只记录数据的“变更操作”比如set/del等等，如果server中持续的大量变更操作，将会导致AOF文件非常的庞大，意味着恢复数据的时间会很长；事实上，如果对一条数据 进行多次更新，我们只需要恢复最后一次操作数据的操作即可。

AOF的特性决定了它相对比较安全，如果你期望数据丢失更少，那么AOF无意是最佳选择，如果AOF文件正在写入的过程中server突然挂掉，有可能导致最后一次记录不完整，我们可以功过手工，或者程序的方法去检测并修正不完整的记录，以便通过AOF文件恢复能够正常。

在Linux服务器中设置aof模式只需配置三行。找到redis的配置文件rediso.conf

# 开启

appendonly yes

# 指定aof文件名

appendfilename appendonly.aof

# 指定同步策略

appendfsync everysec

只需三行配置，配齐后重启redis就齐活了。妈妈再也不用担心你的数据会丢失啦。