超级会员免费看
本文探讨了后台开发中高并发扣减类业务的重要性，定义了扣减类业务并列举了常见场景。文章指出，这类业务需要关注并发一致性、可用性和性能。介绍了纯数据库实现扣减业务的方案，包括依赖数据库的乐观锁和事务来保证并发扣减和回滚。提出了基于读写分离和缓存的架构升级，以提高读取性能和减轻数据库压力。文章强调，任何方案都有适用场景，纯数据库方案在某些中小规模系统中是合适的，并讨论了架构演进的重要性。
在后台开发领域，高并发的扣减一直是比较热门的话题。在各类技术博客、大会分享以及面试问题中，出现频率都非常高，可见它的重要性和技术知识点的密集性。从本讲开始，我将由浅入深、由简至繁地介绍三种能够支撑不同并发量级的解决方案，首先介绍的是基于纯数据库实现的扣减方案。
什么是扣减类业务
看到这个标题很多人可能会有疑惑，扣减类业务不就是指秒杀吗，为什么要取这么抽象的名字呢？
但其实秒杀只是扣减类业务中的一个有代表性、具备一定技术复杂度的场景，它并不能代表扣减类业务的全部场景。我将在“第 16 讲”中详细讲解秒杀相关的内容。除了秒杀之外，常见的扣减类业务有：
购买一个或多商品时扣减的库存
商家针对用户设置的某个或几个商品最多购买次数
支付订单时扣减的金额
...
上述业务场景有几个共性点：购买的或设置需要扣减的数量一次可以是一个或多个；数量是共享的，每个用户都可以扣减某一个数据的数量。基于上述分析，可以给扣减类业务下一个定义：
它是需要通过对一个或多个已有的、用户间或用户内共享的数量，精准扣减成功才能继续的业务。
通过定义，将我们要讨论的扣减类业务圈定了一个边界和清晰的概念。希望你在本模块里和我一起锚定这个定义，防止出现因为定义不清楚导致的认知偏差和讨论分歧。
在了解了扣减类业务的定义之后，再来看看它和前面几个模块中涉及的读业务与 UGC 写业务的区别。
-
读业务的特点是写少读多，同时写入为非在线类运营操作，写入的 SLA（Service Level Agreement，服务等级协议）要求级别较低
订阅专栏 解锁全文
3020
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
