购物车加锁的问题

[hylarucoder]

收益良多, 先感谢贡献者们

在购物车模块中 是这么讲解的

购物车的最后一步是生成订单，这一步最要紧的是需要给购物车加锁，避免提交过程中数据被篡改，多说一句，很多人写的Redis分布式锁代码都存在缺陷，大家一定要注意原子性的问题，这类文章网络上很多不再赘述。

加锁成功之后，我们这里有多种做法，一种是按照DB涉及组织数据开始写表，这适用于业务量要求不大，比如订单每秒下单量不超过2000K的；那如果你的系统并发要求非常高怎么办？

其实也很简单，高性能的三大法宝之一：异步；我们提交的时候直接将数据快照写入MQ中，然后通过异步的方式进行消费处理，可以通过通过控制消费者的数量来提升处理能力。这种方法虽然性能提升，但是复杂度也会上升，大家需要根据自己的实际情况来选择。

问题是为何需要给购物车加锁?

1. 下单的时候如果提交了一个购物车的id, 那么不管是同步落单还是异步落单, 都会做一个全购物车的校验工作. 如果落单成功, 则清理掉购物车即可. 如果失败, 则购物车本身不用发生变化. 似乎不需要加锁便可以完成
2. 加锁是为了落单前不做任何校验吗?

[SUTNB]

@twocucao
个人拙见：
1.购物车校验是必须做的，除了购物车数据本身可能变化（比如多端操作，你女朋友在你下单前从另一端加了一个chanel包包），还有活动等价格信息也可能会有变化，比如提单瞬间活动时间到了，变回原价，这些都需要检验出来，并做拦截，提示用户，如果直接生成订单，用户体验是不太好的。
2.至于原文中的购物车锁，如果做了校验，确实可以不用加锁了，有任何变动都会提示用户，并且简单加锁是解决不了购物车数据变化这个问题的，必须进行校验，但是原文中的锁可以起到作用是防止极端情况下，一个购物车生成多笔订单，如果不考虑这个问题的话，不加锁也是可以的。

[chunpat]

2.至于原文中的购物车锁，如果做了校验，确实可以不用加锁了，有任何变动都会提示用户，并且简单加锁是解决不了购物车数据变化这个问题的，必须进行校验，但是原文中的锁可以起到作用是防止极端情况下，一个购物车生成多笔订单，如果不考虑这个问题的话，不加锁也是可以的。

加锁是为了校验的唯一性，假设校验a b c三个产品，你校验了a，还有b、c没校验，此时a的商品改了价格。那不就白校验了吗？

[TIGERB]

可以避免多端设备同时操作 比如网页和APP

[chunpat]

催更，23333☺☺☺ @TIGERB