redis持久化机制

1.什么是redis持久化？

redis持久化是在指定时间间隔内，将redis内存中的数据写到磁盘中，如果redis服务器宕机了，可以从磁盘上读数据到内存中，从而恢复数据。

2.RDB方式

rdb方式原理

redis会单独创建（fork）一个与当前进程一模一样的子进程来进行持久化，这个子线程的所有数据（变量。环境变量，程序程序计数器等）都和原进程一模一样，会先将数据写入到一个临时文件中，待持久化结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程不进行任何的io操作，这就确保了极高的性能。

执行步骤：

1. Redis调用系统中的fork函数复制一份当前进程的副本(子进程)
2. 父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件。
3. 当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此，一次快照操作完成。

触发rdb持久化的机制

• bgsave：fork子线程进行持久化。特点是：边持久化边处理客户端的请求。
• save：创造快照之前不会处理客户端的请求。save命令并不常用，只有在没有足够的内存来处理bgsave命令时，才考虑使用save方式。save命令持久化比rdb命令持久化要快，50g的内存数据用save只需要3-5分钟，而bgsave需要15-20分钟。
• shutdown或term时：会执行save命令，阻塞所有客户端的操作，在save命令执行结束后，自动关闭redis服务器。
• 执行主从复制操作：主从复制时，从服务器向主服务器发送一个sync的信号，主服务器开始用bgsave方式创建快照。
• save 60 1000：满足添加时，使用该方式。
• 执行flushall命令：里面是空的，无意义

rdb持久化方式的优缺点

缺点：使用RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这个时候我们就需要根据具体的应用场景，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受范围。如果数据相对来说比较重要，希望将损失降到最小，则可以使用**AOF**方式进行持久化
优点： RDB可以最大化Redis的性能：父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无需执行任何磁盘I/O操作。同时这个也是一个缺点，如果数据集比较大的时候，fork可以能比较耗时，造成服务器在一段时间内停止处理客户端的请求；
使用场景： 因此rdb持久化方式只适用于即使丢失一部分数据，也不会对系统造成影响的场景。

rdb的遗留问题

**问题：**rbd边持久化，边处理客户端的请求。也就是说持久化的同时，内存数据结构还在变化，如果一个大型的hash正在持久化，此时客户端提交一个请求，把他删掉，此时还没有持久化结束，这应该怎么搞？
解决方法：redis使用操作系统的多线程cow（copy on Write）机制来实现快照持久化。

3.AOF（append only file）方式

默认情况下Redis没有开启AOF（append only file）方式的持久化。

原理

开启AOF持久化后，每执行一条会更改Redis中的数据的命令，Redis就会将该命令追加至硬盘中的AOF文件，这一过程显然会降低Redis的性能，但大部分情况下这个影响是能够接受的，另外使用较快的硬盘可以提高AOF的性能。

基本配置

# 可以通过修改redis.conf配置文件中的appendonly参数开启
appendonly yes   

# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。
dir   ./   

# 默认的文件名是appendonly.aof，可以通过appendfilename参数修改
appendfilename   appendonly.aof

触发机制

# 每次执行写入都会进行同步， 这个是最安全但是是效率比较低的方式（慢，安全）
appendfsync always  

# 每一秒执行（默认值,很快，但可能会丢失一秒以内的数据）
appendfsync everysec    

# 不主动进行同步操作，由操作系统去执行，这个是最快但是最不安全的方式
appendfsync no  	

AOF 重写机制

# 当aof文件增量到一定百分比的时候，redis调用bgrewriteaof对日志进行重写。当aof文件的增长率大于此配置时，会自动开启重写。
auto-aof-rewrite-percentage 100
# 当aof文件增量达到啊一定值是，redis调用bgrewriteaof对日志进行重新。当AOF文件大小大于该配置项时自动开启重写。
auto-aof-rewrite-min-size 64mb

重写原因：aof持久化采用的是向aof文件追加命令的方法，所以会使aof文件特别大，一方面耗尽了硬盘的可用空间，另一方面恢复数据时间特别长，所以需要进行重写。
重写原理：redis会创建一个子进程，子进程对aof文件进行重写，主进程继续会客户端提供读写服务。但是因为创建进程而导致性能问题和内存占用问题。另一方面，如果不加一控制aof文件的大小，aof文件特别大的时候重写和删除旧文件的时候，会导致操作系统挂起数秒。所有需要设置上述两个参数，保证aof文件的大小不会过大。

AOF文件损坏以后如何修复

**原因：**服务器可能存在在aof文件写入时停机，如果停机造成aof文件写入出错，导致重启时aof文件因为出错而不能恢复数据，从而确保数据的一致性不会被破坏。
修复方法：

1. 为现有的 AOF 文件创建一个备份
2. 用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复。

redis-check-aof --fix readonly.aof

3.重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。

4.RDB和AOF的选择

rdb和aof的选择

1.如果可以承受数分钟以内的数据丢失，那么可以只使用 RDB 持久化。rdb 适合大规模的数据恢复，对数据完整性和一致性不高 ， 在一定间隔时间做一次备份，如果redis意外down机的话，就会丢失最后一次快照后的所有操作
2.有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快 。

# 禁止RDB方式
save ""

3.两种持久化策略可以同时使用，也可以使用其中一种。如果同时使用的话， 那么Redis重启时，会优先使用AOF文件来还原数据。

性能建议（这里只针对单机版redis持久化做性能建议）：

1. 因为RDB文件只用作后备用途，只要15分钟备份一次就够了，只保留save 900 1这条规则。
2. 如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
3. 只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

5. redis 4.0混合持久化

原因

重启redis时，很少用rdb来恢复内存状态，因为会丢失大量数据。通常采用AOF方式，重读AOF日志性能相对rdb来说要慢很多，启动会花费大量的时间。为了解决这个问题，引入了混合持久化方式。

原理

混合持久化是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后在将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据。

配置参数

# 4.0版本的混合持久化默认关闭的，通过aof-use-rdb-preamble配置参数控制，yes则表示开启，no表示禁用，5.0之后默认开启。
aof-use-rdb-preamble

优缺点

优点： 由于绝大部分都是RDB格式，加载速度快，同时结合AOF，增量的数据以AOF方式保存了，数据更少的丢失。
缺点： 兼容性差，一旦开启了混合持久化，在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差