写点什么

亿级流量峰值没在怕,“缓存”技术来减压!

发布于: 2021 年 01 月 05 日
亿级流量峰值没在怕,“缓存”技术来减压!


许多大型互联网系统,如电商、社交、新闻等 App 或网站,动辄日活千万甚至上亿,每分钟的峰值流量在数十万以上,架构上如何应对如此高的流量峰值呢?

本文选自《技术人修炼之道:从程序员到百万高管的 72 项技能》一书,快来了解下如何通过“缓存”技术来给系统减压吧!


流量峰值给系统带来的主要危害在于,它会瞬间产生大量对磁盘数据的读取和搜索,通常数据源是数据库或文件系统,当数据访问次数增大时,过多的磁盘读取可能会最终成为整个系统的性能瓶颈,甚至压垮整个数据库,导致系统卡死、服务不可用等严重后果。

常规的应用系统通常会在需要的时候对数据库进行查找,因此系统的大致结构如下。


当数据量较大时,需要减少对数据库磁盘的读写操作,因此通常都会选择在业务系统和数据库之间加入一层缓存(Cache),从而减少数据库的访问压力,结构如下。


缓存在实际的应用中并非如此简单,下面通过几个比较经典的缓存应用场景来看一些问题。


▊ 缓存和数据库之间的数据一致性问题

常用的缓存处理机制有如下几种。

Cache Aside 模式

种模式通常都先从数据库缓存开始查找,如果缓存没有命中,则从数据库中查找。该模式会发生如下三种情况:

● 缓存命中:当查找的时候发现缓存中存在查找的数据,那么直接从缓存中提取。

● 缓存失效:当缓存中没有数据的时候,则从数据库里面读取源数据,再同步到缓存中。

● 缓存更新:当有新的写操作去修改数据库里面的数据时,需要在写操作完成之后,让缓存里面对应的数据失效,做缓存同步。

Cache Aside 模式是在实际应用开发中最常用的模式,但这种模式的缓存处理并不完美。

例如,一个读操作没有命中缓存,然后到数据库中取数据,此时发生一个写操作,在数据库中完成写操作后,让缓存失效,然后之前的读操作再把老的数据放进去,就会出现脏数据。

分布式环境中要想完全保证数据一致性是一件极为困难的事情,只能够尽可能地减少数据不一致性问题。

Read Through 模式

指应用程序始终从缓存中请求数据,如果缓存中没有数据,则它负责使用底层提供的程序插件从数据库中检索数据,检索数据后,缓存会自行更新并将数据返回给调用的应用程序。

使用 Read Through 模式有一个好处,由于总是使用 key 从缓存中检索数据,调用的应用程序不知道数据库,而由存储方来负责自己的缓存处理,这使得代码更具可读性,更清晰。

但 Read Through 模式也有相应的缺陷,开发人员需要编写相关的程序插件,增加了开发的难度。

Write Through 模式

和 Read Through 模式类似,当数据进行更新时,先去缓存中进行更新,如果命中,则先更新缓存再由缓存方来更新数据库。如果没有命中,就直接更新缓存里面的数据。

Write Behind Caching 模式

这种模式通常先将数据写入缓存,再异步地写入数据库进行数据同步。

这样的设计既可以减少对数据库的直接访问,降低压力,同时对数据库的多次修改可以合并操作,极大地提升了系统的承载能力。

但是使用 Write Behind Caching 模式处理缓存数据有一定的风险,如当缓存机器出现宕机时,数据有丢失的可能。


▊ 缓存在高并发场景中存在的问题

缓存过期后请求将尝试从后端数据库获取数据,这是一个看似合理的流程。但是,在高并发场景下,有可能多个请求并发地从数据库获取数据,会对后端数据库造成极大的冲击,甚至导致“雪崩”。

此外,当某个缓存 key 被更新时,也可能被大量请求获取,这也会导致一致性问题。那么如何避免类似问题呢?可以使用类似“锁”的机制,在缓存更新或者过期的情况下,先尝试获取锁,当更新或者从数据库获取完成后再释放锁,其他请求只需要一定的等待时间即可直接从缓存中继续获取数据。

缓存穿透问题

缓存穿透也称为“缓存击穿”。很多朋友对缓存穿透的理解是:由于缓存故障或者缓存过期导致大量请求穿透到后端数据库服务器,从而对数据库造成巨大冲击。

这其实是一种误解。真正的缓存穿透应该是:

高并发场景下,如果某个 key 被高并发访问,没有命中,出于容错性考虑,会尝试从后端数据库中获取数据,从而导致大量请求到达数据库,而当该 key 对应的数据本身为空时,就会导致数据库中并发地执行很多不必要的查询操作,从而给数据库带来巨大的冲击和压力。

可以通过如下常用方式来避免缓存穿透问题。

● 缓存空对象

对查询结果为空的对象也进行缓存,如果是集合,则可以缓存一个空的集合(非 null),如果是单个对象,则可以通过字段标识来区分。这样可以避免请求穿透到后端数据库,保证缓存数据的时效性。

这种方式实现起来成本较低,比较适合命中率不高但可能被频繁更新的数据。

● 单独过滤处理

对所有对应数据可能为空的 key 进行统一存放,并在请求前做拦截,可以避免请求穿透到后端数据库。

这种方式实现起来相对复杂,比较适合命中率不高但是更新不频繁的数据。

缓存颠簸问题

也被称为“缓存抖动”,可以看作一种比“雪崩”更轻微的故障,但是也会在一段时间内对系统造成冲击和性能影响,一般是由缓存节点故障导致的。业内推荐的做法是通过一致性 Hash 算法来解决问题。

缓存的雪崩

由于缓存的原因,导致大量请求到达后端数据库,从而导致数据库崩溃,进而整个系统崩溃,发生灾难。原因有很多种,上文提到的“缓存并发”“缓存穿透”“缓存颠簸”等问题,都可能导致缓存的雪崩。这些问题还可能被恶意攻击者利用。

还有一种情况,例如在某个时间点,系统预加载的缓存周期性地集中失效了,也可能会导致雪崩。为了避免缓存周期性地集中失效,可以通过设置不同的过期时间来错开缓存过期时间。

从应用架构的角度,可以通过限流、降级、熔断等手段来降低缓存雪崩的影响,也可以通过多级缓存来避免这种灾难。

此外,从整个研发体系流程的角度,应该加强压力测试,尽量模拟真实场景,尽早地暴露问题,从而加以防范。

缓存是大型互联网系统架构中常用的一种技术,在设计缓存架构的过程中,要根据业务场景进行有针对性的设计,避免缓存延迟、脏数据、缓存雪崩等问题,提高系统的高可用性和健壮性。

(完)


本文节选自《技术人修炼之道:从程序员到百万高管的 72 项技能》一书。


▊《技术人修炼之道:从程序员到百万高管的 72 项技能》

黄哲铿 著

  • 全方位讲解 IT 技术人技能首著

  • 72 项核心技能,突破职业瓶颈实现职场跃迁

本书旨在帮助 IT 技术人员提升职场核心技能、架构思维、团队管理能力、商业认知,让每一位普通的技术从业者,修炼成为“技术职场超级个体”,通过全面升级个人的底层操作系统,突破瓶颈,实现职场跃迁。


72 项核心技能列表


用户头像

还未添加个人签名 2019.10.21 加入

还未添加个人简介

评论

发布
暂无评论
亿级流量峰值没在怕,“缓存”技术来减压!