1. redis 为什么快？

在底层上， redis 使用了 IO 多路复用技术，像 select、epoll 等。能较好的保障吞吐量。而且 redis 采用了单线程处理请求，避免了线程切换和锁竞争锁带来的额外消耗。

加上 redis 本身也对一些数据结构进行了优化设计，所以 redis 的性能非常好，官方给出的测试报告是单机可以支持约 10w/s 的 QPS。

2. Redis 有哪些使用场景？应用是怎么样的？

Redis 的使用场景有很多，最常用的莫过于数据缓存了。但由于它提供了多种数据类型，因此我们还可以进行其他场景的开发，比如：

• 排行榜：有序集合（sorted set）每次写入都会进行排序，而且不含重复值，所以我们可以将用户的唯一标识，比如 userId 作为 key，分数作为 score，然后就可以进行 ZADD 操作，以得到排行榜。
• 签到：签到往往只有 2 种状态，已签到和未签到。这就跟 0 和 1 一样，所以 redis 的 setbit、getbit 这种对位的操作就适合签到场景。
• 计数：redis 是单线程操作，这种计数功能，比如点赞数、粉丝数的操作可以交给 redis 以避免并发竞争问题。当然，也得考虑持久化问题。

3. Redis 通信协议 是怎么样的？

redis 采用文本序列化协议，和 http 协议一样，一个请求一个响应，客户端接到响应后再继续请求。也可以发起多次请求，然后一次响应回所有执行结果，即所谓的 pipeline 管道技术。

redis 的文本序列化协议比较简单，通过一些规范格式去解析文本，大概如下：

• \r\n 表示解析结束
• 简单字符串，以“+”开头
• 错误 Errors，以“-”开头
• 整数类型，以“:”开头
• 大字符串类型，以“$”开头
• 数组类型，以“*”开头

例如，客户端向服务器发送命令：

SET key value

将被解析为：

*3\r\n$3\r\nSET\r\n$3\r\nkey\r\n$5\r\nvalue\r\n

上面的命令可以看成：

*<参数数量> CR LF

$<参数 1 的字节数量> CR LF
<参数 1 的数据> CR LF
...
$<参数 N 的字节数量> CR LF
<参数 N 的数据> CR LF

而服务器的回复则有很多类型，一般由响应数据的第一个字节决定：

状态回复（status reply）的第一个字节是 "+"

错误回复（error reply）的第一个字节是 "-"

整数回复（integer reply）的第一个字节是 ":"

批量回复（bulk reply）的第一个字节是 "$"

多条批量回复（multi bulk reply）的第一个字节是 "*"

例如，响应回来的状态回复如下：

+OK

4. redis 对外提供了哪些数据类型，它们的底层数据结构又是怎么样的？

为了让开发者能更好的使用缓存，redis 支持了 5 种数据类型。底层是由 6 种数据结构组成的。

5 种数据类型

字符串：字符串类型是 redis 里最基础的数据类型，像 set name "hello" 操作后，在 get name 时返回的就是字符串，而且还支持了对位的操作。一般一个键能存储 512MB 的值。

hash：哈希类型主要是用来存储对象的，一般我们如果有一整个对象要存储，里面包含了多个字段，则可以使用 hash 来存储，因为 redis 提供了对这些字段的提取和设置，减少了开发者对它的二次处理，比如序列化反序列化操作。

list：一个简单的字符串列表，它允许我们从两端进行 push，pop 操作,还支持一定范围的列表元素。可以看成是双向列表。

set：集合是一个不重复值的组合，为我们提供了交集、并集、差集等操作，像找出共同好友这种需求就可以使用集合操作了。

sorted set：有序集合，在上面集合的基础上提供了排序功能，通过一个 score 属性来进行排序。

6 种底层数据结构

上面的数据类型实际上在 redis 底层是有对应的数据结构来实现的，都是 redis 经过精心设计的，能很好的提高处理效率。

简单动态字符串：redis 是使用 C 语言写的，而 C 语言里的字符串类型比较原始，比如使用 \0 作为字符结束符。所以 redis 实现了属于自己的字符串类型，比如字符串长度，预先分配内存，动态拓展等特点，也保证了处理安全性。

链表：一个双端链表，有 prev，next 指针去获取前后节点，带有 len 属性，能保存多种类型的值。

字典：通过哈希算法来实现 key-value 的映射操作，采用链地址法解决了 hash 冲突，一般时间复杂度能达到 O(1)。

跳跃表：一个多层有序链表，每一层都是对下面一层的有序提取，能降低搜索次数，有点像有序二叉树的搜索一样。

整数集合：一个有序的整数集合，不会有重复元素。

压缩列表(ziplist)：经过特殊编码的一块连续内存，能有效的节省内存。

快速列表：将 ziplist 组织为了一个双向链表，由于 ziplist 的内部连续性，能降低链表的内存碎片问题，提高内存利用率。

5. redis 淘汰策略有哪些？

redis 的淘汰策略主要是 LRU 淘汰、TTL 淘汰和随机淘汰这三种机制。

• LRU 淘汰：最近最少使用的淘汰掉
• TTL 淘汰：越早过期的越先淘汰掉。
• 随机淘汰：采用随机算法淘汰掉。

由于 redis 可以对键设置过期时间，也可以不设置，所以淘汰策略还得再细分：

• volatile-lru：针对设置了过期时间的 key 执行 LRU 淘汰策略，没有设置过期时间的不会被淘汰。
• volatile-ttl：只针对设置了过期时间的 key 执行 TTL 淘汰。
• volatile-random：只针对设置了过期时间的 key 执行随机淘汰。
• allkeys-lru：针对所有键进行 LRU 淘汰策略
• allkeys-random：针对所有键进行随机淘汰策略
• no-enviction：不执行淘汰策略，如果有写入操作，则报错；读请求可以继续进行。

在 Redis 的配置文件 redis.conf 里我们可以进行淘汰策略的设置：

# 数据达到多大后执行淘汰策略
maxmemory 300mb

# 淘汰策略的设置
maxmemory-policy volatile-lru

6. redis 的持久化机制有哪些？

RDB

在指定的时间间隔里将 Redis 内存里的数据镜像下来，保存到文件里。它会先 fork 一个子进程，将数据的写入交给子进程，而父进程不会涉及到磁盘的 IO 操作，所以 RDB 的性能非常好。如果是在 Unix 系统上，还能充分利用写时复制机制，节省对物理内存的使用。

由于 RDB 文件只存储了某个时刻的内存数据，并没有什么逻辑命令，所以在进行重启恢复时，能很快的加载进来。

虽然 RDB 的 fork 能使得 Redis 的持久化独立进行，但是一旦数据量比较大的，就会一直占用 CPU，可能会影响到父进程的进行。

AOF

将服务器对数据的写操作追加到文件里，相当于将所有的逻辑操作都记录了下来。AOF允许我们以每秒的速度进行持久化，这样的话可以很大程度的减少数据的丢失。同时它采用追加的方式进行写文件，这样即使持久化失败，影响较少，而且能够使用 redis-check-aof 进行修复。

不过日志可能会越来越大，需要靠重写来减少对磁盘的占用。

RDB + AOF

将 RDB 和 AOF 结合起来，组合它们各自的优点。4.0 版本以上才支持。其文件时前半部分时 RDB 格式，后半部分是 AOF 格式。

7. redis 的分布式锁： RedLock 原理是什么？有哪些缺点？

RedLock 原理

客户端依次向各个 redis 节点获取锁，一旦超过一半的机器上锁了，并且没有超过规定的时间，则客户端认为是上锁成功了。同时开始计算锁的过期时间，过期则通知所有服务器解锁，如果这次获取锁失败，也通知所有服务器解锁。 并且解锁时会根据当时带过来的一个 token 一致才解锁，防止误解锁。

RedLock 缺点

• 受限于 redis 的持久化机制，当某个 redis 节点重启时丢失了锁记录，则有可能导致新的请求又获取到了超过一半的响应，则此时将有两个操作者同时拥有锁资源。官方针对此建议： 延迟重启，等待超时
• 上面的流程涉及到了时间的判断，如果不同机器的时间差相差太远，则会出现超时解锁，提前释放资源的问题。

8. redis 的高可用方案设计？

主从模式

在不同的机器上部署着同一 Redis 程序。在这多台机器里，我们会选择一个节点作为主节点，它负责数据的写入。其他节点作为从节点，定时的和主节点同步数据。一旦主节点不能使用了，那么就可以在从节点中挑选一个作为主节点，重新上岗服务。

哨兵模式

上面的主从模式需要人工的进行故障节点切换，这种方式对于追求完美的程序员来说，肯定是不够的。所以有了自动切换的哨兵模式。

哨兵模式主要实现了下面几个功能：

• 监控：不断的检测主从节点是否能正常工作。
• 自动转移故障：当某个 master 不能正常工作时，Sentinel 会启动一个故障转移过程，将其中的一个副本提升为 master，并通知其他从节点对应新的 master 相关信息。
• 通知：当某个节点出问题时，会告知所有节点。如果是新的主节点被选举出来，还会告知已连接过来的客户端程序关于主节点新的地址。

集群

Redis 的集群采用了哈希槽的概念，总共会有 16384 个哈希槽。这些哈希槽会被分配到各个节点上，比如：

• 节点 1 分配了 0 至 5500 的哈希槽。
• 节点 2 分配了 5501 至 11000 的哈希槽。
• 节点 3 分配了 11001 至 16384 的哈希槽。

当有 key 过来时，Redis 会对其进行 CRC16(key) % 16384 的运算，看当前的 key 要分散到哪个哈希槽上，再根据当前的哈希槽定位到对应的节点上。这样就完成了一次 key-value 的存储了。

读取也是按这规则来，不同的是，如果运算结果所对应的节点不在当前节点上，则会转发给对应的节点去处理。

当有节点进行新增或删除时，会重新划分这些哈希槽，当然，影响的只会是周围节点，不会造成整个集群不可用。

在这些节点背后还有属于它们的从节点，一旦主节点不可用，那么这些从节点就会被启用，以保证系统的正常运行。

9. 缓存雪崩和穿透该怎么处理？

当缓存失效，就会有大量的请求打到后端服务，压垮系统，这就是缓存雪崩。

除了缓存雪崩，还有缓存穿透的可能。比如每次访问不一样的数据，则请求还是会落到后方。

为了防止缓存雪崩，我们可以对请求做控制，比如加入到消息队列，慢慢消化它；又或者直接开启限流功能，将流量控制在合理的范围内。

而针对缓存穿透，我们可以建立黑白名单，将一些恶意请求拎出来，然后直接拒绝掉。如果是正常的请求，那可以将筛选出来的结果也暂时缓存起来，即使得到的值是 NULL 值。

10. 使用 Redis 在数据并发处理上有哪些需要考虑？

由于 Redis 是以组件形式存在，所以实际上我们的程序通信可以认为是分布式的了，也就是会有缓存和后端数据一致性的问题。

常见的做法是在有新数据到来时，将缓存 key 删除掉，等待下次的查询重新填补上缓存。

之所以在更新数据时不让 Redis 也做更新动作，是为了防止多个更新动作一起发生，可能由于网络原因，导致后更新的比前面更新的先一步达到 Redis， 这样就会跟原来的流程不一样了。所以只采取了删除动作，不做其他。

不过，就算是删除 key 这种方案也有一定概率跟上面的情况一样，真的要严谨的话，一般会设置定时过期时间，让数据最多在这段时间不一致。

11. redis 如何实现延迟队列？

利用有序集合的 score 属性，将时间戳设置到该属性上，然后定时的对其排序，查看最近要执行的记录，如果时间到了，则取出来消费后删除，即可达到延迟队列的目的。

12. redis 的事务和 db 的事务有什么不一样？

Redis 的事务保证了 ACID 中的一致性（C）和隔离性（I），但并不保证原子性（A）和持久性（D）。

对于原子性而言，要么都成功，要么都不成功，而 redis 的事务中途某个语句出错了, 比如 key 类型 出错了, 还会继续执行其他语句；

对于持久性而言，redis 即使开启了最严格的数据落地，由于保存是由后台线程进行的，主线程不会阻塞直到保存成功，所以从命令执行成功到数据保存到硬盘之间，还是有一段非常小的间隔，所以这种模式下的事务也是不持久的。