1. 电商秒杀系统架构设计核心挑战
电商秒杀系统是典型的高并发、低延迟、强一致性要求的业务场景。面对618大促这类活动，我们需要处理的核心技术挑战主要集中在三个方面：
首先是瞬时流量洪峰。当某款热门商品（比如原价9999元的iPhone秒杀价1999元）开启抢购时，系统可能在1秒内涌入数万甚至数十万请求。这种流量特征与传统电商平稳的浏览型流量完全不同，需要特殊的架构设计。
其次是资源竞争问题。库存作为共享资源（比如限量1000台），所有请求都在竞争这个有限资源。如何保证库存扣减的原子性、如何防止超卖，是秒杀系统的核心命题。
最后是系统稳定性保障。在高并发压力下，任何薄弱环节都可能被放大成系统性风险——数据库连接池耗尽、缓存雪崩、消息队列积压等问题会像多米诺骨牌一样引发连锁反应。
2. 分布式锁技术选型与实践
2.1 为什么synchronized不够用
很多初级开发者首先想到的是使用Java原生的synchronized关键字。但在分布式环境下，这存在三个致命缺陷：
- 作用域局限：synchronized只在单个JVM进程内有效，而现代电商系统都是多实例部署
- 性能瓶颈：所有线程串行竞争同一把锁，QPS很难突破1000
- 缺乏容错：如果持有锁的线程崩溃，没有自动释放机制会导致死锁
java复制// 错误示范 - 集群环境下完全无效
public synchronized void deductStock(Long itemId) {
// 扣减库存逻辑
}
2.2 Redis分布式锁的正确实现
Redis的SETNX命令是实现分布式锁的常见方案，但要注意以下关键点：
- 原子性加锁：必须同时设置随机value和过期时间
- 防误删机制：只能删除自己加的锁（通过Lua脚本保证原子性）
- 锁续期：对于长时间操作，需要守护线程定期延长锁有效期
lua复制-- 正确的加锁脚本
if redis.call('setnx', KEYS[1], ARGV[1]) == 1 then
return redis.call('pexpire', KEYS[1], ARGV[2])
else
return 0
end
-- 安全的解锁脚本
if redis.call('get', KEYS[1]) == ARGV[1] then
return redis.call('del', KEYS[1])
else
return 0
end
关键提示：生产环境建议直接使用Redisson客户端，它内置了看门狗机制自动续期，解决了手动实现容易出错的问题。
2.3 Redis主从切换的锁失效问题
当使用Redis主从架构时，存在一个典型陷阱：如果主节点加锁成功后突然宕机，且锁信息还未同步到从节点，此时从节点升为主节点后，新的客户端也能成功加锁，导致锁失效。
解决方案优先级：
- 使用RedLock算法（需部署5个以上独立Redis实例）
- 开启min-replicas-to-write配置（确保锁信息同步到至少1个从节点）
- 改用ZooKeeper/etcd等CP系统实现分布式锁
3. 库存扣减的最终一致性保障
3.1 缓存与数据库的双写一致性
秒杀场景下，库存数据需要同时在Redis和数据库中维护。经典的做法是：
- 在Redis中预扣减库存（使用DECR命令保证原子性）
- 通过消息队列异步更新数据库
- 支付超时后通过定时任务恢复库存
java复制// Redis库存预扣减示例
Long remaining = redisTemplate.opsForValue().decrement("stock:" + itemId);
if (remaining < 0) {
// 库存不足，回滚操作
redisTemplate.opsForValue().increment("stock:" + itemId);
throw new BusinessException("库存不足");
}
// 发送MQ消息异步落库
rocketMQTemplate.asyncSend("stock-update-topic",
new StockUpdateMessage(itemId, -1),
new SendCallback() {...});
3.2 RocketMQ事务消息实践
为了保证本地事务和消息发送的原子性，需要使用RocketMQ的事务消息机制：
java复制// 事务消息生产者示例
TransactionSendResult sendResult = rocketMQTemplate.sendMessageInTransaction(
"stock-tx-group",
MessageBuilder.withPayload(stockMessage).build(),
null
);
// 本地事务执行器
@Override
public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
try {
// 执行本地事务（如创建订单）
orderService.createOrder(...);
return LocalTransactionState.COMMIT_MESSAGE;
} catch (Exception e) {
return LocalTransactionState.ROLLBACK_MESSAGE;
}
}
// 事务回查处理器
@Override
public LocalTransactionState checkLocalTransaction(MessageExt msg) {
// 根据业务ID查询事务状态
Order order = orderService.getByOrderNo(orderNo);
if (order != null) {
return LocalTransactionState.COMMIT_MESSAGE;
}
return LocalTransactionState.ROLLBACK_MESSAGE;
}
重要经验：回查逻辑必须实现幂等性，且不能依赖未提交的数据库事务状态。建议使用独立的幂等表记录事务状态。
4. 高并发场景下的缓存策略
4.1 缓存击穿防护方案
当热点key突然失效时，大量请求直接穿透到数据库，这就是缓存击穿。防护方案包括：
- 互斥锁重建：第一个请求加锁重建缓存，其他请求等待
- 逻辑过期：缓存永不过期，value中包含逻辑过期时间
- 多级缓存：本地缓存+分布式缓存组合使用
java复制// 逻辑过期实现示例
public ItemDetail getItemDetail(Long itemId) {
String key = "item:" + itemId;
String json = redisTemplate.opsForValue().get(key);
if (StringUtils.isEmpty(json)) {
return null;
}
ItemCache itemCache = JSON.parseObject(json, ItemCache.class);
if (itemCache.getExpireTime() > System.currentTimeMillis()) {
return itemCache.getData();
}
// 异步重建缓存
if (redisTemplate.opsForValue().setIfAbsent(key + ":mutex", "1", 30, TimeUnit.SECONDS)) {
executorService.submit(() -> {
try {
ItemDetail detail = loadFromDB(itemId);
redisTemplate.opsForValue().set(key,
new ItemCache(detail, System.currentTimeMillis() + 3600_000),
1, TimeUnit.DAYS);
} finally {
redisTemplate.delete(key + ":mutex");
}
});
}
return itemCache.getData();
}
4.2 布隆过滤器防穿透
对于不存在的商品ID查询，可以使用布隆过滤器前置拦截：
java复制// 布隆过滤器初始化
@PostConstruct
public void initBloomFilter() {
List<Long> allItemIds = itemMapper.getAllItemIds();
BloomFilter<Long> filter = BloomFilter.create(
Funnels.longFunnel(),
allItemIds.size(),
0.01);
allItemIds.forEach(filter::put);
bloomFilter = filter;
}
// 查询拦截
public ItemDetail getItemDetail(Long itemId) {
if (!bloomFilter.mightContain(itemId)) {
return null; // 绝对不存在
}
// 继续正常查询流程
...
}
5. 消息积压与系统容灾
5.1 RocketMQ消费能力弹性扩展
当消息积压达到百万级别时，可以采取以下措施：
- 动态增加消费者实例：无需重启服务，RocketMQ会自动重平衡队列分配
- 调整消费批次大小：适当增大每次拉取的消息数量
- 优化消费逻辑：将非核心操作异步化
properties复制# application.properties配置示例
rocketmq.consumer.consumeThreadMin=20
rocketmq.consumer.consumeThreadMax=64
rocketmq.consumer.pullBatchSize=32
5.2 全链路监控与告警
完善的监控体系包括：
- 基础资源监控：CPU、内存、磁盘、网络
- 中间件监控：Redis命中率、MQ积压量、DB连接数
- 业务指标监控：秒杀成功率、库存变化趋势
java复制// Prometheus自定义指标示例
@RestController
public class MetricsController {
private final Counter orderCounter = Counter.build()
.name("order_create_total")
.help("Total created orders")
.register();
@PostMapping("/order")
public void createOrder() {
// 业务逻辑
orderCounter.inc();
}
}
6. 实战经验与避坑指南
在多个大型秒杀项目实践中，我总结了以下关键经验：
- 预热是关键：提前将热点数据加载到缓存，使用压测工具模拟流量
- 限流不可少：在网关层实现令牌桶限流，保护下游系统
- 降级要有预案：当库存服务不可用时，可以降级到纯页面静态化
- 验证要全面：除了功能测试，更要关注分布式环境下的时序问题
典型问题排查案例：
- 某次大促出现超卖，原因是Redis事务中包含了非原子操作
- 支付回调处理慢，发现是同步调用了第三方征信查询接口
- 凌晨定时任务集中执行导致DB负载飙升，改为错峰执行
最后分享一个性能优化数据：通过将库存扣减的Redis操作从普通字符串改为Hash结构，配合Pipeline批量操作，某次618大促的峰值QPS从3万提升到了8万，同时CPU负载降低了40%。这提醒我们，在高并发场景下，数据结构和批量操作的优化往往能带来意想不到的收益。