开发者社区> jjkjack> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

百万QPS系统的缓存实践

简介: 标题有些吸引眼球了,但并不浮夸,甚至还会远远超过百万,现在的平均响应时间在1ms内,0.08ms左右 如此高的QPS,如此低的AVG,为什么会有如此效果,关键点可能就在多级缓存上 在开发高并发系统时有三把利器用来保护系统:缓存、降级和限流
+关注继续查看

标题有些吸引眼球了,但并不浮夸,甚至还会远远超过百万,现在的平均响应时间在1ms内,0.08ms左右

如此高的QPS,如此低的AVG,为什么会有如此效果,关键点可能就在多级缓存上

在开发高并发系统时有三把利器用来保护系统:缓存、降级和限流

概述

image.png

上图基本上就是查询的通用方案,缓存中是否存在,存在就返回,不存在再查询Db,查询到的结果load进缓存

实践

缓存,逃不过三种操作,创建、查询、删除

此实践可能不保证全场景通用,但满足当前系统各项指标,当然没有完美的方案,只有适合的方案。

下面的时序图中,cache lv1是指本地缓存,cache lv2是cache cluster

查询

image.png

查询过程:

从一级缓存开始查,如果没有,再向下一级查询,直到db

注意点:

  1. 一直查到db时,需要回源各级cache
  2. 防止击穿,需要在cache中填充value

创建

image.png

创建过程:

  1. 创建cacheObject
  2. 放入Db(为了性能,以及db的降级,这儿可以引入异步开关)
  3. 放入cache lv2
  4. 放入cache lv1
  5. publish创建成功消息
  6. 消息监听服务会通知其它服务更新本地缓存

注意点:

  1. 到底是先放入Db,还是先放入cache
  2. db与cache的一致性保障

删除

image.png

删除过程:

  1. 通过key查询cacheobject
  2. 清除db
  3. 清除各级cache
  4. publish消除成功消息
  5. 监听服务清除其它服务的本地缓存

注意点:

  1. 先清除db还是cache
  2. Db与cache的一致性保障

缓存操作模式

除了创建,查询,删除,还有更新操作;但我们业务场景没有。

对于我们的实践是不是放之四海而皆准,肯定是不行的。不以业务为基础的设计都是无根之木

先看下业界常见的操作缓存模式

更新缓存的的Design Pattern有四种:Cache aside, Read through, Write through, Write behind caching

Cache aside

  • 失效:应用程序先从cache取数据,没有得到,则从数据库中取数据,成功后,放到缓存中。
  • 命中:应用程序从cache中取数据,取到后返回。
  • 更新:先把数据存到数据库中,成功后,再让缓存失效。


image.png

这是标准的design pattern,包括Facebook的论文《Scaling Memcache at Facebook》也使用了这个策略。为什么不是写完数据库后更新缓存?你可以看一下Quora上的这个问答《Why does Facebook use delete to remove the key-value pair in Memcached instead of updating the Memcached during write request to the backend?》,主要是怕两个并发的写操作导致脏数据。

那么,是不是Cache Aside这个就不会有并发问题了?不是的,比如,一个是读操作,但是没有命中缓存,然后就到数据库中取数据,此时来了一个写操作,写完数据库后,让缓存失效,然后,之前的那个读操作再把老的数据放进去,所以,会造成脏数据。

但,这个case理论上会出现,不过,实际上出现的概率可能非常低,因为这个条件需要发生在读缓存时缓存失效,而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢得多,而且还要锁表,而读操作必须在写操作前进入数据库操作,而又要晚于写操作更新缓存,所有的这些条件都具备的概率基本并不大。

Cache Aside,我们的应用代码需要维护两个数据存储,一个是缓存(Cache),一个是数据库(Repository)。所以,应用程序比较啰嗦。而Read/Write Through套路是把更新数据库(Repository)的操作由缓存自己代理了,所以,对于应用层来说,就简单很多了。可以理解为,应用认为后端就是一个单一的存储,而存储自己维护自己的Cache。

Read Through

Read Through 套路就是在查询操作中更新缓存,也就是说,当缓存失效的时候(过期或LRU换出),Cache Aside是由调用方负责把数据加载入缓存,而Read Through则用缓存服务自己来加载,从而对应用方是透明的。

这似乎很像guave的LoadCache

Write Through

Write Through 套路和Read Through相仿,不过是在更新数据时发生。当有数据更新的时候,如果没有命中缓存,直接更新数据库,然后返回。如果命中了缓存,则更新缓存,然后再由Cache自己更新数据库(这是一个同步操作)

Write Back

在更新数据的时候,只更新缓存,不更新数据库,而我们的缓存会异步地批量更新数据库。这个设计的好处就是让数据的I/O操作飞快无比(因为直接操作内存嘛 ),因为异步,write backg还可以合并对同一个数据的多次操作,所以性能的提高是相当可观的。

在wikipedia上有一张write back的流程图,基本逻辑如下:

image.png

在游戏开发中基本上都是使用这种模式

但他也有缺点:

  1. 数据不是强一致性
  2. 数据可能会丢失
  3. 逻辑比较复杂

争论

  1. 一致性问题
    这儿的一致性是说强一致性,在分布式环境下,保证强一致性促使系统复杂性增加,或者性能有所下降。所以现在一般对非强制性业务场景都使用最终一致性解决。一致性的解读可以看看《zookeeper-paxos》,在我们实践时,在删除操作时,在清理失败时也通过补偿操作去尝试清除。

  2. 到底是update cache,还是delete cache
    其实任务技术手段都是看业务场景的,不能一概而论

    • update cache
      这个在并发写时,A1写db,B1写db,B2写cache,A2写cache;这时就出现db与Cache不一致的问题
      主动更新缓存,如果cacheobject复杂,需要Db与cache的多次交互,虽然减少了一次cache miss,但却增加了系统复杂度,得不偿失

    • delete cache
      这个不会有不一致问题了,但会造成cache miss,会不会造成热key穿透?

  1. 是先操作Db,还是cache
    假设先操作cache,再操作db;A B并发操作,A1 delete cache; B1 get cache --> miss --> select db --> load cache;A2 delete db;
    此种情况就出现此key一直有效状态,如果没有设置超时时间,那会长期在缓存中。这是不是得先操作db呢?
    一个操作先update db,再delte cache时失败了;那会数据库里是新数据,而缓存里是旧数据,业务无法接受。那是不是该先操作缓存呢?

是不是已经晕头了呢?

再有db主从架构中,主从不一致的情况,是不是没法玩了

所以还是开篇讲的没有放之四海而皆准的方案,只能寻找最适合的方案

在各种业务场景下,还是需要去寻找一些最佳实践,比如关注一下缓存过期策略、设置缓存过期时间

参考资料

缓存更新的套路

A beginner’s guide to Cache synchronization strategies


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
如何设计秒杀系统?
如何设计秒杀系统?
134 0
百万在线的美拍直播弹幕系统的实时推送技术实践之路
1、内容概述 直播弹幕是直播系统的核心功能之一。如何迅速作出一个有很好扩展性的弹幕系统?如何应对业务迅速发展?相信很多工程师/架构师都有自己的想法。 本文作者是美拍的架构师,经历了直播弹幕从无到有,从小到大的过程,借此文为大家分享构建弹幕系统的经验,希望能为正在开发或正打算开发弹幕、消息推送、IM聊天等系统的技术同行带来一些启发。
3282 0
进程的切换和系统的一般执行过程【转】
转自:http://www.cnblogs.com/20135124freedom/p/5391170.html 陈民禾 原创作品转载请注明出处 《Linux内核分析》MOOC课程 http://mooc.study.163.com/course/USTC-1000029000 一.关于进程调度的基本知识       进程的几种不同分类:第一种分类:类型一:I/O-bound:频繁的进行I/O,通常会花费很多的时间等待I/O操作的完成;类型二:CPU-bound:计算密集型 ,需要大量的CPU时间进行运算第二种分类:类型一:批处理进程 ;类型二:实时进程;类型三:交互式进程。
1378 0
第八周 进程的切换和系统的一般执行过程【转】
转自:http://www.cnblogs.com/20135305yg/p/5379542.html 一.进程切换的关键代码switch_to分析 进程的调度时机与进程的切换: 操作系统中的进程调度算法是从运行队列中选择一个新进程,选择的过程中运用了不同的策略 进程调度的时机: ...
779 0
SQL:安装多个实例,修改实例端口号,和IP加端口号连接实例
原文:SQL:安装多个实例,修改实例端口号,和IP加端口号连接实例 sql server 安装第一个实例,默认实例的端口是1433, 一个库中如果有多个实例,从第二个实例开始的端口是动态端口,需要的话,自己手工指定为静态端口,如指定第二个实例为1434 或着随意一个如2080端口  方法: 点...
1972 0
+关注
125
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载