Redis中的两种持久化机制RDB和AOF

什么是RDB（Redis DataBase）

RDB：每隔一段时间，把内存中的数据写入到磁盘的临时文件中，作为快照，恢复是时候把快照文件读进内存中。如果宕机重启，那么内存的数据肯定会被清除的，那么再次启动redis，则会进行数据恢复。

备份与恢复

内存备份–>磁盘临时文件
临时文件–>恢复到内存

RDB的优劣势

• 优势
  1. 每个一段时间进行备份，全量备份。
  2. 灾备简单，可以进行远程传输。
  3. 子进程备份的时候，主进程不会有任何的io操作，保证备份数据的完整性。
  4. 与AOF相比，RDB允许大型数据集更快地重启。
• 劣势
  1. 发生故障时，有可能会丢失最后一次备份的数据。
  2. 子进程所占用的内存会跟主进程的一模一样，会造成cpu负担。
  3. 由于定时备份是重量级操作，所以对与实时备份就无法处理了。

RDB的配置

# The filename where to dump the DB
dbfilename dump.rdb  # RDB持久化文件名

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./     # 数据持久化文件存储目录

# RDB自动持久化规则
# 当 900 秒内有至少有 1 个键被改动时，自动进行数据集保存操作
save 900 1
# 当 300 秒内有至少有 10 个键被改动时，自动进行数据集保存操作
save 300 10
# 当 60 秒内有至少有 10000 个键被改动时，自动进行数据集保存操作
save 60 10000

# yes:如果save过程出错，则停止写的操作。
# no :可能会照成数据不一致。
stop-writes-on-bgsave-error yes

# yes : 开启rdb的压缩模式。
# no :关闭会节约cpu消耗，但文件会变大。
rdbcompression yes

# yes:使用CRC64算法校验对rdb进行数据校验，有10%性能损耗。
# no :不校验。
rdbchecksum yes

总结

RDB适合大量数据的恢复，但数据的一致性和完整性可能会不足。

什么是AOF （Append Only File）

快照功能（RDB）并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。 从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。

AOF的特点

1.以日志的形式来记录用户写的操作。读操作不会记录，因为只有写的操作才会被存储。
2.文件以追加的形式，而不是以修改的形式。
3.redis的aof恢复其实就是把追加的文件从开发到结尾读取执行写操作。

AOF的优劣势

• 优势
  1.AOF更加耐用，可以以秒级单位备份，如果发生故障也只会丢失最后一秒的数据，大大增加了数据的可靠性和完整性。所以AOP可以进行秒级备份，使用fsync操作。
  2.以log日志的形式追加，如果磁盘满了，会执行redis-check-aof工具。
  3.当数据太大的时候redis可以在后台自动重写aof，当redis继续把日志追加到老的文件中去时，重写也是非常安全的，不会影响客服端的读写操作。
  4.AOF日志包含了所以的写操作，会更加便于redis的恢复。
• 劣势
  1.相同的数据，同一份数据，AOF会比RDB大。
  2.针对不同的同步机制，AOF会比RDB慢，因为APF每秒都在做写的备份。每秒备份fsync没毛病，但如果客服端的每秒写入就做一次备份fsync的话，那么redis的性能就会下降。
  3.AOF发生过bug，就是数据恢复的时候数据不完整，这样显得AOF会比较脆弱，容易出现bug，因为AOF没有RDB那么简单，但是为了防止bug的产生，AOF不会根据旧的指令去重构，而是根据当时缓存中存在的数据指令去重构，这样就更加可靠。

AOF配置

# AOF 默认关闭，yes可以开启
appendonly no

# AOF 的文件名
appendfilename "appendonly.aof"

# no：不同步
# everysec：每秒备份，推荐使用
# always：每次操作都会备份，安全并且数据完整，但是慢性能差
appendfsync everysec

# 重写的时候是否要同步，no可以保证数据安全
no-appendfsync-on-rewrite no

# 重写机制：避免文件越来越大，自动优化压缩指令，会fork一个新的进程去完成重写动作，新进程里的内存数据会被重写，此时旧的aof文件不会被读取使用，类似rdb
# 当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m，满足两者则触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

到底采用RDB还是AOF呢？

1. 如果你接受一段时间的数据丢失，那么你可以采用RDB。
2. 如果你对实时性的数据比较care，那么就采用AOF。
3. 使用RDB和AOF结合一起做持久化，RDB做冷备，可以在不同的时期对不同的版本做恢复，AOF做热备，保证数据仅仅只有一秒的损失。当AOF破损不能用，那么再用RDB恢复，这样就可以做到两者的相互结合，也就是说redis恢复会先加载AOF，如果AOF有问题了再加载RDB，这样就可以达到热冷备份的目的。