Redis注意事项

1、Redis3.0没有虚拟内存概念，已从2.4就移除；

2、redis挂掉并重启时，如果有主从备份的，主机挂掉重启时先关掉主从备份，不然从机的数据会被冲洗掉

数据恢复时如果有 AOF（原理是将Reids的操作日志以追加的方式写入文件）和 RDB（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化）的，则从 AOF 恢复，若只有 RDB 的，只从 RDB 恢复。

RDB存在哪些优势呢

3、保存快照需要注意频率，好像没有指明什么方式save，是save还是bgsave；

4、redis指明使用多少内存比较好？

5、删除策略：

　　（1）过期策略

　　（2）内存淘汰机制

　　在redis.conf中有一行配置，用于配内存淘汰策略的

maxmemory-policy volatile-lru

　　1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。应该没人用吧。
　　2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。推荐使用，目前项目在用这种。
　　3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。应该也没人用吧，你不删最少使用Key，去随机删。
　　4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。这种情况一般是把redis既当缓存，又做持久化存储的时候才用。不推荐
　　5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。依然不推荐
　　6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。不推荐
　　　　ps：如果没有设置 expire 的 key，不满足先决条件(prerequisites)；那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为，和 noeviction(不删除) 基本上一致。

6、事务，没有回滚：只有当被调用的Redis命令有语法错误时，这条命令才会执行失败（在将这个命令放入事务队列期间，Redis能够发现此类问题），或者对某个键执行不符合其数据类型的操作：实际上，这就意味着只有程序错误才会导致Redis命令执行失败，这种错误很有可能在程序开发期间发现，一般很少在生产环境发现。Redis已经在系统内部进行功能简化，这样可以确保更快的运行速度，因为Redis不需要事务回滚的能力。

>>>multi，exec，watch，discard，unwatch

批量操作在发送 EXEC 命令前被放入队列缓存，收到 EXEC 命令后进入事务执行；事务中任意命令执行失败，其余的命令依然被执行。

watch 提供 check-and-set （CAS）行为，即乐观锁，监控某个或某些key，在watch监控mykey的过程中，mykey被修改了，所以随后的事务便会被取消；如果watch监视了一个带过期时间的键， 那么即使这个键过期了， 事务仍然可以正常执行， http://code.google.com/p/redis/issues/detail?id=270

exec后因其他原因，redis服务器挂掉，剩下事务的命令没被执行，那么后续的命令将不会被执行；当使用 AOF 方式做持久化的时候， Redis 会使用单个 write(2) 命令将事务写入到磁盘中；使用 redis-check-aof 程序可以修复这一问题：它会移除 AOF 文件中不完整事务的信息，确保服务器可以顺利启动

7、惊群效应：在大并发情况下，我们通常会用缓存来给数据库分压，但是会有这么一种情况发生，那就是在一定时间内生成大量的缓 存，然后当缓存到期之后又有大量的缓存失效，导致后端数据库的压力突然增大，这种现象就可以称为“缓存过期产生的惊群现象”。

处理逻辑：

　　缓存内真实失效时间time1

　　缓存value中存放人为失效时间戳 ：time2 （ time2 永远小于time1）

　　缓存value对应的lock锁（就是一个与value 对应的 另一个key），主要用于判断是第几个线程来读取redis的value

　　当把数据库的数据写入缓存后，这时有客户端第一次来读取缓存，取当前系统时间:system_time 如果system_time >= time2  则认为默认缓存已过期（如果system_time< time1 则还没真实失效 ），这时再获取value的lock锁，调用redis的incr函数（单线程自增函数）判断是第几个获取锁的线程，当且仅当是第一个线程时返回1，以后都逐渐递增。第一个访问的线程到数据库中获取最新值重新放入缓存并删除lock锁的key，并重新设置时间戳；在删除lock之前所有访问value客户端线程获取lock的value都大于1，这些线程仍然读取redis中的旧值，而不会集中访问数据库。

 1 public function getByLock($key)
 2   {
 3     $sth = $this->redis->get($key);
 4     if ($sth === false) {
 5       return $sth;
 6     } else {
 7       $sth = json_decode($sth, TRUE);
 8       if (intval($sth['expire']) <= time()) {
 9         $lock = $this->redis->incr($key . ".lock");
10         if ($lock === 1) {
11           return false;
12         } else {
13           return $sth['data'];
14         }
15       } else {
16         return $sth['data'];
17       }
18     }
19   }

8、redis 集群：

Redis仅支持单实例，内存一般最多10~20GB。对于内存动辄100~200GB的系统，就需要通过集群来支持了。

Redis集群有三种方式：客户端分片、代理分片、RedisCluster

9、缓存与数据库不一致：

1、写数据前后都del key，且设置缓存时间短些

2、监控mysql的binlog，异步删除key

3、缓存操作失败时需要重试，放入消息队列，实在不行报警

10、5种数据类型

11、缓存穿透：缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。

　　解决：1、接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截。

　　　　　2、从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击。

12、缓存雪崩：缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

　　解决：1、缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。

　　　　　2、如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。

13、缓存击穿：缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。

　　解决：1、设置热点数据永远不过期。

　　　　　2、加互斥锁，第一个线程进去获取到锁并去数据库取值，其他的线程等锁；能针对每个key设置颗粒级的锁会更好，这样key1不会影响到key2。

14、redis总说单线程，其实不是整个server就一个线程在处理所有的事情，它是指接收网络IO请求是一个线程（IO多路复用），文件事件分派又是一个线程，然后请求放在队列里，有序执行

15、哨兵机制

16、消息模式

（1）任务队列模式

　　就是“传递消息的队列”。与任务队列进行交互的实体有两类，一类是生产者（producer），另一类则是消费者（consumer）。生产者将需要处理的任务放入任务队列中，而消费者则不断地从任务独立中读入任务信息并执行。

　　任务队列的好处：

　　松耦合。生产者和消费者只需按照约定的任务描述格式，进行编写代码。

　　易于扩展。多消费者模式下，消费者可以分布在多个不同的服务器中，由此降低单台服务器的负载。

　　使用LPUSH、RPOP，这样实现先进先出队列

　　可以使用BRPOP，进行阻塞连接。BRPOP命令接收两个参数，第一个是键名，第二个是超时时间，单位是秒。当超过了此时间仍然没有获得新元素的话就返回nil。为0时表示不限制等待时间，即如果没有新元素加入列表就永远阻塞下去。当获得一个元素后会返回两个值，分别是键名和元素值。BRPOP命令可以同时接收多个键，其完整的命令格式为 BRPOP key [key key ......] timeout ，如果多个键都有元素，则按照从左到右的顺序取第一个键中的元素。借此特性我们可以实现区分优先级的队列。

（2）发布订阅模式

　　 “发布/订阅”模式中包含两种角色，分别是发布者和订阅者。订阅者可以订阅一个或若干个频道（channel），而发布者可以向指定的频道发送消息，所有订阅此频道的订阅者都会收到此消息。

　　PUBLISH：

　　　　将信息 message 发送到指定的频道 channel。返回收到消息的客户端数量。

　　SUBSCRIBE

　　　　订阅给指定频道的信息。

　　　　一旦客户端进入订阅状态，客户端就只可接受订阅相关的命令SUBSCRIBE、PSUBSCRIBE、UNSUBSCRIBE和PUNSUBSCRIBE除了这些命令，其他命令一律失效。

　　UNSUBSCRIBE 

　　　　取消订阅指定的频道，如果不指定，则取消订阅所有的频道。

 1 127.0.0.1:6379> PUBLISH channel1.1 test
 2 (integer) 0 //有0个客户端收到消息
 3  
 4 127.0.0.1:6379> SUBSCRIBE channel1.1
 5 Reading messages... (press Ctrl-C to quit)
 6 1) "subscribe"  //"subscribe"表示订阅成功的信息
 7 2) "channel1.1" //表示订阅成功的频道
 8 3) (integer) 1  //表示当前订阅客户端的数量
 9 //当发布者发布消息时，订阅者会收到如下消息
10 1) "message"    //表示接收到消息
11 2) "channel1.1" //表示产生消息的频道
12 3) "test"       //表示消息的内容
13 //当订阅者取消订阅时会显示如下：
14 127.0.0.1:6379> UNSUBSCRIBE channel1.1
15 1) "unsubscribe"    //表示成功取消订阅
16 2) "channel1.1" //表示取消订阅的频道
17 3) (integer) 0  //表示当前订阅客户端的数量
18  
19 //注：在redis-cli中无法测试UNSUBSCRIBE命令

　　PSUBSCRIBE 

　　　　订阅给定的模式(patterns)。

　　PUNSUBSCRIBE 

　　　　可以退订指定的规则，如果没有参数会退订所有的规则。

 1 127.0.0.1:6379> PSUBSCRIBE channel1.*
 2 Reading messages... (press Ctrl-C to quit)
 3 1) "psubscribe"
 4 2) "channel1.*"
 5 3) (integer) 1
 6 //等待发布者发布消息
 7 127.0.0.1:6379> PUBLISH channel1.1 test1.1
 8 (integer) 1 //发布者在channel1.1发布消息
 9  
10 1) "pmessage"   //表示通过PSUBSCRIBE命令订阅而收到的
11 2) "channel1.*" //表示订阅时使用的通配符
12 3) "channel1.1" //表示收到消息的频道
13 4) "test1.1"        //表示消息内容
14  
15 127.0.0.1:6379> PUBLISH channel1.2 test1.2
16 (integer) 1 //发布者在channel1.2发布消息
17  
18 1) "pmessage"
19 2) "channel1.*"
20 3) "channel1.2"
21 4) "test1.2"
22  
23 127.0.0.1:6379> PUBLISH channel1.3 test1.3
24 (integer) 1 //发布者在channel1.3发布消息
25  
26 1) "pmessage"
27 2) "channel1.*"
28 3) "channel1.3"
29 4) "test1.3"
30  
31 127.0.0.1:6379> PUNSUBSCRIBE channal1.*
32 1) "punsubscribe"   //退订成功
33 2) "channal1.*" //退订规则的通配符
34 3) (integer) 0  //表示当前订阅客户端的数量

　　PUNSUBSCRIBE应该注意一下两点：

　　　　使用PUNSUBSCRIBE命令只能退订通过PSUBSCRIBE命令订阅的规则，不会影响SUBSCRIBE订阅的频道。

　　　　使用PUNSUBSCRIBE命令退订某个规则时不会将其中通配符展开，而是严格的进行字符串匹配，所以PUNSUBSCRIBE *无法退订PUNSUBSCRIBE channal1.*规则，而必须使用PUNSUBSCRIBE channal1.*才能退订

17、主从同步

18、分布式锁