共计 2878 个字符，预计需要花费 8 分钟才能阅读完成。
背景
概述
最近团队里咱们在密集的探讨 Redis 缓存一致性相干的问题，电商外围的域如商品、营销、库存、订单等实际上在缓存的抉择上各有特色，那么在这些差别的业务背地，咱们有没有一些最佳实际可供参考呢？本文尝试着来探讨这个问题，并给出一些倡议。
在探讨之前，有两个重点咱们须要达成统一：
- 分布式场景下无奈做到强统一：不同于 CPU 硬件缓存体系采纳的 MESI 协定以及硬件的强时钟管制，分布式场景下咱们无奈做到缓存与底层数据库的强统一，即把缓存和数据库的数据变更做成一个原子操作。硬件工程师设计了内存屏障（Memory Barrier）的概念，提供给软件开发者不同的一致性选项在性能与一致性上进行衡量。
- 就算是达到最终一致性也很难：分布式场景下，要做到最终一致性，就要求缓存中存储的是最新版本的数据（或者缓存为空），而且是在数据库更新后很迅速的就要达到这个一致性的状态，要做到是极其艰难的。咱们会面临硬件、软件、通信等等组件十分多的异常情况。
CPU 的缓存构造 *
缓存的一致性问题
一般化来说，咱们面临的是这样的一个问题，如下图所示，数据库的数据会有 5 次更新，产生 6 个版本，V1~V6，图中每个方框的长度代表这个版本继续的工夫。咱们冀望，在数据库中的数据变动后，缓存层须要尽快的感知到并作出反应，如下图所示，缓存层方框中的距离代表这个时间段缓存数据不存在，V2、V3 以及 V5 版本在缓存中不存在并不会毁坏咱们的最终一致性要求，只有数据库的最终版本和缓存的最终版本是雷同的就能够了。
缓存是如何写入的
缓存写入的代码通常状况下都是和缓存应用的代码放在一起的，蕴含 4 个步骤，如下图所示：W1 读取缓存，W2 判断缓存是否存在，W3 组装缓存数据（这通常须要向数据库进行查问），W4 写入缓存。每一个步骤间可能会进展多久是没有方法管制的，尤其是 W3、W4 之间的进展最为要命，它很可能让咱们将旧版本的数据写入到缓存中。
咱们可能会想，W4 步的写入，带上 W2 的假如，即应用 WriteIfNotExists 语义，会不会有所改善？
思考如下的情景，假如有 3 个缓存写入的并发执行，因为短时间数据库大量的更新，它们别离组装的是 V1、V2、V3 版本的数据。应用 WriteIfNotExists 语义，其中必然有 2 个执行会失败，哪一个会胜利根本无法保障。咱们无奈简略的做决策，须要再次将缓存读取进去，而后判断是否咱们行将写入的一样，如果一样那就很简略；如果不一样的话，咱们有两种抉择：
1）将缓存删除，让后续别的申请来解决写入。
2）应用缓存提供的原子操作，仅在咱们的数据是较新版本时写入。
如何感知数据库的变动
数据库的数据发生变化后，咱们如何感知到并进行无效的缓存治理呢？通常状况下有如下的 3 种做法：
应用代码执行流
通常咱们会在数据库操作实现后，执行一些缓存操作的代码。这种形式最大的问题是可靠性不高，利用重启、机器意外当机等状况都会导致后续的代码无奈执行。
应用事务音讯
作为应用代码执行流的改良，在数据库操作实现后收回事务音讯，而后在音讯的生产逻辑里执行缓存的治理操作。可靠性的问题就解决了，只是业务侧要为此减少事务音讯的逻辑，以及运行老本。
应用数据变更日志
数据库产品通常都反对在数据变更后产生变更日志，比方 MySQL 的 binlog。能够让中间件团队写一款产品，在接管到变更后执行缓存的治理操作，比方阿里的精卫。可靠性有保障，同时还能够进行某个时间段变更日志的回放，性能就比拟弱小了。
最佳实际一：数据库变更后生效缓存
这是最罕用和简略的形式，应该被作为首选的计划，整体的执行逻辑如下图所示：
W4 步应用最根本的 put 语义，这里的假如是写入较晚的申请往往也是携带的最新的数据，这在大多的情景下都是成立的。D1 步应用监听 DB binlog 的形式来删除缓存，即前述应用数据变更日志中介绍的办法。
这个计划的毛病是：在数据库数据存在高并发更新且缓存读取流量较大的状况下，会有小概率存在缓存中存储的是旧版本数据的状况。
通常的解法有四种：
1）限度缓存无效工夫：设定缓存的过期工夫，比方 15 分钟。即示意咱们最多承受缓存在 15 分钟的工夫范畴内是旧的。
2）小概率缓存重加载：依据流量比设定肯定比例的缓存重加载，以保障大流量状况下的缓存数据的一致性。比方 1% 的比例，这同时还能够帮忙数据库失去充沛的预热。
3）联合业务特点：依据业务的特点做一些设计，比方：
针对营销的场景：在商品详情页 / 确认订单页的优惠计算时应用缓存，而在下单时不应用缓存。这能够让极其状况产生时，不产生过大的业务损失。
针对库存的场景：读取到旧版本的数据只是会在商品已售罄的状况下让多余的流量进入到下单而已，下单时的库存扣减是操作数据库的，所以不会有业务上的损失。
4）两次删除：D1 步删除缓存的操作执行两次，且两头有肯定的距离，比方 30 秒。这两次动作的触发都是由“缓存治理组件”发动的，所以能够由它反对。
最佳实际二：带版本写入
针对象商品信息缓存这种更新频率低、数据一致性要求较高且缓存读取流量很高的场景，通常会采纳带版本更新的形式，整体的执行逻辑如下图如示：
和“数据库变更后生效缓存”计划最大的差别在 W4 步和 D1 步，须要缓存层提供带版本写入的 API，即仅当写入数据版本较新时能够写入胜利，否则写入失败。这同时也要求咱们在数据库减少数据版本的信息。
这个计划的最终一致性成果比拟好，仅在极其状况下（新版本写入后数据失落了，后续旧版本的写入就会胜利）存在缓存中存储的是旧版本数据的可能。在 D1 步应用写入而不是应用删除能够极大水平的防止这个极其状况的呈现，同时因为该计划实用于缓存读取流量很高的场景，还能够防止缓存被删除后 W3 步短时间大量申请穿透到 DB。
总结与瞻望
对于缓存与数据库拆散的场景，在联合了业界多家公司的实践经验以及 ROI 衡量之后，前述的两个最佳实际是被利用的最为宽泛的，尤其是最佳实际一，应该作为咱们日常利用的首选。同时，为了最大限度的防止每个最佳实际背地可能产生的不一致性问题，咱们还须要切合业务的特点，在要害的场景上做一些保障一致性的设计（比方前述的营销在下单时应用数据库读而不是缓存读），这也显得尤为重要（毕竟如“背景”中所述，并不存在完满的技术计划）。
除了缓存与数据库拆散的计划，还有两个业界曾经利用的计划也值得咱们借鉴：
阿里 XKV
简略来讲就是在数据库上部署一个 Memcache 的 Server，它间接绕过数据库层间接拜访存储引擎层（如：InnoDB），同时应用 KV client 来进行数据的拜访。它的特点是数据实际上与数据库是强统一的，性能能够比应用 SQL 拜访数据库晋升 5～10 倍。毛病也很显著，只能通过主键或者惟一键来拜访数据（这只是绝对 SQL 来说的，大多数缓存原本也就是 KV 拜访协定）。
腾讯 DCache
不必自行保护缓存与数据库两套存储，给开发人员对立的一套数据视图，由 DCache 在缓存更新后自行长久化数据。毛病是反对的数据结构无限（key-value，k-k-row，list，set，zset），将来也很难反对形如数据库表一样简单的数据结构。
文 / 苏木
关注得物技术，做最潮技术人！
