使用过Redis，我居然还不知道Rdb

时间  2019-12-07
标签 使用 redis 居然 还不 知道 rdb 栏目 Redis 繁體版
原文   原文链接

目录html

使用过Redis，那就先说说使用过那些场景吧

字符串缓存

//举例
$redis->set();
$redis->get();
$redis->hset();
$redis->hget();

队列

//举例
$redis->rpush();
$redis->lpop();
$redis->lrange();

发布订阅

//举例
$redis->publish();
$redis->subscribe();

计数器

//举例
$redis->set();
$redis->incr();

排行榜

//举例
$redis->zadd();
$redis->zrevrange();
$redis->zrange();

集合间操做

//举例
$redis->sadd();
$redis->spop();
$redis->sinter();
$redis->sunion();
$redis->sdiff();

悲观锁

解释：悲观锁(Pessimistic Lock), 顾名思义，就是很悲观。git

每次去拿数据的时候都认为别人会修改，因此每次在拿数据的时候都会上锁。github

场景：若是项目中使用了缓存且对缓存设置了超时时间。redis

当并发量比较大的时候，若是没有锁机制，那么缓存过时的瞬间，数据库

大量并发请求会穿透缓存直接查询数据库，形成雪崩效应。vim

/**
 * 获取锁
 * @param  String  $key    锁标识
 * @param  Int     $expire 锁过时时间
 * @return Boolean
 */
public function lock($key = '', $expire = 5) {
    $is_lock = $this->_redis->setnx($key, time()+$expire);
    //不能获取锁
    if(!$is_lock){
        //判断锁是否过时
        $lock_time = $this->_redis->get($key);
        //锁已过时，删除锁，从新获取
        if (time() > $lock_time) {
            unlock($key);
            $is_lock = $this->_redis->setnx($key, time() + $expire);
        }
    }

    return $is_lock? true : false;
}

/**
 * 释放锁
 * @param  String  $key 锁标识
 * @return Boolean
 */
public function unlock($key = ''){
    return $this->_redis->del($key);
}

// 定义锁标识
$key = 'test_lock';

// 获取锁
$is_lock = lock($key, 10);
if ($is_lock) {
    echo 'get lock success<br>';
    echo 'do sth..<br>';
    sleep(5);
    echo 'success<br>';
    unlock($key);
} else { //获取锁失败
    echo 'request too frequently<br>';
}

乐观锁

解释：乐观锁(Optimistic Lock), 顾名思义，就是很乐观。缓存

每次去拿数据的时候都认为别人不会修改，因此不会上锁。安全

watch命令会监视给定的key，当exec时候若是监视的key从调用watch后发生过变化，则整个事务会失败。服务器

也能够调用watch屡次监视多个key。这样就能够对指定的key加乐观锁了。网络

注意watch的key是对整个链接有效的，事务也同样。

若是链接断开，监视和事务都会被自动清除。

固然了exec，discard，unwatch命令都会清除链接中的全部监视。

$strKey = 'test_age';

$redis->set($strKey,10);

$age = $redis->get($strKey);

echo "---- Current Age:{$age} ---- <br/><br/>";

$redis->watch($strKey);

// 开启事务
$redis->multi();

//在这个时候新开了一个新会话执行
$redis->set($strKey,30);  //新会话

echo "---- Current Age:{$age} ---- <br/><br/>"; //30

$redis->set($strKey,20);

$redis->exec();

$age = $redis->get($strKey);

echo "---- Current Age:{$age} ---- <br/><br/>"; //30

//当exec时候若是监视的key从调用watch后发生过变化，则整个事务会失败

上面的一些场景，我们大部分都使用过，却尚未说起到Rdb文件。

“对吧，使用过Redis，殊不知道Rdb文件，你中枪了吗？”

Rdb文件是什么，它是干什么的

Redis 做为互联网产品开发中不可缺乏的常备武器，它性能高、数据结构丰富、简单易用，但同时也是由于太容易用了，无论什么数据、无论这数据有多大、无论数据有多少，统统塞进去，最后致使的问题就是 Redis 内存使用持续上升，可是又不知道里面的数据是否是有用，是否能够拆分和清理，最可怕的是服务器发生宕机后，Redis 数据库里的全部数据将会所有丢失。

好比当内存上升，性能慢时，咱们进行性能调优的时候，咱们想知道：

  • 哪些Key占用了大量的内存？
  • 想知道每一个Key的占用空间？
  • 想知道占用空间大的Key都存了啥？
  • 想知道占用空间大的Key的重要性，当性能慢的时候是否能够立刻删除？
  • 更想知道这些Key是哪一个业务方，哪一个开发建立的？这样就能够找他沟通了。

尝试解决问题的思路

1、先经过 keys * 命令，拿到全部的 key，而后根据 key 再获取全部的内容。

  • 优势：能够不使用 Redis 机器的硬盘，直接网络传输。
  • 缺点：若是 key 数据特别多，keys 命令可能会直接致使 Redis 卡住，从而影响业务使用 或 对 Redis 请求太屡次，资源消耗多，遍历数据太慢。

2、开启 aof，经过 aof 文件获取全部的数据。

  • 优势：无需影响 Redis 服务，彻底离线操做，足够安全。
  • 缺点：有一些 Redis 实例写入频繁，不适合开启 aof，普适性不强；aof 文件有可能特别大，传输、解析起来太慢，效率低。

3、使用 bgsave，获取 rdb 文件，解析后获取数据。

  • 优势：机制成熟，可靠性好；文件相对小，传输、解析效率高。
  • 缺点：bgsave 虽然会 fork 子进程，但仍是有可能致使主进程卡住一段时间，对业务有产生影响的风险。

综合评估后，决定采用低峰期在从节点作 bgsave 获取 rdb 文件，相对安全可靠，也能够覆盖全部业务的 Redis 集群。

也就是说每一个实例天天在低峰期自动生成一个 .rdb 文件，即便报表数据有一天的延迟也是能够接受的。

“哦，原来.rdb文件是磁盘的缓存文件，那么如何开启持久化呢？”

下面简单的介绍下，Redis 的持久化。

Redis 支持两种方式的持久化，一种是RDB方式，一种是AOF方式。

RDB 是 Redis 用来进行持久化的一种方式，是把当前内存中的数据集，快照写入磁盘。

RDB - 自动

RDB（Redis DataBase）方式是经过快照完成的，当符合必定条件时Redis会自动将内存中的全部数据进行快照，而且存储到硬盘上，RDB是Redis的默认持久化方式。

vim /usr/local/redis/conf/redis.conf

save 900 1    #15分钟内有至少1个键被更改
save 300 10   #5分钟内至少有10个键被更改
save 60 1000  #1分钟内至少有10000个键被更改

#以上条件都是或的关系，当知足其一就会进行快照。

dbfilename "dump.rdb"       #持久化文件名称
dir "/data/dbs/redis/6381"  #持久化数据文件存放的路径

#配置文件修改后，须要重启redis服务。

还能够经过命令行的方式进行配置：

CONFIG GET save    #查看redis持久化配置

CONFIG SET save "100 20" #修改redis持久化配置

#使用命令行的方式配置，即时生效，服务器重启后须要从新配置。

RDB - 手动

  • save

该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其余命令，直到RDB过程完成为止。

显然该命令对于内存比较大的实例会形成长时间阻塞，这是致命的缺陷。

  • bgsave

执行该命令时，Redis会在后台异步进行快照操做，快照同时还能够响应客户端请求。

具体操做是Redis进程执行fork操做建立子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段。

AOF

AOF（APPEND ONLY MODE）是经过保存对redis服务端的写命令（如set、sadd、rpush）来记录数据库状态的，即保存你对redis数据库的写操做。

配置日志文件以下：

vim /usr/local/redis/conf/redis.conf
dir "/data/dbs/redis/6381"           #AOF文件存放目录
appendonly yes                       #开启AOF持久化，默认关闭
appendfilename "appendonly.aof"      #AOF文件名称（默认）
appendfsync no                       #AOF持久化策略
auto-aof-rewrite-percentage 100      #触发AOF文件重写的条件（默认）
auto-aof-rewrite-min-size 64mb       #触发AOF文件重写的条件（默认）

#上面的每一个参数，能够找资料了解下，不作多解释了。

RDB 与 AOF 的优缺点，见上面的便可。

至此，咱们了解了 Redis 持久化的一些配置，里面的细节建议查询相关资料进行研究。

接下来继续，经过上一步咱们拿到了 rdb 文件，就至关于拿到了Redis实例的数据。

  1. 解析 rdb 文件，获取key和value的值。
  2. 根据相应的数据结构及内容，估算内存消耗。
  3. 统计并生成报表。

分析工具

  • 雪球 rdr：https://github.com/xueqiu/rdr
  • redis-rdb-tools：https://github.com/sripathikrishnan/redis-rdb-tools

小结

  1. 讲解了工做中经常使用的 redis 使用场景。
  2. 讲解了 redis 持久化的两个方式（RDB、AOF）。
  3. 推荐了两个分析rdb的工具。

经过对 redis 的使用 到 了解到服务器上如何对redis数据作持久化快照，再到如何利用工具进行分析rdb文件，最后经过分析后的数据，能够反过来对 redis 的使用提出一些建议。

其余知识点也是这样，咱们不能只停留在方法的简单调用，就以为理解了这门技术！

联想

其实上面分析出来的数据，是不可能定位到这个key是哪一个业务方的，哪一个开发建立的，是否重要等等，那咱们应该怎么作呢？

  1. 制定开发团队的Redis Key的使用规范，经过key的命名能够获得：
    • 属于什么业务（加域名表示）
    • 属于什么数据类型（加数据类型标示）
    • 是否设置过时时间
    • ...
  2. 统一平台进行Redis Key的申请，只有申请了才能进行使用：
    • 填写申请人
    • 填写申请时间
    • 填写申请业务方
    • 填写数据类型
    • 填写Key的重要性
    • 填写Key是否存在过时时间
    • 根据填写项生成规范的key名称
    • ...(等等须要标记的)

  3. 上面咱们已经能分析出某个redis实例rdb文件的内容，经过分析出来的内容 与 统一平台申请的数据，进行整合，分析key的合格率、内存使用量、不一样数据类型的分布、内存占用量Top 100的值 等等。

  4. 咱们能够经过运维了解到，每一个服务器与实例之间的配置关系，就能够了解到某台服务器（N个实例）上的 key的合格率、内存使用量、不一样数据类型的分布、内存占用量Top 100的值等等。

这样，在后台系统中就能够看到哪台服务器，哪一个实例的使用状况，解决了Redis滥用并没有法进行监控的问题。

推荐阅读

本文欢迎转发，转发请注明做者和出处，谢谢！

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程