到底什么业务场景非要用分布式锁不可？

[回锅鱼]

最近有个疑问非常的困扰我，我会做分布式锁，redis的，zk的等等，不过我就想问下到底什么场景非要用分布式锁不可，网上总拿什么库存超卖举例，可是明明update where条件里面加个where 库存 > 购买数量 就能解决的事情为什么非要用锁，再不济用异步队列做也能保障串行运行吧。还有说什么解决业务层幂等性；解决 MQ 消费端多次接受同一消息；多台机器同时执行定时任务等，这些也不是非要用分布式锁来做吧，大把的解决方案，明明都说高并发，不是更应该避免使用锁么？请大佬们解决下疑惑，魔怔了

[Stephen_112]

超卖问题不就很简单易懂的让你了解为什么要做这个了么？并发的时候那同时请求，不就是1个东西俩个人要买，那库存对于任何一个人来说都是够的，那么没有锁不就俩个人都能卖给了。

[回锅鱼]

引用 2 楼 Stephen_112 的回复:

超卖问题不就很简单易懂的让你了解为什么要做这个了么？并发的时候那同时请求，不就是1个东西俩个人要买，那库存对于任何一个人来说都是够的，那么没有锁不就俩个人都能卖给了。

用这个业务举例可以，但是你解决超卖用锁么？update的操作本来就是原子的，两个人买一个，where里面加上库存>购买数量，也只会一个执行成功，一个执行失败的，判断的是影响行数，这怎么会超卖呢？

[Stephen_112]

引用 4 楼 回锅鱼 的回复:

[quote=引用 2 楼 Stephen_112 的回复:]超卖问题不就很简单易懂的让你了解为什么要做这个了么？并发的时候那同时请求，不就是1个东西俩个人要买，那库存对于任何一个人来说都是够的，那么没有锁不就俩个人都能卖给了。

用这个业务举例可以，但是你解决超卖用锁么？update的操作本来就是原子的，两个人买一个，where里面加上库存>购买数量，也只会一个执行成功，一个执行失败的，判断的是影响行数，这怎么会超卖呢？[/quote] 啥叫分布式？那不就是多个数据库么？你的sql只能在你本身的数据库下保证，那分布式了以后不就存在了可以update成功的时候了么

[回锅鱼]

引用 5 楼 Stephen_112 的回复:

[quote=引用 4 楼 回锅鱼 的回复:][quote=引用 2 楼 Stephen_112 的回复:]超卖问题不就很简单易懂的让你了解为什么要做这个了么？并发的时候那同时请求，不就是1个东西俩个人要买，那库存对于任何一个人来说都是够的，那么没有锁不就俩个人都能卖给了。

用这个业务举例可以，但是你解决超卖用锁么？update的操作本来就是原子的，两个人买一个，where里面加上库存>购买数量，也只会一个执行成功，一个执行失败的，判断的是影响行数，这怎么会超卖呢？[/quote] 啥叫分布式？那不就是多个数据库么？你的sql只能在你本身的数据库下保证，那分布式了以后不就存在了可以update成功的时候了么[/quote] 分布式就是多个数据库？即便多个数据库，一般情况下同个商品的库存肯定路由到同一个数据库，数据表吧，即便你拆分库存到大区机房做dns的就近路由，那也不存在锁需要分布式锁吧，另外分布式也不等于多个数据库，数据库可以是主从集群或者分片集群，但是现在很多业务量不高的，也就是业务代码是分布式，数据库就是个主从集群而已，谈什么多个数据库，你具体说一下，举个实际例子，别这样就说多个数据库