Redis持久化配置

前言

上面要求要做一个投票功能，所以不能直接用mysql进行存储，而是先将数据库存储进redis，再用定时任务将redis的数据写入mysql。而为了防止redis因为服务器宕掉而导致数据的丢失情况出现，配置redis持久化是很有必要的。

关于持久化

Redis有两种持久化的方式：快照（RDB文件）和追加式文件（AOF文件）

RDB持久化方式是在一个特定的间隔保存某个时间点的一个数据快照。

AOF（Append only file）持久化方式则会记录每一个服务器收到的写操作。数据回复时，这些记录的操作会逐条执行从而重建出原来的数据。写操作命令记录的格式跟Redis协议一致，以追加的方式进行保存。

RDB

RDB就是Snapshot存储，是默认的持久化方式。

按照一定的策略周期性的将数据保存到磁盘。对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。Redis支持将当前数据的快照存成一个数据文件实现持久化。

而一个持续写入的数据库如何生成快照呢？Redis借助了fork命令的copy on write机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。

Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的。当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件。这样在任何时候出现故障，Redis的RDB文件都总是可用的。

RDB配置

快照自动保存策略：

保存地址：

工作原理

Redis调用fork()，产生一个子进程。

父进程继续处理client请求，子进程把内存数据写到一个临时的RDB文件。由于os的写时复制机制（copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照。

当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。

RDB优点

1）RDB文件是一个很简洁的单文件，它保存了某个时间点的Redis数据，很适合用于做备份。你可以设定一个时间点对RDB文件进行归档，这样就能在需要的时候很轻易的把数据恢复到不同的版本。

2）RDB很适合用于灾备。单文件很方便就能传输到远程的服务器上。

3）RDB的性能很好，需要进行持久化时，主进程会fork一个子进程出来，然后把持久化的工作交给子进程，自己不会有相关的I/O操作。

4）比起AOF，在数据量比较大的情况下，RDB的启动速度更快。

RDB缺点

1）RDB容易造成数据的丢失。假设每5分钟保存一次快照，如果Redis因为某些原因不能正常工作，那么从上次产生快照到Redis出现问题这段时间的数据就会丢失了。

2）RDB使用fork()产生子进程进行数据的持久化，如果数据比较大的话可能就会花费点时间，造成Redis停止服务几毫秒。如果数据量很大且CPU性能不是很好的时候，停止服务的时间甚至会到1秒。

AOF

快照并不是很可靠。如果服务器突然Crash了，那么最新的数据就会丢失。而AOF文件则提供了一种更为可靠的持久化方式。每当Redis接受到会修改数据集的命令时，就会把命令追加到AOF文件里，当你重启Redis时，AOF里的命令会被重新执行一次，重建数据。

AOF配置

在redis.conf默认配置中，aof为关闭状态，将其改为yes。：

保存策略：

重写策略：

第一行为配置当 AOF 文件需要比旧 AOF 文件增大多少时才进行 AOF 重写。

第二行为配置当 AOF 文件需要达到多大体积时才进行 AOF 重写。

只有这两个配置的条件都达到时，才会进行 AOF 重写。

aof持久化会把redis所有的写命令都保存到aof文件，使得aof文件越来越大，大大占用磁盘使用空间，也给还原redis数据很大时间。

那么怎么解决？aof是记录redis执行的写命令也就是一些重复执行的写命令都会记录到aof文件内，所以所删除重复的写入命令可以适当的缩小aof文件大小。

工作原理

1）redis fork一个子进程。

2）子进程基于当前内存中的数据，构建日志，开始往一个新的临时的AOF文件中写入日志。

3）redis主进程，接收到client新的写操作之后，在内存中写入日志，同时新的日志也继续写入旧的AOF文件。

4）子进程写完新的日志文件之后，redis主进程将内存中的新日志再次追加到新的AOF文件中。

5）用新的日志文件替换掉旧的日志文件。

AOF优点

1）AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。（保证数据完整性，对数据要求高的建议使用）

2）AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。（容易修改写入的命令）

3）AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL （清空数据）命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。

AOF 的缺点

1）对于具有相同数据的的 Redis，AOF 文件通常会比 RDF 文件体积更大。

2）虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证。

3）RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在 RDB 没有存在。

总结

可以同时开启RDB和AOF做数据备份。

在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

性能建议：

1）因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

2）如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。

只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写。

3）如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。