恩,先说点题外话。上周被小虐了一丢丢,但有很大收获,了解了自己的不足,知道了自己还在哪些方面有欠缺。更坚定了一直以来的想法,应届生或者工作时间不长的人找工作公司规模,福利薪资都是浮云,跟对人才是最重要的,非常及其以及特别的重要,一个人好技术牛的部门leader绝对抵得上5K的薪资。这也完美解释了为何部门拆分,老大和磊哥走了之后这么不舒服,这尼玛相当于给我减了5K的工资啊,扯远了。。。。还是来看Redis吧,整理下Redis持久化的相关内容,加深下印象。不想看文字的可直接看下面的图?。

概要概要

AOF持久化

AOF(append-only file只追加文件)持久化会将执行的写命令追加到AOF文件的末尾。在恢复数据时,只要从头到尾的执行AOF文件中包含的所有写命令即可

AOF可用配置

配置项 含义 可选值
appendonly 是否开启AOF持久化 no,yes
appendfsync 将写命令同步到硬盘的间隔 everysec,always,no
no-appendfsync-on-rewrite 对文件进行压缩时能否执行同步操作 no,yes
auto-aof-rewrite-percentage 当前文件大小是上一次压缩后AOF文件大小的多少时执行自动压缩
auto-aof-rewrite-min-size 当前文件大小是多少时执行自动压缩
dir path/to/appendonly.aof 文件存放位置

其实主要的就是appendfsync配置项,有三个可选值,always(每次执行写操作都要同步写入硬盘),everysec(每秒执行一次同步),no(让系统决定何时执行同步)。虽然选择always可将数据丢失减少到最少,但这种策略会对硬盘进行大量的写入操作,处理命令速度受到硬盘限制。建议选择everysec

AOF优缺点

优点:

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

缺点:

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

AOF文件格式

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

1
2
127.0.0.1:6379> set number 21
OK

将上面的命令存储到AOF文件就是下面的样子(select 0命令是代表选择id为0的数据库):

1
2
3
4
5
6
7
8
9
10
11
12
*2
$6
SELECT
$1
0
*3
$3
SET
$6
number
$2
21

来看下AOF文件的格式,了解它的格式可以让我们很容易的解析它,指不定哪天能用到啊?。*号代表命令参数的个数(在上面的例子中参数为set、number、21,共3个),$号代表第N个参数的长度,在上面的例子中,三个参数的长度分别为3,6,2。

压缩AOF文件

Redis可以自动压缩(也可以叫重写)AOF文件,用户也可以通过BGREWRITEAOF命令来压缩AOF文件。这里的压缩,不是平时说的压缩的意思,是指创建一个新的文件来替换旧的文件,两个文件保存的数据状态完全一致。如果在本地手动执行BGREWRITEAOF命令,可以看到会生成一个temp-rewriteaof-*.aof的临时文件,在结束后替换appendonly.aof文件,从而减小appendonly.aof文件的大小。我知道这样说其实还是不好理解,还是上图吧。为了方便画图,我就默默假装Redis直接将命令按输入的样子存储到AOF文件中,不要拆穿我?。
假设执行的写命令是下面的样子:
执行的写操作

执行的写操作
那么看看在压缩前AOF文件的样子(就是存储了除get命令外的所有写命令):
压缩前的AOF文件

压缩前的AOF文件
接着执行BGREWRITEAOF命令,Redis会生成一个新的文件来替换旧的AOF文件,从而达到压缩的目的:
压缩后的AOF文件

压缩后的AOF文件

可以看到压缩前文件中存储了7条写命令,压缩后只存储一条。而且执行set number 1和6次incr number命令 ,与执行set number 7命令效果是一样的。从而即保证了数据的正确性又压缩了文件的大小。

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

快照持久化

快照可用配置

配置项 含义 可选值
save m n m秒内有n次写入时创建快照
stop-writes-on-bgsave-error 创建快照失败后是否继续执行写命令 no,yes
rdbcomression 是否压缩快照文件 no,yes
dbfilename 命名快照文件
dir path/to/dump.rdb 文件存放位置

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出现问题,上一次创建快照之后的数据就丢失了

转: https://yemengying.com/2016/04/24/Redis-Persistence/