标签:web 集中 AC 相对 原因 交换 作者 之间 分区
前几天,我司出了个篓子。当时正值某喜闻乐见的关键比赛结束,一堆人打开我司app准备看点东西,结果从来没有感受到过这么多关注量的该功能瞬间幸福到眩晕,触发了熔断,结果就是大量兴致冲冲打开app准备看该比赛结果的人被迫刷了十分钟三天前的野外跑酷,负责内容的人火大到直接骂娘。
虽然这个业务不是我负责,但是也跟相关的人聊了下情况,感慨了一下,于是有了这一篇文章。
在高并发请求时,为何我们频繁提到缓存技术?最直接的原因是,目前磁盘IO和网络IO相对于内存IO的成百上千倍的性能劣势。
做个简单计算,如果我们需要某个数据,该数据从数据库磁盘读出来需要0.1s,从交换机传过来需要0.05s,那么每个请求完成最少0.15s(当然,事实上磁盘和网络IO也没有这么慢,这里只是举例),该数据库服务器每秒只能响应67个请求;而如果该数据存在于本机内存里,读出来只需要10us,那么每秒钟能够响应100,000个请求。
通过将高频使用的数据存在离cpu更近的位置,以减少数据传输时间,从而提高处理效率,这就是缓存的意义。
一切地方。例如:
上面这是系统层面,在软件系统设计层面,很多地方也用了缓存:
回到本文开始的问题上,该系统是怎么设计的呢?底层是数据库,中间放了一层redis,前面的业务系统所需的数据都直接从redis里取,然后计算出结果返回给app;数据库和redis的同步另外有程序保证,避免redis的穿透,防止了程序里出现大量请求从redis里找不到,于是又一窝蜂的去查数据库,直接压垮数据库的情况。从这个角度讲,其实这一步是做的还可以的。
但是这个系统有两个问题:
1.业务系统需要的数据虽然都在redis里,但是是分开存放的。什么意思呢,比如我前台发起一个请求,后台先去redis里取一下标题,然后再取一下作者,然后再取一下内容,再取一下评论,再取一下转发数等等……结果前台一次请求,后台要请求redis十几次。高并发的时候,压力一下被放大十几倍,redis响应、网络响应必然会变慢。
2.其实做业务的那波人也意识到了这个情况可能发生,所以做了熔断机制,另起了一个缓存池,里面放了一些备用数据,如果主业务超时,直接从缓存池里取数据返回。但是他们设计的时候没想周全,这个备选池的数据过期时间设计的太长了,里面居然还有三天前更新进去的数据,最终导致了一大波用户刷出来三天前的野外生态小视频……
说到这,不知道读者有没有意识到他们最致命的一个问题:这个业务系统完全没有考虑本地缓存(也就是在业务服务器内存里做缓存)。比如像我们这种app,一旦大量用户同一时间涌进来,必定都是奔着少数几个内容去的,这种特别集中的高频次极少量数据访问,又不需要对每个用户做特化的,简直就是在脸上写上“请缓存我”。
这时候,如果能在业务端做一层本地缓存,直接把算好的数据本地存一份,那么就会极大减少网络和redis的压力,不至于当场触发熔断了。
缓存很有用,但是缓存用不好也会埋很多坑:
缓存穿透是说收到了一个请求,但是该请求缓存里没有,只能去数据库里查询,然后放进缓存。这里面有两个风险,一个是同时有好多请求访问同一个数据,然后业务系统把这些请求全发到了数据库;第二个是有人恶意构造一个逻辑上不存在的数据,然后大量发送这个请求,这样每次请求都会被发送到数据库,可能导致数据挂掉。
怎么应对这种情况呢?对于恶意访问,一个思路是事先做校验,对恶意数据直接过滤掉,不要发到数据库层;第二个思路是缓存空结果,就是对查询不存在的数据仍然记录一条该数据不存在在缓存里,这样能有效的减少查询数据库的次数。
那么非恶意访问呢?这个要结合缓存击穿来讲。
上面提到的某个数据没有,然后好多请求都被发到数据库其实可以归为缓存击穿的范畴:对于热点数据,当数据失效的一瞬间,所有请求都被下放到数据库去请求更新缓存,数据库被压垮。
怎么防范这种问题呢?一个思路是全局锁,就是所有访问某个数据的请求都共享一个锁,获得锁的那个才有资格去访问数据库,其他线程必须等待。但是现在的业务都是分布式的,本地锁没法控制其他服务器也等待,所以要用到全局锁,比如用redis的setnx实现全局锁。
另一个思路是对即将过期的数据主动刷新,做法可以有很多,比如起一个线程轮询数据,比如把所有数据划分为不同的缓存区间,定期分区间刷新数据等等。这第二个思路又和我们接下来要讲的缓存雪崩有关系。
缓存雪崩是指比如我们给所有的数据设置了同样的过期时间,然后在某一个历史性时刻,整个缓存的数据全部过期了,然后瞬间所有的请求都被打到了数据库,数据库就崩了。
解决思路要么是分治,划分更小的缓存区间,按区间过期;要么是给每个key的过期时间加个随机值,避免同时过期,达到错峰刷新缓存的目的。
说到刷新缓存,其实也有坑的。比如我之前的一份工作里,有一次大活动,正是如火如荼的时候,所有的广告位突然都变空白了。后来追查原因,所有的广告素材都在缓存里,然后起了个程序,专门负责刷新缓存,每次把当前的素材全量刷新。
坏就坏在这个全量上。因为大活动的时候流量极大,广告更新压力也很大,把负责提供更新素材的程序压崩了。刷新缓存的程序在请求时,收到了一个返回结果Null
。接下来就喜闻乐见了,刷新程序根据这个null,清空了整个缓存,所有广告素材都失效了。
总之,想要做好高并发系统的缓存,就要考虑到各种边角情况,小心设计,任何细小的疏忽都可能导致系统崩溃。
转自:https://www.cnblogs.com/bethunebtj/p/9159914.html
标签:web 集中 AC 相对 原因 交换 作者 之间 分区
原文地址:https://www.cnblogs.com/haoxiu1004/p/9184307.html