Redis_常见问题

布满荆棘的人生 2023-02-14 13:25 13阅读 0赞

### 文章目录 ###

*  参考
 *  为什么使用Redis？
 *  Redis与Memcached的区别，为什么选择Redis？
 *  Redis为什么快？
 *  什么是上下文切换
 *  Redis的线程模型是什么？
 *  单线程的Redis是否浪费了多核服务器的性能？
 *  Redis有哪些数据结构和应用场景
 *  如果有大量的key在同一时间过期，需要注意什么？
 *  缓存穿透和击穿分别是什么，和缓存雪崩有什么区别，又该如何解决
 *  布隆过滤器原理是什么？
 *  Redis分布式锁是怎么回事？
 *  如何将存在固定前缀的key找出来？
 *  如果Redis正在线上提供服务，此时使用keys命令会有什么问题
 *  如何用Redis做异步队列？
 *   *  是否可以一条消息消费多次？
 *  Redis如何实现延时队列
 *  Redis如何持久化
 *  Redis同步机制/主从复制如何进行的
 *  如果Redis服务突然断电怎么办？
 *  RDB的原理是什么？
 *  如果Redis遇到瓶颈，该如何解决？
 *  Redis集群的原理是什么，如何保证高可用？
 *  Redis内存删除策略和逐出算法？
 *  手写LRU算法
 *  如何保证双写一致性？ KV、DB读写模式？
 *   *  为什么写数据的时候是删除缓存不是更新缓存

# 参考 #

[https://github.com/AobingJava/JavaFamily][https_github.com_AobingJava_JavaFamily]

# 为什么使用Redis？ #

传统的关系型数据库已经不适用所有场景了，例如频繁变化和操作的短时热点数据，如果直接访问MySQL这类的关系型数据库，会极大地增添数据库负担，严重时可能引起系统崩溃，所以考虑引入缓存中间件Redis。

# Redis与Memcached的区别，为什么选择Redis？ #

*  Redis支持的数据结构更丰富
 *  Redis支持原生集群
 *  Redis单核，MemCached多核，在存储小数据上Redis性能更高，大数据上略逊于MemCached
 *  MemCached key 不能超过 250 个字节；
 *  MemCached value 不能超过 1M 字节；
 *  MemCached key 的最大失效时间是 30 天；
 *  MemCached 只支持 K-V 结构，不提供持久化和主从同步功能。

# Redis为什么快？ #

*  完全基于内存，类似HashMap
 *  单线程，避免不必要的上下文切换和竞争条件
 *  多路IO复用模型，非阻塞IO
 *  数据结构简单
 *  构建了VM机制

# 什么是上下文切换 #

比如你看书的时候，突然有朋友说接他看一下，然后你借给他，等他还给你，你要再翻到你之前看到的页码，这就是一个切换过程。

# Redis的线程模型是什么？ #

[https://doocs.github.io/advanced-java/\#/./docs/high-concurrency/redis-single-thread-model][https_doocs.github.io_advanced-java_._docs_high-concurrency_redis-single-thread-model]  
Redis内部使用文件事件处理器File Event Handler,其包含四个部分：

*  多个socket
 *  IO多路复用程序
 *  文件事件分派器
 *  事件处理器
    
     *  连接应答处理器
     *  命令请求处理器
     *  命令回复处理器  
        文件事件处理器是单线程的，所以Redis是单线程模型，采用IO多路复用机制通知监控多个socket，多个socket可能会并发产生不同操作，每个操作对应不同的文件事件，IO多路复用程序会将事件放入队列，事件分派器依次从队列中取事件，交给对应的事件处理器处理。  
        ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70]

# 单线程的Redis是否浪费了多核服务器的性能？ #

并不会。可以在一台服务器部署多个Redis实例。

# Redis有哪些数据结构和应用场景 #

[https://blog.csdn.net/Chill\_Lyn/article/details/104430104][https_blog.csdn.net_Chill_Lyn_article_details_104430104]  
[https://blog.csdn.net/Chill\_Lyn/article/details/104484301][https_blog.csdn.net_Chill_Lyn_article_details_104484301]

*  基本数据结构
    
     *  String
        
         *  缓存 `setex key seconds value`
         *  计数器 `incr key` `incrby key increment`
         *  共享用户session
     *  Hash
        
         *  对象有很多属性 `hset key field value`
     *  List
        
         *  消息队列 `lpush key value1` `rpop key`
         *  分页展示 `lrange key start stop`
     *  Set
        
         *  获取随机数据 `srandmember key [count]` `spop key [count]`
         *  交集、并集、差集 \`sinter key1 \[key2\]
         *  去重  
            sunion key1 \[key2\]  
            sdiff key1 \[key2\]\`
     *  Sorted\_Set
        
         *  排行榜
         *  权重队列
 *  高级数据结构
    
     *  Bitmaps
        
         *  位图按bit来存储信息，可以用来实现布隆过滤器
     *  HyperLogLog
        
         *  基数统计
     *  Geo
        
         *  保存坐标等地理位置，计算距离
     *  pub/sub
        
         *  订阅发布功能，用作简单的消息队列
     *  Pipeline：
        
         *  执行一组指令，一次性返回全部结果，减少频繁的请求应答

# 如果有大量的key在同一时间过期，需要注意什么？ #

如果大量的key在同一时间过期，Redis会集中访问数据库重新获取缓存，会出现短暂的卡顿现象，如果此时有大量的访问请求过来，可能会引起缓存雪崩。所以在设置缓存过期时间的时候尽量在预想值的基础上随机添加一个时间，使缓存更新的时间点平滑地错开。对于一些短期内的超热点数据，也可以设置永久key。

# 缓存穿透和击穿分别是什么，和缓存雪崩有什么区别，又该如何解决 #

*  缓存穿透是请求的数据在Redis和数据库中都不存在，导致数据库压力过大，严重时会击垮数据库
 *  解决缓存穿透的办法：
    
     *  首先要在参数校验，一些比较离谱的参数就直接拦截掉，比如根据负数id进行数据库查询的情况；
     *  如果存在恶意攻击的情况，可以在网关层限制单个ip每秒访问的阈值；
     *  Redis还可以使用布隆过滤器，利用高效的数据结构和算法判断key是否存在于数据库，如果存在才去数据库查询并刷新缓存
 *  缓存击穿是单个热点key失效，此时大量的请求直接访问到数据库，造成数据库巨大压力
 *  解决缓存击穿可以设置永久key。

# 布隆过滤器原理是什么？ #

[https://github.com/AobingJava/JavaFamily/blob/master/docs/redis/%E5%B8%83%E9%9A%86%E8%BF%87%E6%BB%A4%E5%99%A8(BloomFilter).md][https_github.com_AobingJava_JavaFamily_blob_master_docs_redis_E5_B8_83_E9_9A_86_E8_BF_87_E6_BB_A4_E5_99_A8_BloomFilter_.md]  
当一个元素被加入集合时，通过K个散列函数将这个元素映射成一个位数组中的K个点，把它们置为1。检索时，我们只要看看这些点是不是都是1就（大约）知道集合中有没有它了：如果这些点有任何一个0，则被检元素一定不在；如果都是1，则被检元素很可能在。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70 1]

# Redis分布式锁是怎么回事？ #

进行操作之前首先通过`setnx`命令尝试获取锁，如果成功就继续操作，如果失败就表示当前有其他请求正在进行操作，操作完成后通过`del key`释放锁。

为了防止忘记释放锁，或者因为某些异常原因长时间占用锁，可以通过`expire`命令给这个key设置一个过期时间。

也可以将`setnx`和`expire`命令组合成一条命令。

# 如何将存在固定前缀的key找出来？ #

[https://blog.csdn.net/Chill\_Lyn/article/details/104442470][https_blog.csdn.net_Chill_Lyn_article_details_104442470]

//阻塞
    keys pattern
    //非阻塞
    scan

# 如果Redis正在线上提供服务，此时使用keys命令会有什么问题 #

Redis是单线程的，keys命令会导致线程阻塞，线上服务会等到keys命令执行完成后才能恢复。可以使用scan命令，是非阻塞获取。

# 如何用Redis做异步队列？ #

利用list数据类型，从一侧push，从另一层pop，比如`lpush`,`rpop`。  
也可以使用`brpop`设置在一定时间内获取数据

## 是否可以一条消息消费多次？ ##

使用pub/sub主题订阅者模式，但是消费者下线消息会丢失，一对多这种模式还是建议使用MQ

# Redis如何实现延时队列 #

利用数据类型`Sorted Set`，`zadd`添加消息，用时间戳做`score`，`zrangebyscore`获取一定时间内的消息

# Redis如何持久化 #

[https://blog.csdn.net/Chill\_Lyn/article/details/104460252][https_blog.csdn.net_Chill_Lyn_article_details_104460252]

*  RDB，以快照的模式全量复制，大量数据的情况下，生成快照慢，但是在恢复的时候快，同时也不能保证数据的完整性。
 *  AOF，保存操作指令，生成快，但是恢复需要执行指令，比较慢，根据数据写入策略可以保证数据的完整性，

# Redis同步机制/主从复制如何进行的 #

首先是master进行一次bgsave，通过RDB全量复制给slave，同时在此之后的后续操作被记录在AOF缓存区中，然后在通过AOF将RDB这段时间新增的操作进行复制

# 如果Redis服务突然断电怎么办？ #

AOF是可以做到数据实时是复制，这取决于AOF数据写入策略：

*  always(每次）  
    每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用。
 *  everysec（每秒）  
    每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高，建议使用，也是默认配置，在系统突然宕机的情况下丢失1秒内的数据
 *  no（系统控制）  
    由操作系统控制每次同步到AOF文件的周期，整体过程不可控

# RDB的原理是什么？ #

Redis通过创建fork子进程进行RDB操作，父子进程共享数据，写时复制。

# 如果Redis遇到瓶颈，该如何解决？ #

考虑扩展，可以部署集群。

# Redis集群的原理是什么，如何保证高可用？ #

[https://blog.csdn.net/Chill\_Lyn/article/details/104518235][https_blog.csdn.net_Chill_Lyn_article_details_104518235]  
[https://blog.csdn.net/Chill\_Lyn/article/details/104501397][https_blog.csdn.net_Chill_Lyn_article_details_104501397]

*  将所有的存储空间计划切割成16384份，每台主机保存一部分，每份代表的是一个存储空间，称作槽，不是一个key的保存空间。
 *  将key按照CRC16(key) %16384计算出的结果放到对应的存储空间
 *  通过Sentinel模式，负责监控集群是否正常工资，如果某个sentinel发现master故障，首先会在sentinel之间进行投票确认master是否真的故障，确认之后，选举出一个sentinel去做故障转移，负责故障转移的sentinel从该master的slave中选出一个响应快数据新的作为新的master，然后通知其他slave新master的地址。

# Redis内存删除策略和逐出算法？ #

[https://blog.csdn.net/Chill\_Lyn/article/details/104479867][https_blog.csdn.net_Chill_Lyn_article_details_104479867]

*  删除策略
    
     *  定时删除：一到过期时间就删除，节约内存，但是CPU压力大，一般不采用
     *  惰性删除：key到期不会被删除，下次访问该key时删除，CPU利用率高，内存占用严重
     *  定期删除：Redis轮询库，内存定期随机抽取清除，每秒花费固定的CPU资源维护

如果内存不够用，就会触发逐出算法

*  检测易失数据（可能会过期的数据集server.db\[i\].expires ）
    
     *  volatile-lru：挑选最近最长时间未使用的数据淘汰
     *  volatile-lfu：挑选最近使用次数最少的数据淘汰
     *  volatile-ttl：挑选将要过期的数据淘汰
     *  volatile-random：任意选择数据淘汰
 *  检测全库数据（所有数据集server.db\[i\].dict ）
    
     *  allkeys-lru：挑选最近最长时间未使用的数据淘汰
     *  allkeys-lfu：挑选最近使用次数最少的数据淘汰
     *  allkeys-random：任意选择数据淘汰
 *  放弃数据驱逐
    
     *  no-enviction（驱逐）：禁止驱逐数据（redis4.0中默认策略），会引发错误OOM（Out Of Memory）

# 手写LRU算法 #

利用`LinkedHashMap`中的实现，重写其中`removeEldestEntry`方法

public class LRUTest extends LinkedHashMap<String,String> {
        
    
        private final int CACHE_SIZE;
    
        public LRUTest(int cacheSize) {
        
            super((int) (Math.ceil(cacheSize/0.75)+1),0.75f,true);
            CACHE_SIZE = cacheSize;
        }
    
        @Override
        protected boolean removeEldestEntry(Map.Entry eldest) {
        
            return size()>CACHE_SIZE;
        }
    }

# 如何保证双写一致性？ KV、DB读写模式？ #

*  读的时候先读缓存，缓存如果没有的话，再读数据库，取出数据放入缓存，同时返回响应
 *  写的时候，先更新数据库，再删除缓存

## 为什么写数据的时候是删除缓存不是更新缓存 ##

采用懒加载的思想，只有访问到某个数据的时候才会放入缓存，如果每次修改数据库都要更新缓存，而这个缓存数据是并不会经常被访问到的冷数据，更新缓存的操作就相当于浪费了大量的资源

[https_github.com_AobingJava_JavaFamily]: https://github.com/AobingJava/JavaFamily
[https_doocs.github.io_advanced-java_._docs_high-concurrency_redis-single-thread-model]: https://doocs.github.io/advanced-java/#/./docs/high-concurrency/redis-single-thread-model
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200604210121759.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg==,size_16,color_FFFFFF,t_70
[https_blog.csdn.net_Chill_Lyn_article_details_104430104]: https://blog.csdn.net/Chill_Lyn/article/details/104430104
[https_blog.csdn.net_Chill_Lyn_article_details_104484301]: https://blog.csdn.net/Chill_Lyn/article/details/104484301
[https_github.com_AobingJava_JavaFamily_blob_master_docs_redis_E5_B8_83_E9_9A_86_E8_BF_87_E6_BB_A4_E5_99_A8_BloomFilter_.md]: https://github.com/AobingJava/JavaFamily/blob/master/docs/redis/%E5%B8%83%E9%9A%86%E8%BF%87%E6%BB%A4%E5%99%A8%28BloomFilter%29.md
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200604173251641.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NoaWxsX0x5bg==,size_16,color_FFFFFF,t_70
[https_blog.csdn.net_Chill_Lyn_article_details_104442470]: https://blog.csdn.net/Chill_Lyn/article/details/104442470
[https_blog.csdn.net_Chill_Lyn_article_details_104460252]: https://blog.csdn.net/Chill_Lyn/article/details/104460252
[https_blog.csdn.net_Chill_Lyn_article_details_104518235]: https://blog.csdn.net/Chill_Lyn/article/details/104518235
[https_blog.csdn.net_Chill_Lyn_article_details_104501397]: https://blog.csdn.net/Chill_Lyn/article/details/104501397
[https_blog.csdn.net_Chill_Lyn_article_details_104479867]: https://blog.csdn.net/Chill_Lyn/article/details/104479867