在上两讲里分别介绍了使用数据库和纯缓存实现的扣减方案。在需求层面上，上述两者都能实现业务需求。但均存在一些缺陷：
数据库方案的性能较差；
纯缓存方案虽不会导致超卖，但因缓存不具备事务特性，极端情况下会存在缓存里的数据无法回滚，导致出现少卖的情况。且因“第 13 讲”是异步写库，也可能发生异步写库失败，导致多扣的数据再也无法找回的情况。
因此，本讲将向你介绍一种新的实现方案——使用数据库+缓存的方式规避上述存在的潜在问题。
顺序写的性能更好
本讲的方案是借助了“顺序写要比随机更新性能好”这个特性进行设计的。
在向磁盘进行数据操作时，向文件末尾不断追加写入的性能要远大于随机修改的性能。因为对于传统的机械硬盘来说，每一次的随机更新都需要机械键盘的磁头在硬盘的盘面上进行寻址，再去更新目标数据，这种方式十分消耗性能。而向文件末尾追加写入，每一次的写入只需要磁头一次寻址，将磁头定位到文件末尾即可，后续的顺序写入不断追加即可。
对于固态硬盘来说，虽然避免了磁头移动，但依然存在一定的寻址过程。此外，对文件内容的随机更新和数据库的表更新比较类似，都存在加锁带来的性能消耗。
数据库同样是插入要比更新的性能好。对于数据库的更新，为了保证对同一条数据并发更新的一致性，会在更新时增加锁，但加锁是十分消耗性能的。此外，对于没有索引的更新条件，要想找到需要更新的那条数据，需要遍历整张表，时间复杂度为 O(N)。而插入只在末尾进行追加，性能非常好。
借力顺序写的架构
有了上述的理论基础后，只要对上一讲的架构稍做变更，就可以得到兼具性能和高可靠的扣减架构了，整体架构如下图 1 所示：
图 1：兼具性能和更加高可靠的扣减架构
上述的架构和纯缓存的架构区别在于，写入数据库不是异步写入，而是在扣减的时候同步写入。
这里你可能会有些疑问：同步的写入数据库是不是和“第 12 讲”讲述的内容类似？且数据库扣减的性能对于海量并发是扛不住的，这个方案是不是在倒退？
如果你仔细看架构图，会发现并非如此。同步写入数据库使用是 insert 操作，也就是顺序写，而不是 update 做数据库数量的扣减。因此，它的性能较好。
insert 的数据库称为任务库，它只存储每次扣减的原始数据，而不做真实扣减（即不进行 update）。它的表结构大致如下：
create table task{
id bigint not null comment "任务顺序编号",
task_id bigint not null
}任务表里存储的内容格式可以为 JSON、XML 等结构化的数据。以 JSON 为例，数据内容大致可以如下：
{ "扣减号":uuid, "skuid1":"数量", "skuid2":"数量", "xxxx":"xxxx" }在上述架构里，还有一个**正式业务库，这里面存储的才是真正的扣减明细和 SKU 的汇总数据。对于正式库里的数据，通过任务表的任务进行同步即可，此种方式保证了数据的最终一致性。
扣减流程
在引入了任务表之后，整体的扣减流程如下图 2 所示：
图 2：基于任务的扣减流程
上述的流程和纯缓存的区别在于增加了事务开启与回滚的步骤，以及同步的数据库写入流程，详细分析如下。
首先是前置业务参数检验（包含基础参数、数量检验等），此步骤在本讲和前两讲的方案里都有。可以说，任何对外接口此功能都是不可或缺的，是完成业务验证性的必要一环。
然后在图中编号 2 处，开始数据事务。
当开始事务后，首先将此次序列化后的扣减明细写入到扣减数据库中的任务表里。
假设数据库插入扣减明细失败，则事务回滚，任务表中无新增数据，数据一致，无任何影响。
当数据库插入扣减明细成功后，便针对缓存进行扣减。和上一讲保持一致，使用 lua 等功能进行扣减即可。
如果缓存扣减成功，也就是流程正常结束，提交数据库事务，给客户返回扣减成功。
如果缓存扣减失败，有可能有两大类原因。
一类原因是此次扣减的数量不够，比如缓存里有 5 个数量，而实际此次扣减需要 10 个。当判断数量不够后，便调用缓存的归还并将数据库进行回滚即可。
第二类原因是缓存出现故障，导致扣减失败。缓存失败的可能性有很多，比如网络不通、调用缓存扣减超时、在扣减到一半时缓存突然宕机（故障 failover）了，以及在上述返回的过程中产生异常等。针对上述请求，都有相应的异常抛出，根据异常进行数据库回滚即可，最终任务库里的数据都是准的。
完成上述步骤之后，便可以进行任务库里的数据处理了。任务库里存储的是纯文本的 JSON 数据，无法被直接使用。需要将其中的数据转储至实际的业务库里。业务库里会存储两类数据，一类是每次扣减的流水数据，它与任务表里的数据区别在于它是结构化，而不是 JSON 文本的大字段内容。另外一类是汇总数据，即每一个 SKU 当前总共有多少量，当前还剩余多少量（即从任务库同步时需要进行扣减的），表结构大致如下：
create table 流水表{
id bigint not null,
uuid bigint not null comment '扣减编号',
sku_id bigint not null comment '商品编号',
num int not null comment '当次扣减的数量'
} comment '扣减流水表'商品的实时数据汇总表，结构如下：
create table 汇总表{
id bitint not null,
sku_id unsigned bigint not null comment '商品编号',
total_num unsigned int not null comment '总数量',
leaved_num unsigned int not null comment '当前剩余的商品数量'
} comment '记录表'原理分析
本讲介绍的数据库+缓存的架构主要利用了数据库顺序写入要比更新性能快的这一特性。此外，在写入的基础之上，又利用了数据库的事务特性来保证数据的最终一致性。当异常出现后，通过事务进行回滚，来保证数据库里的数据不会丢失。
在整体的流程上，还是复用了上一讲纯缓存的架构流程。当新加入一个商品，或者对已有商品进行补货时，对应的新增商品数量都会通过 Binlog 同步至缓存里。在扣减时，依然以缓存中的数量为准。补货或新增商品的数据同步架构如下图 3 所示：
图 3：补货或新增商品的数据同步架构图
这里你可能会产生疑问：通过任务库同步至正式业务库里那份数据岂不是没用了？当然不是。正式业务库异构的那份扣减明细和 SKU 当前实时剩余数量的数据，是最为准确的一份数据，我们以它作为数据对比的基准。如果发现缓存中的数据不一致，就可以及时进行修复。对于数据校准，你可以参考“第 05 讲”里介绍的方案。
比如，当缓存扣减完成后，我们的应用客户端重启了，此时外部调用方的连接会断开，外部调用方判断此次调用失败。但因突然重启，当次完成的扣减在缓存里是没有完成返还的。但数据库采用的是事务，客户端重启时，事务就自动回滚了。此时，数据库的数据是正确的，但缓存的数据是少的。
在纯缓存的方案里，如果当时的异步刷库也失败了，则缓存数据一直都是少卖的。而数据库+缓存的方案，只会在一定时间出现少卖的情况，最终的数据一定是一致的。此方案会保证任务数据库和正式业务数据库里的数据准确性，出现故障后基于正式数据库进行异步对比修复即可。这便是两种方案的差异所在。
性能提升
进行方案升级后，我们便完成了一个更加可靠的扣减架构，且使用任务数据库的顺序插入也保证了一定的性能。但总的来说，即使是基于数据库的顺序插入，缓存操作的性能和数据库的顺序插入也不是一个量级，那么如何提升顺序插入任务数据库的性能和吞吐量呢？
这里我们回顾一下在“第 9 讲”（无状态存储）里介绍的内容和理念——通过无状态的存储提升可用性。同样的逻辑，任务库主要提供两个作用，一个是事务支持，其次是随机的扣减流水任务的存取。这两个功能均不依赖具体的路由规则，也是随机的、无状态的。因此，可以借鉴“第 9 讲”的架构对本讲的内容进行升级，升级后的架构如下图 4 所示：
图 4：无状态存储的架构图
采用无状态存储后，任务库便可以进行水平扩展了，在性能和高可用上得到进一步的加强。具体的细节原理和落地步骤，你可以参考“第 9 讲”，这里不再赘述。
数据同步
任务库和业务正式库之间的数据同步和“第 9 讲”里介绍的无状态的存储基本类似，但整体实现上会更加简单。因为在业务上，扣减前置依赖的均是缓存里的数据，业务正式库里的数据只用来做兜底使用。因此最终只要使用 Worker 将数据从任务库同步至业务正式库即可，架构如下图 5 所示：
图 5：Worker 架构图
本节总结
在本讲里，我们介绍了通过缓存和数据库结合的方式，实现了一个更加可靠的扣减方案。相比纯缓存方案，即使使用了无状态的分库存储，它的性能也会有一定的损耗。但此方案的好处在于数据更精准、更可靠。对于类似额度扣减、实物库存扣减等场景，此方案均适用。而对于一些虚拟的次数限制，同时业务上能够容忍在一定概率下数据不准确的场景，也可以选择纯缓存的扣减方案。
此外，“顺序追加写要比随机修改的性能好”这个技巧，其实在很多场景里都有应用，是一个值得你深入学习和理解的技能。比如数据库的 Redo log、Undo log；Elasticsearch 里的 Translog 都是先将数据按非结构化的方式顺序写入日志文件里，再进行正常的变更。当出现宕机后，采用日志进行数据恢复。
经过“12、13、14”这三讲的学习，我想你对“扣减”相关的内容已经掌握得如鱼得水了，欢迎你动一动手指，在留言区写一写思考、做一做总结。如果你对哪里有疑问，也可以在留言区提问，咱们一起讨论。