在高功用的系统开发规划进程中，缓存的开发与运用是必不行少的内容，关于较杂乱的事务系统往往并不是一个缓存计划就能处理一切功用问题，而是根据事务场景的不同挑选不同的缓存计划进行调配产出更好的全体功用。去哪儿的增值事务系统是一个承接多事务线贯穿多种售卖场景的三高系统，2021 年上半年咱们对系统进行了缓存系统化改造晋级，改造后的缓存不只简单拓展和保护，功用上的直接纳益十分可观，数据库 qps 下降 80% 以上，概况接口呼应时长从 150ms 下降到了 90ms ，内部子系统间的 rpc 调用削减了 40% 以上，要害部分缓存射中率保护在 80% 以上 。那么这样的一个缓存系统是怎么规划开发出来的呢？本文将处以具体回答。

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

1.1 开发布景

2020圣诞节前后事务流量受疫情康复开端反弹，增值事务系统 db 的 qps 单库上涨至 3 万以上，中心接口推迟添加，增值事务交易系统 load 节节升高，生单存在功用安全隐患。经查询发现许多恳求处在 IO 堵塞中且系统线程数(2000+)和活动线程过高，系统上下文切换开支大。为此，咱们团队做了许多功用优化的办法，其间最重要一个动作便是给数据库层加了一个特其他缓存计划，这个缓存计划便是咱们开发的第一个缓存组件。

之前系统已有在用redis和guava缓存的，为什么这次还要再加一个针对 db 层的缓存计划呢？首要源于以下几点:

1. 本次功用问题突出在 db 上，db 的衔接过高也在报警。
2. 系统体量是很大的，仅交易系统有 30 万以上代码，系统内部流程和分支许多，直接在入口处做缓存射中率不会很高，而系统最要害表结构只要 6 个，在此处做缓存更好收口。
3. 这是个迭代过多年的系统，内部流程很长，上下文间经常有些对 db 重复的查询，改事务流程作业量大需求回归的 case 太多。
4. 交易系统对缓存的共同性要求极高，需求专用的缓存计划。

除此之外，传统的与数据库有关的缓存计划在咱们的事务场景下是存在缺限的:

• mysql 数据库端的查询缓存，这个缓存很鸡肋，只需数据发生改变相关缓存数据悉数失效，关于一个含订单交易的系统而言改变可是常态。
• mybatis 二级存在，不只共同性较差，其缓存粒度是根据 mapper , 一条数据的改变会将整个 mapper 的缓存数据清空。
• 运用 aop 和注解，根据办法直接在 dao 恳求和 mysql 间加一个 redis ，这个假如没有更细节的规划，分布式环境下的大局共同性是得不到确保的。
• 根据 binglog 同步做缓存，这个是有秒级内推迟的，不适用于交易系统。

1.2 规划考虑

咱们规划的这个缓存组件命名为 daoCache ，原于其加在 dao 层上，其主作用于分担数据库的 qps ，以近 1：1 的份额将 mysql 的查询恳求转移至 redis ，经过一套固化的流程和机制确保在分布式环境下缓存数据与 db 具有较高共同性，一起尽或许对事务运用透明。

分布式场景的共同性理论根底 cap 原则和 base 理论告诉咱们在分布式环境下无法在强共同性上去死磕，分布式缓存完好的强制共同是一个不行解的问题， 工程实践时应首要考虑共同性、开发本钱与功用开支之间的平衡。由于这是一个重要的缓存计划，为了下降实践风险，咱们做了充沛的剖析和考虑。

• 内部状况考虑

数据层的编码有专人担任，一般事务开发只需调用数据层人员供给好的接口即可，这样的分工在项目人员较多时有显着优点，DB 和 SQL 能力强的同学写出的数据层代码质量更好，也能够集中做一些优化，缺点便是事务链路长的时分事务开发人员不太会去从全体和底层重视数据层的功率；为了下降计划后续接入改造的本钱，规划的计划要尽量削减对数据层以上编码的要求或重视。为了下降 DB 的压力，团队现已做了分库分表相关的操作，并对某些高频频的查询做过一些缓存，但不太系统，仅仅根据一些点片。已有的分库分表是后续做缓存分片时应该重点考虑到的内容。

• 外部状况考虑

这儿首要是考虑公司对 redis 的 api 在安全运用上的约束。比方公司的 redis 客户端是不支撑许多批量处理操作的，这就决议了削减交互次数欠好进行批处理优化；其他服务端禁用了 lua 脚本，没办法进行 cas 操作。

• 共同性的考虑

在缓存与 db 之间的更新一般有四种组合：先更新数据库，再更新缓存；先更新缓存，再更新数据库；先删缓存，再更新数据库；先更新数据库，再删缓存。仔细想想这四种更新组合在并发场景下都存在共同性问题，本文限于篇幅就不具体展开讨论了。

其他，要做到高共同性对缓存与 db 进行更新一般也四种思路：a、分布式同步加锁；b、映射到单线程+行列；c、监听数据库 binlog 同步更新缓存(秒级内推迟)；d、独立的缓存更新渠道共同操控, 缓存 key 分片与客户端监听变化。咱们的计划没有运用以上的使命何一种，这个在后文会具体介绍。

• 功用的考虑

为了做好功用，在具体计划完结流程中重视了以下几个点:

资源耗费，平均资源调用次数： 这儿首要是指要尽量削减接入缓存的实例与redis服务端的交互次数，当然不必要的db交互也要削减。

缓存射中率:缓存方针经过装备能够挑选，对缓存射中率低的key尽量不缓存，一般来说缓存射中30%以下就要考虑是否去除缓存。

反常流程： 一些反常进程是否会构成极端的脏数据，是否有清洗手法，清洗是否对功用有影响，redis服务端网络的动摇是否会影响到事务服务

加锁与并行度: 在并行更缓存下无锁化规划优于加锁，尽可削减加锁操作，特别是骨干流程，可是不要由于网络推迟而构成脏数据。

• 本钱的考虑

这儿首要是时刻本钱，由于事务流量还在上涨中，所以开发出的计划一定是轻量级的。

1.3 完结原理详解

流程

本缓存是运用 redis 作为缓存中间件(也能够换其分布式进程外缓存)，经过 mybatis 插件加 dao 层的注解加发动扫描完结的。在运用发动时扫描 dao 层一切加了 daoCache 注解的缓存，剖析要对哪些办法进行阻拦(预剖析而不是在拜访 dao 层时实时剖析，也是为了功用的考虑)；添加一个 mybatis 的插件对数据的增修改查做阻拦，其阻拦进程与缓存处理流程如下图：

上图中咱们将 sql 语句分为 4 种，重点重视的是图中第二种和第三种 sql ，关于第四种 sql 咱们只关怀新加数据时整理缓存兜空的状况，而关于第一种 sql ，由于多对多的处理太杂乱，而且咱们的项目中这样的 sql 的 qps 很低，不处理不影响大局，只需求对 qps 较高的一对多进行处理即可。仔细看这张图上有几个点要注意:

1. 读的流程，假如缓存射中开支是很低了，没有多余的交互和确保动作，而假如 miss，除了有 db 操作，还添加了两三次的 redis 操作;所以，关于射中率较低的sql能够用注解疏忽运用缓存。
2. 缓存不进自动更新，仅仅自动删去，只要被动 miss 时才向 redis 加入数据。
3. 整个流程没有分布式锁，确保并发时ABA不发生的要害在于打个自动过期的符号，相关同一个key的更新操作的符号是能够彼此复盖，打标持续期间是不允许向缓存中寄存数据, 向缓寄存数据的那个线程遇到符号是不堵塞的，而是直接丢弃本次操作;符号存活时刻可装备，默许长达10秒， 这么处理，或许从单条数据来看缓存长时刻没被运用，可是从微观全体去看，损失的miss则是占比很小的，几乎能够疏忽。
4. 缓存都设置了过期时刻，用以作终究共同性确保的兜底，一般时长为10分钟至20分钟，这个时长和用户单次运用咱们系统时长相差不多。
5. 为了进一步处理极端状况，还做了许多处理，比方: put完数据后立刻又check一下标识，假如标识又存在则整理缓存；关于一些退款判定类的sql，直接疏忽缓存; 为了确保生单进程的不被或许的脏缓存影响，关于生单线程做特别放行。

该计划的中心思想是:

• 关于共同性，不是彻底 case 处理，而是尽量处理大都 case ，关于欠优点理的部分就直接扔给数据库。
• 以主流程为根本确保共同性手法，弥补例外手法，线程维度放行与办法保护放行相结合。
• 按实践流量排行，优先处理大流量的查询。

要害数据结构

整个流程中 key 映射处理十分要害，由于只要映射联系精确了，在对应的dao 执行更新时才有或许将缓存中一切相相关的数据整理掉，具体映射联系如下图:

图中的字段意义解释:

bizKey： 事务主键，在咱们场景下一般便是定单号 orderId

bizValue： 事务主键对应的值，后加数字表明不同的值

selectKey： 一般咱们的查询条件中会带有 bizKey，假如不包括则需求指明一个能与 bizKey 发生联系的 key ，它们之间的相关是在miss后经过回来值建立起来的。

selectKeyValue： selectKey 对应的值，后加数字表明不同的值

methodReturnValue： 表明的是被阻拦的 dao 办法的回来值

其他字段大家能够顾名思义一下。set 结构表明它们之间的映射联系在 redis 中是经过 set 结构保护的，hash 结构表明它们之间的联系在 redis 中是经过hash结构保护的。一般假如咱们的查询条件中带有事务主键，那么经过 redis 的 hash 结构能够一次查询到，假如不带则需求先从 set 接口中拿到联系的键再经过主键获取数据，这个进程有些相似数据库的非聚合索引查找数据需求回表的进程。这么规划使得咱们只需求给那个 bizValue 相关的缓存打个符号并将其缓存内容删除即等价于一切与这个 bizValue 相关的缓存都被删去了(此刻经过 selectKey 能检索到 bizKey ，可是对应的 selectValue 被删去了，回来成果仍是空，等价于没有射中)。同一个 bizValue 存储着多个缓存值是由于关于同一条数据的查询其回来的数据结构或许是纷歧样的，所以缓存不是按表中记载一条条存储的，而是按每个办法的回来值存储。其他，咱们的计划要求关于被缓存办理的 dao 的一切更改操作都能带上 bizKey ，以便程序更新数据时能相关清除掉一切相关的数据。

注意，目前该映射联系仅能处理表和 dao 是一一映射的场景，在高 qps 场景，多表联合查询的规划很少，至少在咱们当时运用上不存在的。越杂乱的查询需求的这个映射联系也越杂乱，缓存端的数据结构也要进行定制，数据结构的杂乱也会影响缓存的功用，理论完本钱钱也很高，redis 现有的数据结构无法满意，或许需求开发专用缓存中间件。

1.4功用上线

做好上线，要把以下两个问题处理好。

1、怎么滑润晋级?

由于缓存是以 dao 接口为粒度进行装备的，所以能够先挑选一些不太重要的、更新频度低的先上线进行验证，做好装备与切换的开关，一旦问题能够切换回无缓存状况。在正式开量之前先进行充沛的 diff ，也便是拿缓存数据和拿 db 数据进行比照，看看差异，假如存在差异再经过日志查找构成差异的原因。这个验证进程能够查找出细节没有处理好的点，或者漏处理的点。实践上咱们在渐进上线进程和后续保护进程中就经过 diff ，查日志，看调栈的方法优化了一些细节才使得缓存共同性达到了线上可承受的状况，这儿就不具体说明晰。

2、呈现意想不到的问题时怎么处理，有没有反制手法?

首先在编码处理的细节大将 redis 做了弱依靠处理，也便是即使redis服务挂了也不影响事务的正常运转，在编码的每一步就考虑到了 redis 挂了后程序的继续运转。咱们调短了 redis 衔接超时时刻，运用滑动窗口算法对 redis 超时和反常进行分流，redis 越不稳定或反常越多时，直接走 db 的流量也就越多，当然为 db 的安全，正常分流最大值是 50% 直接走 db ，这个分流调整几乎是毫秒级的，究竟 redis 不稳定，哪怕仅仅堵塞 1 秒，咱们的运用也会发生数万条的过错日志。上线进程中的那个 diff 功用一向保存，它有额定的两个作用：一是上线后留置 5% 流量 diff ，一旦发现缓存不共同会触发报警; 二是当开 100% diff 的时分其实是在做缓存清洗的，由于 diff 的逻辑是呈现差异会以 db 的数据为准，并整理缓存，当有意想不到的问题呈现时，比方跑 sql 洗数了，能够针对性的把相关 dao 的 diff 全开。

二、大局缓存系统规划与规划

2.1 提出布景

在做了第一个缓存计划之后虽然解了 db 之忧，但后续有出项目发动过慢，系统功用颤动等问题，经查询发现一部分原因是由于产品缓存守时全量加载所造成的。这个产品缓存一起存在多个微服务系统之间，为此咱们提出了同享缓存的概念。不过，在提出同享缓存概念之前，为了防止又有其它相似问题呈现，先用了一个临时计划的计划堵住了表象问题，然后再对系统已有缓存作了一个全盘整理，经过全盘整理发现以下问题：

• 缓存的运用很零星，在长时刻项目跌代进程中变得很保护，无法全体观察，也无法进行大局调参装备。
• 有些缓存key可有多个子运用共用着，导致开发人员在不是很了解各运用代码的状况下不敢容易对这些缓存key做下线整理，时刻一长，redis中或许残存着许多无用的数据，浪费了许多的缓存资源;

其实这些问题是有一些代表性的，我想它不只仅存在于咱们增值事务系统中。

2.2 缓存系统简介

图中由上至下是从纵向按恳求流对缓存进行横向划分。

一级缓存: 指进程内部的缓存，运用一级缓存彻底是内存操作没有 io 开支，可是在分布场景下一级缓存分隔在各个进程中，共同性没有任何确保，它适用于周期较短的无状况化恳求，或者是其数据不共同性但事务可承受且在程序员可控范围内的，最理想的状况是被拜访资源能从全体架流程上做到被某个进程独享。一级缓存分成两类，如图中 a 类一般是不需求考虑大局共同性的，而 b 类许多状况是要考虑共同性的；一切缓存都要考虑容量、射中率、过期等问题；在某一个被缓存的条目上，a 类缓存和 b 类缓存一般是二选一，两者一起运用会使缓存规划过于杂乱，缓存共同性问题难解。

二级缓存：是指进程外部被一个运用多个实例或多个运用同享的缓存，一般会同享数据，这儿咱们暂只用 redis 做二级缓存；将 redis 缓存按功用用途分为以下四块，这四块在布置的时分纷歧定需求四个独立的命名空间，仅仅一种逻辑划分以便于编码上的差异对待，如布置时被放入同一命名空间编码时可考虑用命名前缀加以区分。

下面从右至左解释一下这四块内存:

通用 service 缓存:相似 spring 的注解，其缓存的数据量或许较大，要有内存约束，要考虑崩了不影响程序逻辑和正常流程，首要作用是对一般缓存运用场景的共同收口。

daoCache 缓存: 也称为数据库缓存，加在 dao 层，以办法签名和参数内容为 key ，内存较冗余，一般只 cache 部分表及部分办法；该缓存有较强共同性要求。

运用专项缓存: 被一个运用所独享的专用缓存，一般不做批量数据存储，多用做一些标识、计量、功用性行列、锁、幂等判定，对推迟要求灵敏，redis 毛病或推迟会影响到系统功用; 咱们现在大部分功用性缓存都归于这种状况，其间不归于但运用的部分今后要考虑迁走。

同享内存: 一般是被多个运用同享，其间至少一个运用对内存具备保护的权限(一般是谁创立谁保护)，这种缓存一般适合用于被多个运用拜访的高频热数据，数据的改变很少或不改变，承受一守时刻的数据不共同，但数据有必要终究共同。运用这种缓存，一般会配合一级缓存中的b类，二级缓存做全量，一级缓存做热点，一起要规划一二级缓存的共同性协议；关于咱们的系统来讲，产品缓存显着适用这一状况。

2.3 缓存组件相关间联系

上文介绍的各种缓存，它们除了可单独运用外，还能整合起来运用，达到 1+1 大于 2 的效果。完结这一点得益于两方面:

1、上文的全体规划上界说了各计划组件之间的鸿沟;

2、组件之间在完结上有明确的依靠联系，这个依靠联系如下图:

图中箭头的指向为依靠方向，中间绿色的部分收敛一切缓存中间件的和工具的运用，笼统出共同的缓存界说、装备、构建、根本接口，它自带两个缓存计划, 即通用缓存 service 缓存计划和条件上下缓存办法；其它缓存计划是坐落这个接口的界说和办理之上的，每一个上层的缓存计划是解一个特定缓存场景问题。

这样处理带来许多的优点:

1. 一切缓存计划都不依靠具体的缓存中间件，缓存中间件能够很便利的按上层具体场景甚至具体运用进行替换（ redis 有多种数据结构能够构成多个笼统实例，将其功用性和存储性部分分离）。
2. 有共同的根底监控和根底功用，比方根据音讯中间件做本地缓存更新的告诉。
3. 便于各计划间彼此打通，由于增值系统中运用了多种缓存计划，当缓存因一些特别原因（如手动改数据库数据了）而呈现不共一起，使得问题十分难排查，特别是在不太健状且杂乱多变的测验环境上时，此刻只需求在通用缓存组件部分加一个禁用缓存上下文的功用就能够很便利有挑选的禁用或悉数禁用缓存，进行差异 diff 。
4. 通用 service 缓存有一些根底功用，上层缓存计划是能够直接复用的，比方运用 mq 做根本的音讯同步（这儿仅仅一个接口界说，实践能够根据场景换），各种序列化计划的挑选与运用。

鉴于本文篇幅有限，下面只具体介绍同享缓存。

三、同享缓存组件开发

微服务环境下大项目会被拆分为多个小项目，原来在一个单体中的缓存或许会面临一起存在多个子运用中，这时就发生了共同性问题，将本地缓存直接改写成用 redis 这种进程外同享的缓存往往有功用上的风险。同享缓存的中心理念是多运用同享数据，以本地缓存作为一级缓存，redis 作为二级缓存，经过 mq 音讯或其它扩展完结缓存改变的增量更新，它的内容不单单仅仅如此，接下来咱们先对它的架构作个扼要的了解，然后再看看它到底有哪些特色。

3.1 架构简述

说明：

1. 同享缓存的接入方分为 Provider 和 Consumer 两个人物。Provider 方是持有缓存相关的数据源的一方（纷歧定要求是 db 数据源，但有必要有更新闭环），可对缓存进行读写；Consumer 方是只读缓存数据的一方, 只要在二级缓存 miss 的时分 consumer 才可经过隐式的 rpc 接口触发 provider 缓存数据的填充。
2. provider 和 consumer 都是可选，只运用 consumer 相当于对第三方接口进行了缓存，只运用 provider 的场景多为同一运用多实例节点，数据无需跨运用同享。
3. redis 既作为二级缓存，也作为注册中心。

为什么要分为 Provider 和 Consumer 两个人物呢? 这是照料跨团队的场景，在 api 的便用上 consumer 做得尽或许简洁，只需求调用即可，而 provider 则要关怀更新闭环和缓存的保护;其他，在微服务的场景下，服务间的联系也存在这样的人物，也是职能分工的需求。多运用同享一个 redis 集群和拆分后继续同享在咱们团队里是个常见的现象，而这时同享 key 的设置十分重要，参与运用或许要手艺保护 key 的共同性，有了同享缓存 key 共同性就再也不必担心出问题了。

3.2 价值特色

共存缓存应对的是低频更新极高频拜访的场景，是终究共同性缓存计划，同步一般在 2 秒内完结，顶峰时 10 秒内，反常时 5 分钟，极端状况 20 分钟，自身晋级有 bug 时有手艺同步后门。

同享缓存计划无论是在 redis 仍是在本地都只要一条原数据，这样做不只节约内存，在共同性上也优点理，完结细节上咱们也做了许多优化作业。

支撑事务，支撑按条件查询条件缓存。

真增量更新，全量数据本地缓存时，当新加某条数据或某条数据发生改变时，一切节点添加当条数据索引或仅过期当条数据。

自动分包与合包，为了防止 qmq 音讯过载，短时刻内许多相同音讯会在发送端和接纳端去重，并尽可兼并音讯，削减音讯发送量。

支撑 mq 音讯丢掉, 多种机制防止音讯丢掉后导致缓存成果不共同。

咱们接下来看来完结这些价值特色的原理。

3.3 中心完结原理

在没有做同享缓存之前，团队里其实有同学现已用 mq 做本地缓存数据同步了，也有些团队用数据库的 binlog 日志做同步; 可是没有将这个进程进行模版化，很难进行持续优化，计划很欠好复用。同享缓存完结的一个根本原理便是将 mq 同步缓存的这个进程进行模版化了。那么怎么进行模版化的呢？简单的说便是将与缓存相关的几个流程进行分化，将其间不变的部分提取出来放到框架中，将事务的部分留给运用时注入。同享缓存将缓存操作相关的流程分为：预热、读取、更新、接纳同步音讯和处理同步、兜底查看五个主流程，其间只要前三个流程需求用户去注册事务动作。本文限于篇幅具体流程就不再展述了。下面咱们看看完结同享缓存最要害的一个规划，正是这个规划使其与一般的经过 mq 进行同步的缓存有着根本的不同。

同享缓存的中心数据结构

同享缓存与 daoCache 一样也有一个事务主键的概念，与 daoCache 不同的是同享缓存无论是在本地仍是在 redis 关于同一个事务主键一般只对应一条数据， daoCache 存储的是 db 中数据的映射，同享缓存理论上能够存用户界说的任何数据。咱们来具体看看这张图上的缓存结构。

在 reids 这边， 存着注册相关的元数据，全量的事务数据，晋级进程中或许一起存在多个全量数据的版别，它们之间经过字节码前缀加以差异。

在本地，同享缓存保护着当时热点数据(当时没有开发热推送渠道，这个热点指的是经常被拉上来的数据)，保护四种索引：单条主键索引、条件调集索引（可选）、全量索引（可选）、回转索（有条件调集时才存在）。由于数据在本地和长途都只要一份，它们的终究共同性就很好保护。而关于索引的保护最坏的状况便是重建索引，在内存中重建索引的功率远高于重建相关的数据。为了做到更好的增量更新，数据更新都是先比照最新更新的 key 相关的内容是否契合索引条件，再决议是否向下取数据的。

同享缓存的共同性

有以下 5 个点来确保数据的共同性:

1. mq 进行本地缓存同步，mq 仅告诉发生变化数据的事务主键，本地接纳后对相关缓存进行删去，然后事务拜访时从头抽取数据即可，这个拉取数据的进程要尽量不要拉取到旧数据，由于这个流程远比 daoCache 要杂乱，这儿就不具体解释了。
2. provider 端对缓存进行更新的前后会在 redis 进行打标和删标，leader 节点会守时查看最近的符号，假如发现存在 30 秒前未删去的符号，则以为相关的缓存更新或许呈现反常，随即整理相关的缓存。
3. provider 端更新或添加数据时会将相相关的事务主键登记到 redis 里，各节点会在本地记载最近收到的需求改变的事务主键，每距离 5 分钟会和 redis 里进行比照(仅 5 分钟内改变的事务主键)，关于差异化的部分进行缓存整理。
4. leader 节点一般每距离（开发时可编码设定）20 分钟会将数据库中的数据全量更新至 redis 做二级缓存共同性的兜底，本地缓存也能够设置过期时刻做共同性的兜底，一般默许是半小时。
5. 本地缓存全量翻滚更新后门，能够手动调用，也能够装备 QSchedule 守时调用。(该方法可先，一般用于大版别更新，或运用初接时)

同享缓存的典型运用场景

图中放入同享缓存的数据是中间的那一部分，这个数据是由两个表结构出来的(实践运用时也能够来源于 qconfig 或其他接口, 但条件是运用能掌握数据更新的闭环)，图中事务容器数据是根据被缓存数据创立的（这个创立进程能够穿插其他数据源），当节点 1 把表 1 或表 2 的数据更新时会触发一切节点被缓存数据的更新，当某个节点缓存数据更新完结之后会回调注册的事务代码，由事务代码从头构建根据缓存数据的上层数据。这个场景假如运用其它缓存计划是需求许多编码才能处理的，而经过咱们同享缓存只需求事务界说好被缓存的象的读取构建进程，上层相关构建进程，相关表的 Dao 办法上添加注解即可。事实上这些进程在接入同享缓存之前事务就有相似的代码，只需求按同享缓存的方法修改一下即可。这一点并不是本计划最大特色，最大的特色是，短时刻内屡次被缓存目标的多个表的多条数据更新，同享缓存只会触发一条 mq 音讯进行数据同步。其它一般根据 mq 音讯同步或 binlog 同步的缓存，或许需求许多的网络开支。这儿举个例子，咱们某个运用几个产品数据的更新，或许会更新到一批 ext 表的数据又有主表的更新，主表的更新或许又会构成所属分组的更新，所属分组更新会又引起上层分类容器的更新，假如直接运用传统的 mq 音讯同步计划或许瞬时发生几千条 mq 音讯给一切节点消费，而这些节点又会或许悉数从头拉取数据，引起网络 IO 风暴。同享缓存在框架内部的发送端和接纳端都根据事务主键进行了兼并去重的操作，在这些根底之上又进行数据合包，使得终究发出的 mq 音讯降了几个量级，除此之外关于相关的的上层容器构建的触发也作了处理，当短期内收到许多更新触发时也会只执行最新的有用更新。

其他，由于同享缓存是根据通用缓存之上做了缓存计划，是不依靠具体的底层组件的，本地默许的 caffine 能够替换功用更高的 Map，redis 也能够在某些场景换成 memcached 。没错，在咱们的实践中 caffine 在单机百万级跌代下功用会有显着耗费(耗秒级，咱们查找接口 20ms 超时），在这种场景下直接换成 map 丢掉了缓存过期失效(能够经过自动失效补偿)换取了功用优势。

四、总结

这些缓存上线了不只直接削减了 db 的 qps ，一起也消除了 DB 峰值的颤动，一些运用间的接口由于同享缓存的存在也直接由高频qps到直接下线。数据库缓存自上线以来并没有呈现过显着缓存不共同，仅在一些改造晋级期呈现过零星不共同，也没有给事务构成负面影响，几乎没有收到与此相关的问题单。可是数据库缓存计划有许多的局限，首要表现在:

1. 缓存在恳求流的末端，缓存效益是很低的，给系统做缓存是分层的，越接近接近恳求入口收益越高（不过射中率欠好做高）。
2. 运用上对 dao 有一些要求和约束，如：只能单表查询，更新必带事务主键，对一对多的支撑需求 @DaoCacheSelectMethod 指明一些参数，否则不会阻拦这种办法，也并不是支撑一切的一对多，这个细节要了解原码才比较清楚，最重要的是配错了是没有任何提示的，需开发人员自己小心。
3. 特别放行逻辑需求事务额定编码配合。
4. 一向以为该缓存计划较高的射中率和咱们项目的编码特色有关（自身也是按项目已有的编码特色发生的），换成其他项目缓存射中率或许会下降。

不过本文共享的重点不是该计划的完结细节，而是发生和规划这个计划的思想，这个规划思想是能够用作其他缓存计划的。

而文中描绘的同享缓存其适用于极高 qps 与低 tps 的终究共同性却是在运用局限上面要小许多，目前的完结彻底满意咱们增值系统的需求，在对外推行上还有很大的成长空间，需求更多的事务场景去驱动完善。总之，根据缓存系统的大局规划，咱们力争在后续的事务驱动开发进程中将一切遇到的缓存计划的整组成一个缓存计划池，不断优化迭代使其成为更通用的缓存计划库。