---

1. 背景痛点：营销节点的系统瓶颈

每到双11、618这类大促节点，系统总会面临三大致命问题：

• 数据库被打爆：瞬时查询量激增200倍，MySQL主库CPU直接飙到100%
• 超卖问题频发：库存扣减出现负数的经典bug，技术群瞬间被运维报警淹没
• 服务雪崩：一个优惠券查询接口超时，导致整个订单服务链崩溃

去年我们系统在流量高峰期的表现：

1. 订单创建TPS峰值仅800，但实际需求是2万+
2. 平均响应时间从200ms劣化到8秒
3. 30%的请求因超时被丢弃

2. 技术选型：架构的十字路口

单体vs微服务的抉择：

• 单体架构：
• 开发简单但扩展性差
• 一个BUG可能导致全站不可用

• 适合初创公司快速迭代

• 微服务：

• 资源隔离性好
• 可针对订单服务单独扩容
• 需要完善的监控体系

我们最终选择Spring Cloud + Docker的组合，关键考虑：

1. 营销系统需要独立伸缩
2. 不同促销活动存在资源竞争
3. 故障隔离是刚需

3. 核心实现：事件驱动的异步架构

订单处理流程改造前后对比：

// 旧版同步处理（伪代码）
@PostMapping("/order")
public Result createOrder(OrderDTO dto) {
    // 1. 校验库存（同步调用）
    stockService.checkStock(dto.getSkuId()); 
    // 2. 扣减库存
    stockService.reduceStock(dto.getSkuId());
    // 3. 生成订单（数据库事务）
    return orderService.create(dto); 
}

新版异步方案：

1. 前端提交订单后立即返回排队中状态
2. 使用RabbitMQ实现三级消息缓冲：
3. 订单接收队列（内存队列）
4. 库存处理队列（持久化队列）
5. 物流通知队列（延迟队列）

核心代码片段：

// 订单事件生产者
@RestController
public class OrderController {
    @Autowired
    private RabbitTemplate rabbitTemplate;

    @PostMapping("/async-order")
    public Result createAsyncOrder(@Valid OrderDTO dto) {
        String msgId = UUID.randomUUID().toString();
        // 发送到订单队列（设置1分钟TTL）
        rabbitTemplate.convertAndSend(
            "order.exchange", 
            "order.create", 
            dto,
            message -> {
                message.getMessageProperties()
                    .setMessageId(msgId)
                    .setExpiration("60000");
                return message;
            });
        return Result.success(msgId);
    }
}

// 库存消费者
@Component
@RabbitListener(queues = "stock.queue")
public class StockConsumer {
    @Autowired
    private RedisTemplate<String, String> redisTemplate;

    @RabbitHandler
    public void handle(OrderDTO dto) {
        // 分布式锁防超卖
        String lockKey = "lock_sku_" + dto.getSkuId();
        Boolean locked = redisTemplate.opsForValue()
            .setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS);

        try {
            if (locked != null && locked) {
                // 实际库存操作
                stockService.reduceWithCAS(dto.getSkuId()); 
            }
        } finally {
            redisTemplate.delete(lockKey);
        }
    }
}

4. 性能保障三板斧

第一斧：缓存策略

• 使用Redis集群做多级缓存：
• 本地缓存（Caffeine）：存放静态配置
• 分布式缓存（Redis）：库存预热数据
• 持久层缓存（MySQL Buffer Pool）：热点订单

第二斧：熔断降级

Sentinel配置示例：

# 优惠券服务熔断规则
spring.cloud.sentinel:
  datasource:
    ds1:
      nacos:
        server-addr: 127.0.0.1:8848
        dataId: coupon-flow-rule
        ruleType: flow
  flow:
    rules:
      - resource: GET:/coupon/{id}
        count: 1000  # QPS阈值
        grade: 1     # 基于QPS限流
        strategy: 0  # 直接拒绝

第三斧：数据分片

订单表按用户ID分库分表：

/* 分片算法：user_id % 128 */
CREATE TABLE order_00 (
    id BIGINT PRIMARY KEY,
    user_id BIGINT,
    -- 其他字段
) ENGINE=InnoDB;

5. 避坑指南：血泪经验

消息堆积处理：

1. 监控队列深度：当积压超过1万条时触发报警
2. 动态增加消费者：通过K8s快速扩容Pod
3. 死信队列：处理3次仍失败的消息转入人工处理

分布式事务：

• 最终一致性方案：
• 本地消息表
• TCC模式（Try-Confirm-Cancel）
• 绝对避免的方案：
• XA两阶段提交（性能杀手）
• 同步阻塞调用

6. 未来优化方向

留给读者思考的问题：

1. 如何实现基于预测的弹性伸缩？能否利用历史流量数据训练模型？
2. Serverless架构是否适合营销系统？冷启动问题如何解决？
3. 在多云环境下如何保证数据同步的实时性？

这套架构已经在去年双11期间验证，核心指标：

• 订单处理峰值：23,456 TPS
• 平均响应时间：<500ms
• 资源成本节省：40%的云服务器支出

关键收获：高并发不是堆机器就能解决，合理的架构设计+精准的瓶颈定位才是王道。