Redis常见使用场景问题分析

浅浅的花香味﹌ 2021-09-02 04:56 485阅读 0赞

#### 1、如何从海量key中查询出某一固定前缀的key ####

正例：  
通过scan命令，scan返回的是一个游标，它不会遍历所有的key，所以速度是比较快的。  
命令格式：scan cursor MATCH pattern COUNT count  
这里的count表示你期望获取满足格式的数据量，但结果不一定完全匹配。同时返回的key值有可能重复，在业务层要做好去重。如果一次返回的数据不够，就将上一次返回的cursor再次传入获取。

![在这里插入图片描述][20200915165728211.png_pic_center]  
反例：  
通过keys pattern命令，keys会遍历所有的key，耗时较长。当数据量dbsize大的会产生明显卡顿，不建议使用。  
![在这里插入图片描述][20200915170035640.png_pic_center]

#### 2、 如何通过redis实现分布式锁 ####

分布式锁需要解决的问题：  
1、互斥性：只能有一个客户端持有锁  
2、安全性：锁只能由持有锁的客户端释放  
3、容错：如果持有锁的客户端宕机，也应该能释放锁  
4、死锁

setnx key value：如果没有这个key，则新增这个key，返回1。如果已经存在，返回0。客户端可以不断通过setnx获取锁，如果得到1，则获取锁成功。  
setnx缺点：如果持有锁的客户端宕机，锁将无法过期。

那就想办法给锁设置一个过期时间，同时让setnx与设置过期时间为一个原子操作：

*  通过set key value ex seconds nx，通过一个会自动过期的key实现分布式锁。如果设置成功，返回OK，否则返回nil。  
    ![在这里插入图片描述][20200915172414922.png_pic_center]
 *  记得还有一个setex命令，不过试了一下，该命令每次返回的值都是OK，无法判断是否获取到了锁，所以似乎搞不定。  
    ![在这里插入图片描述][20200915172452612.png_pic_center]  
    最终还是建议使用：set key value ex seconds nx的方式实现分布式锁。

#### 3、大量的key同时过期 ####

大量key集中过期，首先由于清除大量的key很耗时，redis服务会出现卡顿现象。另外如果这些key是热点key，同时过期有可能会造成缓存雪崩，造成的问题是很大的。  
解决方案：设置key的过期时间的时候，再加上一个随机值。

#### 4、如何用redis实现异步队列 ####

使用list的RPUSH、LPOP操作，往队列中新增元素，和取出元素。  
![在这里插入图片描述][20200915184321477.png_pic_center]  
缺点：无法做到队列里有值就消费，只能通过应用层隔一段时间轮询LPOP，一次次重试。没有做到及时消费

为了做到队列里有值就及时消费，还有一个就是阻塞读，BLPOP key timeout，该命令是在队列里有元素的时候，最左边的元素立即出队列。如果队列中没有元素，则会阻塞，在timeout时间内直到等待有元素入队列，有则返回，如果超时则返回nil。  
缺点： 一个消息只能被一个客户端消费（也不能说是缺点，这是数据结构的性质决定）

pub/sub 模式  
如：两个客户端监听一个topic  
![在这里插入图片描述][20200915191026564.png_pic_center]  
![在这里插入图片描述][20200915191037883.png_pic_center]  
其中一台服务器发布一个消息：  
![在这里插入图片描述][20200915191108720.png_pic_center]  
多个客户端都能收到自己订阅的消息：  
![在这里插入图片描述][20200915191127173.png_pic_center]  
缺点：发布者无法确保消息能发送到消费者

#### 5、Redis如何做持久化 ####

RDB快照：保存redis某个时间段的全量快照，用于redis恢复  
我们可以看redis.conf配置中：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center]  
这是redis系统自动保存快照的配置，采用的是bgsave命令，通过fork出一个子进程进行生成快照，不影响主线程的工作。  
其中配置值的含义在注释中已经写了：

In the example below the behaviour will be to save:
    #   after 900 sec (15 min) if at least 1 key changed
    #   after 300 sec (5 min) if at least 10 keys changed
    #   after 60 sec if at least 10000 keys changed

RDB持久化缺点：：  
1、因为是内存的全量同步，数据量大会影响IO性能  
2、如果redis挂掉，当前至上一次同步快照期间的数据会丢失。

AOF（Append-Only-File）：  
它会记录下除查询以外所有变更数据库状态的指令，以append的形式增量追加到AOF文件中。  
redis.conf默认是关闭的，如果要打开，要设为yes  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 1]  
AOF文件过大问题可以参考：https://www.cnblogs.com/ExMan/p/11264676.html  
AOF持久化缺点：  
因为AOF保存了每条修改redis的命令，因此AOF的文件大小可能会很大，远超过内存的大小。（举个栗子：假如一个key从1加到100，每次加1，对于rdb来说，只要记录一个最终状态100，而AOF会记录100次的记录。），在redis重启恢复的过程中，会较慢。

RDB与AOF组合使用：  
在RDB与AOF共存的情况下，redis的启动、恢复流程：  
1、判断AOF文件是否存在，如果存在，就使用AOF进行恢复（恢复的数据会相对更完整）  
2、如果不存在AOF文件，则读取RDB进行恢复（恢复的数据比aof不完整）。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 2]

#### PipeLine ####

redis如果一条一条执行指令，下一条指令需要等待上一条执行结果返回再发送执行，这样的流程的执行效率较低。  
PipeLine管道减少了网络来回往返的时间，将指令批量发送给服务端，服务端执行完毕后返回结果，提高了执行效率。

#### 6、redis主从同步 ####

全同步：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 3]  
全同步结束之后，就进行增量同步。  
增量同步：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 4]  
这里会有一个问题，第二步的环形缓冲区是定长的，假如网络条件不好，当环形缓冲区满了，就会从头开始覆盖前面的数据，此时就需要快照同步了。

#### 7、redis集群 ####

*  数据分片：为了能够在海量数据中支持高并发，数据分片是一种常见思路，将数据分散存储在多个节点上。
 *  一致性hash算法：余数算法当节点数量变动时，缓存失效的概率大，所以引入一致性hash算法。

一致性hash算法的一种实现是：采用一个2^32大小的虚拟环，虚拟环上有0,2^32个按顺序的数据，redis中key的hash值就落在这个环上，同时redis的服务节点也在hash环上。  
当一个key写入的时候，先计算key的hash值，然后顺时针寻找服务节点，找到最近的节点，就将数据存入。示意图如下：objectA 存入到NodeA中  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 5]  
此种方法的缺陷：  
前面说到，redis服务节点也会在这个虚拟环上，一般是通过服务器节点名称进行hash运算，当服务器节点较少时，可能会出现数据倾斜问题。也就是说，不同的节点存的数据的比例差距较大，如图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 6]  
此时大量的数据会存在A上，可能会撑爆服务节点，而节点B上的数据却很少。  
虚拟节点：为了解决数据倾斜问题，可以采用虚拟节点，将一个节点分成多个虚拟节点落在hash环上，数据写入时，找到虚拟节点，并根据映射关系计算出真实节点，进行存储。  
一致性hash的java实现可以参考：https://blog.csdn.net/u011305680/article/details/79721030

[20200915165728211.png_pic_center]: /images/20210518/2d6c82aa74b54af39c32755e946765ac.png
[20200915170035640.png_pic_center]: /images/20210518/7c3babf1cc3d4dcda8586afa4ac2214a.png
[20200915172414922.png_pic_center]: /images/20210518/ffd7c474432b4aac9592a379bb8f02ba.png
[20200915172452612.png_pic_center]: /images/20210518/580318a9958b465da7c1d7585da8f06d.png
[20200915184321477.png_pic_center]: /images/20210518/b49758d66e3940659f126c7f3e7d2946.png
[20200915191026564.png_pic_center]: /images/20210518/19f130e190e74b1780fa3554bd85f4b9.png
[20200915191037883.png_pic_center]: /images/20210518/0c31116dd4354ee68e79cce224d09ab6.png
[20200915191108720.png_pic_center]: /images/20210518/ebef2263abd84e7fba65864508fb4eb1.png
[20200915191127173.png_pic_center]: /images/20210518/aab29139e65b41a983b3fdfcd2d8f70d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center]: /images/20210518/47e75c672cf44496868079fb2882119b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20210518/1a912ba7a1a54d769487c56c5c1f90fd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20210518/0875e23563fb4166b9caf817c39e35cc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20210518/fd1ae78204014259b5f9465f4583b988.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20210518/db583fad05884cad902ab1d598e642e2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20210518/e19da2ba960c4e9fb9307f300fb57199.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzk2ODYxMw_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20210518/25ee92961a4b49449c3dc7210f3019d9.png