在高并发场景下（如秒杀、抢购），保证库存扣减的正确性主要面临两个核心挑战：超卖（库存减为负数） 和 性能瓶颈（数据库锁竞争严重）。 解决这个问题的核心思路是：将同步的数据库操作转化为异步的消息处理，利用缓存抗压，利用数据库兜底。 以下是分层级的详细解决方案，从数据库层面到架构层面逐步优化： --- 第一层：数据库层面的保护（最后一道防线） 即使上层架构再复杂，数据库层必须保证数据的最终一致性和原子性。 1. 避免悲观锁 () 在并发量不高时可以使用，但在高并发下，悲观锁会导致严重的锁竞争，数据库连接池瞬间被打满，导致服务不可用。坚决不推荐在秒杀场景使用。 2. 使用乐观锁（CAS机制） 利用 SQL 语句本身的原子性进行更新。 方案 A（版本号机制）： 缺点： 高并发下冲突率极高，大量请求失败需要重试，浪费 CPU 资源。 方案 B（利用条件限制 - 推荐）： 直接在更新语句中判断库存是否大于 0。 优点： 利用 MySQL 行锁保证原子性，且不会出现负库存。 缺点： 依然直接打库，数据库抗不住每秒上万的 QPS。 --- 第二层：缓存层面的抗压（核心方案） 为了保护数据库，必须...
播面