redis知识点

太过爱你忘了你带给我的痛 2024-03-22 00:52 68阅读 0赞

### redis是什么？ ###

一种键值对数据库，也是一种分布式缓存的方案。  
基于内存的数据库，一般都用来当做缓存使用。

### 常用命令？ ###

set KEY VALUE
    get KEY
    EXISTS key
    ## 清除数据库
    > flushdb

### redis cli怎么设置过期时间？ ###

TTL: time to live，可以查看还有多久过期

SET resource:lock "Redis Demo"
        EXPIRE resource:lock 120
        TTL resource:lock => 113
        // after 113s
        TTL resource:lock => -2

### redis删除过期数据的常见策略有什么？ ###

1.  惰性删除：只有在取出key的时候才会进行过期检查。这样对cpu最友好，但可能会造成遗留大量过期key没有被删除。
2.  定期删除： ： 每隔一段时间抽取一批 key 执行删除过期 key 操作。并且，Redis 底层会通过限制\[删除操作执行的时长和频率\]，来减少删除操作对 CPU 时间的影响。

### 两种删除过期数据的策略各有什么优点？redis是用的哪种？ ###

惰性删除：对cpu好，因为删的少  
定期删除：对内存好  
redis用的是定期删除+惰性删除，因为这二者各有千秋。

### redis可以实现高什么？（。分别指什么意思？ ###

高性能和高并发

*  高性能：指读写速度更快  
    将读数据从硬盘读变为从缓存（内存）读，更快。  
    \*注意：这里缓存指的是redis实现的“缓存”，而它是基于内存的，所以我这么写。（我理解
 *  高并发：指能承载的同时读写的请求更多  
    一般像 MySQL 这类的数据库的 QPS 大概都在 1w 左右（4 核 8g） ，但是使用 Redis 缓存之后很容易达到 10w+，甚至最高能达到 30w+（就单机 Redis 的情况，Redis 集群的话会更高）。QPS（Query Per Second）：服务器每秒可以执行的查询次数；由此可见，直接操作缓存能够承受的数据库请求数量是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。进而，我们也就提高了系统整体的并发。

### 常见的缓存读写策略/缓存读写模式有？ ###

*  Cache Aside Pattern（旁路缓存模式）<-一般情况下都用这种（我感觉
 *  Read/Write Through Pattern（读写穿透）
 *  Write Behind Pattern（异步缓存写入）  
    各有优劣，不存在最佳模式，根据具体的业务场景选择适合自己的缓存读写模式。

### 说明下旁路缓存模式的读写原理 ###

读：先从cache读，如果cache没有，再从db读，并且把db读到的数据写入cache  
写：写入db，同时删除cache

#### 面试题：旁路缓存模式中，写数据的过程中，可以先删除cache，后写入db么？ ####

不行，因为可能会造成db和cache数据不一致的问题。  
举例：  
Request1要写入数据apple的price（6元/斤）。它先把旧的apple price（5元/斤）从cache中删除，此时即将写入db，但因为写入db的速度比较慢，所以此时可能有Request2插入进来读取apple的price，此时他读到的是旧的apple price（5元）因为cache已经被删了，而db里的price还没更新，所以它读到的数据不是最新的6元。

#### 展开：那么先删除cache，后写入db就不会有数据不一致的问题了么？ ####

也会有，举例：

但是写cache的速度比写db的速度快很多所以概率很小。

### 这三种缓存读写策略的具体内容和优缺点？ ###

[https://javaguide.cn/database/redis/3-commonly-used-cache-read-and-write-strategies.html][https_javaguide.cn_database_redis_3-commonly-used-cache-read-and-write-strategies.html]

### 单机redis存在什么风险？ ###

如果唯一一个redis节点宕机，就会导致大量的请求直接到数据库，数据库的负载量没那么大，严重的情况下，数据库也会宕机。

### 如何保证redis服务的高可用？ ###

高可用，也就是一个节点宕机之后，有备用节点  
在redis中，常基于**主从复制**搭建一个redis集群，来实现高可用，即master（主节点）主要负责写请求，slave（从节点）主要负责读请求。  
![在这里插入图片描述][da705a75029f47e38d6c1902dbd86bd8.png]  
如果master宕机，则从slave中选取一个出来作为新的master，这称为“故障转移”。  
![在这里插入图片描述][1b294922515b4e41b2812892f7b709e4.png]

#### “这类似mysql的读写分离”，那是啥？？？ ####

### 主从复制具体如何实现？ ###

概念：将一台redis主节点的数据复制到其他redis从节点中，并最大可能保证二者数据的统一性。

1.  基于redis的[Redis replication][]（这是算特性？还是啥？）
2.  使用replicaof命令来配置各个redis节点的主从关系

replicaof ip port

1.  配置完后，主从节点的数据同步会自动进行，不需要手动干涉

### 面试题：主从复制下，从节点会主动删除过期数据吗？ ###

类似问题：

### 面试题：主从复制下，会读取到过期数据吗？ ###

类似问题： 主从复制下，如何避免读取到过期数据？  
有可能。

1.  redis旧版本中的问题  
    Redis 3.2 版本之前，客户端读从库并不会判断数据是否过期，有可能返回过期数据。  
    Redis 3.2 版本及之后，客户端读从库会先判断数据是否过期，如果过期的话，就会删除对应的数据并返回空值。
2.  EXPIRE/PEXPIRE导致的问题  
    采用EXPIRE或PEXPIRE可能会导致。设置过期时间的话，表示的是从执行这个命令开始往后 TTL 时间过期。如果从节点同步执行命令因为网络等原因延迟的话，客户端就可能会读取到过期的数据（如下图所示，客户端在 T3-T4 之间读取到的就是过期数据）。这种情况可以考虑使用 EXPIREAT , PEXPIREAT，它们的语义和EXPIRE/PEXPIRE类似，但但不是指定 TTL（生存时间）的秒数/毫秒数，而是使用绝对的Unix时间戳，由于是绝对时间，所以主从节点的时钟需要保持一致。

![在这里插入图片描述][b4e7e9d0f51541b19b3be2b96e92c8cb.png]

### 主从复制的好处是？ ###

保证了redis的高可用性，并且实现了读写分离，提高了系统的并发量，尤其是读并发量。

### 主从节点之间如何同步数据？ ###

类似问题：

*  主从复制的原理是？
 *  复制积压缓冲区有什么用？  
    [http://t.csdn.cn/o8Bpl][http_t.csdn.cn_o8Bpl]

### 主从复制方案的痛点？ ###

master宕机时主从切换需要手动将slave转为master，且需要修改应用方的主节点地址，还需要命令从节点去复制新的主节点，这些都需要人工干预。（可以用Redis sentinel来解决）  
另外，主从复制方案在高并发场景下能力有限。如果缓存的数据量太大或者并发量要求太高，主从复制就没办法满足我们的要求了。  
主从复制和 Redis Sentinel 这两种方案都不支持横向扩展来缓解写压力以及解决缓存数据量过大的问题。我们后面介绍的 Redis Cluster（官方切片集群解决方案）就可以帮助我们来解决这个痛点。

### 比较RDB和AOF两种持久化方式 ###

RDB：Redis DataBase，原理把当前数据生成快照保存在硬盘上。  
AOF：Append Only File，原理是把每次写命令追加写入日志中  
[https://www.yuque.com/snailclimb/mf2z3k/ks9olb19hc9wse5k\#b84eb3ce][https_www.yuque.com_snailclimb_mf2z3k_ks9olb19hc9wse5k_b84eb3ce]

### redis会丢数据吗？ ###

### redis的核心流程是什么？它是什么意思？ ###

单线程模式，这就意味着Redis是串行处理所有请求的，当请求过多时，请求就会拥堵起来，从应用层的视角来看，就是请求Redis的耗时会特别特别高。

### redis热点数据是什么？ ###

Redis中某个Key的访问频次远大于其他剩余的Key。  
我们来举个简单的例子，相信大家都在微博上吃过瓜，当有大瓜出现时，微博上会迅速涌入一批用户检索相关信息，疯狂访问同一份微博（数据），这种情况下这份数据就是热点数据，如果数据太“热”最终会导致微博挂掉，实际上微博挂掉的情况已经出现很多次了，不是因为微博技术不行，而是因为热点问题太可怕。

### springboot整合redis步骤？ ###

[https://tobebetterjavaer.com/redis/redis-springboot.html\#spring-boot-%E6%95%B4%E5%90%88-redis][https_tobebetterjavaer.com_redis_redis-springboot.html_spring-boot-_E6_95_B4_E5_90_88-redis]

### memcached和redis的区别？ ###

[https://javaguide.cn/database/redis/redis-questions-01.html\#%E8%AF%B4%E4%B8%80%E4%B8%8B-redis-%E5%92%8C-memcached-%E7%9A%84%E5%8C%BA%E5%88%AB%E5%92%8C%E5%85%B1%E5%90%8C%E7%82%B9][https_javaguide.cn_database_redis_redis-questions-01.html_E8_AF_B4_E4_B8_80_E4_B8_8B-redis-_E5_92_8C-memcached-_E7_9A_84_E5_8C_BA_E5_88_AB_E5_92_8C_E5_85_B1_E5_90_8C_E7_82_B9]

[https_javaguide.cn_database_redis_3-commonly-used-cache-read-and-write-strategies.html]: https://javaguide.cn/database/redis/3-commonly-used-cache-read-and-write-strategies.html
[da705a75029f47e38d6c1902dbd86bd8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/f6d7c96078904ca1ae5046b400003ed2.png
[1b294922515b4e41b2812892f7b709e4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/64b58afeda264757ba8760e30df6e563.png
[Redis replication]: https://redis.io/docs/management/replication/
[b4e7e9d0f51541b19b3be2b96e92c8cb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/0b400e857556427f952f7485f0594590.png
[http_t.csdn.cn_o8Bpl]: http://t.csdn.cn/o8Bpl
[https_www.yuque.com_snailclimb_mf2z3k_ks9olb19hc9wse5k_b84eb3ce]: https://www.yuque.com/snailclimb/mf2z3k/ks9olb19hc9wse5k#b84eb3ce
[https_tobebetterjavaer.com_redis_redis-springboot.html_spring-boot-_E6_95_B4_E5_90_88-redis]: https://tobebetterjavaer.com/redis/redis-springboot.html#spring-boot-%E6%95%B4%E5%90%88-redis
[https_javaguide.cn_database_redis_redis-questions-01.html_E8_AF_B4_E4_B8_80_E4_B8_8B-redis-_E5_92_8C-memcached-_E7_9A_84_E5_8C_BA_E5_88_AB_E5_92_8C_E5_85_B1_E5_90_8C_E7_82_B9]: https://javaguide.cn/database/redis/redis-questions-01.html#%E8%AF%B4%E4%B8%80%E4%B8%8B-redis-%E5%92%8C-memcached-%E7%9A%84%E5%8C%BA%E5%88%AB%E5%92%8C%E5%85%B1%E5%90%8C%E7%82%B9