Redis 持久化

Redis持久化的意义？

​ 意义在于故障恢复，redis挂掉了，而存放在内存中的数据没了，重启之后要花费很多时间去恢复redis，如果不使用持久化，不能应对灾难恢复。所以我们要定期对数据同步和备份到一些云存储服务器服务器上面。可以恢复相当大部分数据，但不能保证绝对不丢数据。

​ 能让redis尽可能的高可用，宕机之后尽快地重启让它对外提供服务。如果能把redis持久化做好，备份和恢复方案做到企业级的程度，那么redis故障了，也可以通过数据备份快速恢复，一旦恢复即可马上对外提供服务

Redis RDB、 AOF区别、特点

RDB：相当于内存快照，记录的是当前redis的所有键值对的快照，

AOF：则每次接收到一个操作，都为在AOF文件当中追加记录，而且每次是先写到OS cache当中，然后每秒都会 将OS cache当中的数据刷入到磁盘当中。AOF只有一个，而且会越来越大，当AOF达到一定程度之后，会对AOF做rewrite操作，再fork一个新的线程，先生成一个AOF副本，然后基于当前redis内存当中最新的数据（LRU淘汰之后），构造更小的数据集存放的副本当中，然后将旧的，很大的AOF文件给删除掉。

如果两种都使用，会优先使用AOF来恢复

我们可以将RDB 或者AOF文件被分到云服务器上面，重启的时候可以从云服务拷贝下来，然后重新启动redis，redis就会根据该备份文件快速恢复数据

RDB的优点

可以生成多个数据文件，每个数据文件都代表某一个时刻中redis的数据，这种多个数据文件的方式非常适合做冷备份，可以将一份完整的数据文件发送到远程的安全存储上面去，以预定的备份策略去恢复redis的数据，并且能保证redis性能保持在较高的一个水平，redis只需要fork一个子进程，才执行磁盘IO操作才进行RDB持久化.

RDB的缺点

如果redis故障了，RDB可能无法恢复较为完整的数据，一般来说每隔5分钟才会生成一次，这时候redis宕机了，则会就是最近5分钟的数据.

AOF持久化机制的优点

AOF可以更好的保护数据不丢失，一般AOF会每隔1秒钟，通过一个后台线程执行一次fsync操作，保证os cache的数据写入磁盘当中。所以最多最多也就丢掉1秒钟的数据

AOF日志是以append-only模式写入的，每次是接着在最后写，不会有任何磁盘随机寻址的开销，写入性能非常高，而且文件不容易破损，即使破损了也是文件尾部破损，容易修复。

rewrite的时候还是写入老的日志

AOF记录的日志是人易读的，比如有人不小心flushall了，那么我们可以把AOF文件拿出来，把最后一条的flushall删掉，再重启redis，就可以恢复到之前所有的数据

AOF持久化的缺点

对于同一份数据来说，AOF会比RDB更大

开启AOF会消耗额外的性能开销，每秒都要fsync 操作

如果想redis一条数据都不丢，那就每条操作都执行一次fsync,那样的话redis的性能会大大下降，不过1秒一次还是可以接受的。

每次AOF都会基于AOF的文件去重新构建内存的数据，所以恢复的时间会比较长。做冷备份不太方便。

AOF和RDB之间该如何选择？

不仅仅要使用RDB，因为这样会导致丢时很多数据

也不仅仅使用AOF，做冷备份很慢，AOF不够健壮，而且恢复机制可能出现bug

所以，它们应该总和使用，用AOF保证数据不丢失，用RDB做快速冷备份。这样即使AOF都丢失了，我们仍然可以到云服务器上面拉去RDB文件下来进行数据恢复。