Redis 技术详解

一、Redis 基础

（一）为什么使用 Redis

1. 速度快，因为数据存在内存中，类似于 HashMap，查找和操作的时间复杂度都是 O(1)。
2. 支持丰富数据类型，支持 string、list、set、Zset、hash 等。
3. 支持事务，操作都是原子性，即对数据的更改要么全部执行，要么全部不执行。
4. 丰富的特性：可用于缓存、消息，按 key 设置过期时间，过期后将会自动删除。

（二）Redis 的常用数据类型有哪些

1. String：
   • 介绍：string 数据结构是简单的 key-value 类型。Redis 没有使用 C 的字符串表示，而是构建了一种简单动态字符串（simple dynamic string，SDS）。最大能存储 512MB。
   • 常用命令：set、get、strlen、exists、decr、incr、setex 等等。
   • 应用场景：计数、缓存文章标题、微博内容等。
2. List：
   • 介绍：list 即是链表。特点是易于数据元素的插入和删除并且可以灵活调整链表长度，但随机访问困难。最多可存储 2^32 - 1 元素（4294967295，每个列表可存储 40 亿）。
   • 常用命令：rpush、lpop、lpush、rpop、lrange、llen 等。
   • 应用场景：发布与订阅或者说消息队列。
3. Hash：
   • 介绍：hash 类似于 JDK1.8 前的 HashMap，内部实现也差不多（数组+链表）。Redis 的 hash 做了更多优化，是一个 string 类型的 field 和 value 的映射表，特别适合用于存储对象。每个 hash 可以存储 2^32 - 1 键值对（40 多亿）。
   • 常用命令：hset、hmset、hexists、hget、hgetall、hkeys、hvals 等。
   • 应用场景：系统中对象数据的存储。
4. Set：
   • 介绍：set 类似于 Java 中的 HashSet。Redis 中的 set 类型是一种无序集合，集合中的元素没有先后顺序。当需要存储一个列表数据，又不希望出现重复数据时，set 是一个很好的选择，并且 set 提供了判断某个成员是否在一个 set 集合内的重要接口。最大的成员数为 2^32 - 1（4294967295，每个集合可存储 40 多亿个成员）。
   • 常用命令：sadd、spop、smembers、sismember、scard、sinterstore、sunion 等。
   • 应用场景：需要存放的数据不能重复以及需要获取多个数据源交集和并集等场景。
5. SortedSet(zset)：
   • 介绍：SortedSet 和 set 相比，SortedSet 增加了一个权重参数 score，使得集合中的元素能够按 score 进行有序排列，还可以通过 score 的范围来获取元素的列表。有点像是 Java 中 HashMap 和 TreeSet 的结合体。
   • 常用命令：zadd、zcard、zscore、zrange、zrevrange、zrem 等。
   • 应用场景：需要对数据根据某个权重进行排序的场景。比如在直播系统中，实时排行信息包含直播间在线用户列表，各种礼物排行榜，弹幕消息等信息。

（三）跳表你了解吗？

跳表（SkipList）首先是链表，但与传统的链表相比有几点差异：

1. 结合了链表和二分查找的思想。
2. 元素按照升序排列存储。
3. 节点可能包含多个指针，指针跨度不同。
4. 查找时从顶层向下，不断缩小搜索范围。
5. 整个查询的复杂度为 O(log n)。
   Redis 数据类型 Sorted Set 使用了跳表作为其中一种数据结构。
   

（四）Redis 可以用来做什么？

1. 缓存。
2. 排行榜。
3. 分布式计数器。
4. 分布式锁。
5. 消息队列。
6. 分布式 token。
7. 限流。

（五）Redis 为什么快？

1. 内存操作：完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。
2. 单线程，省去线程切换、锁竞争的开销：采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。
3. NIO 的 IO 多路复用模型：使用多路 I/O 复用模型，非阻塞 IO；这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。

（六）Redis 过期删除策略？

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

定期删除对内存更加友好，惰性删除对 CPU 更加友好。两者各有千秋，所以 Redis 采用的是定期删除+惰性/懒汉式删除。但是，仅仅通过给 key 设置过期时间还是有问题的。因为还是可能存在定期删除和惰性删除漏掉了很多过期 key 的情况。这样就导致大量过期 key 堆积在内存里，然后就 Out of memory 了。解决这个问题的方法是 Redis 内存淘汰机制。

（七）Redis 内存淘汰策略？

Redis 提供 6 种数据淘汰策略：

1. volatile-lru（least recently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰。
2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰。
3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰。
4. allkeys-lru（least recently used）：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）。
5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰。
6. no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！4.0 版本后增加以下两种：
   • volatile-lfu（least frequently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最不经常使用的数据淘汰。
   • allkeys-lfu（least frequently used）：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的 key。

二、持久化

（一）Redis 持久化机制 RDB 和 AOF 区别？

在 Redis 中提供了两种数据持久化的方式：RDB 和 AOF。

1. RDB：
   • 定期更新，定期将 Redis 中的数据生成的快照同步到磁盘等介质上，磁盘上保存的就是 Redis 的内存快照。
   • 优点：数据文件的大小相比于 AOF 较小，使用 RDB 进行数据恢复速度较快。
   • 缺点：比较耗时，存在丢失数据的风险。
2. AOF：
   • 将 Redis 所执行过的所有指令都记录下来，在下次 Redis 重启时，只需要执行指令就可以了。
   • 优点：数据丢失的风险大大降低了。
   • 缺点：数据文件的大小相比于 RDB 较大，使用 AOF 文件进行数据恢复的时候速度较慢。

项目中的持久化配置选择：RDB + AOF。

（二）Redis 如何选择合适的持久化方式

1. 如果是数据不那么敏感，且可以从其他地方重新生成补回的，那么可以关闭持久化。
2. 如果是数据比较重要，不想再从其他地方获取，且可以承受数分钟的数据丢失，比如缓存等，那么可以只使用 RDB。
3. 如果是用做内存数据库，要使用 Redis 的持久化，建议是 RDB 和 AOF 都开启，或者定期执行 bgsave 做快照备份，RDB 方式更适合做数据的备份，AOF 可以保证数据的不丢失。

补充：Redis4.0 对于持久化机制的优化
Redis4.0 相对与 3.X 版本其中一个比较大的变化是 4.0 添加了新的混合持久化方式。简单的说：新的 AOF 文件前半段是 RDB 格式的全量数据后半段是 AOF 格式的增量数据。

优势：混合持久化结合了 RDB 持久化和 AOF 持久化的优点，由于绝大部分都是 RDB 格式，加载速度快，同时结合 AOF，增量的数据以 AOF 方式保存了，数据更少的丢失。

劣势：兼容性差，一旦开启了混合持久化，在 4.0 之前版本都不识别该 aof 文件，同时由于前部分是 RDB 格式，阅读性较差。

（三）在生成 RDB 期间，Redis 可以同时处理写请求么？

可以的，Redis 使用操作系统的多进程写时复制技术 COW（Copy On Write）来实现快照持久化，保证数据一致性。Redis 在持久化时会调用 glibc 的函数 fork 产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端请求。当主线程执行写指令修改数据的时候，这个数据就会复制一份副本，bgsave 子进程读取这个副本数据写到 RDB 文件。这既保证了快照的完整性，也允许主线程同时对数据进行修改，避免了对正常业务的影响。

三、主从和集群

（一）Redis 集群方案

在 Redis 中提供的集群方案总共有三种：

1. 主从复制：
   • 保证高可用性。
   • 实现故障转移需要手动实现。
   • 无法实现海量数据存储。
2. 哨兵模式：
   • 保证高可用性。
   • 可以实现自动化的故障转移。
   • 无法实现海量数据存储。
     
3. Redis 分片集群：
   • 保证高可用性。
   • 可以实现自动化的故障转移。
   • 可以实现海量数据存储。
     

（二）Redis 主从同步

主从第一次同步是全量同步，流程如下：

1. 从节点执行replicaof命令，发送自己的replid和offset给主节点。
2. 主节点判断从节点的replid与自己的是否一致。
3. 如果不一致说明是第一次来，需要做全量同步，主节点返回自己的replid给从节点。
4. 主节点开始执行bgsave，生成rdb文件。
5. 主节点发送rdb文件给从节点，在发送的过程中。
6. 从节点接收rdb文件，清空本地数据，加载rdb文件中的数据。
7. 同步过程中，主节点接收到的新命令写入从节点的写缓冲区(repl_buffer)。
8. 从节点接收到缓冲区数据后写入本地，并记录最新数据对应的offset。

后期数据变化后，则执行增量同步：

1. 主节点会不断把自己接收到的命令记录在repl_baklog中，并修改offset。
2. 从节点向主节点发送psync命令，发送自己的offset和replid。
3. 主节点判断replid和offset与从节点是否一致。
4. 如果replid一致，说明是增量同步。然后判断offset是否一致。
5. 如果从节点offset小于主节点offset，并且在repl_baklog中能找到对应数据，则将offset之间相差的数据发送给从节点。
6. 从节点接收到数据后写入本地，修改自己的offset与主节点一致。

增量同步的风险：repl_baklog大小有上限，写满后会覆盖最早的数据。如果slave断开时间过久，导致尚未备份的数据被覆盖，则无法基于log做增量同步，只能再次全量同步。repl_baklog可以在配置文件中进行修改存储大小。

（三）Redis 分片集群中数据的存储和读取

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

上图是存值的流程，取值的流程类似:

• 例如：set {aaa} name zhangsan，计算 hash 是根据aaa计算的。取值的流程类似。

（四）Redis 主从架构数据会丢失吗？为什么？

有两种数据丢失的情况：

1. 异步复制导致的数据丢失：因为 master -> slave 的复制是异步的，所以可能有部分数据还没复制到 slave，master 就宕机了，此时这些部分数据就丢失了。
2. 脑裂导致的数据丢失：某个 master 所在机器突然脱离了正常的网络，跟其他 slave 机器不能连接，但是实际上 master 还运行着，此时哨兵可能就会认为 master 宕机了，然后开启选举，将其他 slave 切换成了 master。这个时候，集群里就会有两个 master，也就是所谓的脑裂。此时虽然某个 slave 被切换成了 master，但是可能 client 还没来得及切换到新的 master，还继续写向旧 master 的数据可能也丢失了。因此旧 master 再次恢复的时候，会被作为一个 slave 挂到新的 master 上去，自己的数据会清空，重新从新的 master 复制数据。

四、使用场景

（一）如何保存 Redis 数据与 DB 一致？

1. 方案 1：同步双写，即更新完 DB 后立即同步更新 redis。
2. 方案 2：异步监听，即通过 Canal 监听 MySQL 变化的表，同步更新数据到 Redis。
3. 方案 3：MQ 异步，即更新完 DB 后生产消息到 MQ，MQ 消费者更新数据到 Redis。

（二）Redis 中什么是缓存预热？

缓存预热是指系统上线后，提前将相关的缓存数据加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题，用户直接查询事先被预热的缓存数据。

如果不进行预热，那么 Redis 初始状态数据为空，系统上线初期，对于高并发的流量，都会访问到数据库中，对数据库造成流量的压力。

缓存预热解决方案：

1. 数据量不大的时候，工程启动的时候进行加载缓存动作。
2. 数据量大的时候，设置一个定时任务脚本，进行缓存的刷新。
3. 数据量太大的时候，优先保证热点数据进行提前加载到缓存。

（三）什么是缓存降级？

缓存降级是指缓存失效或缓存服务器挂掉的情况下，不去访问数据库，直接返回默认数据或访问服务的内存数据。降级一般是有损的操作，所以尽量减少降级对于业务的影响程度。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

1. 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级。
2. 警告：有些服务在一段时间内成功率有波动（如在 95% - 100%之间），可以自动降级或人工降级，并发送告警。
3. 错误：比如可用率低于 90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级。
4. 严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

（四）什么是缓存穿透？怎么解决？

加入缓存以后的数据查询流程：

缓存穿透概述：指查询一个一定不存在的数据，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到 DB 去查询，可能导致 DB 挂掉。例如：get 请求：api/v1/news/13。

解决方案：

1. 查询返回的数据为空，仍把这个空结果进行缓存，但过期时间会比较短。
2. 布隆过滤器：将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对 DB 的查询。

Redis 中使用布隆过滤器防止缓存穿透流程图如下所示：

（五）什么是缓存击穿？怎么解决？

概述：对于设置了过期时间的 key，缓存在某个时间点过期的时候，恰好这时间点对这个 Key 有大量的并发请求过来，这些请求发现缓存过期一般都会从后端 DB 加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把 DB 压垮。

解决方案：

1. 使用互斥锁：当缓存失效时，不立即去load db，先使用如 Redis 的setnx去设置一个互斥锁，当操作成功返回时再进行load db的操作并回设缓存，否则重试get缓存的方法。
2. 可以设置当前 key 逻辑过期：大概是思路如下：
   • 优点：线程无需等待，性能较好。
   • 缺点：不保证一致性，有额外内存消耗，实现复杂。
   • 解决方案：
     • ①：在设置 key 的时候，设置一个过期时间字段一块存入缓存中，不给当前 key 设置过期时间。
     • ②：当查询的时候，从 redis 取出数据后判断时间是否过期。
     • ③：如果过期则开通另外一个线程进行数据同步，当前线程正常返回数据，这个数据不是最新。

两种方案对比：

解决方案	优点	缺点
互斥锁	没有额外的内存消耗，保证一致性，实现简单	线程需要等待，性能受影响，可能有死锁风险，不保证一致性
逻辑过期	线程无需等待，性能较好	有额外内存消耗，实现复杂

（六）什么是缓存雪崩？怎么解决？

概述：设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到 DB，DB 瞬时压力过重雪崩。与缓存击穿的区别：雪崩是很多 key，击穿是某一个 key 缓存。

解决方案：
将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，比如 1 - 5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

（七）Redis 分布式锁如何实现？

Redis 实现分布式锁主要利用 Redis 的setnx命令。setnx是SET if not exists（如果不存在，则 SET）的简写。

加锁：使用setnx key value命令，如果 key 不存在，设置 value（加锁成功）。如果已经存在 lock（也就是有客户端持有锁了），则设置失败（加锁失败）。

解锁：使用del命令，通过删除键值释放锁。释放锁之后，其他客户端可以通过命令进行加锁。

（八）Redis 分布式锁的有效时长

1. 第一种解决方案：程序员自己去把握，预估一下业务代码需要执行的时间，然后设置有效期时间比执行时间长一些，保证不会因为自动解锁影响到客户端业务代码的执行。
2. 第二种解决方案：给锁续期。

锁续期实现思路：当加锁成功后，同时开启守护线程，默认有效期是用户所设置的，然后每隔 10 秒就会给锁续期到用户所设置的有效期，只要持有锁的客户端没有宕机，就能保证一直持有锁，直到业务代码执行完毕由客户端自己解锁，如果宕机了自然就在有效期失效后自动解锁。

上述的第二种解决方案可以使用 redis 官方所提供的 Redisson 进行实现。Redisson 分布式锁原理（重要）

注意：Redisson 的watchDog不是每 10 秒做一次续期，而是每隔(releaseTime / 3)的时间做一次续期。也就是锁自动释放时间的 1/3，默认的锁释放时间是 30 秒，因此默认每隔 10 秒续期。