redis数据持久化

redis是内存型的nosql数据库，所以数据安全必须考虑，redis支持将数据持久化到磁盘。redis持久化的方式有两种：RDB(Snapshotting，默认方式)和AOF。

1. RDB

1.1 运行原理

1. 在某些时刻，redis通过fork产生子进程，一个父进程的快照，其中有和父进程当前时刻相同的数据；
2. 父进程继续处理client请求，子进程负责将快照（数据副本）写入临时文件；
3. 子进程写完后，用临时文件替换原来的快照文件，然后子进程退出；

1.2 细节

1. 若果发生系统崩溃，则会丢失最近一次rdb之后的数据，所以如果项目不能接受这样的数据损失，还需要其他安全手段
2. 不适于实时性持久化，但其数据体量小，执行速度快，适合做数据版本控制；
3. 如果数据量巨大，则创建子进程的时间长，导致redis卡顿，要谨慎设置save参数时间间隔大一些；或如果软件允许，可以每天在闲时手动同步（凌晨后...）
4. 将生成的快照文件，留在原地，则可以在重启redis后，保持数据状态；将生产的快照文件，复制到其他redis服务中心，可以方便的将数据移植过去；

优点：

• 性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO 最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能
• 相对于数据集大时，比 AOF 的启动效率更高。

缺点：

• 数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

1.3 配置

save 900 1   #900秒超过1个key被修改

save 300 10   #300秒超过10个key被修改（删除所有save项，则会关闭rdb）

dbfilename dump.rdb  #快照文件名

stop-writes-on-bgsave-error yes  #快照失败后是否继续写操作

rdbcompression yes  #是否压缩快照文件

1.4 触发方式

1. 某一个save参数被满足；

2. 执行bgsave

3. 执行save

4. redis服务关闭时

2. AOF

2.1 原理

1. redis将每一个写操作（执行成功），写入一个aof文件；
2. redis重启时只要从头到尾执行一次aof文件，即可恢复数据；也可以将aof文件复制到别的服务器，做数据移植；

注意：在重启时，要恢复数据，如果rdb文件和aof文件同时存在，以aof为准

2.2 细节

1. aof文件会不断增长（可能比快照文件大几倍），在极端情况下，可能会对硬盘空间造成压力；
2. redis重启时，需要重新执行一个可能非常大的aof，时间会很长
3. aof同步时间间隔小，数据更安全，理论上至多丢失1秒的数据，比rdb更擅长做更实时的持久化

优点：

• 数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次 命令操作就记录到 aof 文件中一次。
• 通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
• AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）)

缺点：

• AOF 文件比 RDB 文件大，且恢复速度慢。
• 数据集大的时候，比 rdb 启动效率低。

2.3 配置

appendonly yes  #启动aof机制

appendfsync always  #每次收到写命令就立即强制写入磁盘，保证完全的持久化，但产生极大的IO开销（不推荐使用）

appendfsync everysec  #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的这种（推荐使用）

appendfsync no  #由操作系统决定何时同步，如果系统宕机则导致redis丢失不定数量数据

appendfilename “appendonly.aof”  #设置aof文件名

3. AOF重写

3.1 原理

为了减小aof文件的体量，可以手动发送bgrewriteaof命令，则会创建子进程，生成更小体量的aof，然后替换掉旧的、大体量的aof文件。

3.2 细节

1. 如果当前数据量巨大，则子进程创建过程会很耗时；
2. 在替换aof文件时，如果旧的aof很大，则删除它也是一个耗时的过程；

3.3 配置

# 在体量超过64mb，且比上次重写后的体量增加了100%时自动触发重写

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

4. 如何选择合适的持久化方式

1. 一般来说， 如果想达到足以媲美PostgreSQL的数据安全性，你应该同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

2. 如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。

3. 有很多用户都只使用AOF持久化，但并不推荐这种方式，因为定时生成RDB快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免AOF程序的bug。

4. 如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。