Redis 面试准备

系列文章目录

提示：这里可以添加系列文章的所有文章的目录，目录需要自己手动添加

---

提示：写完文章后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

提示：这里可以添加本文要记录的大概内容：

例如：随着人工智能的不断发展，机器学习这门技术也越来越重要，很多人都开启了学习机器学习，本文就介绍了机器学习的基础内容。

---

提示：以下是本篇文章正文内容，下面案例可供参考

常用操作

bit操作

setbit

设置一个key值的bit位

bigcount

统计bit位

incr、incrby、decr、decrby

自增减、自增减某值

watch

用来保证事务。该命令可以监控1个或多个键，一旦其中有一个键被修改或删除，之后的事务就不会执行。

register_script

执行一段lua脚本。
应用：通常用来实现原子操作，如redis解锁操作。

pipeline

打包将命令一块儿发过去，在服务端拆分执行，并不保证原子性。通过配置参数，可以保证事务（当前默认保证）。

scan

对key进行正则扫描， 避免直接调用keys扫描全部从而引发阻塞。通过游标分步执行避免阻塞，通过limit限制搜索到的最大条数。

flushall async

异步快速删除

数据结构

ziplist

listpack

示例：pandas 是基于NumPy 的一种工具，该工具是为了解决数据分析任务而创建的。

缓存更新策略

主动更新

通过应用api调用

被动更新

过期机制

对于设置了过期时间的key会放入到一个独立的字典中，以后会定期遍历这个字典来删除到期的key。

删除策略

redis采取的策略为定期删除和惰性删除

1. 定期删除
   遍历指定库数，指定key数，然后随机删除，删除运行时间够了就退出。
   例：每秒10次扫描，每次随机挑20个key，如果比例超过1/4，则重复步骤，超过25ms退出。
2. 惰性删除
   当用到key时判断是否过期，执行删除操作。
3. 定时删除
   主动为key设置一个定时器，到点删除。

定时任务 serverCron

redis中使用定时任务实现删除策略等操作。通常每毫秒更新一次。
使用定时任务的场景：过期key的主动淘汰；渐进式hash迁移；触发bgsave时

内存淘汰

所有头对象节点都有一个24bit的字段，用来记录对象的热度。

LRU（Least Recently Used）

通常使用双向链表或者双向链表和哈希实现。

Redis的LRU

近似LRU算法，因为双向链表要维护双向指针，开销较大，所以通过随机选取部分数据进行LRU判定。维护一个淘汰池，每次随机得出的淘汰key会和淘汰池做一个融合，淘汰掉最老的。

LRU方法：
1.allkeys-lru
2.volatile-lru 只选择有过期时间的参与lru

LFU（Least Frequently Used）

通常使用哈希和数组或者哈希和堆实现。

TTL（Time to Live）

选择剩余存活时间最短的进行淘汰。

随机淘汰

报错

事务

一次性、顺序性、排它性的执行队列中的一组命令。 不保证原子性，没有回滚，如果事务中一条执行失败会继续执行其他命令； 没有隔离级别，不过有隔离操作，即指令执行中不会被其他客户端打断。
乐观锁
可以借助watch实现，监控数据是否被修改过，没有则成功，否则失败。

分布式锁

redisson实现

单点锁

存在问题：
非公平锁，获得锁的任务需要自旋，浪费资源。

1.引入库

代码如下（示例）：

2.读入数据

代码如下（示例）：

该处使用的url网络请求的数据。

---

一致性策略

任何数据冗余，必将引发一致性问题

方案

没有绝对完美的方案，需要因地制宜，合适的即为最好的。根据对一致性需求的强弱进行判断，通常场景保证最终一致性即可。
1. 先改数据库再删缓存
缺点：在写db时，存在其他client读到旧数据的可能。适合最终一致性场景。
2. 延时双删
缺点：延时时间不好控制，通常设置200ms。同上，依旧无法避免一致性问题，适合查询不是特别频繁，最终一致性场景。
3. 加锁
例：更新操作时先记录一个唯一变更key作为锁，更新未完成时如有其他更新则获取锁失败。引入操作较多，或者就直接读db。
适合强一致性场景。
4. 队列同步
对于更新操作均加入队列中，依赖队列保证同步更新。适合无需实时查询，最终一致性场景。

穿透、击穿、雪崩

本质都是大量请求怼到了数据库上

穿透

大量请求缓存中不存在的数据，导致所有的请求都怼到数据库上，从而数据库连接异常。
方案：可以先缓存个空值，并且判断是否为可能存在的数据，不可能直接返回；可能是恶意攻击，可以通过过滤器进行登陆限制。

击穿

大量请求缓存中的热点数据，当热点数据过期的一瞬间，所有的请求都怼到数据库上，从而数据库连接异常。
方案：热点商品不过期或者及时更新过期时间；或者加一个互斥锁，等有了数据再释放锁。

雪崩

缓存同一时间大面积的失效（过期或者崩溃），这个时候又来了一波请求，结果请求都怼到数据库上，从而导致数据库连接异常。
方案：redis挂了导致可以加集群；可以合理分配缓存间隔，加一个过期随机值；除了分布式缓存，做多级缓存，通过定时任务预热数据到一级缓存上；做限流，每秒请求一部分响应，剩余的降级返回静态数据

集群方式

单点模式

主从模式

哨兵模式

cluster模式

持久化方式

rdb

aof

混合

4.0新功能。把当前数据以rdb形式存储，把后续的命令以aof格式存入，降低数据丢失风险。

高并发原因

性能优化

1. 缩短键值对的存储长度
2. 禁用长耗时的查询命令，如keys，使用scan替代
3. 限制redis内存使用大小
4. 使用分布式集群加快读写速度
5. 客户端使用连接池，避免频繁创建和销毁连接；使用pipeline批量操作数据
6. 避免大量数据同时失效
7. 选择合适的持久化策略
8. 使用slowlog优化耗时命令

总结

提示：这里对文章进行总结：

以上就是今天要讲的内容，本文仅仅简单介绍了redis的面试考察要点。