目录
1.redis主要消耗什么物理资源？
2.单线程为什么快
3.为什么要使用Redis
4.简述redis事务实现
5.redis缓存读写策略
6.redis除了做缓存，还能做些什么？
7.redis主从复制的原理
8.Redis有哪些数据结构？分别有哪些典型的应用场景？
9.如何解决 Redis 的并发竞争 Key 问题
10.缓存雪崩、缓存穿透、缓存击穿，如何解决
11.Redis和Mysql如何保证数据一致
12.redis的持久化机制
13.redis内存淘汰机制
14.Redis如何设置key的过期时间
15.Redis过期键的删除机制
16.Redis集群会有写操作丢失吗？为什么？
17.redis集群方案
18.Redis常见性能问题和解决方案？
19.Redis分布式锁是如何实现的？
20.Redis死锁情况，如何避免死锁
21.redis 6.0新增特性
22.redis 6.0为什么要改为多线程
23.redis和redisson有什么关系？
1.redis主要消耗什么物理资源？
内存
2.单线程为什么快
1.纯内存操作
2.核心是基于非阻塞的IO多路复用机制，避免了多线程的频繁上下文切换带来的性能问题
3.Redis 内置了多种优化过后的数据结构实现，性能非常高
3.为什么要使用Redis
高性能：操作缓存就是直接操作内存，所以速度相当快
高并发：Redis每秒查询次数最高能达到 30w+，能够承受的请求数量是远远大于直接访问数据库的
4.简述redis事务实现
事务是一个单独的隔离操作：一组按顺序执行的命令集合；事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行
实现：
1.执行命令 multi 开启一个事务
2.开启事务之后执行的命令都会被放入一个队列，如果成功之后会固定返回队列
3.执行命令 exec 提交事务之后，Redis 会依次执行队列里面的命令，并依次返回所有命令结果（如果想要放弃事务，可以执行 discard 命令）
命令：
multi：开启事务
exec：执行事务
discard：取消事务
watch：监视
5.redis缓存读写策略
旁路缓存模式：服务端同时维护Mysql和Redis，并且以Mysql的主要存储；
读：先从Redis中读，如果Redis中没有，再从Mysql中读取，并将结果返回写入Redis
写：先写Mysql，再删除Redis
缺陷：1.首次请求数据一定不在 Redis中（可以将热点数据可以提前放入Redis中）2.写操作比较频繁的话导致 cache 中的数据会被频繁被删除，这样会影响缓存命中率（加一个锁）
读写穿透：视Redis为主要存储
读：先从Redis中读，读到直接返回。没有读到就从Mysql中读取数据放入到Redis中后，再返回数据
写：先看Redis中是否存在该数据，存在则先更新换，再更新数据库
缺陷：1.首次请求数据一定不在 Redis中（可以将热点数据可以提前放入Redis中）
异步缓存写入：视Redis为主要存储
只更新缓存，不直接更新Mysql，而是改为异步批量的方式来更新Mysql
6.redis除了做缓存，还能做些什么？
分布式锁
限流:一般是通过 Redis + Lua 脚本的方式来实现限流
消息队列 ........
7.redis主从复制的原理
数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器;
好处：
- 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式
- 负载均衡：可以轻易地实现横向扩展，实现读写分离
- 故障恢复：如果master宕掉了，使用哨兵模式，可以提升一个 slave 作为新的 master，进而实现故障转移，实现高可用
流程：
slave服务器连接到master服务器，便开始进行数据同步
master服务器收到psync命令之后，开始执行bgsave命令生成RDB快照文件并使用缓存区记录此后执行的所有写命令
master服务器bgsave执行完之后，就会向所有Slava服务器发送快照文件，并在发送期间继续在缓冲区内记录被执行的写命令。
slave服务器收到RDB快照文件后，会将接收到的数据写入磁盘，然后清空所有旧数据，在从本地磁盘载入收到的快照到内存中，同时基于旧的数据版本对外提供服务。
master服务器发送完RDB快照文件之后，便开始向slave服务器发送缓冲区中的写命令。
slave服务器完成对快照的载入，开始接受命令请求，并执行来自主服务器缓冲区的写命令；
如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF。
8.Redis有哪些数据结构？分别有哪些典型的应用场景？
String：字符串；计数器、分布式id、token
hash：哈希；用户信息、商品信息、文章信息、购物车信息
List：列表；最新文章、最新动态
Set：集合；共同关注、点赞
ZSet：有序集合；排行榜
9.如何解决 Redis 的并发竞争 Key 问题
Redis 的并发竞争 Key 的问题也就是多个系统同时对一个 key 进行操作
解决方案：
- 乐观锁：适用于大家一起抢着改同一个key，对修改顺序没有要求的场景，使用watch命令来实现
- 分布式锁：在业务层进行控制，操作 redis 之前，先去申请一个分布式锁，拿到锁的才能操作
- 时间戳：写入时保存一个时间戳，写入前先比较自己的时间戳是不是早于现有记录的时间戳，如果早于，就不写入
- 消息队列：在并发量很大的情况下，可以通过消息队列进行串行化处理
10.缓存雪崩、缓存穿透、缓存击穿，如何解决
缓存雪崩：缓存同一时间大面积失效，所有请求落在数据库上
解决：
缓存数据过期时间设置随机，防止同一时间大面积过期
给每个缓存增加标记，记录缓存是否失效，如果失效，则更新数缓存
缓存预热
互斥锁
缓存穿透：缓存和数据库中都没有数据，所有请求都落在数据库上
解决：
接口层增加校验，如用户鉴权校验，id做基础校验
从缓存取不到的数据，在数据库中也没有取到，可以将value设为null
布隆过滤器，将所有数据存到bitmap中，不存在数据会被拦截掉
缓存击穿：同一条数据，缓存中没有，数据库中有，但由于访问并发量大，造成数据库压力大
解决：
设置热点数据永远不过期
加互斥锁，互斥锁缓存预热
11.Redis和Mysql如何保证数据一致
延迟双删：先删除redis数据，再更新mysql，延迟几百毫秒，再删除redis数据；
12.redis的持久化机制
持久化机制：redis数据都是存储在内存中，为了避免数据丢失，需要将数据以某种形式从内存中保存到硬盘中，重启时利用持久化数据恢复。
RDB（快照）：指定时间间隔将数据进行快照存储，重启时读取文件来恢复数据
触发方式：
- 配置文件
- 执行filshall命令（这个命令就相当于删库跑路）
- 执行shutdown命令（客户端执行命令）
- 执行bgsave命令（对save命令的优化，异步操作）
- 执行save命令（同步操作命令）
AOF（日志文件）：记录每次对服务器的操作，当服务器重启重新执行这些命令恢复原始数据
aof持久化方式redis是默认不开启的，我们可以通过配置文件开启aof持久化方式（appendonly的值默认为no，改为yes）
13.redis内存淘汰机制
跟redis的内存淘汰机制有关，默认是当内存用完写入数据报错
内存淘汰机制：
1.从已设置过期时间的数据中挑选最近最少使用的数据淘汰
2.从已设置过期时间的数据中挑选将要过期的数据淘汰
3.从已设置过期时间的数据中任意选择数据淘汰
4.从已设置过期时间的数据中挑选最不经常使用的数据淘汰
5.移除最近最少使用的 key
6.移除最不经常使用的 key
7.任意选择数据淘汰
8.写入数据报错
14.Redis如何设置key的过期时间
redis作为缓存存储的时候，一般都要设置过期时间，否则垃圾数据会占用大量的内存
分开设置：先设置值，再设置时间（非原子操作，极端情况下会出现问题）；
合并设置：一条命令设置过期时间和值（推荐）
命令：
设置过期时间：expire name 1000
查看剩余时间：ttl name
取消过期时间：persist name
15.Redis过期键的删除机制
惰性过期：当访问key时，检查是否过期，过期则删除；最大化节约cpu，但对内存不友好；极端情况下出现大量过期key未被访问，会占用大量内存
定期过期：每隔一段时间扫描一定数量的key，并清除已过期的key；通过调整扫描时间间隔和扫描耗时，可以让cpu和内存达到最优的平衡效果
16.Redis集群会有写操作丢失吗？为什么？
Redis并不能保证数据的强一致性，这意味这在实际中集群在特定的条件下可能会丢失写操作
条件：
- 过期key被清理
- 最大内存不足，导致 Redis 自动清理部分 key 以节省空间
- 主库故障后自动重启，从库自动同步
- 单独的主备方案，网络不稳定触发哨兵的自动切换主从节点，切换期间会有数据丢失
17.redis集群方案
主从模式：使用一个redis实例作为主机，其余的实例作为备份机，主机和从机的数据完全一致，主机支持数据的写入和读取等各项操作，而从机则只支持与主机数据的同步和读取
优缺点：
- 一个主节点可以同步多个从节点
- 难以支持在线扩容
- 不具备自动容错与恢复功能
- 主从之间的同步是以非阻塞的方式进行的，同步期间，客户端仍然可以提交查询或更新请求
- 主节点自动将数据同步到从节点，可以进行读写分离
哨兵模式：Redis集群站哨的，一旦发现问题能做出相应的应对处理；监控主节点、从节点是否正常运行当主节点出现故障时，能自动将一个从节点转换为主节点（大哥挂了，选一个小弟上位）多个哨兵可以监控同一个Redis，哨兵之间也会自动监控
Redis Cluster模式：Cluster采用无中心结构,客户端与redis节点直连,客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可
18.Redis常见性能问题和解决方案？
- 主节点不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化
- 如果数据比较关键，某个从节点开启AOF备份数据，策略为每秒同步一次
- 为了主从复制的速度和连接的稳定性，主从节点最好在同一个局域网内
- 尽量避免在压力较大的主库上增加从库
- 为了主节点的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，主节点挂了，可以立马启用Slave1做主节点，其他不变
19.Redis分布式锁是如何实现的？
分布式锁，即分布式系统中的锁，解决了分布式系统中控制共享资源访问的问题；
- 基于set命令的分布式锁
- 基于setnx、get、getset的分布式锁
- 基于RedLock的分布式锁
- 基于Redisson看门狗的分布式锁
20.Redis死锁情况，如何避免死锁
发生条件：
- ⼀个资源每次只能被⼀个线程使用
- ⼀个线程在阻塞等待某个资源时，不释放已占有资源
- ⼀个线程已经获得的资源，在未使用完之前，不能被强制剥夺
- 循环等待
解决：
- 使用事务时，尽量缩短事务的逻辑处理过程，及早提交或回滚事务
- 所有的程序都要有错误处理
- 对所有的脚本和程序都要仔细测试
- 优化程序，检查并避免死锁现象出现
- 设置死锁超时参数为合理范围，超过时间，自动放弃本次操作，避免进程悬挂
21.redis 6.0新增特性
新增特性：
- 多线程
- 客户端缓存
- 细粒度权限控制
- resp3协议的使用
- rdb文件加载更快
- 用于复制的rdb文件不再有用，将立刻被删除
22.redis 6.0为什么要改为多线程
随着硬件性能的提升，redis单个线程处理网络读写的速度跟不上底层网络硬件的速度。读写占用了大部分cpu的时间，瓶颈主要是网络的io消耗；优化的方向主要是：
1.优化网络 I/O 模块
2.提高机器内存读写的速度
提高机器内存读写的速度依赖于硬件，暂时无解；所以，Redis 采用多个 IO 线程来处理网络请求，提高网络请求处理的并行度。
Redis 多 IO 线程模型只用来处理网络读写请求，对于 Redis 的读写命令，依然是单线程处理文章来源：https://www.toymoban.com/news/detail-426059.html
23.redis和redisson有什么关系？
Redisson是一个高级的分布式协调Redis客服端，能帮助用户在分布式环境中轻松实现一些Java的对象文章来源地址https://www.toymoban.com/news/detail-426059.html
到了这里，关于java面试题（redis）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
