缓存中的穿透、并发及雪崩

简析

使用缓存的时候,最常见的场景莫过于查询缓存是否存在,存在则直接获取缓存并走业务流程,不存在则读取DB层并组装数据,组装完成后写入缓存,并返回业务层。

但这种做法在高并发的时候可能会遇到缓存穿透、缓存并发和缓存雪崩的问题,以下是一点笔记(真的只是一点)。


// 伪代码 if val := cache.Get("key"); val == nil{ // 缓存不存在,重建缓存 val = db.Read("key") cache.Set("key", val) // 一般还要设置一个过期时间,这里简化了 return val }else{ // 缓存存在,直接返回结果 return val }

缓存穿透

行为简述

缓存穿透常见于客户端的恶意行为,一般场景下,查询DB的开支(各方面,CPU\MEM\TIME\BRANDWIDTH等等),我们都可以认为是远大于查询缓存的(这也是为啥会出现缓存的原因,引入了可靠性低的不一致因素,还是要用缓存),而恶意查询则是故意查询没有结果的东西(往往还是轮询),则造成大量的无效请求传到了DB层,最后引起DB层不堪重负挂掉,或者导致正常查询难以进行。

按照开头笔者提到的逻辑,我们在设计缓存的时候,有两个基本逻辑:

  1. 只会缓存已存在的数据,而不存在的数据是不缓存的。
  2. 查询某个键不存在,则在db中读取并重建缓存

但是这里有个问题,假设某个客户端查询的数据本身就是不存在的,则按照①,该数据永远不存在,则一定不会构建缓存;按照②,因为缓存不存在,每次都会查询DB以确认是否可以重新构建该缓存。

虽然笔者这里定义说是恶意行为,但也要区分是主观上恶意,还是过失性恶意,前者是我们要小心提防的,后者我们更多要在应用的设计(UI交互、业务培训等等)上防止用户无意中造成这样的结果。

当然,还有一种很常见的情况是客户端开发过程中,某些逻辑形成了死循环,不断向服务器发起请求引起的(表示笔者曾经折腾了一整天,才发现开发服务器不断宕机的原因是客户端写了一个while(true)循环……)

结果就是会导致该查询每次被执行的时候,都成功穿透了缓存层,并导致DB进行查询,而DB的查询要调用的资源是缓存层的十倍乃至百倍千倍,用缓存层尽可能的挡掉对DB的直接查询是我们设计缓存层的核心目的,然后在这个场景下,该盾牌被人恶意绕过了,此谓之缓存穿透。

注意,恶意绕过和由于业务流程绕过是两个问题。

解决思路

考虑到具体问题具体分析,缓存穿透的情况并不能一概而论,这里仅是一些思路:

请求参数检查

表示带实习生的时候总要强调一遍又一遍的一个原则:客户端传来的任何数据都是不可靠的,必须校验。

对客户端传入的查询参数提前进行检查。

例如,业务数据库设计上,所有的用户id都是正整数,则直接丢弃查询id为负数和小数乃至连数字都不是的查询。

延期失效

另一种场景是查询参数本身是合法的,但对于数据库没有意义。

例如,业务数据库设计上用户id是从1开始的自增长uint,当前系统有100个用户,而客户端不断传来查询id=10000的用户的请求,此时,id确实是合法的,然后却不符合数据库的实际情况,最后仍然是导致缓存层被穿透,DB要做一次没有结果的查询。

这种场景没有统一的解决思路,因为参数本身是合法的,必须考量业务情况及可靠性还有性能的平衡(也就是没有统一的答案)。

最简单的一种解决思路就是,每发生一次无效的缓存穿透,则让相同参数的缓存查询在一定时间内无法发生第二次,具体做法可以是:

// 毫无PS痕迹的伪代码

if val := cache.Get("id:14250"); val == nil{
        // 缓存不存在,重建缓存
        if val = db.Read("id:14250"); val == nil{
                // 数据库也不存在,则给该key赋一个180s过期的值
                cache.Set("id:14250",nil,180*time.Seconds)
                return nil
        }else{
                cache.Set("id:14250", val) // 一般还要设置一个过期时间,这里简化了
        }
        return val
}else{
        return val
}

一定量的数据库查询,是正常的,缓存层要解决的是异常的、多余的、没必要的查询。千万别矫枉过正,真理往前走一步,就可能变成了谬误。

也就是仍然向数据库写入该key,只是写入一个业务上表示空的值,代码中的nil仅供参考,具体业务中要结合自己的情况,设置合适的值。然后设置这个key在一定时间后会过期,这样在这个key过期前的一段时间里,缓存是不会被穿透的,其目的不是禁止缓存被穿透,而是在削平缓存被穿透产生的数据库峰值。

集合<Set>查询

同样是查询参数本身是合法的,但对于数据库没有意义的场景,还有另外一种思路,把所有合法的用户id存到一个Set中,在校验请求参数的同事,检查请求参数中的用户id是否存在于这个Set,如果存在则继续,不存在则直接返回。

这种实现需要注意如果查询的参数很多,要同步所有可用参数的结果,业务逻辑上做起来并不容易。

布隆在此:有一种布隆过滤器(Bloom Filter)可以处理这种BigSet的场景,就不细说了。

缓存并发

缓存并发其实某种程度也是缓存穿透的问题,但为了细化区分,前文中描述的缓存穿透,本质上是客户端发来的“意外”请求产生的,而这里缓存并发产生的穿透,则往往网站业务并发量大的时候产生的,我们来看看它产生的场景。

行为简述

按一般的行为,如果一个缓存key失效了,我们会在重新向DB层请求数据,并降新的数据存如缓存层,但想象一个这样的场景,如果服务的并发访问量很高,同时有1000个客户端向服务器请求查询用户1的信息,而此时凑巧由于某些原因(例如缓存服务刚重启、该缓存刚刚过期),则此时会有多个线程查询key不存在,然后调用数据库查询用户1的情况,则此时会凭空产生999个多余的数据库查询,因为这999个请求只要等一下,等第1个DB查询的请求完成并顺利写入缓存以后,就可以顺利从缓存拿数据了。

并发鸭梨过大很有可能瞬间打爆后端的DB服务。

解决思路

这跟做异步开发时遇到的问题其实是一样的,事实上WebServer基本都是一个并发程序,遇到并发的问题也不出奇,那么怎么解决这个问题呢?同样从并发式编程思路可以找到基本答案——锁。

基本思路就是利用缓存服务某些带成功操作返回值的操作,例如Redis的SetNX方法,用于模拟锁的实现。

SetNX的含义是“只有在 key 不存在时设置 key 的值。设置成功,返回 1 。 设置失败,返回 0 ”

// 仍然是毫无PS痕迹的伪代码

for {
        if val := redis.Get("id:14250"); val == nil{
                // 缓存不存在,重建缓存
                // 通过setNX设置锁,同设置超时,防止del失败
                if redis.SetNX("id:14250:mutex", 10*time.Second) == true{
                        // 只有能拿到锁的线程可以通过db重建缓存,其他线程应等待
                        if val = db.Read("id:14250"); val == nil{
                                // 数据库也不存在,则给该key赋一个180s过期的值
                                redis.set("id:14250",nil,180*time.Seconds)
                                // 释放锁
                                redis.del("id:14250:mutex")
                                return nil
                        }else{
                                // 一般还要设置一个过期时间,这里简化了
                                redis.set("id:14250", val)
                        }
                }else{
                        // 此时表示已经有其他现在重建缓存了,等待一个随机时间以后重试
                        wait := rand.Intn(1000)
                        time.Sleep(time.Duration(wait) * time.Millisecond)
                }
                return val
        }else{
                return val
        }
}

通过模拟锁的设计,我们可以尽可能的削平重建缓存时产生高并发请求,把鸭梨拦截在DB层之外了,当然,这里其实完全可以绕过缓存层,在业务层根据语言特性自己设计锁、信号量等等也是完全可以的,好处就是把锁的业务鸭梨从缓存层直接拆走,缺点是,锁的开发并不容易,用不好容易出问题。

缓存雪崩

雪崩效应说的都是一个小因素的变化,却往往有着无比强大的力量,以至于最后改变整体结构、产生意想不到的结果。

行为简述

而缓存雪崩也是来自于设计缓存时一个看起来很合理的设计——缓存失效。

大多数情况下,缓存都是存放在内存中的,而内存的成本要原大于硬盘,所以出于成本考虑,我们一般会把热数据放在缓存中,而冷数据放在硬盘中。

那么怎么区分热数据和冷数据呢?最常见的做法莫过于给缓存设置一个失效时间,当某个缓存寿终正寝时,则将该缓存逐出缓存服务,以空出空间给更多的用户;而如果又有用户需要访问这个缓存,则重建缓存。这样,既保持了缓存中数据的时效性,同时也防止冷门缓存一直占着宝贵的内存却无人问津。

这是一个很伟大的思路,简单,实用!

但,在高并发的场景下,这里又会产生新的问题,在上一节的“缓存并发”中我们见识了同一个key在失效时被高发访问引起DB层崩溃的场景,那么这里我们就要考虑不同的key刚好在同一个时间点失效的问题了。

记得一位伟人说过,任何小问题,乘以13亿都是一个大问题

经常我们设置缓存失效时间的时候,往往给出的是一个固定值,特别是系统刚启动时,在段时间内会构建大量的缓存。

而这些缓存愉快地工作了一段时间后,又会在一个较短的时间内大量的失效,这就会导致时段性的大量不同业务的请求穿透缓存层直面DB层。

解决思路

上述两个时间点之间的较长时间内(即缓存都处于生效状态是),DB层的时间片又比较空闲,空闲不是问题,但如果忙起来的时候,会出现忙不过来的现象时,就又要考虑削峰平谷的问题了。

尽可能把不同的缓存重构时机分摊到整个系统的运行周期中,而不是在某个时间段集中处理。

简单的处理方式是给缓存的失效时间增加一个不影响大局的随机数:

// 仍然是毫无PS痕迹的伪代码

for {
        if val := redis.Get("id:14250"); val == nil{
                // 缓存不存在,重建缓存
                // 通过setNX设置锁,同设置超时,防止del失败
                if redis.SetNX("id:14250:mutex", 10*time.Second) == true{
                        // 只有能拿到锁的线程可以通过db重建缓存,其他线程应等待
                        if val = db.Read("id:14250"); val == nil{
                                // 给失效时间增加一个随机数
                                randExpire := rand.Intn(180)
                                // 数据库也不存在,则给该key赋一个180s~360s过期的值
                                redis.set("id:14250",nil,time.Duration(randExpire+180)*time.Seconds)
                                // 释放锁
                                redis.del("id:14250:mutex")
                                return nil
                        }else{
                                // 一般还要设置一个过期时间,这里简化了
                                redis.set("id:14250", val)
                        }
                }else{
                // 此时表示已经有其他现在重建缓存了,等待一个随机时间以后重试
                        wait := rand.Intn(1000)
                        time.Sleep(time.Duration(wait) * time.Millisecond)
                }
                return val
        }else{
                return val
        }
}

小结

在本文中我们简单介绍了使用缓存时遇到缓存穿透、缓存并发及缓存雪崩的问题,三种问题本质面对的都是通过缓存保护DB时,可能遇到的常见的失效原因,产生问题的方式各不相同,解决的方式看起来也都不一样,但其实核心的思路都是一样的,就是“大而化之,削而分之”。

虽然笔者这里整理了几种解决方案,但切记的一个问题是,缓存是直面业务的服务,所以没有通用的解决方案,而是要根据业务情况具体分析再处理,本文仅供抛砖引玉。

1 评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据