1 发布/订阅

 

类似于MQ的主题模式-只能消费订阅之后发布的消息，一个消息可以被多个订阅者消费

普通的发布/订阅

 　　除了实现任务队列外，redis还提供了一组命令可以让开发者实现"发布/订阅"(publish/subscribe)模式。"发布/订阅"模式同样可以实现进程间的消息传递，其原理如下:

普通的发布/订阅

 　　除了实现任务队列外，redis还提供了一组命令可以让开发者实现"发布/订阅"(publish/subscribe)模式。"发布/订阅"模式同样可以实现进程间的消息传递，其原理如下:

        "发布/订阅"模式包含两种角色，分别是发布者和订阅者。订阅者可以订阅一个或者多个频道(channel),而发布者可以向指定的频道(channel)发送消息，所有订阅此频道的订阅者都会收到此消息。

 (1)发布消息

　　发布者发布消息的命令是  publish,用法是 publish channel message，如向 channel1.1说一声hi。

这样消息就发出去了。返回值表示接收这条消息的订阅者数量。发出去的消息不会被持久化，也就是有客户端订阅channel:1后只能接收到后续发布到该频道的消息，之前的就接收不到了。

(2)订阅频道

　　订阅频道的命令是 subscribe，可以同时订阅多个频道，用法是 subscribe channel1 [channel2 ...],例如新开一个客户端订阅上面频道:(不会收到消息，因为不会收到订阅之前就发布到该频道的消息)

  

执行上面命令客户端会进入订阅状态，处于此状态下客户端不能使用除subscribe、unsubscribe、psubscribe和punsubscribe这四个属于"发布/订阅"之外的命令，否则会报错。

　进入订阅状态后客户端可能收到3种类型的回复。每种类型的回复都包含3个值，第一个值是消息的类型，根据消类型的不同，第二个和第三个参数的含义可能不同。

消息类型的取值可能是以下3个:

(1)subscribe。表示订阅成功的反馈信息。第二个值是订阅成功的频道名称，第三个是当前客户端订阅的频道数量。

(2)message。表示接收到的消息，第二个值表示产生消息的频道名称，第三个值是消息的内容。

(3)unsubscribe。表示成功取消订阅某个频道。第二个值是对应的频道名称，第三个值是当前客户端订阅的频道数量，当此值为0时客户端会退出订阅状态，之后就可以执行其他非"发布/订阅"模式的命令了。

按照规则发布/订阅

　　除了可以使用subscribe命令订阅指定的频道外，还可以使用psubscribe命令订阅指定的规则。规则支持通配符格式。命令格式为      psubscribe pattern [pattern ...]订阅多个模式的频道。

通配符中?表示1个占位符，*表示任意个占位符(包括0)，?*表示1个以上占位符。

1 订阅者订阅三个通配符频道

 

2 新开一个客户端发送到指定频道

订阅端

还可以针对数据的实时性处理：

(1)使用psubscribe命令可以重复订阅同一个频道，如客户端执行了psubscribe c? c?*。这时向c1发布消息客户端会接受到两条消息，而同时publish命令的返回值是2而不是。.同样的，如果有另一个客户端执行了subscribe c1 和psubscribe c?*的话，向c1发送一条消息该客户顿也会受到两条消息(但是是两种类型:message和pmessage)，同时publish命令也返回

(2)punsubscribe命令可以退订指定的规则，用法是: punsubscribe [pattern [pattern ...]],如果没有参数则会退订所有规则。

(3)使用punsubscribe只能退订通过psubscribe命令订阅的规则，不会影响直接通过subscribe命令订阅的频道；同样unsubscribe命令也不会影响通过psubscribe命令订阅的规则。另外需要注意punsubscribe命令退订某个规则时不会将其中的通配符展开，而是进行严格的字符串匹配，所以punsubscribe * 无法退订c*规则，而是必须使用punsubscribe c*才可以退订。

2 管道pipeline

Redis是一个响应式的服务，当客户端发送一个请求后，就处于阻塞状态等待Redis返回结果。这样一次命令消耗的时间就包括四个部分：请求从客户端到服务器的时间、命令排队的时间和命令真正执行时间、结果从服务器到客户端的时间，第一个和第四个消耗的时间总和称为RTT（Round Trip Time），当客户端与服务器存在网络延时时，RTT就可能会很大，这样就会导致性能问题。

管道（Pipeline）就是为了改善这个情况的，利用管道，客户端可以一次性发送多个请求而不用等待服务器的响应，待所有命令都发送完后再一次性读取服务的响应，这样可以极大的降低RTT时间从而提升性能。需要注意到是用pipeline方式打包命令发送，redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多，缓存消耗内存也越多。所以并不是打包的命令越多越好。

pipeline和“事务”是两个完全不同的概念，pipeline只是表达“交互”中操作的传递的方向性，pipeline也可以在事务中运行，也可以不在。无论如何，pipeline中发送的每个command都会被server立即执行，如果执行失败，将会在此后的响应中得到信息；也就是pipeline并不是表达“所有command都一起成功”的语义；但是如果pipeline的操作被封装在事务中，那么将有事务来确保操作的成功与失败。

具体实现代码，后续专门补上。

3 事务

MULTI 命令用于开启一个事务，它总是返回 OK 。 MULTI 执行之后， 客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行， 而是被放到一个队列中， 当 EXEC命令被调用时， 所有队列中的命令才会被执行。

另一方面， 通过调用 DISCARD ， 客户端可以清空事务队列， 并放弃执行事务。

一个事务从开始到执行会经历以下三个阶段：

• 开始事务。
• 命令入队。
• 执行事务。

• 为什么 Redis 不支持回滚（roll back）

  如果你有使用关系式数据库的经验， 那么 “Redis 在事务失败时不进行回滚，而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。

  以下是这种做法的优点：

  Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。

  因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

  有种观点认为 Redis 处理事务的做法会产生 bug ， 然而需要注意的是， 在通常情况下， 回滚并不能解决编程错误带来的问题。 举个例子， 如果你本来想通过 INCR 命令将键的值加上 1 ， 却不小心加上了 2 ， 又或者对错误类型的键执行了 INCR ， 回滚是没有办法处理这些情况的。

• 案例：

• 

• 两个客户端，客户端1先开启事务，获取k1的值

  

• 客户端2 后开启事务，删除k1的值

• 

• 但是客户端2先执行事务

• 

• 客户端1后执行事务

• 

• 4 布隆过滤器

• 之前的布隆过滤器可以使用Redis中的位图操作实现，直到Redis4.0版本提供了插件功能，Redis官方提供的布隆过滤器才正式登场。布隆过滤器作为一个插件加载到Redis Server中，就会给Redis提供了强大的布隆去重功能。

• 4.1 添加布隆过滤器模块

  下载 wget https://github.com/RedisBloom/RedisBloom/archive/master.zip

  解压 unzip master.zip

  安装，进入cd RedisBloom-master/，make

•  

  

   

   

  查看，安装完成之后，多了一个.so文件

•  

  

   

  拷贝.so文件到redis安装目录
• 

• 启动：redis-server --loadmodule /usr/local/redis5/redisbloom.so

• 

• 新建过滤器：

  BF.RESERVE {key} {error_rate} {size}
  error_rate指容错率，取值范围为(0,1)，数值越小，占用内存越大，操作时占用cpu资源 越大。
  Size指过滤器的容量，添加的条目数超过此数字后，性能将开始下降。实际降级将取决 于超出限制的程度。随着条目数呈指数增长，性能将呈线性下降。
  如果不通过该命令来新建过滤器，bf.add添加值时会自动创建过滤器，但会使用默认的 容量与容错率。

  添加过滤器与值：

  BF.ADD {newFilter} {foo}
  如果过滤器不存在，则会自动创建，使用默认的容量与容错率。

  检查过滤器中是否存在值：

  BF.EXISTS {newFilter} {foo}

  举例：

• 

• 应用场景

  解决缓存穿透的问题

  一般情况下，先查询缓存是否有该条数据，缓存中没有时，再查询数据库。当数据库也不存在该条数据时，每次查询都要访问数据库，这就是缓存穿透。缓存穿透带来的问题是，当有大量请求查询数据库不存在的数据时，就会给数据库带来压力，甚至会拖垮数据库。

  可以使用布隆过滤器解决缓存穿透的问题，把已存在数据的key存在布隆过滤器中。当有新的请求时，先到布隆过滤器中查询是否存在，如果不存在该条数据直接返回；如果存在该条数据再查询缓存查询数据库。

  黑名单校验

  发现存在黑名单中的，就执行特定操作。比如：识别垃圾邮件，只要是邮箱在黑名单中的邮件，就识别为垃圾邮件。假设黑名单的数量是数以亿计的，存放起来就是非常耗费存储空间的，布隆过滤器则是一个较好的解决方案。把所有黑名单都放在布隆过滤器中，再收到邮件时，判断邮件地址是否在布隆过滤器中即可。

•  

  5 缓存有效期与淘汰策略

   

  有效期 TTL （Time to live)

  设置有效期的作用：

  5.1节省空间

  5.2做到数据弱一致性，有效期失效后，可以保证数据的一致性

  Redis的过期策略

  过期策略通常有以下三种：

  定时过期

  每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

  惰性过期

  只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。

  定期过期

  每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。

  expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。

  Redis中同时使用了惰性过期和定期过期两种过期策略。

  Redis过期删除采用的是定期删除，默认是每100ms检测一次，遇到过期的key则进行删除，这里的检测并不是顺序检测，而是随机检测。那这样会不会有漏网之鱼？显然Redis也考虑到了这一点，当我们去读/写一个已经过期的key时，会触发Redis的惰性删除策略，直接回干掉过期的key

  为什么不用定时删除策略?

  定时删除,用一个定时器来负责监视key,过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key,因此没有采用这一策略.

  定期删除+惰性删除是如何工作的呢?

  定期删除，redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。

  于是，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。

  采用定期删除+惰性删除就没其他问题了么?

  不是的，如果定期删除没删除key。然后你也没即时去请求key，也就是说惰性删除也没生效。这样，redis的内存会越来越高。那么就应该采用内存淘汰机制。

  缓存淘汰 eviction

  Redis自身实现了缓存淘汰

  Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。

  noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。

  allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。

  allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。

  volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。

  volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。

  volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。

  redis 4.x 后支持LFU策略，最少频率使用

  allkeys-lfu

  volatile-lfu

  LRU

  LRU（Least recently used，最近最少使用）

  LRU算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。

  基本思路

  新数据插入到列表头部；

  每当缓存命中（即缓存数据被访问），则将数据移到列表头部；

  当列表满的时候，将列表尾部的数据丢弃。

  LFU

  LFU（Least Frequently Used 最近最少使用算法）

  它是基于“如果一个数据在最近一段时间内使用次数很少，那么在将来一段时间内被使用的可能性也很小”的思路。

  LFU需要定期衰减。不然有一些数据会倚老卖老

  Redis淘汰策略的配置

  maxmemory 最大使用内存数量

  maxmemory-policy noeviction 淘汰策略