高并发

引子：一次价值百万的库存超卖事故 2024年双十一，凌晨00:05分，我的手机突然响起刺耳的告警声。 打开监控大盘，一行红色数字让我瞬间清醒：某爆款SKU超卖217件。这意味着我们已经卖出了比实际库存多217件商品，客户投诉、赔偿成本、品牌信任危机接踵而至。 这不是我第一次遇到超卖问题，但这次的损失格外惨重——该SKU是限量联名款，成本价就超过500元，217件的赔偿成本加上品牌损失，直接损失超过百万。 事后复盘，我们发现问题的根源：在分布式环境下，单机锁完全失效了。 10个服务实例同时处理来自Amazon、Shopify、天猫国际等多个渠道的订单，每个实例内部的synchronized锁只能保证单个JVM内的线程安全，但对于跨JVM的并发请求，库存扣减的原子性荡然无存。 这次事故后，我们用了整整一周时间，重构了整个库存中心的并发控制机制，将Redis分布式锁引入生产环境。三个月后，超卖率从5%降至0.1%，系统TPS从200提升到2000。 这篇文章，就是那次重构的完整技术总结。 问题本质：分布式环境下的并发控制 业务场景 我们的渠道共享库存中心需要服务10+电商平台，这些平台的订单会同时扣减同一个商品的库存： 时间 渠道 SKU-1001 操作 当前库存 00:01 Amazon -1 扣减 100 → 99 00:01 Shopify -2 扣减 99 → 97 00:01 天猫国际 -1 扣减 97 → 96 00:01 独立站 -3 扣减 96 → 93 在分布式部署下（假设5个服务实例），这些请求可能被不同的实例处理。如果没有正确的并发控制机制，就会出现经典的竞态条件（Race Condition）。 错误方案的代价 我们尝试过的失败方案： ❌ 方案1：数据库行锁 SELECT * FROM inventory WHERE sku = 'SKU-1001' FOR UPDATE; UPDATE inventory SET quantity = quantity - 1 WHERE sku = 'SKU-1001'; 问题： 性能极差：TPS<50，远低于业务需求 锁等待严重：高并发时大量请求超时 数据库压力大：成为系统瓶颈 ❌ 方案2：乐观锁（版本号） // 基于版本号的乐观锁 UPDATE inventory SET quantity = quantity - 1, version = version + 1 WHERE sku = 'SKU-1001' AND version = 10; 问题： ...

引子：一次价值百万的库存超卖事故 2024年双十一，凌晨00:05分，我的手机突然响起刺耳的告警声。 打开监控大盘，一行红色数字让我瞬间清醒：某爆款SKU超卖217件。这意味着我们已经卖出了比实际库存多217件商品，客户投诉、赔偿成本、品牌信任危机接踵而至。 这不是我第一次遇到超卖问题，但这次的损失格外惨重——该SKU是限量联名款，成本价就超过500元，217件的赔偿成本加上品牌损失，直接损失超过百万。 事后复盘，我们发现问题的根源：在分布式环境下，单机锁完全失效了。 10个服务实例同时处理来自Amazon、Shopify、天猫国际等多个渠道的订单，每个实例内部的synchronized锁只能保证单个JVM内的线程安全，但对于跨JVM的并发请求，库存扣减的原子性荡然无存。 这次事故后，我们用了整整一周时间，重构了整个库存中心的并发控制机制，将Redis分布式锁引入生产环境。三个月后，超卖率从5%降至0.1%，系统TPS从200提升到2000。 这篇文章，就是那次重构的完整技术总结。 问题本质：分布式环境下的并发控制 业务场景 我们的渠道共享库存中心需要服务10+电商平台，这些平台的订单会同时扣减同一个商品的库存： 时间 渠道 SKU-1001 操作 当前库存 00:01 Amazon -1 扣减 100 → 99 00:01 Shopify -2 扣减 99 → 97 00:01 天猫国际 -1 扣减 97 → 96 00:01 独立站 -3 扣减 96 → 93 在分布式部署下（假设5个服务实例），这些请求可能被不同的实例处理。如果没有正确的并发控制机制，就会出现经典的竞态条件（Race Condition）。 错误方案的代价 我们尝试过的失败方案： ❌ 方案1：数据库行锁 SELECT * FROM inventory WHERE sku = 'SKU-1001' FOR UPDATE; UPDATE inventory SET quantity = quantity - 1 WHERE sku = 'SKU-1001'; 问题： 性能极差：TPS<50，远低于业务需求 锁等待严重：高并发时大量请求超时 数据库压力大：成为系统瓶颈 ❌ 方案2：乐观锁（版本号） // 基于版本号的乐观锁 UPDATE inventory SET quantity = quantity - 1, version = version + 1 WHERE sku = 'SKU-1001' AND version = 10; 问题： ...

引子：一次价值百万的库存超卖事故 2024年双十一，凌晨00:05分，我的手机突然响起刺耳的告警声。 打开监控大盘，一行红色数字让我瞬间清醒：某爆款SKU超卖217件。这意味着我们已经卖出了比实际库存多217件商品，客户投诉、赔偿成本、品牌信任危机接踵而至。 这不是我第一次遇到超卖问题，但这次的损失格外惨重——该SKU是限量联名款，成本价就超过500元，217件的赔偿成本加上品牌损失，直接损失超过百万。 事后复盘，我们发现问题的根源：在分布式环境下，单机锁完全失效了。 10个服务实例同时处理来自Amazon、Shopify、天猫国际等多个渠道的订单，每个实例内部的synchronized锁只能保证单个JVM内的线程安全，但对于跨JVM的并发请求，库存扣减的原子性荡然无存。 这次事故后，我们用了整整一周时间，重构了整个库存中心的并发控制机制，将Redis分布式锁引入生产环境。三个月后，超卖率从5%降至0.1%，系统TPS从200提升到2000。 这篇文章，就是那次重构的完整技术总结。 问题本质：分布式环境下的并发控制 业务场景 我们的渠道共享库存中心需要服务10+电商平台，这些平台的订单会同时扣减同一个商品的库存： 时间 渠道 SKU-1001 操作 当前库存 00:01 Amazon -1 扣减 100 → 99 00:01 Shopify -2 扣减 99 → 97 00:01 天猫国际 -1 扣减 97 → 96 00:01 独立站 -3 扣减 96 → 93 在分布式部署下（假设5个服务实例），这些请求可能被不同的实例处理。如果没有正确的并发控制机制，就会出现经典的竞态条件（Race Condition）。 错误方案的代价 我们尝试过的失败方案： ❌ 方案1：数据库行锁 SELECT * FROM inventory WHERE sku = 'SKU-1001' FOR UPDATE; UPDATE inventory SET quantity = quantity - 1 WHERE sku = 'SKU-1001'; 问题： 性能极差：TPS<50，远低于业务需求 锁等待严重：高并发时大量请求超时 数据库压力大：成为系统瓶颈 ❌ 方案2：乐观锁（版本号） // 基于版本号的乐观锁 UPDATE inventory SET quantity = quantity - 1, version = version + 1 WHERE sku = 'SKU-1001' AND version = 10; 问题： ...