拼多多二面：高并發場景扣減商品庫存如何防止超賣？
數據庫扣減
我們先來看下通過數據庫方式去實現。
因為要防止它超賣，所以要先把庫存鎖住，避免庫存還剩最后一個時，多個線程同時去扣減成負數了。
圖片
但是這種方式顯而易見效率非常低下，因為這里加的悲觀鎖，讀請求也被阻塞了，我們知道大部分場景下都是讀多寫少，所以如何優化呢？
很快小白想到了，可以通過樂觀鎖的方式實現。
樂觀鎖：事務不會在讀取數據時加鎖，而是繼續執行后續操作，只有在提交數據時才會檢查數據是否已經被其他事務修改，通常通過 版本號或時間戳來實現。
我們可以給庫存這條記錄加一個版本號字段 version，在更新庫存時判斷版本號是否一致，這樣也不會阻塞讀請求。
UPDATE product_inventory
SET stock = stock - :quantity,
version = version + 1
WHERE product_id = :productId
AND version = :version;這種方式能滿足一般場景，但是假設在高并發的搶購活動下，當你壓測時發現 TPS 怎么也提不上來。
高并發場景下使用樂觀鎖，一是其他請求拿不到版本號導致線程一直自旋等待中，甚至會降低系統的性能。二是數據庫的性能瓶頸。
這時，你在想有沒有其他更好的方式呢？
Redis 扣減
既然數據庫無法滿足高并發性能，我們知道 Redis 單節點理論能支持幾萬級 TPS，而且我們還可以部署集群多節點，這樣肯定能滿足了吧。
Redis 如何實現庫存扣減呢？
很快，你想到了，Redis 不是有一個 INCRBY 的命令嗎？可以通過這個實現呀。
INCRBY product:1001:stock -10但很快，測試時你又發現了問題，在場景下，這個庫存會被扣成負數，這顯然是不能接受的。
那再加上鎖不就好了嗎，因為是是節點操作，我們想到通過加分布式鎖的方式。
圖片
同一時刻只有一個線程能獲取到鎖去執行扣減，這樣肯定不會超賣了，但這種方式因為只有一個線程能去扣減這個商品的庫存，顯然并發性能還有待提升。
我們可以不加鎖嗎？但判斷庫存是否大于 0 和扣減庫存是兩個指令，如何保證一致性呢？
Redis Lua 扣減
Lua：Redis 支持在服務器端執行 Lua 腳本時，腳本的所有操作都是原子執行的，即腳本中的所有命令要么全部成功，要么全部失敗。
我們可以通過 Lua 的原子性來實現，避免加鎖。
先獲取當前庫存，判斷是否足夠，如果足夠再進行扣減。
local stock = redis.call('get', KEYS[1]) -- 獲取當前庫存
if not stock then
return nil -- 如果沒有找到庫存，返回nil
end
if tonumber(stock) >= tonumber(ARGV[1]) then -- 如果庫存足夠
redis.call('decrby', KEYS[1], ARGV[1]) -- 扣減庫存
return tonumber(stock) - tonumber(ARGV[1]) -- 返回扣減后的庫存
else
return nil -- 庫存不足，返回nil
end如果這時老板看商品賣的很好，要后臺調增庫存怎么辦？
如果要調增庫存，為了防止多個線程同時調整庫存出現并發問題，這里要加分布式鎖，可以通過 SETNX 實現。
/**
* 增加庫存，使用分布式鎖確保并發安全
* @param productId 商品ID
* @param quantity 增加的數量
* @param lockValue 鎖的值，用于解鎖時進行驗證
* @param lockTimeout 鎖的超時時間
* @return 是否成功增加庫存
*/
public boolean increaseInventoryWithLock(String productId, int quantity, String lockValue, int lockTimeout) {
try (Jedis jedis = jedisPool.getResource()) {
// 獲取分布式鎖
String lockKey = "product_lock:" + productId;
boolean lockAcquired = acquireLock(jedis, lockKey, lockValue, lockTimeout);
if (lockAcquired) {
try {
// 增加庫存
jedis.incrBy("product:" + productId + ":stock", quantity);
return true;
} finally {
// 釋放鎖
releaseLock(jedis, lockKey, lockValue);
}
} else {
// 如果獲取不到鎖，可以返回 false 或進行重試等操作
return false;
}
}
}這樣，你想應該就萬無一失了吧。
但是，如果你的商品賣得非常好，Redis 單節點也扛不住了，針對這種熱點商品怎么辦呢？
Redis 庫存分片
莫慌，別忘了我們 Redis 是多節點集群部署的，我們如果把這個熱點商品庫存拆分到每個節點上不就解決了嗎。
怎么拆分呢？
假設我們 Redis 有 12 個節點，我們可以把商品庫存緩存 Key 再加個后綴 0，1，2....12 分布到每一個節點上，扣減時如果發現當前節點沒庫存了，再扣除下個緩存 key。
當然，如果每次都從節點 1 開始，熱點問題并沒有解決，我們可以設置一個隨機數組把順序打散，比如[1，2，......，12]，[2,12......,1]。
圖片
這樣避免了該熱點商品的所有請求都打到同一個節點上的問題了。
