电商高并发系统架构实战：缓存、消息队列与存储选型

1. 项目背景与核心挑战

去年双十一期间，我们团队负责的淘客APP在流量高峰期出现了严重的系统崩溃。当时每秒订单量突破5万，数据库CPU直接飙到100%，整个交易链路瘫痪了近20分钟。这次事故让我深刻意识到：在电商促销场景下，技术选型直接决定了系统的生死存亡。

淘客类应用的技术架构有三个致命痛点：

• 瞬时高并发：大促时流量可能是平时的100倍
• 数据强一致性：佣金结算差1分钱都会引发客诉
• 复杂业务逻辑：优惠计算、分佣规则、风控策略相互嵌套

经过半年重构，我们最终基于Java生态搭建了新一代系统。本文将重点分享缓存、消息队列和存储三大核心组件的选型对比，包含实际压测数据和踩坑经验。

2. 缓存方案选型：Redis vs Caffeine

2.1 需求场景分析

淘客APP的缓存主要服务于三类场景：

1. 商品详情页：需要承受最高10W QPS的读取压力
2. 用户会话信息：要求毫秒级响应且不能出现雪崩
3. 佣金规则：需要支持复杂数据结构存储

2.2 Redis实战配置

我们最终选择Redis 6.2作为主缓存，关键配置如下：

yaml复制spring:
  redis:
    lettuce:
      pool:
        max-active: 200
        max-idle: 50
        min-idle: 10
    timeout: 300ms
    cluster:
      nodes: 10.0.0.1:6379,10.0.0.2:6379

性能优化点：

• 使用Hash结构存储商品详情，相比String节省40%内存
• 采用Lua脚本实现原子化佣金计算
• 热点数据采用多级缓存策略（后面会详述）

踩坑记录：曾经因为没设置合理的连接超时时间，导致线程池被打满。建议timeout不要超过500ms

2.3 Caffeine本地缓存补偿

在高并发场景下，我们通过Caffeine构建了二级缓存：

java复制LoadingCache<String, Product> cache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(5, TimeUnit.MINUTES)
    .refreshAfterWrite(1, TimeUnit.MINUTES)
    .build(key -> productDao.get(key));

选型对比表：

3. 消息队列选型：RocketMQ vs Kafka

3.1 业务消息类型

• 订单消息：要求绝对不丢失（如用户下单事件）
• 日志消息：允许少量丢失但需要高吞吐（如用户行为日志）
• 延迟消息：需要精确时间控制（如15天后结算佣金）

3.2 RocketMQ核心配置

java复制// 生产者配置
DefaultMQProducer producer = new DefaultMQProducer("PID_ORDER");
producer.setNamesrvAddr("mq1:9876;mq2:9876");
producer.setRetryTimesWhenSendFailed(3);
producer.start();

// 消费者配置
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("CID_ORDER");
consumer.setConsumeThreadMin(20);
consumer.setConsumeThreadMax(64);

关键特性：

• 事务消息实现分布式事务
• 消息轨迹追踪功能
• 支持18个延迟级别（从1s到2h）

3.3 Kafka性能调优

针对日志类消息，我们使用Kafka并做了以下优化：

• 调整batch.size=16384和linger.ms=20提升吞吐
• 采用snappy压缩节省带宽
• 分区数设置为CPU核数的2倍

压测数据对比：

4. 存储方案选型：MySQL vs TiDB

4.1 分库分表实践

MySQL采用ShardingSphere实现水平分片：

sql复制# 订单表按用户ID分片
CREATE TABLE `t_order_0` (
  `id` bigint NOT NULL COMMENT '包含用户ID哈希值',
  `user_id` bigint NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

分片策略：

• 用户表：user_id % 16
• 订单表：order_id % 64
• 佣金表：按商家ID范围分片

4.2 TiDB分布式方案

对于需要跨分片查询的业务，我们引入TiDB 5.0：

sql复制-- 创建分区表
CREATE TABLE `t_settlement` (
  `id` BIGINT AUTO_RANDOM,
  `amount` DECIMAL(18,2),
  PRIMARY KEY (`id`)
) PARTITION BY RANGE (id) (
  PARTITION p0 VALUES LESS THAN (1000000),
  PARTITION p1 VALUES LESS THAN (2000000)
);

性能对比：

5. 架构设计中的隐藏技巧

5.1 缓存击穿防护方案

采用双重检查锁+异步加载机制：

java复制public Product getProduct(String id) {
    // 第一层检查
    Product product = redis.get(id); 
    if (product == null) {
        synchronized (this) {
            // 第二层检查
            product = redis.get(id);
            if (product == null) {
                product = loadFromDB(id);
                // 异步更新缓存
                executor.submit(() -> redis.setex(id, 3600, product));
            }
        }
    }
    return product;
}

5.2 消息堆积处理预案

当RocketMQ出现堆积时，我们采用三级处理策略：

1. 自动扩容：监控到堆积超过1W时自动增加消费者实例
2. 降级处理：非核心消息转为异步批处理
3. 紧急通道：启动备用消费者组并行消费

5.3 分布式ID生成方案

综合性能考虑，我们最终选择改良版Snowflake：

code复制0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000

调整了workerId的分配策略，通过ZK动态分配避免冲突。

6. 性能压测数据实录

在8核32G的物理机上进行的对比测试：

缓存层测试：

• Redis集群：12W QPS时平均延迟8ms
• Caffeine：150W QPS时平均延迟0.3ms

消息队列测试：

• RocketMQ：单Topic 15W TPS时磁盘IO使用率75%
• Kafka：同等配置下达到28W TPS

数据库测试：

• MySQL：分片后写入峰值1.2W TPS
• TiDB：3节点集群写入峰值2.8W TPS

所有测试数据均通过Grafana监控采集，JMeter施加压力。