库存扣多了,到底怎么整 | 架构师之路

业务复杂、数据量大、并发量大的业务场景下,典型的互联网架构,一般会分为这么几层:

  • 调用层,一般是处于端上的browser或者APP
  • 站点层,一般是拼装html或者json返回的web-server层
  • 服务层,一般是提供RPC调用接口的service层
  • 数据层,提供固化数据存储的db

对于库存业务,一般有个库存服务,提供库存的查询、扣减、设置等RPC接口:

  • 库存查询,stock-service本质上执行的是 select num from stock where sid=$sid
  • 库存扣减,stock-service本质上执行的是 update stock set num=num-$reduce where sid=$sid
  • 库存设置,stock-service本质上执行的是 update stock set num=$num_new where sid=$sid

用户下单前,一般会对库存进行查询,有足够的存量才允许扣减:

如上图所示,通过查询接口,得到库存是5。

用户下单时,接着会对库存进行扣减:

如上图所示,购买3单位的商品,通过扣减接口,最终得到库存是2。

希望设计往往有容错机制,例如“重试”,如果通过扣减接口来修改库存,在重试时,可能会得到错误的数据,导致重复扣减:

如上图所示,如果数据库层面有重试容错机制,可能导致一次扣减执行两次,最终得到一个负数的错误库存。

重试导致错误的根本原因,是因为“扣减”操作是一个非幂等的操作,不能够重复执行,改成设置操作则不会有这个问题:

如上图所示,同样是购买3单位的商品,通过设置库存操作,即使有重试容错机制,也不会得到错误的库存,设置库存是一个幂等操作。

在并发量很大的情况下,还会有其他的问题:

如上图所示,两个并发的操作,查询库存,都得到了库存是5。

接下来用户发生了并发的购买动作(秒杀类业务特别容易出现):

如上图所示:

  • 用户1购买了3个库存,于是库存要设置为2
  • 用户2购买了2个库存,于是库存要设置为3
  • 这两个设置库存的接口并发执行,库存会先变成2,再变成3,导致数据不一致(实际卖出了5件商品,但库存只扣减了2,最后一次设置库存会覆盖和掩盖前一次并发操作)

根本原因是,设置操作发生的时候,没有检查库存与查询出来的库存有没有变化,理论上:

  • 库存为5时,用户1的库存设置才能成功
  • 库存为5时,用户2的库存设置才能成功

实际执行的时候:

  • 库存为5,用户1的set stock 2确实应该成功
  • 库存变为2了,用户2的set stock 3应该失败掉

升级修改很容易,将库存设置接口,stock-service上执行的:

update stock set num=$y where sid=$sid

升级为:

update stock set num=$num_new where sid=$sid and num=$num_old

这正是大家常说的“Compare And Set”(CAS),是一种常见的降低读写锁冲突,保证数据一致性的方法。

总结

在业务复杂,数据量大,并发量大的情况下,库存扣减容易引发数据的不一致,常见的优化方案有两个:

  • 调用“设置库存”接口,能够保证数据的幂等性
  • 在实现“设置库存”接口时,需要加上原有库存的比较,才允许设置成功,能解决高并发下库存扣减的一致性问题

希望大伙有收获。

原文发布于微信公众号 - 架构师之路(road5858)

原文发表时间:2017-06-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java架构师学习

多研究些架构,少谈些框架——一名阿里架构师的笔记

微服务架构和SOA区别 微服务现在辣么火,业界流行的对比的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为...

3388
来自专栏企鹅号快讯

如何提升Java应用程序性能

作者 | Eugen Paraschiv 翻译 | 雁惊寒 【摘要】本文首先介绍了负载测试、基于APM工具的应用程序和服务器监控,随后介绍了编写高性能Java代...

2048
来自专栏后端技术探索

携程异步消息系统实践

今天会跟大家分享一下我们在携程,现在应该是正在推广的一个新的消息系统,主要会偏重于讲一些架构和实现方面的内容。目前我在携程大概一年多都在做新的消息系统Herme...

1012
来自专栏北京马哥教育

《大型网站技术架构》读书笔记之六:永无止境之网站的伸缩性架构

一、网站架构的伸缩性设计 01、不同功能进行物理分离实现伸缩 (1)纵向分离:将业务处理流程上得不同部分分离部署,实现系统的伸缩性; ? (2)横向分离:将不同...

3179
来自专栏行者常至

在Hibernate中,使用二级缓存机制要注意什么?

642
来自专栏JAVA高级架构

多研究些架构,少谈些框架(3)-- 微服务和事件驱动

接上篇,我们采用了领域驱动的开发方式,使用了充血模型,享受了他的好处,但是也不得不面对他带来的弊端。这个弊端在分布式的微服务架构下面又被放大。 事务一致性 事务...

2754
来自专栏Java技术

Java分布式开发不得不知的Dubbo技术详细介绍

随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进。

783
来自专栏java一日一条

编写高性能 Java 代码的最佳实践

在这篇文章中,我们将讨论几个有助于提升Java应用程序性能的方法。我们首先将介绍如何定义可度量的性能指标,然后看看有哪些工具可以用来度量和监控应用程序性能,以及...

913
来自专栏散尽浮华

网站系统架构梳理-解决高负载高并发

随着互联网业务的不断丰富,网站系统架构已经细分到方方面面,尤其对于大型网站来说,所采用的技术更是涉及面非常广,从硬件到软件、编程语言、数据库、WebServer...

24410
来自专栏恰同学骚年

《大型网站技术架构》读书笔记之六:永无止境之网站的伸缩性架构

此篇已收录至《大型网站技术架构》读书笔记系列目录贴,点击访问该目录可获取更多内容。

612

扫码关注云+社区