概念

(1)缓存能解决的问题

  • 性能——将相应数据存储起来以避免数据的重复创建、处理和传输,可有效提高性能。比如将不改变的数据缓存起来,例如国家列表等,这样能明显提高web程序的反应速度;

  • 稳定性——同一个应用中,对同一数据、逻辑功能和用户界面的多次请求时经常发生的。当用户基数很大时,如果每次请求都进行处理,消耗的资源是很大的浪费,也同时造成系统的不稳定。例如,web应用中,对一些静态页面的呈现内容进行缓存能有效的节省资源,提高稳定性。而缓存数据也能降低对数据库的访问次数,降低数据库的负担和提高数据库的服务能力;

  •  可用性——有时,提供数据信息的服务可能会意外停止,如果使用了缓存技术,可以在一定时间内仍正常提供对最终用户的支持,提高了系统的可用性。

为什么要缓存数据

(1)在应用程序中缓存数据有以下好处:

  • 减少交互的通讯量——缓存数据能有效减少在进程和机器间的传输量;

  • 降低系统中的处理量——减少处理次数;

  • 降低需要做的磁盘访问次数——比如缓存在内存中的数据。

缓存选型

  • 我们这里介绍的的缓存组件为redis。


正文

  1.缓存雪崩

  对于系统 A,假设每天高峰期每秒 5000 个请求,本来缓存在高峰期可以扛住每秒 4000 个请求,但是缓存机器意外发生了全盘宕机。缓存挂了,此时 1 秒 5000 个请求全部落数据库,数据库必然扛不住,它会报一下警,然后就挂了。此时,如果没有采用什么特别的方案来处理这个故障,DBA 很着急,重启数据库,但是数据库立马又被新的流量给打死了。

这就是缓存雪崩。

   


1.1 缓存雪崩解决方案 

  解决方案如下:

  • 事前:redis 高可用,主从+哨兵,redis cluster,避免全盘崩溃。

  • 事中:本地 ehcache 缓存 + hystrix 限流&降级,避免 MySQL 被打死。

  • 事后:redis持久化,一旦重启,自动从磁盘上加载数据,快速恢复缓存数据。



大致流程为

    用户发送一个请求,系统 A 收到请求后,先查本地 ehcache 缓存,如果没查到再查 redis。如果 ehcache和 redis 都没有,再查数据库,将数据库中的结果,写入 ehcache 和 redis 中。

限流组件,可以设置每秒的请求,有多少能通过组件,剩余的未通过的请求,怎么办?走降级!可以返回一些默认的值,或者友情提示,或者空白的值。

这样做的好处

  1. 数据库绝对不会死,限流组件确保了每秒只有多少个请求能通过。

  2. 只要数据库不死,就是说,对用户来说,2/5 的请求都是可以被处理的。

  3. 只要有 2/5 的请求可以被处理,就意味着你的系统没死,对用户来说,可能就是点击几次刷不出来页面,但是多点几次,就可以刷出来一次。

2.缓存穿透
 对于系统 A,假设一秒 5000 个请求,结果其中 4000 个请求是黑客发出的恶意攻击。

 黑客发出的那 4000 个攻击,缓存中查不到,每次你去数据库里查,也查不到。

 举个栗子。数据库 id 是从 1 开始的,结果黑客发过来的请求 id 全部都是负数。这样的 话,缓存中不会有,请求每次都“视缓存于无物”,直接查询数据库。这种恶意攻击场 景的缓存穿透就会直接把数据库给打死。

缓存雪崩、缓存穿透、缓存击穿分别是什么意思?缓存溃之后会怎么样?系统该如何应对这种情况?_java

解决方案

有2种解决方法

1.每次系统 A 从数据库中只要没查到,就写一个空值到缓存里去,比如 set -999 UNKNOWN。然后设置一个过期时间,这样的话,下次有相同的 key 来访问的时候,在缓存失效之前,都可以直接从缓存中取数据。

2.使用布隆过滤器,对于不在条件中的请求直接返回。(布隆过滤器的机制需要自己百度查询,这里不做详细扩展)

3.缓存击穿

    缓存击穿,就是说某个key非常热点,访问非常频繁,处于集中式高并发访问的情况,当这个key在失效的瞬间,大量的请求就击穿了缓存,直接请求数据库,就像是在一道屏障上凿开了一个洞。

   解决方案

  1. 将热点数据设置为永远不过期

  2. 基于redis or zookeeper 实现互斥锁,等待第一个请求构建完缓存之后,再释放锁,进而其它请求才能通过该 key 访问数据。


总结

   缓存的问题,在系统开发中还是比较经常会遇到的问题。

   而不同并发度的系统实际开发中可能会遇到各种不同的情况,对应也会有不同的手段来解决对应的问题,上文分析的内容错误可能不能完全覆盖所有情况。

   另外,缓存可讨论的问题还是比较多,比如数据库与缓存如何保证数据统一或者两者的同步策略该如何等,后面文章会有相关更新,欢迎继续关注。


以上为全部内容。