Redis
应⽤
-
缓存与分布式锁

🌈 个人主页：Zfox_
🔥 系列专栏：Redis

🔥 什么是缓存

缓存(cache)是计算机中的⼀个经典的概念.在很多场景中都会涉及到

核⼼思路就是把⼀些常⽤的数据放到触⼿可及 (访问速度更快) 的地⽅,⽅便随时读取

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

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

🔥 使⽤Redis作为缓存

在⼀个⽹站中,我们经常会使⽤关系型数据库(⽐如MySQL)来存储数据.

关系型数据库虽然功能强⼤,但是有⼀个很⼤的缺陷,就是性能不⾼.(换⽽⾔之,进⾏⼀次查询操作消耗的系统资源较多).

因此,如果访问数据库的并发量⽐较⾼,对于数据库的压⼒是很⼤的,很容易就会使数据库服务器宕机.

如何让数据库能够承担更⼤的并发量呢?核⼼思路主要是两个:

• 开源:引⼊更多的机器,部署更多的数据库实例,构成数据库集群.(主从复制,分库分表等…)
• 节流:引⼊缓存,使⽤其他的⽅式保存经常访问的热点数据,从⽽降低直接访问数据库的请求数量.

实际开发中,这两种⽅案往往是会搭配使⽤的.

Redis就是⼀个⽤来作为数据库缓存的常⻅⽅案.

就像⼀个"护盾"⼀样,把MySQL给罩住了.

• 客户端访问业务服务器,发起查询请求.
• 业务服务器先查询Redis,看想要的数据是否在Redis中存在.
  • 如果已经在Redis中存在了,就直接返回.此时不必访问MySQL了.
  • 如果在Redis中不存在,再查询MySQL.

按照上述讨论的"⼆⼋定律",只需要在Redis中放20%的热点数据,就可以使80%的请求不再真正查询数据库了.

当然,实践中究竟是"⼆⼋",还是"⼀九",还是"三七",这个情况可能会根据业务场景的不同,存在差异.但是⾄少绝⼤多数情况下,使⽤缓存都能够⼤⼤提升整体的访问效率,降低数据库的压⼒.

🔥 缓存的更新策略

接下来还有⼀个重要的问题,到底哪些数据才是"热点数据"呢?

🦋 定期⽣成

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

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

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

🦋 实时⽣成

先给缓存设定容量上限 (可以通过Redis配置⽂件的 maxmemory 参数设定)

接下来把⽤户每次查询:

• 如果在Redis查到了,就直接返回.
• 如果Redis中不存在,就从数据库查,把查到的结果同时也写⼊Redis.

如果缓存已经满了(达到上限),就触发缓存淘汰策略,把⼀些"相对不那么热⻔"的数据淘汰掉.

按照上述过程,持续⼀段时间之后Redis内部的数据⾃然就是"热⻔数据"了.

通⽤的淘汰策略主要有以下⼏种:

下列策略并⾮局限于Redis,其他缓存也可以按这些策略展开.

FIFO(FirstInFirstOut)先进先出

把缓存中存在时间最久的(也就是先来的数据)淘汰掉.

LRU(LeastRecentlyUsed)淘汰最久未使⽤的

记录每个key的最近访问时间.把最近访问时间最⽼的key淘汰掉.

LFU(LeastFrequentlyUsed)淘汰访问次数最少的

记录每个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 中随机淘汰数据.
• olatile-ttl 在设置了过期时间的 key 中，根据过期时间进⾏淘汰，越早过期的优先被淘汰. (相当于FIFO,只不过是局限于过期的key)
• noeviction 默认策略，当内存不⾜以容纳新写⼊数据时，新写⼊操作会报错

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

🔥 缓存预热,缓存穿透,缓存雪崩和缓存击穿

🦋 什么是缓存预热(Cachepreheating)

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

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

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

🦋 什么是缓存穿透?(Cachepenetration)

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

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

这种情况称为缓存穿透.

🎀 为何产⽣?

原因可能有⼏种:

• 业务设计不合理.⽐如缺少必要的参数校验环节,导致⾮法的key也被进⾏查询了.
• 开发/运维误操作.不⼩⼼把部分数据从数据库上误删了.
• ⿊客恶意攻击.

如何解决?

• 针对要查询的参数进⾏严格的合法性校验.⽐如要查询的key是⽤户的⼿机号,那么就需要校验当前key是否满⾜⼀个合法的⼿机号的格式.
• 针对数据库上也不存在的key,也存储到Redis中,⽐如value就随便设成⼀个"".避免后续频繁访
  问数据库.
• 使⽤布隆过滤器先判定key是否存在,再真正查询.

🦋 什么是缓存雪崩(Cacheavalanche)

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

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

为何产⽣?

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

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

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

如何解决?

• 部署⾼可⽤的Redis集群,并且完善监控报警体系.
• 不给key设置过期时间或者设置过期时间的时候添加随机时间因⼦.

🦋 什么是缓存击穿?(Cachebreakdown)

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

如何解决?

• 基于统计的⽅式发现热点key,并设置永不过期.
• 进⾏必要的服务降级.例如访问数据库的时候使⽤分布式锁,限制同时请求数据库的并发数.

🔥 什么是分布式锁?

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

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

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

🦋 分布式锁的基础实现

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

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

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

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

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

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

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

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

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

但是上述⽅案并不完整

🦋 引⼊过期时间

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

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

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

如果分开多个操作,⽐如setnx之后,再来⼀个单独的expire,由于Redis的多个指令之间不存在关联,并且即使使⽤了事务也不能保证这两个操作都⼀定成功,因此就可能出现setnx成功,但是expire失败的情况

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

🦋 引⼊校验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",这样做并⾮是原⼦的

如果一个服务器中的两个线程都去解锁，（由于不是原子的）可能会 del 两次，这个时候又来了一个服务器set 锁，然后就被第二个线程删了

🦋引⼊lua

为了使解锁操作原⼦,可以使⽤Redis的Lua脚本功能
https://www.lua.org/about.html

使⽤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的写法⼤家可以⾃⾏研究.

🦋引⼊watchdog(看⻔狗)

上述⽅案仍然存在⼀个重要问题.当我们设置了key过期时间之后(⽐如10s),仍然存在⼀定的可能性,当任务还没执⾏完,key就先过期了.这就导致锁提前失效.

把这个过期时间设置的⾜够⻓,⽐如30s,是否能解决这个问题呢?很明显,设置多⻓时间合适,是⽆⽌境的.即使设置再⻓,也不能完全保证就没有提前失效的情况.

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

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

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

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

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

🦋 引⼊Redlock算法

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

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

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

我们引⼊⼀组Redis节点.其中每⼀组Redis节点都包含⼀个主节点和若⼲从节点.并且组和组之间存储的数据都是⼀致的,相互之间是"备份"关系(⽽并⾮是数据集合的⼀部分,这点有别于Rediscluster).

加锁的时候,按照⼀定的顺序,写多个master节点.在写锁的时候需要设定操作的"超时时间".⽐如 50ms.即如果setnx操作超过了50ms还没有成功,就视为加锁失败.

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

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

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

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

🎼 那么是否可能出现上述节点都同时遇到了"⼤冤种"情况呢?
理论上这件事是可能发⽣的,但是概率太⼩了.⼯程上就可以忽略不计了.

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

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

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

🦋 其他功能

上述描述中我们解释了基于Redis的分布式锁的基本实现原理.

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

• 可重⼊锁
• 公平锁
• 读写锁
• …

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

此处我们不做过多讨论了.

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

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

🔥 共勉

😋 以上就是我对 Redis应⽤-缓存与分布式锁 的理解, 觉得这篇博客对你有帮助的，可以点赞收藏关注支持一波~ 😉