redis专栏

在我们背诵这些八股文之前，我们不妨自己思考以下能回答出几道题，自己回答的和百度的是否一致

使用场景

缓存，分布式锁，计数器，保存token，消息队列，延迟队列

使用场景问题：

• Redis的数据持久化策略有那些？
• 什么是缓存穿透，怎么解决？
• 什么是布隆过滤器？
• 什么是缓存击穿，怎么解决？
• 什么是缓存雪崩，怎么解决？
• redis双写问题
• redis分布式锁如何实现
• redis分布式锁如何合理的控制锁的有效时长
• redis的数据过期策略有哪些？
• redis的数据淘汰策略有哪些？

其他问题：
redis集群有哪些方案？
什么是redis主从同步?
你们使用redis是单点还是集群？哪种集群
redis分片集群中数据是怎么存储和读取的
redis集群脑裂
怎么保证redis的高并发和高可用
你们用过redis的事务吗？事务的命令有哪些
redis是单线程的，但是为什么还那么快。

相关信息

Redis的数据持久化策略有那些？

持久化策略主要有两种：RDB(Redis DataBase)和AOF(Append Only File)

RDB:通过指定时间间隔将内存数据集快照写入磁盘。Redis会单独创建一个子进程来进行持久化，将数据写入到一个临时文件(dump.rdb).缺点是如果发生在两次快照间隔期，可能丢失一部分数据
AOF:记录服务器接收的每个写操作，性能不如RDB

什么是redis的缓存穿透？

用户请求的数据在缓存中不存在，数据库也不存在，导致每次都去查询数据库，返回空。不断请求系统中不存在的数据，每次都去数据库查，造成数据库压力过大。

解决方案：
1.缓存空数据：当查询返回的数据为空，仍把这个空结果进行缓存
2.使用锁： 当发现缓存不存在时，可以使用锁来避免多个相同请求同时访问数据库，
3.布隆过滤器： 一种数据结构，快速判断一个元素是否存在于一个集合中

什么是布隆过滤器

在查询redis之前经过布隆过滤器过滤一遍，没有则直接返回空。布隆过滤器存在误判的可能，主要应用在对于大数据量的，对于查询精度要求不那么高的应用中。
布隆过滤器是存放在redis中的特殊数据，集成在redis中。
主要原理是对查询的key值进行多次不同的hash，将结果存放到多个bit位中，因为利用了hash算法，可能会存在hash碰撞-----不同的值hash后指向了同一个位置。所以布隆过滤器的结果可以看作：不存在则一定不存在，存在则不一定存在。

如何减少hash碰撞发生的概率呢？

1.增加hash的次数，通过多个hash落在不同的位置，减少误判,这会增加cpu的一个运算量
2.增加存放的字节的长度，这样会减少落在同一个位置的概率，但是会增加内存。
具体怎么考虑，需要找到一个平衡内存，空间和容错率的值

什么是redis的缓存击穿？

当缓存中某个热点数据突然过期或者被删除时，突然有大量的请求访问这个数据，请求直接打到了数据库。
为了避免这种情况，我们可以采取一些策略。比如使用互斥锁来确保同一时间只有一个请求去查询数据库，并将查询结果更新到缓存中。当然还有其他解决方法，比如预热缓存，设置缓存永不过期等…

什么是缓存雪崩

在某个特定的时间段，缓存中的大部分数据都过期了，导致大量的请求直接访问数据库
缓存雪崩可能由以下几种情况引起：
1.缓存数据同时过期
2.缓存服务器宕机
解决方案：搭建redis的高可用集群

redis的双写问题

主要涉及在修改数据库中的数据时，如何保持redis中的缓存数据与数据库一致。
主要考虑延迟一致性：
1.在更新数据库的数据后，不立即删除缓存中的数据，而是等待一段时间再删除。—这我也不懂，结合具体情况吧
2.使用异步通知工具：当有数据被写入数据库时，异步通知的工具捕获变更的信息，发送给redis做更新。------这个靠谱一点

redis分布式锁如何实现

这个不建议看，业务中没用到，忽略吧

redis的数据过期策略有哪些？

1.定时删除：当设置了过期时间的key过期时，redis会立即创建一个定时器来删除这个key.然而，这种策略对CPU并不友好，它需要不断地检查key的过期时间，即使key的过期时间还很长。
2.惰性删除：当客户端访问时，会判断过期时间，如果过期就会删除。缺点是对于内存会有一定的压力。
3.定期删除：结合定时删除和惰性删除。redis定期的检查数据库中的过期数据，采用抽样方法估计过期数据的比例，当比例超过预设的阈值(比如1/4),redis执行删除操作，使得过期数据比例下降到阈值以下。

redis的数据淘汰策略有哪些？

主要有8种

• noeviction(默认)：当内存不足以容纳新写入数据时，新写入操作会报错。此策略不会淘汰任何数据，只会在内存不足时阻止新的写入请求。
• volatile-lru：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。如果数据集中没有已设置过期时间的数据，那么该策略和noeviction策略一样，不淘汰任何数据。
• volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据淘汰。这种方法与volatile-lru类似，但它更关注过期时间较短的数据。
• volatile-random:对设置了TTL的key，随机进行淘汰
• volitile-lfu:对设置了ttl的key,基于LFU算法进行淘汰。
• allkeys-random:对全体key进行随机淘汰。
• allkeys-lru:对全体key,基于LRU算法进行淘汰
• allkeys-lfu:对全体key,基于LFU算法进行淘汰

说一下LRU的相关概念：最近最少使用。用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。

• 举例：key1是在3s之前访问的，key2是在9秒之前访问的，删除的就是key2.

LFU:最少使用频率。会统计每个key的访问频率，值越小淘汰优先级越高。

• 举例：key1最近5s访问了4次，key2最近5s访问了9次，删除的就是key1.

数据淘汰策略使用建议:

• 优先使用allkeys-lru策略。充分利用LRU算法的优势，把最近最长访问的数据留在缓存中，如果业务有明显的冷热数据区分，建议使用
• 如果业务中数据访问频率差别不大，没有明显冷热数据区分，建议使用allKeys-random,随机选择淘汰。
• 如果业务中有置顶的需求，可以使用vliatile-lru策略，同时置顶数据不设置过期时间，这些数据就一直不被删除，会淘汰其他设置过期时间的数据。
• 如果业务中有短时高频访问的数据，可以使用allkeys-lfu或volatile-lfu策略。

面试问题举例：
1.数据库有1000万数据，redis只能缓存20w的数据，如何保证Redis中的数据都是热点数据？
回答：使用allkeys-lru淘汰策略，留下来的都是经常访问的热点数据
2.redis内存用完了会发生什么？
主要看数据淘汰策略是什么？如果是默认的配置(noeviction),会直接报错。

其他问题

Redis的集群方案有哪些？

1.主从复制
2.哨兵模式
3.分片集群

相关问题：
1.redis主从数据同步流程是什么？
2.怎么保证redis的高并发和高可用
3.你们使用redis是单点还是集群，哪种集群？
4.Redis分片集群中数据是怎么存储和读取的？
5.Redis集群脑裂，该怎么解决呢？

主从复制

单节点redis的并发能力是有上限的，要进一步提高redis的并发能力，就需要搭建主从集群，实现读写分离

Replication Id:简称replid,是数据集的标记，id一致则说明是同一数据集，每一个master都有唯一的replid,slave则会继承master节点的replid
offset:偏移量，随着记录在repl_baklog中的数据增多而逐渐增大，slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset,说明salve数据落后于master，需要更新

说明：如果从节点的id和主节点不一致，则是第一次同步数据，执行上述操作，如果一致并且offset不同，则只需要发送repl_baklog让从节点更新即可。

模拟面试题：

1.介绍一下redis的主从同步

单节点的Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离，一般就是一主多从，主节点负责写数据，从节点负责读数据。

2.能说一下主从同步的流程吗？

全量同步：
1.从节点请求主节点的同步数据(replication id,offset)
2.主节点判断是否是第一次请求，是第一次请求就与从节点同步版本信息（replication id和offset）
3.主节点执行bgsave,生成rdb文件后，发送给从节点去执行
4.在rdb生成执行期间，主节点会以命令的方式记录到缓冲区(一个日志文件)
5.把生成之后的命令日志文件发送给从节点进行同步
增量同步：
1.从节点请求主节点同步数据
2.主节点判断不是第一次请求，获取到从节点的offset值
3.主节点获取offset值之后的数据，发送给从节点进行数据同步

哨兵模式

Redis提供了哨兵机制来实现主从集群的自动故障恢复。哨兵的结构和作用如下：
监控：Sentinel会不断检查您的master和slave是否按预期工作
自动故障恢复：如果master故障，Sentinel会将一个slave提升为master.当故障实例恢复后也以新的master为主。
通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis客户端。

服务状态监控
Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

• 主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
• 客观下线：若超过指定数量(quorum)的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

哨兵选主规则

• 首先判断主与从节点断开时间长短，如超过指定值，该从节点不会被选择成为主节点
• 然后判断从节点的slave-priority值，越小优先级越高
• 如果slave-prority一样，则判断slave节点的offset值，越大优先级越高
• 最后判断slave节点的运行id大小，越小优先级越高

脑裂问题

主从节点不再同一个服务器，主节点网络异常，继续写的数据无法同步，从节点选出新的主节点，当数据恢复后，老的主节点成为从节点，之前的数据丢失。

解决方案：
redis中有两个配置参数：min-replicas-to-write 1 表示最少的salve节点为1
min-replicas-max-lag 5 表示数据复制和同步的延迟不能超过5秒
个人解释下：当主节点连接不上其他从节点时，因为min-replicas-to-write 1的原有，主节点拒绝写入，哨兵发起服务状态变更通知，告知客户端变更写入到新的被选举出的主节点。min-replicas-max-lag 5限制了丢失的数据量，确保从节点基本上和主节点保持一致。在切换主节点时，减少丢失的数据量。

模拟面试题

1.怎么保证redis的高并发高可用？

哨兵模式：实现主从集群的自动故障恢复

2.你们使用的redis是单点还是集群？哪种集群？

这个就不说了，涉及商业机密

3.redis的集群脑裂，该怎么解决？
集群脑裂是由于主节点和从节点和sentinel处于不同的网络分区，使得sentinel没有能够心跳感知到主节点，所以通过选举的方式提升了一个从节点为主，这样就存在了两个master,就像大脑分裂了一样，这样会导致客户端还在老的主节点那里写入数据，新节点无法同步数据，当网络恢复后，sentinel会将老的主节点降为从节点，这时再从新的master同步数据，就会导致数据丢失。
解决：我们可以修改redis的配置，可以设置最少的节点数量以及缩短主从数据同步的延迟时间，达不到要求就拒绝请求，就可以避免大量的数据丢失。

分片集群结构

主从和哨兵可以解决高可用，高并发读的问题，但是依然有两个问题没有解决：

• 海量数据存储问题
• 高并发写的问题

使用分片集群可以解决上述问题，分片集群特征：

• 集群中有多个master,每个master保存不同数据
• 每个master都可以有多个slave节点。
• 客户端请求可以访问集群任意节点，最终都会被转发到正确节点。

分片集群结构-数据读写

Redis分片集群引入了哈希槽的概念，redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

可以设置有效部分使得同一类业务数据存放在相同的redis集群中。

模拟

1.redis的分片集群有什么作用？

• 集群中有多个master，每个master保存不同数据
• 每个master都可以有多个slave节点
• master之间通过ping监测彼此健康状态
• 客户端请求可以访问集群任意节点，最终都会被转发到正确节点

2.redis分片集群中数据是怎么存储和读取的？

• redis分片集群中引入了哈希槽的概念，redis集群有16384个哈希槽
• 将16384个插槽分配到不同实例
• 读写数据：根据key的有效部分计算哈希值，对16384取余(有效部分，如果key前面有大括号，大括号的内容就是有效部分，如果没有，则以key本身作为有效部分)，余数作为插槽，寻找插槽所在实例。

3.Redis是单线程的，但是为什么还那么快？

• Redis是纯内存操作，执行速度非常快
• 采用单线程，避免不必要的上下文切换可竞争条件，多线程还要考虑线程安全问题
• 使用I/O多路复用模型

4.能解释一下I/O多路复用模型？
Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度，I/O多路复用模型主要就是实现了高效的网络请求。

你需要掌握的知识：

• 用户空间和内核空间
• 常见的IO模型
  • 阻塞IO
  • 非阻塞IO
  • IO多路复用
• Redis网络模型

小结

个人建议：在复习完这些知识点后，自己先看看自己公司的redis集群搭建框架，之后在虚拟机上自己搭建一遍。