作为目前作为流行的 cash,redis 除了支持丰富的数据类型之外,还支持对内存中 u 数据的持久化,这样一来便可以防止因为一些崩溃情况(突然间断电、内存吃满)造成的整个内存数据的丢失,这对我们来说无疑是巨大的帮助。这里我们简单的了解一下 redis 持久化的策略,下面是自己的一些总结,如有错误,请及时指正。
rdb 是 redis 的一种数据持久化策略,redis 将某一时间点的数据全部打包生成一个. rdb 的文件,保存在磁盘中,当我们重启 redis 服务的时候,将会读取该 rdb 文件恢复数据库中的数据。
手动生成 rdb 快照:
自动生成 rdb 快照:
a、save 选项的设置,最重要的一个配置,它直接决定了是否生成快照。redis 支持设置多条 save 规则,当其中的一条规则满足后就会自动的执行 bgsave 命令 (换句话说下面的这些规则是 或 的关系),下面是 redis 安装时的默认 save 规则
设置的规则 | 规则解释 |
---|---|
save 900 1 | 距离上一次执行 rdb 快照时间超过 900 秒,并且至少有 1 个键发生了改变,便会触发备份操作 |
save 300 10 | 距离上一次执行 rdb 快照时间超过 300 秒,并且至少有 10 个键发生了改变,便会触发备份操作 |
save 60 1000 | 距离上一次执行 rdb 快照时间超过 60 秒,并且至少有 1000 个键发生了改变,便会触发备份操作 |
b、rdbcompression 选项的设置,该规则决定是否对生成的 rdb 文件进行压缩
规则的选项 | 规则解释 |
---|---|
rdbcompression yes(默认是开启的) | 对生成的 rdb 快照文件进行压缩 |
rdbcompression no | 不对生成的 rdb 快照文件进行压缩 |
c、dbfilename 选项的设置,该规则决定了生成的. rdb 文件的名字,默认情况下的配置为 dbfilename dump.rdb
d、 stop-writes-on-bgsave-error 规则的设置,该规则决定了当 bgsave 备份命令执行失败的时候,redis 是停止接受客户端发送过来的写命令
规则的选项 | 规则解释 |
---|---|
stop-writes-on-bgsave-error yes(默认是开启的) | 当最近的一次 rdb 快照生成失败,redis 将不再接受相关的写命令,以此来提醒用户备份的失败 |
stop-writes-on-bgsave-error no | 最近一次的 rdb 快照生成失败,仍然接受 redis 客户端发送过来的写命令,不过需要要靠谱的监控系统提醒我们 rdb 快照失败了,否则不会有人知道的 |
e、rdbchecksum 是否校验 rdb 文件,这个配置项在实际的作用没怎么弄清楚, 有了解的同学可以解释下
规则的选项 | 规则解释 |
---|---|
rdbchecksum yes(默认是开启的) | 从版本 RDB 版本 5 开始,一个 CRC64 的校验就被放在了文件末尾。这会让格式更加耐攻击,但是当存储或者加载 rbd 文件的时候会有一个 10% 左右的性能下降, 所以,为了达到性能的最大化,你可以关掉这个配置项 |
rdbchecksum no | 没有校验的 RDB 文件会有一个 0 校验位,来告诉加载代码跳过校验检查 |
f、dbfilename 选项的设置,该规则决定了生成的. rdb 文件的名字,默认情况下的配置为 dbfilename dump.rdb
g、dir rdb 文件要保存的位置
aof 同样是 redis 的持久化策略,采用该策略的时候,redis 会将被执行的写命令添加到 aof 文件的末尾,该文件被保留在磁盘中。当重启 redis 服务的时候会优先(相对于 rdb 文件而言)读取 aof 文件,完成对 redis 数据的恢复。
a、appendonly,该选项决定了是否开启 aof 持久化策略
配置名称 | 配置选项 | 解释说明 |
---|---|---|
appendonly | yes / no | 决定是否开启 aof 策略,默认情况下是 no |
b、appendfsync, 该选项决定了写入 aof 文件的频率
配置名称 | 配置选项 | 解释说明 |
---|---|---|
appendfsync | always | 每一个 redis 写命令都会被写入到 aof 文件中,这样会严重降低 redis 的速度 |
appendfsync | everysec | 每秒钟执行一次同步,将这一秒钟之内接受到的命令写入 aof 文件中 |
appendfsync | no | 并不是不进行 aof 持久化,而是让操作系统决定什么时候将命令写入 aof 文件中,这样我们丢失的数据将不可控 |
c、no-appendfsync-on-rewrite, 当服务器出现短暂性的阻塞的时候,通常情况下,如果我们执行 bgsave 或者 bgrewriteof 命令时,可能会造成服务的短暂挂起,此时该选项决定是否还将命令同步到 aof 文件
配置名称 | 配置选项 | 解释说明 |
---|---|---|
no-appendfsync-on-rewrite | yes | 当服务器出现短暂性阻塞的时候,不将命令同步到 aof 文件中,暂时放入内存,知道阻塞结束后再同步 |
no-appendfsync-on-rewrite | no | 当服务器出现阻塞时仍然尝试将命令追加到 aof 文件 |
d、auto-aof-rewrite-percentage 和 auto-aof-rewite-min-size。由于,我们不断将 redis 执行的写命令追加到 aof 文件中,会导致 aof 文件越来越大,redis 就想出来一个办法,在保证 redis 存储数据正确的前提下,要尽可能的减少 aof 文件存储的命令,从而达到帮 aof 文件 "瘦身" 的目的。redis 的想到的办法就是执行 bgrewriteaof 命令,对 aof 文件进行重写,而这两个选项则决定了在什么情况下出发该命令。这里需要提到的一点是,这两个选项通常是一起使用,共同来决定是否执行 bgrewriteaof 命令。
配置名称 | 配置选项 | 解释说明 |
---|---|---|
auto-aof-rewrite-percentage | 100(任意数字都可以) | 如果为 100 的话,就表示当 aof 文件相对于上次的 aof 文件大小要增加一倍,也就是 now_file_size >= last_file_size * (1 + auto-aof-rewrite-percentage / 100),此时便会试着出发 bgrewrite,当然还要看另外一个条件 |
auto-aof-rewrite-min-size | 64mb(一个指定大小) | 如果为 64mb 的话,就表示当 aof 文件 >= 64mb 的时候,尝试进行 bgrewrite 重写 ,当然还要看另外一个条件 |
e、appendfilename,选项决定了产生的 aof 文件的名称,举个例子 : appendfilename "appendonly.aof"
f、dir aof 文件要保存的位置,该选项同时决定了 aof 和 rdb 两个文件的保存位置
为了方便测试工作,基于 yii 框架,写了一个测试脚本,脚本的内容如下:
- <?php
- namespace app\commands;
- use yii\console\Controller;
- class HelloController extends Controller
- {
- public static $START_TIME = null;
- public $number = 0;
- public function init()
- {
- parent::init();
- static::$START_TIME = time();
- }
- /**
- * redis database test
- */
- public function actionRedis()
- {
- $redis = \Yii::$app->redis;
- while(true) {
- $left_time = time() - static::$START_TIME;
- if($left_time > 10 && $this->number > 15) {
- echo "\r\n","total use {$left_time} seconds, and {$this->number} keys had been set","\r\n";
- break;
- } else {
- $key_name = "test:${left_time}:" . mt_rand(0, 9999);
- $redis->set($key_name, $key_name);
- echo $key_name,"\r\n";
- }
- $this->number++;
- sleep(1);
- }
- }
- }
4.1.1、更改 redis 配置如下
save 15 10
rdbcompression no
4.1.2、执行测试脚本
4.1.3、查看 redis 内存中的数据
4.1.4、查看 dump.rdb 文件
经过大约 15 秒左右的时间,我们发现在在指定的 data 目录下产生了一个 dump.rdb 文件
4.1.5、强杀 redis 服务,模拟宕机情况
4.1.6、重启 redis 服务,查看 redis 内存中的数据
经过对比发现,丢失了一些 key
更新 redis 的配置如下
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
测试的流程大致相同,这里不再详细介绍,相同的测试脚本再次执行,发现 key 并没有任何丢失,这是由于 redis 每秒钟同步一次的缘故,在这种配置下,如果写入很频繁,也就是丢失 1 秒钟的数据
《redis 实战》
《redis 入门指南》
http://redisdoc.com/topic/per...
https://my.oschina.net/wfire/...
http://blog.nosqlfan.com/html...
来源: http://www.tuicool.com/articles/F3Erii2