首先這是個很棒的問題。這個問題本身其實超出了多線程的討論范圍，因為你考慮的場景是用集群服務器來工作，多線程的討論范圍應該是在一個物理CPU內。但是這真的是一個很好的問題，我很想嘗試回答一下。

需要聲明的是我的回答是我個人的思考，不代表什么正確答案之類的東西，僅供你參考。

一個集群需要互斥的訪問共享資源，那么集群間是需要通信的，通信有一個中心節點我們稱之為Master, 真正負責處理業務邏輯的節點我們稱之為Slave。通常Master將資源指定給某一個Slave來處理，選取特定Slave需要使用投票算法。熱的燙手的Hadoop就是這樣一種模式。但僅僅是這樣我覺得還不足以回答你得疑問，我們如何保證資源被正確的分配？比如10本書本正確分配給是個訂單（假設每單買一本），剩余數量是0時不會繼續銷售。首先看電商的處理方式，他們其實降低了難度，因為并不是實時銷售的，你在電商購物時會注意到提交訂單后會受到郵件說訂單成功受收到，正在受理。后續他們會審批的啊，審批通過了才郵件告訴你訂單受理成功正在出庫。

基于以上，我想你感興趣的是另外一種場景，12306有沒有？12306是實時銷售的例子，這種場景解決方案一種是將真正減庫存的地方串行化處理，如果你得峰值壓力不是特大，這應該沒問題，不就相當于單線程嘛。另一種方案是加鎖，在數據庫表的行上加鎖，可以是數據庫提供的鎖，也可以是業務模擬的鎖（比如一個叫lock的表，插入一行記錄標示摸個資源被鎖定了）。需要說明的是直接用數據庫提供的鎖是有風險的，要嗎性能降低的什么迅猛，要么搞成死鎖，要再嚴重把數據庫搞壞了就不好了。我真的聽說過某省的煙草局項目因為數據庫的鎖把整個生產環境搞得無法恢復的案例。

好了個人觀點，希望能到你。