redis持久化策略浅析

作为目前作为流行的cash,redis除了支持丰富的数据类型之外,还支持对内存中u数据的持久化,这样一来便可以防止因为一些崩溃情况(突然间断电、内存吃满)造成的整个内存数据的丢失,这对我们来说无疑是巨大的帮助。这里我们简单的了解一下redis持久化的策略,下面是自己的一些总结,如有错误,请及时指正。

redis实现数据持久化的两种策略

1、rdb(redis database)-- 快照持久化

1.1、什么是rdb?

rdb是redis的一种数据持久化策略,redis将某一时间点的数据全部打包生成一个.rdb的文件,保存在磁盘中,当我们重启redis服务的时候,将会读取该rdb文件恢复数据库中的数据。

1.2、如何生成rdb快照

手动生成rdb快照:

  • redis客户端发送bgsave命令来创建rdb快照

  • redis客户端发送save命令来创建rdb快照

  • redis客户端发送shutdown命令,redis服务端会在收到命令后先产生rdb快照,再关闭服务

自动生成rdb快照:

  • redis基于redis配置文件的 save规则进行自动生成快照,具体的配置项请参考1.3

1.3、关于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文件要保存的位置

2、aof(append only file ) -- 只追加文件持久化

2.1、什么是aof(append only file)?

aof同样是redis的持久化策略,采用该策略的时候,redis会将被执行的写命令添加到aof文件的末尾,该文件被保留在磁盘中。当重启redis服务的时候会优先(相对于rdb文件而言)读取aof文件,完成对redis数据的恢复。

2.2、关于aof持久化相关的配置

a、appendonly,该选项决定了是否开启aof持久化策略

配置名称配置选项解释说明
appendonlyyes / no决定是否开启aof策略,默认情况下是no

b、appendfsync, 该选项决定了写入aof文件的频率

配置名称配置选项解释说明
appendfsyncalways每一个redis写命令都会被写入到aof文件中,这样会严重降低redis的速度
appendfsynceverysec每秒钟执行一次同步,将这一秒钟之内接受到的命令写入aof文件中
appendfsyncno并不是不进行aof持久化,而是让操作系统决定什么时候将命令写入aof文件中,这样我们丢失的数据将不可控

c、no-appendfsync-on-rewrite, 当服务器出现短暂性的阻塞的时候,通常情况下,如果我们执行bgsave或者bgrewriteof命令时,可能会造成服务的短暂挂起,此时该选项决定是否还将命令同步到aof文件

配置名称配置选项解释说明
no-appendfsync-on-rewriteyes当服务器出现短暂性阻塞的时候,不将命令同步到aof文件中,暂时放入内存,知道阻塞结束后再同步
no-appendfsync-on-rewriteno当服务器出现阻塞时仍然尝试将命令追加到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-percentage100(任意数字都可以)如果为100的话,就表示当aof文件相对于上次的aof文件大小要增加一倍,也就是now_file_size >= last_file_size * (1 + auto-aof-rewrite-percentage / 100 ),此时便会试着出发bgrewrite,当然还要看另外一个条件
auto-aof-rewrite-min-size64mb(一个指定大小)如果为64mb的话,就表示当aof文件 >= 64mb 的时候,尝试进行bgrewrite重写 ,当然还要看另外一个条件

e、appendfilename,选项决定了产生的aof文件的名称,举个例子 : appendfilename "appendonly.aof"

f、dir aof文件要保存的位置,该选项同时决定了aof和rdb两个文件的保存位置

3、准备工作

为了方便测试工作,基于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、举个例子

4.1、rdb策略持久化的例子

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

4.2、aof策略持久化的例子

更新redis的配置如下
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

测试的流程大致相同,这里不再详细介绍,相同的测试脚本再次执行,发现key并没有任何丢失,这是由于redis每秒钟同步一次的缘故,在这种配置下,如果写入很频繁,也就是丢失1秒钟的数据

5、参考资料

《redis实战》
《redis入门指南》
http://redisdoc.com/topic/per...
https://my.oschina.net/wfire/...
http://blog.nosqlfan.com/html...

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值