网店的库存同步一般是怎么高效实现的? 如何防止超卖的情况?

[u010649781]

假如一件商品, 可以卖的数量为2000, 有500或者更多的用户去购买该商品,
那商品的库存才如何才能高效同步?
如果每下一个订单,就锁定一次库存,把库存数减1,效率会不高,
电子商务网站一般是如何实现的?

[oh_Maxy]

算是安全性与性能的一个折中吧~

[逃业新尘]

人数太多，确实需要锁定来进行同步，这是无可厚非的，关键你是怎么利用同步来更高效实现库存管理.除非你想不用同步呵呵。

[「已注销」]

引用 7 楼 oh_Maxy 的回复:

算是安全性与性能的一个折中吧~

我没有理解你的思路~~~

[oh_Maxy]

引用 8 楼 andan14 的回复:

引用 7 楼 oh_Maxy 的回复:

算是安全性与性能的一个折中吧~

我没有理解你的思路~~~

就是一个分流的思想，类似火车票代售点的处理模式：将总量分成n个队列，这样就将所有人竞争一个锁，转化为竞争n个锁，效率会高些。

[「已注销」]

引用 9 楼 oh_Maxy 的回复:

引用 8 楼 andan14 的回复:

[quote=引用 7 楼 oh_Maxy 的回复:] 算是安全性与性能的一个折中吧~

我没有理解你的思路~~~

就是一个分流的思想，类似火车票代售点的处理模式：将总量分成n个队列，这样就将所有人竞争一个锁，转化为竞争n个锁，效率会高些。[/quote] 想法真的很棒,那我们来谈论下数据库的实现,在数据库中 库存应该只是一张表中的某个数据,在修改的时候是应该会加上乐观锁的,但是按你的想法是需要将一个数据化分成2000个数据吧,然后都在加上锁 ，是吗？

[leeyeefeng2004]

引用 11 楼 oh_Maxy 的回复:

引用 10 楼 andan14 的回复:

[quote=引用 9 楼 oh_Maxy 的回复:] [quote=引用 8 楼 andan14 的回复:] [quote=引用 7 楼 oh_Maxy 的回复:] 算是安全性与性能的一个折中吧~

我没有理解你的思路~~~

就是一个分流的思想，类似火车票代售点的处理模式：将总量分成n个队列，这样就将所有人竞争一个锁，转化为竞争n个锁，效率会高些。[/quote] 想法真的很棒,那我们来谈论下数据库的实现,在数据库中 库存应该只是一张表中的某个数据,在修改的时候是应该会加上乐观锁的,但是按你的想法是需要将一个数据化分成2000个数据吧,然后都在加上锁 ，是吗？[/quote] 查询的话，一次性查出来（此时串行），然后分流处理（此时并发）。后面操作的时候按主键操作，速度会很快的。如果数据量太大，或者数据库性能差，可以考虑互斥操作数据库（最好依赖数据库性能）。[/quote] 具体如何实现！大神！

[「已注销」]

引用 12 楼 leeyeefeng2004 的回复:

引用 11 楼 oh_Maxy 的回复:

[quote=引用 10 楼 andan14 的回复:] [quote=引用 9 楼 oh_Maxy 的回复:] [quote=引用 8 楼 andan14 的回复:] [quote=引用 7 楼 oh_Maxy 的回复:] 算是安全性与性能的一个折中吧~

我没有理解你的思路~~~

就是一个分流的思想，类似火车票代售点的处理模式：将总量分成n个队列，这样就将所有人竞争一个锁，转化为竞争n个锁，效率会高些。[/quote] 想法真的很棒,那我们来谈论下数据库的实现,在数据库中 库存应该只是一张表中的某个数据,在修改的时候是应该会加上乐观锁的,但是按你的想法是需要将一个数据化分成2000个数据吧,然后都在加上锁 ，是吗？[/quote] 查询的话，一次性查出来（此时串行），然后分流处理（此时并发）。后面操作的时候按主键操作，速度会很快的。如果数据量太大，或者数据库性能差，可以考虑互斥操作数据库（最好依赖数据库性能）。[/quote] 具体如何实现！大神！[/quote] 不大喜欢大神这个词语,哈哈哈 ！

[oh_Maxy]

引用 12 楼 leeyeefeng2004 的回复:

引用 11 楼 oh_Maxy 的回复:

[quote=引用 10 楼 andan14 的回复:] [quote=引用 9 楼 oh_Maxy 的回复:] [quote=引用 8 楼 andan14 的回复:] [quote=引用 7 楼 oh_Maxy 的回复:] 算是安全性与性能的一个折中吧~

我没有理解你的思路~~~

就是一个分流的思想，类似火车票代售点的处理模式：将总量分成n个队列，这样就将所有人竞争一个锁，转化为竞争n个锁，效率会高些。[/quote] 想法真的很棒,那我们来谈论下数据库的实现,在数据库中 库存应该只是一张表中的某个数据,在修改的时候是应该会加上乐观锁的,但是按你的想法是需要将一个数据化分成2000个数据吧,然后都在加上锁 ，是吗？[/quote] 查询的话，一次性查出来（此时串行），然后分流处理（此时并发）。后面操作的时候按主键操作，速度会很快的。如果数据量太大，或者数据库性能差，可以考虑互斥操作数据库（最好依赖数据库性能）。[/quote] 具体如何实现！大神！[/quote] 不敢当。。只是恰好有这么个思路，抛砖引玉而已。 具体实现也都是心里瞎琢磨的，就不献丑了。

[oh_Maxy]

引用 10 楼 andan14 的回复:

引用 9 楼 oh_Maxy 的回复:

[quote=引用 8 楼 andan14 的回复:] [quote=引用 7 楼 oh_Maxy 的回复:] 算是安全性与性能的一个折中吧~

我没有理解你的思路~~~

就是一个分流的思想，类似火车票代售点的处理模式：将总量分成n个队列，这样就将所有人竞争一个锁，转化为竞争n个锁，效率会高些。[/quote] 想法真的很棒,那我们来谈论下数据库的实现,在数据库中 库存应该只是一张表中的某个数据,在修改的时候是应该会加上乐观锁的,但是按你的想法是需要将一个数据化分成2000个数据吧,然后都在加上锁 ，是吗？[/quote] 查询的话，一次性查出来（此时串行），然后分流处理（此时并发）。后面操作的时候按主键操作，速度会很快的。如果数据量太大，或者数据库性能差，可以考虑互斥操作数据库（最好依赖数据库性能）。

[蓝海]

[sky663]

当你在对数据执行Update的时候，本身这个操作本身就是一个行级锁。也就是说，在同一事务内，先执行数量减1的update,不提交，再select ,如果select 返回了-1，说明超卖了。回滚事务，订单失败。否则提交嘛。 为什么还要搞那么多复杂的动作。

[sky663]

对同一个商品库存分为多份数据存储以现实并发的方式，个人认为不可取。会有很多问题搞出来，比如：这个商品的库存总数如何保持一致，会不会有这份数据用完了，另外的还没有使用的情况。 从性能上说：对数据库Update是免不了的，分成多份会增加它的数据索引量，或许为解决数据总量分配问题而用的额外的算法。所以我认为性能会降低。

[litiebiao2012]

集中式redis队列可以解决这个问题！

[wsxing008]

搞个memcached、、、、、

[hello_code_com]

mark

[疯筝飞]

同样mark一下

[yybjroam05]

队列+事务！完美搞定。

[猫神jdx]

2000个商品, 试试每次拿200个放进缓存,有人买的话,从缓存取,如果取完了,再去改数据库.每次去数据库拿,数据库库存就减少200,比每次都-1要好

[IFocusYou]

还是缓存吧。

[sweat89]

redis的计数。。