一、高并发场景下的优惠券核销挑战

在电商大促、节日营销等高并发场景中，优惠券核销功能常面临以下性能瓶颈：

数据库锁竞争：传统方案中，核销操作需同时更新优惠券状态、用户余额及订单信息，涉及多表关联更新。在高并发下，行锁或表锁会导致大量线程阻塞，系统吞吐量急剧下降。
缓存穿透与雪崩：若依赖缓存存储优惠券状态，未命中缓存时直接查询数据库可能引发穿透；而缓存集中过期则可能导致雪崩，瞬间压垮数据库。
分布式事务一致性：跨服务（如订单、支付、优惠券）的核销操作需保证数据一致性，传统XA事务或TCC模式可能因网络延迟或节点故障导致性能损耗。
实时性要求：用户期望核销后立即看到优惠生效，延迟过高会影响用户体验，甚至导致超卖（如同一优惠券被多次核销）。

二、数据库优化：从锁竞争到无锁设计

1. 拆分核销流程为原子操作

将核销流程拆解为独立步骤，通过消息队列或本地事务表保证最终一致性。例如：

-- 1. 预占优惠券（状态更新为"已锁定"）
UPDATE coupon 
SET status = 'LOCKED', lock_time = NOW() 
WHERE id = ? AND status = 'UNUSED' AND expire_time > NOW();
-- 2. 核销成功后更新状态（异步处理）
UPDATE coupon 
SET status = 'USED', used_time = NOW() 
WHERE id = ? AND status = 'LOCKED';

通过状态机设计（UNUSED→LOCKED→USED），避免长时间持有数据库锁。

2. 数据库分片与读写分离

按用户ID或优惠券类型对数据库分片，分散写压力。例如：

用户表按user_id % 10分片，优惠券表同步分片。
写操作（核销）路由至主库，读操作（查询）路由至从库。

3. 索引优化

为高频查询字段（如coupon_id、user_id、status）建立复合索引，避免全表扫描。例如：

ALTER TABLE coupon ADD INDEX idx_user_status (user_id, status);

三、缓存策略：多级缓存与热点数据隔离

1. 多级缓存架构

采用本地缓存（Caffeine/Guava）+ 分布式缓存（Redis）的组合：

本地缓存：存储用户个人优惠券列表，减少Redis查询。
Redis集群：按优惠券ID哈希分片，存储全局状态。
布隆过滤器：预防缓存穿透，过滤无效优惠券ID查询。

2. 热点数据隔离

对高频核销的优惠券（如全网通用券）单独存储，采用更细粒度的分片（如按coupon_id % 100）。例如：

// Redis键设计示例
String hotCouponKey = "hot_coupon:" + (couponId % 100);

3. 异步刷新缓存

核销成功后，通过消息队列（Kafka/RocketMQ）异步更新缓存，避免同步操作阻塞主流程。伪代码示例：

// 核销服务
public void consumeCoupon(Long couponId, Long userId) {
    // 1. 数据库核销
    boolean success = couponDao.consume(couponId, userId);
    if (success) {
        // 2. 发送异步消息
        messageQueue.send("coupon_consume_topic", 
            new CouponConsumeEvent(couponId, userId));
    }
}
// 缓存消费者
@RabbitListener(queues = "coupon_consume_queue")
public void handleConsumeEvent(CouponConsumeEvent event) {
    // 更新Redis缓存
    redisTemplate.opsForValue().set("coupon:" + event.getCouponId(), 
        "USED", 24, TimeUnit.HOURS);
}

四、异步处理与削峰填谷

1. 消息队列削峰

通过消息队列缓冲核销请求，后端服务按处理能力消费。例如：

用户点击核销后，立即返回“处理中”，实际核销由异步任务完成。
设置队列最大长度，超过阈值时触发限流（如返回“系统繁忙”）。

2. 批量处理优化

对低实时性要求的操作（如统计核销次数），采用批量写入：

// 每100ms批量更新数据库
@Scheduled(fixedRate = 100)
public void batchUpdate() {
    List<CouponConsumeRecord> records = recordQueue.drain();
    if (!records.isEmpty()) {
        couponDao.batchUpdateStatus(records);
    }
}

五、分布式架构设计

1. 服务拆分与独立部署

将优惠券系统拆分为独立服务，避免与其他业务耦合。例如：

Coupon-Core：处理核销逻辑。
Coupon-Query：提供查询接口。
Coupon-Task：异步任务处理。

2. 分布式锁优化

使用Redisson或Zookeeper实现分布式锁，但需控制锁粒度：

// 按优惠券ID加锁，避免全局锁
RLock lock = redissonClient.getLock("coupon_lock:" + couponId);
try {
    lock.lock(10, TimeUnit.SECONDS);
    // 核销逻辑
} finally {
    lock.unlock();
}

3. 最终一致性方案

对跨服务操作，采用Saga模式或本地消息表：

Saga模式：将长事务拆分为多个本地事务，通过补偿操作回滚。
本地消息表：事务提交时写入消息表，异步任务将消息推送至MQ。

六、监控与容灾

1. 实时监控指标

监控以下关键指标：

核销成功率：成功数/总请求数。
平均延迟：从请求到核销完成的耗时。
数据库QPS：识别热点表。
缓存命中率：优化缓存策略。

2. 熔断与降级

集成Hystrix或Sentinel，当系统负载过高时：

返回缓存数据（如“优惠券状态未知”）。
排队等待（如“系统繁忙，请稍后重试”）。

3. 数据备份与恢复

定期备份优惠券数据，并测试恢复流程。例如：

每日全量备份至对象存储。
核销日志写入Kafka，支持按时间点恢复。

七、总结与建议

优先无锁设计：通过状态机+异步处理减少数据库锁。
缓存分层：本地缓存+分布式缓存+布隆过滤器组合防御。
异步削峰：消息队列缓冲请求，避免瞬时高峰。
分布式扩展：服务拆分+分库分表支撑横向扩展。
监控先行：实时指标驱动优化，提前发现瓶颈。

通过以上策略，优惠券系统可在高并发场景下保持稳定，同时兼顾性能与一致性。实际开发中，需根据业务特点（如优惠券类型、用户规模）调整方案，并通过压测验证效果。

优惠券系统从入门到精通（十四）：高并发场景下的优惠券核销优化策略