redis持久化机制

redis相对与memcache最大的不同就是redis是单线程，且redis支持持久化，那么问题来了

面试常见问题，redis持久后有几种方式？

redis的两种持久化机制

1. RDB：RDB是redis的默认持久化机制（如果开始AOF，优先使用AOF）。 当满足一定条件，会把内存中数据写入磁盘生成快照dump.rdb。redis重启会加载dump.rdb文件恢复数据

RDB触发条件

1. 配置自动触发规则：配置多少秒内有多少个key被修改，触发持久化
2. shutdown触发，服务关闭时，触发持久化
3. 手动执行save命令触发。不过执行save生成快照时会阻塞redis服务器，如果内存中数据较多，会造成长时间阻塞
4. 执行bgsave命令，异步生成快照

RDB优势和劣势

优势

1. RDB是一个非常紧凑的文件，保存了redis在某个时间点的数据集。非常适合灾备和灾难恢复
2. RDB在恢复大数据集时，速度比AOF快
3. 支持异步生成RDB

劣势

1. RDB没有办法实现实时持久化/秒级持久化
2. 间隔一段时间进行持久化，如果redis意外挂掉，会丢失最后一次快照之后的所有数据

如果数据十分重要，想把损失降到最小，可以使用AOF持久化方式

2. AOF：redis默认不开启，需要在redis.conf中修改配置进行开启。AOF 采用写入日志的方式记录每个写操作，追加到日志中。开启后，执行更改redis命令，就会把命令写到AOF日志中。在 redis 重启的时候，会把AOF日志从前往后执行一遍以完成恢复工作。

AOF持久化策略

更改redis命令后，AOF并没有马上把数据写入硬盘，而是写入了硬盘缓存
持久化策略：appendfsync everysec

1. no：表示不执行同步,由操作系统保证数据同步到磁盘，速度快，但是不安全
2. always：表示每次写入都执行同步命令，保证数据同步到磁盘，但是效率低
3. everysec：表示每秒执行一次同步，如果服务器意外挂掉，也只是丢失一秒钟数据。兼顾安全和效率，默认使用该策略

那么问题来了。AOF记录命令日志，日志文件越来越大怎么办？

为了解决这个问题，redis增加了重写机制。当AOF文件超过所设定的阙值时，redis就会启动AOF文件的内容压缩，只保留恢复文件的最小指令集。

也可以使用bgrewriteaof命令来重写

AOF文件重写并不是对原文件进行整理，而是读取服务器中的键值对，然后用一条命令去替换之前记录这个键值对的多个命令，生成一个新的文件替换原来的AOF文件

如果在重写AOF时，新数据要写入AOF怎么办，可以修改conf配置。执行重写时，新写入命令放在缓存中，等重写完之后再写入AOF

AOF优势和劣势

优势

1. 支持多种同步频率，使用默认频率最多也就丢失一秒数据

劣势

1. AOF文件通常会比RDB文件更大
2. 高并发下RDB比AOF有更好的性能