Java高手進階：秒殺場景下的庫存一致性解決方案
秒殺活動作為電商平臺的重要營銷手段，對庫存管理的精確性提出了極高要求。防止超賣，即確保商品在秒殺過程中庫存不會被過度消耗，是秒殺功能實現的關鍵。本文將探討幾種防止超賣的經典方案。
1.悲觀鎖機制
悲觀鎖機制通過鎖定數據庫中的某行數據，確保在高并發情況下只有一個用戶可以修改庫存。在用戶請求秒殺時，數據庫會鎖定庫存行，直到操作完成后才釋放鎖。
優缺點
- 優點：強一致性保障，確保在高并發下不會出現超賣問題。
- 缺點：鎖的開銷較大，容易導致數據庫性能瓶頸。在高并發場景下，過多的悲觀鎖可能導致鎖等待和死鎖問題。
使用場景適用于對一致性要求極高，但并發量相對較小的場景。
Demo
@Mapper
public interface ProductMapper {
@Select("SELECT stock FROM products WHERE product_id = #{productId} FOR UPDATE")
Integer selectStockForUpdate(@Param("productId") int productId);
@Update("UPDATE products SET stock = stock - 1 WHERE product_id = #{productId}")
int updateStock(@Param("productId") int productId);
}
@Service
public class ProductService {
@Autowired
private ProductMapper productMapper;
@Transactional
public boolean seckill(int productId) {
Integer stock = productMapper.selectStockForUpdate(productId);
if (stock != null && stock > 0) {
productMapper.updateStock(productId);
return true; // 秒殺成功
} else {
return false; // 庫存不足
}
}
}2.樂觀鎖機制
樂觀鎖通常通過“版本號”機制來實現。在庫存表中增加一個version字段，每次更新庫存時，檢查version是否與上次讀取的一致，如果一致則更新庫存和version，如果不一致則說明庫存已經被其他用戶修改過，需要重新嘗試。
優缺點
- 優點：無需鎖表，對數據庫性能影響較小，適合中小規模并發。
- 缺點：并發過高時可能導致更新失敗頻繁，用戶體驗下降。在高并發場景下，樂觀鎖可能導致大量重試，增加系統負擔。
使用場景適合于高并發但沖突不頻繁的場景。
Demo
// 假設有一個Product實體類，包含stock和version字段
// 在Service層進行庫存更新操作
@Service
public class ProductService {
@Autowired
private ProductMapper productMapper;
@Transactional
public boolean updateStock(int productId, int version) {
Product product = productMapper.selectByPrimaryKey(productId);
if (product.getVersion() != version) {
return false; // 版本不匹配，更新失敗
}
product.setStock(product.getStock() - 1);
product.setVersion(product.getVersion() + 1);
productMapper.updateByPrimaryKey(product);
return true; // 更新成功
}
}3.分布式鎖
分布式鎖可以確保在多臺服務器上并發處理庫存時不會導致超賣。常用Redis來實現分布式鎖。當用戶請求秒殺時，先嘗試通過Redis獲得鎖，如果獲得鎖則執行扣減庫存操作，并釋放鎖；如果未獲得鎖則等待或重試。
優缺點
- 優點：適合大規模并發場景，鎖機制能夠確保多臺服務器在并發情況下安全修改庫存。
- 缺點：如果Redis出現故障，可能會影響鎖的管理和庫存的正確性。鎖的粒度要控制好，鎖的過大可能影響性能。在高并發場景下，分布式鎖可能導致網絡延遲和鎖競爭問題。
使用場景適用于高并發場景，特別是多臺服務器分布式部署時，對一致性要求較高。
Demo
@Service
public class SeckillService {
@Autowired
private RedisTemplate<String, Object> redisTemplate;
public boolean seckill(int productId) {
String lockKey = "lock:product:" + productId;
boolean lock = redisTemplate.opsForValue().setIfAbsent(lockKey, "locked", 5, TimeUnit.SECONDS);
if (lock) {
try {
String stockKey = "stock:" + productId;
Integer stock = (Integer) redisTemplate.opsForValue().get(stockKey);
if (stock != null && stock > 0) {
redisTemplate.opsForValue().decrement(stockKey);
return true; // 秒殺成功
} else {
return false; // 庫存不足
}
} finally {
redisTemplate.delete(lockKey); // 釋放鎖
}
} else {
return false; // 秒殺失敗，未獲得鎖
}
}
}4.庫存預減+異步處理
在用戶請求秒殺時，使用緩存進行庫存預減（即在用戶下單前就先減少庫存），然后通過異步隊列（如Kafka或RabbitMQ）將訂單請求發往后端進行異步處理。商品秒殺開始前，將商品庫存預先加載到Redis。當用戶請求秒殺時，先從Redis中預減庫存，將請求通過消息隊列發送到后端進行訂單處理和庫存的最終確認。如果訂單處理失敗（如支付失敗等），則通過異步任務將Redis中的庫存回補。
優缺點
- 優點：使用緩存大幅減少數據庫壓力，適合大規模并發場景。削峰填谷，利用消息隊列將訂單處理異步化，緩解高并發對數據庫的沖擊。
- 缺點：需要處理訂單失敗后的庫存回補，增加了系統復雜性。在極端情況下可能出現Redis庫存與數據庫庫存不一致的問題，需要通過補償機制來解決。同時，對緩存的可靠性和一致性要求較高。
使用場景適用于高并發場景，特別是需要減輕數據庫壓力時，對性能要求較高，但對一致性要求可以容忍一定延遲的場景。
Demo（僅展示庫存預減部分，異步處理部分需結合消息隊列實現）：
@Service
public class SeckillService {
@Autowired
private RedisTemplate<String, Object> redisTemplate;
public boolean preDecreaseStock(int productId) {
String stockKey = "stock:" + productId;
Integer stock = (Integer) redisTemplate.opsForValue().get(stockKey);
if (stock != null && stock > 0) {
redisTemplate.opsForValue().decrement(stockKey);
return true; // 庫存預減成功
} else {
return false; // 庫存不足
}
}
}5.小結
以上四種方案各有優劣，選擇合適的方法取決于業務需求和技術棧。在實際應用中，可以根據并發量、系統性能要求、一致性需求等因素綜合考慮選擇合適的方案。
