1. 我们的这个Redis示例使用AOF进行持久化(appendonly)

   appendfsync策略采用的是everysec刷盘。但是AOF随着时间推移，文件会越来越大，因此，Redis还有一个rewrite策略，实现AOF文件的减肥，但是结果的幂等的。我们no-appendfsync-on-rewrite的策略是no. 这就会导致在进行rewrite操作时，appendfsync会被阻塞。如果当前AOF文件很大，那么相应的rewrite时间会变长，appendfsync被阻塞的时间也会更长。

• 这不是什么新问题，很多开启AOF的业务场景都会遇到这个问题。解决的办法有这么几个：

  • 将no-appendfsync-on-rewrite设置为yes. 这样可以避免与appendfsync争用文件句柄，但是在rewrite期间的AOF有丢失的风险。

  • 给当前Redis实例添加slave节点，当前节点设置为master, 然后master节点关闭AOF，slave节点开启AOF。这样的方式的风险是如果master挂掉，尚没有同步到salve的数据会丢失。

AOF(append-only file只追加文件)持久化会将执行的写命令追加到AOF文件的末尾。在恢复数据时，只要从头到尾的执行AOF文件中包含的所有写命令即可（全量复制数据是这样实现的）

AOF可用配置：

image.png

• 其实主要的就是appendfsync配置项，有三个可选值，
  • always(每次执行写操作都要同步写入硬盘),
  • everysec(每秒执行一次同步),
  • no(让系统决定何时执行同步)。

虽然选择always可将数据丢失减少到最少，但这种策略会对硬盘进行大量的写入操作，处理命令速度受到硬盘限制。建议选择everysec。

• AOF优缺点

  • 优点：

    比快照方式可靠，默认每秒同步一次，意味着最多丢失一秒的数据

  • 缺点：

    相同数据集大小，AOF文件会比快照文件大

• AOF文件格式

  一开始以为Redis就是将写命令原封不动的存储到AOF文件中，自己试了一下才知道，AOF文件是使用Redis网络通讯协议的格式来保存这些命令。

• 压缩AOF文件

  Redis可以自动压缩(也可以叫重写)AOF文件，用户也可以通过BGREWRITEAOF命令来压缩AOF文件。这里的压缩，不是平时说的压缩的意思，是指创建一个新的文件来替换旧的文件，两个文件保存的数据状态完全一致。如果在本地手动执行BGREWRITEAOF命令，可以看到会生成一个temp-rewriteaof-*.aof的临时文件，在结束后替换appendonly.aof文件，从而减小appendonly.aof文件的大小。

需要注意的是:

Redis是启用子进程来进行AOF文件的压缩，在这期间主进程还是可以继续处理请求的，如果这时请求有写操作就可能导致当前数据库与压缩后的AOF不一致。Redis增加了一个缓存来解决这个问题，主进程在接收到新的写操作命令之后，会将命令写入现有的AOF文件和缓存中。在子进程完成新的AOF文件之后会将缓存的内容写入到新的AOF文件中，并改名覆盖旧的AOF文件。

RDB快照持久化

image.png

• RDB文件结构：

  RDB文件是一个经过压缩的二进制文件，不同类型的键值对会采用不同的方式来保存它们。具体的结构我也还没理清楚。。可以参考这篇文章 http://redisbook.com/preview/rdb/rdb_struct.html

• 创建快照, 创建快照的方式有以下几种：

  • 客户端发送BGSAVE命令。与压缩AOF文件一样，Redis会fork出一个子进程，由子进程负责将快照写入硬盘。
  • 客户端发送SAVE命令。Redis会开始创建快照，并且在快照创建完成之前不再处理其他命令。不常使用SAVE命令
  • 在满足配置的save m n选项时。比如，配置了save 60 1000,会在满足60秒内有1000次写入的时候开始创建快照。
  • 当接收到SHUTDOWN请求时，Redis会执行SAVE命令,并且不再执行任何其他命令。
  • 当从服务器向主服务器发送SYNC命令时，如果主服务器不是刚刚执行过BGSAVE命令,就会开始执行BGSAVE来创建快照

• 快照优缺点

  • 优点：

    • 文件紧凑,适用于做不同版本的数据备份
    • 与AOF相比在恢复大数据集时，更快
    • 很方便传送到另一个数据中心

  • 缺点：

    • 一旦Redis出现问题，上一次创建快照之后的数据就丢失了