失效链接处理 |
行业案例:去哪儿100Wqps二级缓存组件架构案例 PDF 下载
相关截图:
主要内容:
一、第一个缓存组件的开发
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 理论告诉我们在分布式环境下无法在强一致性上去死
磕,分布式缓存完整的强制一致是一个不可解的问题, 工程实践时应主要考虑一致性、开发成本与性能
开销之间的平衡。由于这是一个重要的缓存方案,为了降低实践风险,我们做了充分的分析和思考。
|