行业案例：去哪儿100Wqps二级缓存组件架构案例.pdfVIP

行业案例：去哪儿100Wqps二级缓存组件架构案例

在高性能的系统开发设计过程中，缓存的开发与使用是必不可少的内容，对于较复杂的业务系统往往并

不是一个缓存方案就能解决所有性能问题，而是根据业务场景的不同选择不同的缓存方案进行搭配产出

更好的整体性能。

去哪儿的增值业务系统是一个承接多业务线贯穿多种售卖场景的三高系统，

2021年上半年我们对系统进行了缓存体系化改造升级，

改造后的缓存不仅容易拓展和维护，性能上的直接收益非常可观，数据库qps下降80%以上，详情接

口响应时长从150ms下降到了90ms，内部子系统间的rpc调用减少了40%以上，关键部分缓存命中

率维护在80%以上。

那么这样的一个缓存体系是如何设计开发出来的呢？

接下来，给大家介绍一下，去哪儿100Wqps二级缓存组件架构

大家可以把去哪儿100Wqps三级缓存组件架构,和有赞的二级缓存组件，对比学习。

有赞的二级缓存组件架构，在下文中做了具体介绍：

场景题：假设10W人突访，你的系统如何做到不雪崩？-疯狂创客圈-博客园())

一、第一个缓存组件的开发

1、开发背景

2020圣诞节前后业务流量受疫情恢复开始反弹，增值业务系统db的qps单库上涨至3万以上，核心

接口延迟增加，增值业务交易系统load节节升高，生单存在性能安全隐患。

经调查发现：

大量请求处在IO阻塞中且系统线程数(2000+)和活动线程过高，系统上下文切换开销大。

为此，我们团队做了很多性能优化的措施，其中最重要一个动作就是给数据库层加了一个特殊的缓存方

案，这个缓存方案就是我们开发的第一个缓存组件。

之前系统已有在用redis和guava缓存的，为什么这次还要再加一个针对db层的缓存方案呢？主要源于

以下几点：

本次性能问题突出在db上，db的连接过高也在报警。

系统体量是很大的，仅交易系统有30万以上代码，系统内部流程和分支很多，直接在入口处做缓

存命中率不会很高，而系统最关键表结构只有6个，在此处做缓存更好收口。

这是个迭代过多年的系统，内部流程很长，上下文间经常有些对db重复的查询，改业务流程工作

量大需要回归的case太多。

交易系统对缓存的一致性要求极高，需要专用的缓存方案。

除此之外，传统的与数据库有关的缓存方案在我们的业务场景下是存在缺限的:

mysql数据库端的查询缓存，这个缓存很鸡肋，只要数据发生变更相关缓存数据全部失效，对于

一个含订单交易的系统而言变更可是常态。

mybatis二级存在，不仅一致性较差，其缓存粒度是基于mapper,一条数据的变更会将整个

mapper的缓存数据清空。

使用aop和注解，基于方法直接在dao请求和mysql间加一个redis，这个如果没有更细节的设

计，分布式环境下的全局一致性是得不到保证的。

基于binglog同步做缓存，这个是有秒级内延迟的，不适用于交易系统。

2、设计思考

我们设计的这个缓存组件命名为daoCache，原于其加在dao层上，其主作用于分担数据库的qps，

以近1：1的比例将mysql的查询请求转移至redis，通过一套固化的流程和机制确保在分布式环境下

缓存数据与db具有较高一致性，同时尽可能对业务使用透明。

分布式场景的一致性理论基础cap原则和base理论告诉我们在分布式环境下无法在强一致性上去死

磕，分布式缓存完整的强制一致是一个不可解的问题，工程实践时应主要考虑一致性、开发成本与性能

开销之间的平衡。由于这是一个重要的缓存方案，为了降低实践风险，我们做了充分的分析和思考。

1）内部情况考虑

数据层的编码有专人负责，一般业务开发只