秒杀系统架构分析与实战
陶邦仁 发表于11个月前
秒杀系统架构分析与实战
  • 发表于 11个月前
  • 阅读 33375
  • 收藏 270
  • 点赞 69
  • 评论 56
粉丝 1107
博文 389
码字总数 1483914
评论 (56)
卖小女孩的小火柴
文章真心写的非常好,32个赞。有个疑问,为啥没有做降低qps的操作?
陶邦仁

引用来自“卖小女孩的小火柴”的评论

文章真心写的非常好,32个赞。有个疑问,为啥没有做降低qps的操作?

秒杀最基本的要求是高并发处理,降低QPS反而失去了秒杀的特性
首席撸破屌
我觉得技术上实现差异并不大,但是防范才是关键。
易木夕林
分析很不错
都市网达
与现有网站业务系统拆分,这个很难执行下去,如果秒杀能成为常规业务,这是不错的方案,《大型网站技术架构:核心原理与案例分析》里面也提了一些类似的解决思路。
陶邦仁

引用来自“都市网达”的评论

与现有网站业务系统拆分,这个很难执行下去,如果秒杀能成为常规业务,这是不错的方案,《大型网站技术架构:核心原理与案例分析》里面也提了一些类似的解决思路。
zgw06629
一个疑问:
减少库存有必要用乐观锁吗?
update auction_auctions set
quantity = #inQuantity#
where auction_id = #itemId# and quantity = #dbQuantity#

直接
update auction_auctions set
quantity = quantity-#count#
where auction_id = #itemId#

这样不行吗?
陶邦仁

引用来自“zgw06629”的评论

一个疑问:
减少库存有必要用乐观锁吗?
update auction_auctions set
quantity = #inQuantity#
where auction_id = #itemId# and quantity = #dbQuantity#

直接
update auction_auctions set
quantity = quantity-#count#
where auction_id = #itemId#

这样不行吗?
必须得需要啊 乐观锁其实就是个MVCC,第二个SQL在两个减库存事务中未及时提交会导致超卖。
w4ww
分析的很好!
hotsmile
分析到位!!!!
OSCER
mark
saviorzuo
nice
linxiaobai
http://www.csdn.net/article/2014-11-28/2822858 有些内容和这个地方是一样的是为啥。。
陶邦仁

引用来自“linxiaobai”的评论

http://www.csdn.net/article/2014-11-28/2822858 有些内容和这个地方是一样的是为啥。。
是有些重复 本篇文章 有些引自外部的
martos

引用来自“zgw06629”的评论

一个疑问:
减少库存有必要用乐观锁吗?
update auction_auctions set
quantity = #inQuantity#
where auction_id = #itemId# and quantity = #dbQuantity#

直接
update auction_auctions set
quantity = quantity-#count#
where auction_id = #itemId#

这样不行吗?

引用来自“陶邦仁”的评论

必须得需要啊 乐观锁其实就是个MVCC,第二个SQL在两个减库存事务中未及时提交会导致超卖。
改为这样是否可以解决超卖问题: update auction_auctions set quantity = quantity-#count# where auction_id = #itemId# and quantity>=#count#
martos

引用来自“zgw06629”的评论

一个疑问:
减少库存有必要用乐观锁吗?
update auction_auctions set
quantity = #inQuantity#
where auction_id = #itemId# and quantity = #dbQuantity#

直接
update auction_auctions set
quantity = quantity-#count#
where auction_id = #itemId#

这样不行吗?

引用来自“陶邦仁”的评论

必须得需要啊 乐观锁其实就是个MVCC,第二个SQL在两个减库存事务中未及时提交会导致超卖。
(前面的排版有问题,重新回复。) 改为这样是否可以解决超卖问题: update auction_auctions set quantity = quantity-#count# where auction_id = #itemId# and quantity>=#count#
陶邦仁

引用来自“zgw06629”的评论

一个疑问:
减少库存有必要用乐观锁吗?
update auction_auctions set
quantity = #inQuantity#
where auction_id = #itemId# and quantity = #dbQuantity#

直接
update auction_auctions set
quantity = quantity-#count#
where auction_id = #itemId#

这样不行吗?

引用来自“陶邦仁”的评论

必须得需要啊 乐观锁其实就是个MVCC,第二个SQL在两个减库存事务中未及时提交会导致超卖。

引用来自“martos”的评论

(前面的排版有问题,重新回复。) 改为这样是否可以解决超卖问题: update auction_auctions set quantity = quantity-#count# where auction_id = #itemId# and quantity>=#count#
这样也不可以 乐观锁的本质是保证在读写数据库时库存要强一致,这个SQL还是在两个减库存事务未及时提交会导致。比如:两个事务同时读取库存为10,但提交顺序有先后,第一个事务,库存由10-4=6,但未提交;第二个事务库存也是由10-3=7,提交;此时理论这两个事务都提交后库存剩余应为10-4-3=3,但是等第二个事务提交、第一个事务提交后,库存会变为6。可以理解下此场景。
martos

引用来自“zgw06629”的评论

一个疑问:
减少库存有必要用乐观锁吗?
update auction_auctions set
quantity = #inQuantity#
where auction_id = #itemId# and quantity = #dbQuantity#

直接
update auction_auctions set
quantity = quantity-#count#
where auction_id = #itemId#

这样不行吗?

引用来自“陶邦仁”的评论

必须得需要啊 乐观锁其实就是个MVCC,第二个SQL在两个减库存事务中未及时提交会导致超卖。

引用来自“martos”的评论

(前面的排版有问题,重新回复。) 改为这样是否可以解决超卖问题: update auction_auctions set quantity = quantity-#count# where auction_id = #itemId# and quantity>=#count#

引用来自“陶邦仁”的评论

这样也不可以 乐观锁的本质是保证在读写数据库时库存要强一致,这个SQL还是在两个减库存事务未及时提交会导致。比如:两个事务同时读取库存为10,但提交顺序有先后,第一个事务,库存由10-4=6,但未提交;第二个事务库存也是由10-3=7,提交;此时理论这两个事务都提交后库存剩余应为10-4-3=3,但是等第二个事务提交、第一个事务提交后,库存会变为6。可以理解下此场景。
这条sql语句应该是在DB中运行的吧,第1个事务运行后,假如还未提交,更新锁应该会阻塞第2个事务的读操作吧?
陶邦仁

引用来自“zgw06629”的评论

一个疑问:
减少库存有必要用乐观锁吗?
update auction_auctions set
quantity = #inQuantity#
where auction_id = #itemId# and quantity = #dbQuantity#

直接
update auction_auctions set
quantity = quantity-#count#
where auction_id = #itemId#

这样不行吗?

引用来自“陶邦仁”的评论

必须得需要啊 乐观锁其实就是个MVCC,第二个SQL在两个减库存事务中未及时提交会导致超卖。

引用来自“martos”的评论

(前面的排版有问题,重新回复。) 改为这样是否可以解决超卖问题: update auction_auctions set quantity = quantity-#count# where auction_id = #itemId# and quantity>=#count#

引用来自“陶邦仁”的评论

这样也不可以 乐观锁的本质是保证在读写数据库时库存要强一致,这个SQL还是在两个减库存事务未及时提交会导致。比如:两个事务同时读取库存为10,但提交顺序有先后,第一个事务,库存由10-4=6,但未提交;第二个事务库存也是由10-3=7,提交;此时理论这两个事务都提交后库存剩余应为10-4-3=3,但是等第二个事务提交、第一个事务提交后,库存会变为6。可以理解下此场景。

引用来自“martos”的评论

这条sql语句应该是在DB中运行的吧,第1个事务运行后,假如还未提交,更新锁应该会阻塞第2个事务的读操作吧?
对啊 更新锁等同于悲观锁,悲观锁会阻塞并发,而乐观锁会更宽容些。
martos

引用来自“zgw06629”的评论

一个疑问:
减少库存有必要用乐观锁吗?
update auction_auctions set
quantity = #inQuantity#
where auction_id = #itemId# and quantity = #dbQuantity#

直接
update auction_auctions set
quantity = quantity-#count#
where auction_id = #itemId#

这样不行吗?

引用来自“陶邦仁”的评论

必须得需要啊 乐观锁其实就是个MVCC,第二个SQL在两个减库存事务中未及时提交会导致超卖。

引用来自“martos”的评论

(前面的排版有问题,重新回复。) 改为这样是否可以解决超卖问题: update auction_auctions set quantity = quantity-#count# where auction_id = #itemId# and quantity>=#count#

引用来自“陶邦仁”的评论

这样也不可以 乐观锁的本质是保证在读写数据库时库存要强一致,这个SQL还是在两个减库存事务未及时提交会导致。比如:两个事务同时读取库存为10,但提交顺序有先后,第一个事务,库存由10-4=6,但未提交;第二个事务库存也是由10-3=7,提交;此时理论这两个事务都提交后库存剩余应为10-4-3=3,但是等第二个事务提交、第一个事务提交后,库存会变为6。可以理解下此场景。

引用来自“martos”的评论

这条sql语句应该是在DB中运行的吧,第1个事务运行后,假如还未提交,更新锁应该会阻塞第2个事务的读操作吧?

引用来自“陶邦仁”的评论

对啊 更新锁等同于悲观锁,悲观锁会阻塞并发,而乐观锁会更宽容些。
但是,假如第1个事务运行后但未提交,即使你是使用乐观锁,应该也会阻塞第二个事务的更新操作吧?
×
陶邦仁
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥2 ¥5
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: