使用过Redis,我竟然还不知道Rdb
使用过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), 顾名思义,就是很悲观。
每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁。
场景:如果项目中使用了缓存且对缓存设置了超时时间。
当并发量比较大的时候,如果没有锁机制,那么缓存过期的瞬间,
大量并发请求会穿透缓存直接查询数据库,造成雪崩效应。
/** * 获取锁 * @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是哪个业务方,哪个开发创建的?这样就可以找他沟通了。
尝试解决问题的思路
一、先通过 keys * 命令,拿到所有的 key,然后根据 key 再获取所有的内容。
- 优点:可以不使用 redis 机器的硬盘,直接网络传输。
- 缺点:如果 key 数据特别多,keys 命令可能会直接导致 redis 卡住,从而影响业务使用 或 对 redis 请求太多次,资源消耗多,遍历数据太慢。
二、开启 aof,通过 aof 文件获取所有的数据。
- 优点:无需影响 redis 服务,完全离线操作,足够安全。
- 缺点:有一些 redis 实例写入频繁,不适合开启 aof,普适性不强;aof 文件有可能特别大,传输、解析起来太慢,效率低。
三、使用 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实例的数据。
- 解析 rdb 文件,获取key和value的值。
- 根据相应的数据结构及内容,估算内存消耗。
- 统计并生成报表。
分析工具
- 雪球 rdr:https://github.com/xueqiu/rdr
- redis-rdb-tools:https://github.com/sripathikrishnan/redis-rdb-tools
小结
- 讲解了工作中常用的 redis 使用场景。
- 讲解了 redis 持久化的两个方式(rdb、aof)。
- 推荐了两个分析rdb的工具。
通过对 redis 的使用 到 了解到服务器上如何对redis数据做持久化快照,再到如何利用工具进行分析rdb文件,最后通过分析后的数据,可以反过来对 redis 的使用提出一些建议。
其他知识点也是这样,我们不能只停留在方法的简单调用,就觉得理解了这门技术!
联想
其实上面分析出来的数据,是不可能定位到这个key是哪个业务方的,哪个开发创建的,是否重要等等,那我们应该怎么做呢?
- 制定开发团队的redis key的使用规范,通过key的命名可以得到:
- 属于什么业务(加域名表示)
- 属于什么数据类型(加数据类型标示)
- 是否设置过期时间
- ...
- 统一平台进行redis key的申请,只有申请了才能进行使用:
- 填写申请人
- 填写申请时间
- 填写申请业务方
- 填写数据类型
- 填写key的重要性
- 填写key是否存在过期时间
- 根据填写项生成规范的key名称
- ...(等等需要标记的)
上面我们已经能分析出某个redis实例rdb文件的内容,通过分析出来的内容 与 统一平台申请的数据,进行整合,分析key的合格率、内存使用量、不同数据类型的分布、内存占用量top 100的值 等等。
我们可以通过运维了解到,每个服务器与实例之间的配置关系,就可以了解到某台服务器(n个实例)上的 key的合格率、内存使用量、不同数据类型的分布、内存占用量top 100的值等等。
这样,在后台系统中就可以看到哪台服务器,哪个实例的使用情况,解决了redis滥用并无法进行监控的问题。
本文欢迎转发,转发请注明作者和出处,谢谢!
上一篇: 安装mysql
下一篇: swfupload 多文件上传实现代码