首先这是个很棒的问题。这个问题本身其实超出了多线程的讨论范围，因为你考虑的场景是用集群服务器来工作，多线程的讨论范围应该是在一个物理CPU内。但是这真的是一个很好的问题，我很想尝试回答一下。

需要声明的是我的回答是我个人的思考，不代表什么正确答案之类的东西，仅供你参考。

一个集群需要互斥的访问共享资源，那么集群间是需要通信的，通信有一个中心节点我们称之为Master, 真正负责处理业务逻辑的节点我们称之为Slave。通常Master将资源指定给某一个Slave来处理，选取特定Slave需要使用投票算法。热的烫手的Hadoop就是这样一种模式。但仅仅是这样我觉得还不足以回答你得疑问，我们如何保证资源被正确的分配？比如10本书本正确分配给是个订单（假设每单买一本），剩余数量是0时不会继续销售。首先看电商的处理方式，他们其实降低了难度，因为并不是实时销售的，你在电商购物时会注意到提交订单后会受到邮件说订单成功受收到，正在受理。后续他们会审批的啊，审批通过了才邮件告诉你订单受理成功正在出库。

基于以上，我想你感兴趣的是另外一种场景，12306有没有？12306是实时销售的例子，这种场景解决方案一种是将真正减库存的地方串行化处理，如果你得峰值压力不是特大，这应该没问题，不就相当于单线程嘛。另一种方案是加锁，在数据库表的行上加锁，可以是数据库提供的锁，也可以是业务模拟的锁（比如一个叫lock的表，插入一行记录标示摸个资源被锁定了）。需要说明的是直接用数据库提供的锁是有风险的，要吗性能降低的什么迅猛，要么搞成死锁，要再严重把数据库搞坏了就不好了。我真的听说过某省的烟草局项目因为数据库的锁把整个生产环境搞得无法恢复的案例。

好了个人观点，希望能到你。