用过Redis，所以先说说那些场景Stringcache//例子$redis->set();$redis->get();$redis->hset();$redis->hget();queue//示例$redis->rpush();$redis->lpop();$redis->lrange();发布订阅//示例$redis->publish();$redis->subscribe();Counter//例子$redis->set();$redis->incr();Rankinglist//例子$redis->zadd();$redis->zrevrange();$redis->zrange();集合间操作//例子$redis->sadd();$redis->spop();$redis->sinter();$redis->sunion();$redis->sdiff();悲观锁解释：悲观锁（PessimisticLock），顾名思义，就是非常悲观。每次去拿数据，我都觉得别人会修改，所以我每次拿数据都会加锁。场景：如果项目中使用了缓存，并且为缓存设置了超时时间。当并发量比较大的时候，如果没有加锁机制，那么当缓存过期的时候，大量的并发请求会穿透缓存，直接查询数据库，造成雪崩效应。/***获取锁*@paramString$key锁ID*@paramInt$expire锁过期时间*@returnBoolean*/publicfunctionlock($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);}}返回$is_lock？true:false;}/***释放锁*@paramString$key锁ID*@returnBoolean*/publicfunctionunlock($key=''){return$this->_redis->del($key);}//定义锁ID$key='test_lock';//获取锁$is_lock=lock($key,10);if($is_lock){echo'获取锁成功
';echo'做某事..
';睡觉（5）；echo'成功
';unlock($key);}else{//获取锁失败echo'requesttoofrequently
';}乐观锁解释：乐观锁（OptimisticLock），顾名思义，就是非常乐观。每次去拿数据，我想别人不会修改，所以不会上锁。watch命令将监视给定的键。exec时，如果调用watch后监控的key发生了变化，则整个事务将失败。也可以多次调用watch来监控多个key。这样就可以给指定的key加上乐观锁了。注意watchkey对整个连接有效，事务是一样的。如果连接丢失，手表和交易都会自动清除。当然，exec、discard、unwatch命令会清除连接中的所有监听。$strKey='test_age';$redis->set($strKey,10);$age=$redis->get($strKey);echo"----当前年龄：{$age}----
";$redis->watch($strKey);//启动事务$redis->multi();//此时开启一个新会话，执行$redis->set($键,30);//新会话回显“----当前年龄：{$age}----
”；//30$redis->set($strKey,20);$redis->exec();$age=$redis->get($strKey);echo"----当前年龄：{$age}----
”；//30//exec时，如果调用watch后监听的key发生变化，则整个事务会失败上面的一些场景，我们大部分人都用过，只是没有提到rdb文件。“对了，我用过Redis，不知道Rdb文件，中枪了吗？”什么是Rdb文件，它有什么用？Redis作为互联网产品开发不可或缺的利器，性能高，数据结构丰富，简单易用，但也是因为太好用了。不管什么数据，不管多大的数据，不管有多少数据，全部塞进去。最后的问题是Redis的内存占用持续上升，但是他们不知道是什么里面。数据有没有用，能不能拆分清理，最可怕的是服务器宕机后，Redis数据库中的数据全部丢失。比如当内存增加，性能变慢的时候，我们在进行性能调优的时候，想知道：哪些键占用内存大？想知道每个键占用的空间吗？想知道占用大量空间的密钥中存储了什么吗？想知道占用大量空间的key的重要性，性能慢的时候能不能立马删掉？我想知道这些密钥是哪个业务方和哪个开发人员创建的？这样你就可以和他交流了。尝试解决问题的思路1.先通过keys*命令获取所有key，然后根据key获取所有内容。优点：可以直接通过网络传输，不需要使用Redis机器的硬盘。缺点：如果关键数据特别大，keys命令可能会直接导致Redis卡死，从而影响业务使用或者对Redis的请求过多，资源消耗大，数据遍历慢。2、开启aof，通过aof文件获取所有数据。优点：不影响Redis服务，完全离线运行，足够安全。缺点：部分Redis实例写入频繁，不适合开启aof，通用性不强；aof文件可能特别大，传输和解析太慢，效率低下。3、使用bgsave获取rdb文件，解析后获取数据。优点：机制成熟，可靠性好；文件比较小，传输和分析效率高。缺点：bgsave虽然会fork子进程，但仍然可能导致主进程卡住一段时间，影响业务。经过综合评估，决定在非高峰期使用bgsave从slave节点获取rdb文件，相对安全可靠，也可以覆盖所有业务Redis集群。也就是说，每个实例在淡季每天自动生成一个.rdb文件，即使报表数据延迟一天，也是可以接受的。“哦，原来.rdb文件是磁盘缓存文件，那怎么开启持久化呢？”下面简单介绍一下Redis的持久化。Redis支持两种持久化方式，一种是RDB方式，一种是AOF方式。RDB是Redis用于持久化的一种方式，即将当前内存中的数据集和快照写入磁盘。RDB——自动RDB（RedisDataBase）方式通过快照完成。当满足一定条件时，Redis会自动对内存中的所有数据进行快照，并存储到硬盘上。RDB是Redis默认的持久化方式。vim/usr/local/redis/conf/redis.confsave9001#15分钟内至少修改了1个save30010#5分钟内至少修改了10个save601000#1分钟内至少修改了10000个Akeyischanged#以上条件都是or关系，当满足其中一个时，就会进行快照。dbfilename"dump.rdb"#持久化文件名dir"/data/dbs/redis/6381"#持久化数据文件存放路径#修改配置文件后，需要重启redis服务。也可以通过命令行配置：CONFIGGETsave#查看redis持久化配置CONFIGSETsave"10020"#修改redis持久化配置#使用命令行配置，立即生效，需要到服务器后重新配置重新启动。RDB-手动保存这个命令会阻塞当前的Redis服务器。在save命令执行过程中，Redis无法处理其他命令，直到RDB进程完成。很明显，对于内存比较大的实例，这个命令会造成长时间的阻塞，这是一个致命的缺陷。当bgsave执行该命令时，Redis会在后台异步进行快照操作，快照也可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在分叉阶段。AOFAOF（APPENDONLYMODE）通过保存对redis服务器的写命令（如set、sadd、rpush）来记录数据库的状态，也就是将你对redis数据库的写操作保存下来。配置日志文件如下：vim/usr/local/redis/conf/redis.confdir"/data/dbs/redis/6381"#AOF文件存放目录appendonlyyes#开启AOF持久化，appendfilename默认关闭"appendonly.aof"#AOF文件名（默认）appendfsyncno#AOF持久化策略auto-aof-rewrite-percentage100#触发AOF文件重写的条件（默认）auto-aof-rewrite-min-size64mb#触发AOF文件的条件rewriting(Default)#上面的每个参数，大家可以找资料看懂，就不过多解释了。RDB和AOF的优缺点从上面可以看出。至此，我们了解了Redis持久化的一些配置。具体建议查阅相关资料进行研究。接下来我们通过上一步获取到rdb文件，相当于获取到了Redis实例的数据。解析rdb文件，得到key和value的值。根据对应的数据结构和内容，估算内存消耗。统计并生成报告。分析工具Snowballrdr:https://github.com/xueqiu/rdrredis-rdb-tools:https://github.com/sripathikr...总结讲解工作中常见的redis使用场景。redis持久化的两种方式（RDB、AOF）进行了说明。推荐两种用于分析RDB的工具。通过redis的使用，我们可以了解如何对服务器上的redis数据进行持久化快照，进而了解如何使用工具来分析rdb文件。最后，通过分析的数据，我们可以反过来对redis的使用提出一些建议。其他知识点也是如此。我们不能只停留在方法的简单调用上，就觉得自己懂这门技术了！事实上，联想上面分析的数据是无法定位这个key属于哪个业务方，哪个开发者创建的，是否重要等等，那怎么办呢？制定开发团队RedisKey的使用规范。通过key的命名可以得到：属于什么业务（加域名表示）属于什么数据类型（加数据类型表示）是否设置过期时间...使用a统一平台申请RedisKey，申请后才能使用：填写申请人，填写申请时间，填写申请业务方，填写数据类型，填写Key重要性，填写在Key是否有过期时间，根据填写的项生成标准化的key名...（等等需要标注的）上面我们已经可以分析出一个redis实例的rdb文件的内容了，将分析的内容与统一平台申请的数据进行整合，分析key的通过率，内存占用，不同数据类型的分布，内存占用Top100值等。通过运维，我们可以了解各个服务器和实例之间的配置关系，进而可以知道一个服务器（N个实例）上key的合格率，内存占用，不同数据类型的分布，以及内存占用的度量值前100名等等。这样后台系统就可以看到哪个server、哪个instance的使用情况，解决了Redis滥用无法监控的问题。推荐阅读系统详解-SSO单点登录系统详解-PHPWEB安全防御系统详解-PHP缓存技术系统详解-PHP接口签名验证系统详解-PHP浮点数高精度运算一起学习
