redis-10-缓存-分布式锁

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

文章目录

• 前言
• [1. 缓存](#1. 缓存)
• • [1.1 使用redis作为mysql的缓存](#1.1 使用redis作为mysql的缓存)
  • [1.2 缓存的更新策略](#1.2 缓存的更新策略)
  • • 定期⽣成
    • 实时⽣成***
  • [1.3 缓存预热, 缓存穿透, 缓存雪崩 和 缓存击穿***](#1.3 缓存预热, 缓存穿透, 缓存雪崩 和 缓存击穿***)
  • • 缓存预热 (Cache preheating)
    • 缓存穿透 (Cache penetration)
    • 缓存雪崩 (Cache avalanche)
    • 缓存击穿 (Cache breakdown)
• [2. 分布式锁](#2. 分布式锁)
• • [2.1 什么是分布式锁?](#2.1 什么是分布式锁?)
  • [2.2 分布式锁的基础实现](#2.2 分布式锁的基础实现)
  • [2.3 引⼊过期时间](#2.3 引⼊过期时间)
  • [2.4 引⼊校验 id](#2.4 引⼊校验 id)
  • [2.5 引⼊ lua](#2.5 引⼊ lua)
  • [2.6 引⼊ watch dog (看⻔狗)](#2.6 引⼊ watch dog (看⻔狗))
  • [2.7 引⼊ Redlock 算法](#2.7 引⼊ Redlock 算法)
  • [2.8 其他功能](#2.8 其他功能)
• 总结

---

前言

1. 缓存

redis三个作用：存储数据，缓存，消息队列

缓存就是最常用的场景

对于硬件的访问速度来说, 通常情况下:

CPU 寄存器 > 内存 > 硬盘 > ⽹络

对于计算机硬件来说, 往往访问速度越快的设备, 成本越⾼, 存储空间越⼩.

缓存是更快, 但是空间上往往是不⾜的. 因此⼤部分的时候, 缓存只放⼀些 热点数据 (访问频繁的数据),就⾮常有⽤了.

关于 "⼆⼋定律"

20% 的热点数据, 能够应对 80% 的访问场景.

因此只需要把这少量的热点数据缓存起来, 就可以应对⼤多数场景, 从⽽在整体上有明显的性能提升

1.1 使用redis作为mysql的缓存

经常会使⽤关系型数据库 (⽐如 MySQL) 来存储数据

为什么说关系型数据库性能不⾼?

1. 数据库把数据存储在硬盘上, 硬盘的 IO 速度并不快. 尤其是随机访问.
2. 如果查询不能命中索引, 就需要进⾏表的遍历, 这就会⼤ 增加硬盘 IO 次数.
3. 关系型数据库对于 SQL 的执⾏会做⼀系列的解析, 校验, 优化⼯作.
4. 如果是⼀些复杂查询, ⽐如联合查询, 需要进⾏笛卡尔积操作, 效率更是降低

为什么并发量⾼了就会宕机?

服务器每次处理⼀个请求, 都是需要消耗⼀定的硬件资源的. 所谓的硬件资源包括不限于 CPU,内存, 硬盘, ⽹络带宽...

⼀个服务器的硬件资源本⾝是有限的. ⼀个请求消耗⼀份资源, 请求多了, ⾃然把资源就耗尽了. 后续的请求没有资源可⽤, ⾃然就⽆法正确处理. 更严重的还会导致服务器程序的代码出现崩溃

Redis 访问速度⽐ MySQL 快很多. 或者说处理同⼀个访问请求, Redis 消耗的系统资源⽐MySQL 少很多. 因此 Redis 能⽀持的并发量更⼤.

• Redis 数据在内存中, 访问内存⽐硬盘快很多.

• Redis 只是⽀持简单的 key-value 存储, 不涉及复杂查询的那么多限制规则.

客⼾端访问业务服务器, 发起查询请求.

• 业务服务器先查询 Redis, 看想要的数据是否在 Redis 中存在.

◦ 如果已经在 Redis 中存在了, 就直接返回. 此时不必访问 MySQL 了.

◦ 如果在 Redis 中不存在, 再查询 MySQL

1.2 缓存的更新策略

定期⽣成

每隔⼀定的周期(⽐如⼀天/⼀周/⼀个⽉), 对于访问的数据频次进⾏统计. 挑选出访问频次最⾼的前 N%的数据.

以搜索引擎为例.

⽤⼾在搜索引擎中会输⼊⼀个 "查询词", 有些词是属于⾼频的, ⼤家都爱搜(鲜花, 蛋糕, 同城交友, 不孕不育...). 有些词就属于低频的, ⼤家很少搜.

搜索引擎的服务器会把哪个⽤⼾什么时间搜了啥词, 都通过⽇志的⽅式记录的明明⽩ . 然后每隔⼀段时间对这期间的搜索结果进⾏统计 (⽇志的数量可能⾮常巨⼤, 这个统计的过程可能需要使⽤ hadoop 或者 spark 等⽅式完成). 从⽽就可以得到 "⾼频词表" .

这种做法实时性较低. 对于⼀些突然情况应对的并不好.

⽐如春节期间, "春晚" 这样的词就会成为⾮常⾼频的词. ⽽平时则很少会有⼈搜索 "春晚"

实时⽣成***

先给缓存设定容量上限(可以通过 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 也提供了内置的淘汰策略, 也可以供我们直接使⽤.

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" 做分别处理

1.3 缓存预热, 缓存穿透, 缓存雪崩 和 缓存击穿***

缓存预热 (Cache preheating)

什么是缓存预热

使⽤ Redis 作为 MySQL 的缓存的时候, 当 Redis 刚刚启动, 或者 Redis ⼤批 key 失效之后, 此时由于Redis ⾃⾝相当于是空着的, 没啥缓存数据, 那么 MySQL 就可能直接被访问到, 从⽽造成较⼤的压⼒.

因此就需要提前把热点数据准备好, 直接写⼊到 Redis 中. 使 Redis 可以尽快为 MySQL 撑起保护伞

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

缓存穿透 (Cache penetration)

什么是缓存穿透?

访问的 key 在 Redis 和 数据库中都不存在. 此时这样的 key 不会被放到缓存上, 后续如果仍然在访问该key, 依然会访问到数据库.

这就会导致数据库承担的请求太多, 压⼒很⼤.

这种情况称为 缓存穿透.

为何产⽣?

原因可能有⼏种:

• 业务设计不合理. ⽐如缺少必要的参数校验环节, 导致⾮法的 key 也被进⾏查询了.

• 开发/运维误操作. 不⼩⼼把部分数据从数据库上误删了.

• ⿊客恶意攻击.

如何解决?

• 针对要查询的参数进⾏严格的合法性校验. ⽐如要查询的 key 是⽤⼾的⼿机号, 那么就需要校验当前key 是否满⾜⼀个合法的⼿机号的格式.

• 针对数据库上也不存在的 key , 也存储到 Redis 中, ⽐如 value 就随便设成⼀个 "". 避免后续频繁访问数据库.

• 使⽤布隆过滤器先判定 key 是否存在, 再真正查询

关于布隆过滤器, 在数据结构进阶, 有具体介绍. 此处就不再赘述.

简单的说, 布隆过滤器是结合了 hash + bitmap 的思想, 能够⽤较少的空间, 判定某个元素是否存在.

缓存雪崩 (Cache avalanche)

什么是缓存雪崩

短时间内⼤量的 key 在缓存上失效, 导致数据库压⼒骤增, 甚⾄直接宕机.

本来 Redis 是 MySQL 的⼀个护盾, 帮 MySQL 抵挡了很多外部的压⼒. ⼀旦护盾突然失效了, MySQL⾃⾝承担的压⼒骤增, 就可能直接崩溃.

为何产⽣?

⼤规模 key 失效, 可能性主要有两种:

• Redis 挂了.

• Redis 上的⼤量的 key 同时过期.

为啥会出现⼤量的 key 同时过期?

这种和可能是短时间内在 Redis 上缓存了⼤量的 key, 并且设定了相同的过期时间.

如何解决?

• 部署⾼可⽤的 Redis 集群, 并且完善监控报警体系.

• 不给 key 设置过期时间 或者 设置过期时间的时候添加随机时间因⼦

缓存击穿 (Cache breakdown)

什么是缓存击穿?

相当于缓存雪崩的特殊情况. 针对热点 key , 突然过期了, 导致⼤量的请求直接访问到数据库上, 甚⾄引起数据库宕机

如何解决?

• 基于统计的⽅式发现热点 key, 并设置永不过期.

• 进⾏必要的服务降级. 例如访问数据库的时候使⽤分布式锁, 限制同时请求数据库的并发数.所以有些请求不会得到响应，但也比所有请求炸了，导致所有请求都得不到响应好

2. 分布式锁

2.1 什么是分布式锁?

在⼀个分布式的系统中, 也会涉及到多个节点访问同⼀个公共资源的情况. 此时就需要通过 锁 来做互斥控制, 避免出现类似于 "线程安全" 的问题.

⽽ java 的 synchronized 或者 C++ 的 std::mutex, 这样的锁都是只能在当前进程中⽣效, 在分布式的这种多个进程多个主机的场景下就⽆能为⼒了.

此时就需要使⽤到分布式锁

本质上就是使⽤⼀个公共的服务器, 来记录 加锁状态.

这个公共的服务器可以是 Redis, 也可以是其他组件(⽐如 MySQL 或者 ZooKeeper 等), 还可以是我们⾃⼰写的⼀个服务.

2.2 分布式锁的基础实现

思路⾮常简单. 本质上就是通过⼀个键值对来标识锁的状态.

举个例⼦: 考虑买票的场景, 现在⻋站提供了若⼲个⻋次, 每个⻋次的票数都是固定的.

现在存在多个服务器节点, 都可能需要处理这个买票的逻辑: 先查询指定⻋次的余票, 如果余票 > 0, 则设置余票值 -= 1.

显然上述的场景是存在 "线程安全" 问题的, 需要使⽤锁来控制.

否则就可能出现 "超卖" 的情况

此时如何进⾏加锁呢? 我们可以在上述架构中引⼊⼀个 Redis , 作为分布式锁的管理器

此时, 如果 买票服务器1 尝试买票, 就需要先访问 Redis, 在 Redis 上设置⼀个键值对. ⽐如 key 就是⻋次, value 随便设置个值 (⽐如 1).

如果这个操作设置成功, 就视为当前没有节点对该 001 ⻋次加锁, 就可以进⾏数据库的读写操作. 操作完成之后, 再把 Redis 上刚才的这个键值对给删除掉.

如果在 买票服务器1 操作数据库的过程中, 买票服务器2 也想买票, 也会尝试给 Redis 上写⼀个键值对,key 同样是⻋次. 但是此时设置的时候发现该⻋次的 key 已经存在了, 则认为已经有其他服务器正在持有锁, 此时 服务器2 就需要等待或者暂时放弃

Redis 中提供了 setnx 操作, 正好适合这个场景. 即: key 不存在就设置, 存在则直接失败

但是上述⽅案并不完整.

setnx进行加锁，del进行解锁

2.3 引⼊过期时间

当 服务器1 加锁之后, 开始处理买票的过程中, 如果 服务器1 意外宕机了, 就会导致解锁操作 (删除该key) 不能执⾏. 就可能引起其他服务器始终⽆法获取到锁的情况.

为了解决这个问题, 可以在设置 key 的同时引⼊过期时间. 即这个锁最多持有多久, 就应该被释放.

可以使⽤ set ex nx 的⽅式, 在设置锁的同时把过期时间设置进去.

注意! 此处的过期时间只能使⽤⼀个命令的⽅式设置.

如果分开多个操作, ⽐如 setnx 之后, 再来⼀个单独的 expire, 由于 Redis 的多个指令之间不存在关联, 并且即使使⽤了事务也不能保证这两个操作都⼀定成功, 因此就可能出现 setnx 成功, 但是 expire失败的情况.因为redis的多个命令之间，无法保证原子性，事务只能保证命令都去执行，但是不能保证都执行成功，或者都执行失败

此时仍然会出现⽆法正确释放锁的问题.

2.4 引⼊校验 id

对于 Redis 中写⼊的加锁键值对, 其他的节点也是可以删除的.

⽐如 服务器1 写⼊⼀个 "001": 1 这样的键值对, 服务器2 是完全可以把 "001" 给删除掉的.

当然, 服务器2 不会进⾏这样的 "恶意删除" 操作, 不过不能保证因为⼀些 bug 导致 服务器2 把锁误删除.就是它不是解锁，但是就是删除了锁

为了解决上述问题, 我们可以引⼊⼀个校验 id.

⽐如可以把设置的键值对的值, 不再是简单的设为⼀个 1, ⽽是设成服务器的编号. 形如 "001": "服务器1".

这样就可以在删除 key (解锁)的时候, 先校验当前删除 key 的服务器是否是当初加锁的服务器, 如果是,才能真正删除; 不是, 则不能删除.

String key = [要加锁的资源 id];
String serverId = [服务器的编号];

// 加锁，设置过期时间为 10s
redis.set(key, serverId, "NX", "EX", "10s");

// 执行各种业务逻辑，比如修改数据库数据。
doSomeThing();

// 解锁，删除 key。但是删除前要检验下 serverId 是否匹配。
if (redis.get(key) == serverId) {
    redis.del(key);
}

但是很明显, 解锁逻辑是两步操作 "get" 和 "del", 这样做并⾮是原⼦的

如果再来一个服务器，在这两个线程之间执行了set nx ex就完蛋了

这里也可以使用事务，虽然事务没有原子性，但是可以避免其他服务插队

2.5 引⼊ lua

为了使解锁操作原⼦, 可以使⽤ Redis 的 Lua 脚本功能.lua是一个编程语言，是作为redis的内嵌的脚本

比如mysql8支持js内嵌语言

Lua 也是⼀个编程语⾔. 读作 "撸啊". 是葡萄⽛语中的 "⽉亮" 的意思. (出⾃于 Lua 官⽅⽂档https://www.lua.org/about.html)

Lua 的语法类似于 JS, 是⼀个动态弱类型的语⾔. Lua 的解释器⼀般使⽤ C 语⾔实现. Lua 语法

简单精炼, 执⾏速度快, 解释器也⽐较轻量(Lua 解释器的可执⾏程序体积只有 200KB 左右).

因此 Lua 经常作为其他程序内部嵌⼊的脚本语⾔. Redis 本⾝就⽀持 Lua 作为内嵌脚本.

很多程序都⽀持内嵌脚本, ⽐如 MySQL 8 ⽀持 JS 作为内嵌脚本, ⽐如 Vim ⽀持 VimScript和 Python 作为内嵌脚本... 通过内嵌脚本来实现更复杂的功能, 提供更强的扩展性.

Lua 除了和 Redis 搭伙之外, 在很多场景也会作为内嵌脚本. ⽐如在游戏开发领域常常作为编写逻辑的语⾔. (⽐如魔兽世界, ⼤话西游等)

lua

使⽤ Lua 脚本完成上述解锁功能

可以使用lua编写一些逻辑，把这个脚本上传到redis服务器上，然后就可以让客户端来控制redis执行上述脚本了

redis执行lua脚本是原子的

所以lua其实就是事务的代替方案

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

上述代码可以编写成⼀个 .lua 后缀的⽂件, 由 redis-cli 或者 redis-plus-plus 或者jedis 等客⼾端加载, 并发送给 Redis 服务器, 由 Redis 服务器来执⾏这段逻辑.⼀个 lua 脚本会被 Redis 服务器以原⼦的⽅式来执⾏.

redis-plus-plus 和 jedis 如何调⽤ lua, 咱们此处不做过多介绍. 具体 api 的写法⼤家可以⾃⾏研究

2.6 引⼊ watch dog (看⻔狗)

上述⽅案仍然存在⼀个重要问题. 当我们设置了 key 过期时间之后 (⽐如 10s), 仍然存在⼀定的可能性,

当任务还没执⾏完, key 就先过期了. 这就导致锁提前失效.

把这个过期时间设置的⾜够⻓, ⽐如 30s, 是否能解决这个问题呢? 很明显, 设置多⻓时间合适, 是⽆⽌

境的. 即使设置再⻓, 也不能完全保证就没有提前失效的情况.

⽽且如果设置的太⻓了, 万⼀对应的服务器挂了, 此时其他服务器也不能及时的获取到锁.

因此相⽐于设置⼀个固定的⻓时间, 不如动态的调整时间更合适.

所谓 watch dog, 本质上是加锁的服务器上的⼀个单独的线程, 通过这个线程来对锁过期时间进⾏ "续约".

注意, 这个线程是业务服务器上的, 不是 Redis 服务器的

举个具体的例⼦:

初始情况下设置过期时间为 10s. 同时设定看⻔狗线程每隔 3s 检测⼀次.

那么当 3s 时间到的时候, 看⻔狗就会判定当前任务是否完成.

• 如果任务已经完成, 则直接通过 lua 脚本的⽅式, 释放锁(删除 key).

• 如果任务未完成, 则把过期时间重写设置为 10s. (即 "续约")

这样就不担⼼锁提前失效的问题了. ⽽且另⼀⽅⾯, 如果该服务器挂了, 看⻔狗线程也就随之挂了, 此时⽆⼈续约, 这个 key ⾃然就可以迅速过期, 让其他服务器能够获取到锁了

针对过期时间的操作，很多时候都会引入看门狗

2.7 引⼊ Redlock 算法

实践中的 Redis ⼀般是以集群的⽅式部署的 (⾄少是主从的形式, ⽽不是单机). 那么就可能出现以下⽐较极端的⼤冤种情况:

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

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

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

如果给某个节点加锁失败, 就⽴即再尝试下⼀个节点.

当加锁成功的节点数超过总节点数的⼀半, 才视为加锁成功.

如上图, ⼀共五个节点, 三个加锁成功, 两个失败, 此时视为加锁成功.

这样的话, 即使有某些节点挂了, 也不影响锁的正确性

那么是否可能出现上述节点都同时遇到了 "⼤冤种" 情况呢?

理论上这件事是可能发⽣的, 但是概率太⼩了. ⼯程上就可以忽略不计了

同理, 释放锁的时候, 也需要把所有节点都进⾏解锁操作. (即使是之前超时的节点, 也要尝试解锁, 尽量保证逻辑严密).

简⽽⾔之, Redlock 算法的核⼼就是, 加锁操作不能只写给⼀个 Redis 节点, ⽽要写个多个!! 分布式系统中任何⼀个节点都是不可靠的. 最终的加锁成功结论是 "少数服从多数的".

由于⼀个分布式系统不⾄于⼤部分节点都同时出现故障, 因此这样的可靠性要⽐单个节点来说靠谱不少.

2.8 其他功能

上述锁只是⼀个简单的互斥锁. 但是实际上我们在⼀些特定场景中, 还有⼀些其他特殊的锁, ⽐如:

• 可重⼊锁（同一线程可以连续加锁两次想当于加锁一次）

• 公平锁（先来后到）

• 读写锁（针对读和写进行不同的加锁）

• ...

基于 Redis 的分布式锁, 也可以实现上述特性. (当然了对应的实现逻辑也会更复杂)

实际开发中, 我们也并不会真的⾃⼰实现⼀个分布式锁. 已经有很多现成的库帮我们封装好了, 我们直接使⽤即可.

⽐如 Java 中的 Redisson, C++ 中的 redis-plus-plus. 当然, 有些⼤⼚也会有⾃⼰版本的分布式锁的实现

总结