【Redis】缓存和分布式锁

🔥个人主页：中草药

🔥专栏：【中间件】企业级中间件剖析

一、缓存（Cache）

概述

Redis最主要的应用场景便是作为缓存。缓存（Cache）是一种用于存储数据副本的技术或组件，目的是提高数据访问性能、减轻后端数据源负载。

数据存储：在靠近数据源或用户的位置，开辟一块存储空间，用于存放常用或热点数据副本。例如浏览器缓存网页资源（图片、CSS、JavaScript 文件等），将其存储在本地磁盘或内存特定区域

访问逻辑：当应用程序请求数据时，先检查缓存中是否有所需数据。若存在（即缓存命中），直接从缓存读取返回，避免对原始数据源（如数据库、远程服务器）的访问；若不存在（缓存未命中），则从原始数据源获取数据，同时可将数据存入缓存，供后续可能的请求使用。

在缓存设计中，二八定律体现得十分明显

通常约 20% 的热点数据会被频繁访问，占据约 80% 的访问请求量。

使用Redis作为缓存

关系性数据库有一个很大的缺陷，性能不高（进行一次查询操作小号的系统资源比较多），主要原因有以下几点：

1）数据库把数据存储在硬盘上，硬盘的 IO 速度并不快。尤其是随机访问.

2）如果查询不能命中索引，就需要进行表的遍历，这就会大大增加硬盘 IO 次数.

3）关系型数据库对于 SQL 的执行会做一系列的解析，校验，优化工作.

4）如果是一些复杂查询，比如联合查询，需要进行笛卡尔积操作，效率更是降低很多.

因此，如果访问数据库的并发量比较高，对于数据库的压力比较大，很容易使数据库服务器宕机，应对此的策略主要有两种，实际开发中，这两种方案往往是会搭配使用的.

开源：引入更多的机器，部署更多的数据库实例，构成数据库集群.(主从复制，分库分表等...)

节流：引入缓存，使用其他的方式保存经常访问的热点数据，从而降低直接访问数据库的请求数量.

Redis是一个用来作为数据库缓存的常用方案

Redis 访问速度比 MySQL 快很多。或者说处理同一个访问请求，Redis 消耗的系统资源比 MySQL 少很多。因此 Redis 能支持的并发量更大.

Redis 数据在内存中，访问内存比硬盘快很多.
Redis 只是支持简单的 key-value 存储，不涉及复杂查询的那么多限制规则.

缓存的更新策略

缓存的使用存在一个重要问题，那些数据属于是热点数据

1）定期生成

每隔一定的周期 (比如一天 / 一周 / 一个月), 对于访问的数据频次进行统计。挑选出访问频次最高的前 N% 的数据，可以通过定时任务来进行触发

以搜索引擎为例.
用户在搜索引擎中会输入一个 "查询词", 有些词是属于高频的，大家都爱搜，有些词就属于低频的，大家很少搜.
搜索引擎的服务器会把哪个用户什么时间搜了啥词，都通过日志的方式记录的明明白白。然后每隔一段时间对这期间的搜索结果进行统计 (日志的数量可能非常巨大，这个统计的过程可能需要使用 hadoop 或者 spark 等方式完成). 从而就可以得到 "高频词表".

优点：上述过程，实际上实现起来比较简单的。过程更可控，方便排查问题.
缺点：实时性不够。如果出现一些突发性事件，在短时间内，有一些本来不是热词的内容，成了热词了。新的热词就可能给后面的数据库啥的带来较大的压力。

2）实时生成

先给缓存设定容量上限 (可以通过 Redis 配置文件的 maxmemory 参数设定).
接下来把用户每次查询:

如果在 Redis 查到了，就直接返回.

如果 Redis 中不存在，就从数据库查，把查到的结果同时也写入 Redis.

如果缓存已经满了 (达到上限), 就触发缓存淘汰策略，把一些 "相对不那么热门" 的数据淘汰掉，按照上述过程，持续一段时间之后 Redis 内部的数据自然就是 "热门数据" 了.

Redis缓存淘汰策略

通用的缓存淘汰策略有以下几种：

FIFO (First In First Out) 先进先出
把缓存中存在时间最久的（也就是先来的数据）淘汰掉。

LRU (Least Recently Used) 淘汰最久未使用的
记录每个 key 的最近访问时间，把最近访问时间最老的 key 淘汰掉。

LFU (Least Frequently Used) 淘汰访问次数最少的
记录每个 key 最近一段时间的访问次数，把访问次数最少的淘汰掉。

Random 随机淘汰
从所有的 key 中抽取幸运儿被随机淘汰掉。

Redis 内置的淘汰策略如下:

volatile-lru 当内存不足以容纳新写入数据时，从设置了过期时间的 key 中使用 LRU（最久未使用）算法进行淘汰
allkeys-lru 当内存不足以容纳新写入数据时，从所有 key 中使用 LRU（最近最少使用）算法进行淘汰.
volatile-lfu 4.0 版本新增，当内存不足以容纳新写入数据时，在过期的 key 中，使用 LFU 算法进行删除 key.
allkeys-lfu 4.0 版本新增，当内存不足以容纳新写入数据时，从所有 key 中使用 LFU 算法进行淘汰.
volatile-random 当内存不足以容纳新写入数据时，从设置了过期时间的 key 中，随机淘汰数据.
allkeys-random 当内存不足以容纳新写入数据时，从所有 key 中随机淘汰数据.
volatile-ttl 在设置了过期时间的 key 中，根据过期时间进行淘汰，越早过期的优先被淘汰.(相当于 FIFO, 只不过是局限于过期的 key)
noeviction 默认策略，当内存不足以容纳新写入数据时，新写入操作会报错.

整体来说 Redis 提供的策略和我们上述介绍的通用策略是基本一致的.只不过 Redis 这里会针对"过期key"和"全部 key"做分别处理

*缓存使用注意事项

缓存预热（Cache Warm-up）

系统重启或新服务上线时缓存为空，若大量请求涌入，会直接查询数据库，导致瞬时压力过大。

缓存预热是指在系统启动或高并发场景来临前，主动将热点数据加载到缓存中，避免首次请求直接穿透到数据库。

热点数据可以基于之前介绍的统计的方式生成即可,这份热点数据不一定非得那么"准确”,只要能帮助MySQL抵挡大部分请求即可.随着程序运行的推移,缓存的热点数据会逐渐自动调整,来更适应当前情况.

缓存穿透（Cache Penetration）

缓存穿透是指查询一个不存在的数据（缓存和数据库中均无），可能被恶意攻击利用，导致每次请求都直接访问数据库，如果存在很多像这样的数据，并进行反复查询，一样会给MySQL带来压力。

原因

业务逻辑缺陷：缺少必要的参数校验工作，导致非法的key也进行了查询（典型）
开发/运维的误操作：不小心将某一部分数据删除了
恶意攻击：频繁请求无效参数（如不存在的 ID）。

解决方案

可以通过 加强监控报警，改进业务逻辑

此外可以通过以下方式降低问题的严重性

1、缓存空对象（Null Caching）：对不存在的数据也缓存一个空值（设置较短过期时间）。

if (data == null) {redis.set(key, "NULL", 300); // 缓存空值，5分钟过期
}

2、布隆过滤器（Bloom Filter）：在缓存层前加布隆过滤器，快速判断数据是否存在。

优点：内存占用低。

缺点：存在误判率（需权衡误判率和内存）。

布隆过滤器本质是结合了hash+bitmap，以较小的空间开销，以较快的响应速度，实现针对key是否存在进行判断

缓存雪崩（Cache Avalanche）·

缓存雪崩是指大量缓存key同时失效，导致所有请求直接访问数据库，引发数据库压力激增甚至崩溃。

原因

缓存过期时间集中：在短时间内，所有缓存设置为相同 TTL（Time-To-Live）。
缓存服务故障：Redis 宕机。

解决方案

1、随机过期时间：在基础 TTL 上增加随机值（如 TTL + random(0, 300s)）。

2、高可用架构：采用 Redis 集群（主从、哨兵、Cluster 模式）避免单点故障。

3、持久化缓存：对部分核心数据设置永不过期，通过后台更新数据。

缓存击穿（Cache Breakdown）

缓存击穿是指某个热点数据过期时，大量并发请求直接穿透到数据库，导致数据库压力骤增。

解决方案

基于统计的方式发现热点 key，并设置永不过期。
进行必要的服务降级，例如访问数据库的时候使用分布式锁，限制同时请求数据库的并发数。
热点数据永不过期：通过后台任务定期更新数据。

对比总结

问题	触发条件	核心原因	解决方案
缓存预热	冷启动或高并发前	缓存初始为空	提前加载热点数据
缓存穿透	查询不存在的数据	数据不存在于缓存和数据库	布隆过滤器、缓存空对象、参数校验
缓存雪崩	大量缓存同时失效	缓存过期时间集中或服务宕机	随机过期时间、高可用架构
缓存击穿	热点数据过期	高并发请求同一热点数据	互斥锁、逻辑过期时间、永不过期

二、Redis分布式锁

在一个分布式的系统中，也会涉及到多个节点访问同一个公共资源的情况,此时就需要通过锁来做互斥控制,避免,出现类似于"线程安全"的问题而 java 的 synchronized 或者 C++ 的 std:mutex,这样的锁都是只能在当前进程中生效,在分布式的这种多个进程多个主机的场景下就无能为力了此时就需要使用到分布式锁.

Redis 分布式锁是一种利用 Redis 实现跨进程、跨服务器资源互斥访问的机制，常用于解决分布式系统中的并发竞争问题（如秒杀扣库存、任务调度等场景）。

分布式锁的基本实现

原理很简单：就是通过一个键值对来标识锁的状态，是一个简单的互斥锁

Redis中提供了setnx正好适用这个场景：即key不存在就设置，存在则直接失败

为了防止出现当服务器1 加锁之后,开始处理业务的过程中,如果服务器1 意外宕机了,就会导致解锁操作(删除该key)不能执行.就可能引起其他服务器始终无法获取到锁的情况，需要引入过期时间

set nx ex

注意此处设置过期时间爷需要使用一个命令来设置，由于redis的多个命令之间不存在关联，不是原子的，可能会存在setnx成功后，expire失败的情况

为了防止出现，由于业务逻辑产生的误解锁问题，意外导致服务器1加锁之后，被服务器2解锁的情况，需要引入校验id

给不同的服务器进行编号，作为唯一的身份id，且在设置key-value的时候，key是针对需要加锁的资源，value是持有锁的服务器编号

解锁的时候, 先查询一下这个锁对应的服务器编号然后判定一下这个编号是否就是当前执行解锁的服务器编号如果是, 才能真正执行 del. 如果不是,就失败，通过上述校验,就可以有效避免,"误解锁"。

在解锁的操作的时候由于需要验证+解锁这两步操作，这两步操作也不是原子的，会出现问题此时又需要引入Lua脚本（Redis本身支持Lua作为内嵌脚本）

if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) 
elsereturn 0 
end;

一个Lua脚本会被redis服务器作为原子来执行

为了防止出现，在任务还未完成执行的时候，我们设置的key就先过期了，这会导致锁的提前失效

把key的过期时间设置的足够长,比如 30s,是否能解决这个问题呢?

很明显,设置多长时间合适,是无止境的.即使设置再长,也不能完全保证就没有提前失效的情况.而且如果设置的太长了,万一对应的服务器挂了,此时其他服务器也不能及时的获取到锁.因此相比于设置一个固定的长时间,不如动态的调整时间更合适.

引入watch dog（看门狗）

“Watchdog 看门狗” 是一种监控机制，在这里通过加锁服务器（业务服务器非redis服务器）上的一个单独线程，通过这个线程来对锁的过期时间进行续约。

举个具体的例子:

初始情况下设置过期时间为 10s.同时设定看门狗线程每隔 3s 检测一次那么当 3s 时间到的时候,看门狗就会判定当前任务是否完成.

如果任务已经完成,则直接通过 lua 脚本的方式,释放锁(删除 key).
如果任务未完成,则把过期时间重写设置为 10s.(即“续约")

实际业务中的 Redis 一般是以集群的方式部署的. 那么就可能出现以下比较极端的情况:

服务器 1 向 master 节点进行加锁操作。这个写入 key 的过程刚刚完成，master 挂了；slave 节点升级成了新的 master 节点。但是由于刚才写入的这个 key 尚未来得及同步给 slave 呢，此时就相当于服务器 1 的加锁操作形同虚设了，服务器 2 仍然可以进行加锁 (即给新的 master 写入 key. 因为新的 master 不包含刚才的 key).

为了解决这个问题，Redis 的作者提出了 Redlock 算法.

Redlock 算法是 Redis 作者 antirez 提出的分布式锁算法，用于解决分布式环境下锁的可靠性和有效性问题，它的核心是特别是避免在多个 Redis 实例场景中出现单点故障、死锁和锁丢失等情况

引入一组 Redis 节点,其中每一组 Redis 节点都包含一个主节点和若干从节点,并且组和组之间存储的数据都是一致的,相互之间是"备份"关系(而并非是数据集合的一部分,这点有别于 Redis cluster)加锁的时候,按照一定的顺序,写多个 master 节点,在写锁的时候需要设定操作的"超时时间".比如50ms.即如果 setnx 操作超过了 50ms 还没有成功,就视为加锁失败.

如果给某个节点加锁失败,就立即再尝试下一个节点，当加锁成功的节点数超过总节点数的一半,才视为加锁成功。同理，在释放锁的时候也需要将所有节点都进行解锁操作（哪怕是之间超时的节点，也要尝试解锁，尽量保证逻辑的严密）

如上图,一共五个节点,三个加锁成功,两个失败,此时视为加锁成功,这样的话,即使有某些节点挂了,也不影响锁的正确性。