一、系统架构分层设计：构建高可用底座

10Wqps级抢购系统的核心挑战在于瞬时流量洪峰与数据一致性的平衡。建议采用四层架构：

• 接入层：通过Nginx集群实现负载均衡，配置动态权重算法（如Least Connections），结合DNS轮询实现多地域接入。例如，某银行系统曾通过Nginx的upstream模块将请求均匀分配至4个机房，单机房QPS峰值控制在2.5W以内。
• 逻辑层：采用微服务架构，将抢购流程拆解为库存校验、订单生成、支付预扣等独立服务。使用Spring Cloud Gateway实现服务路由，通过Hystrix进行熔断降级。例如，库存服务可独立扩容，避免因订单服务故障导致整体崩溃。
• 数据层：主库采用分库分表（如ShardingSphere），按用户ID哈希分10库，每库10表，支撑百万级库存。缓存层使用Redis Cluster，配置主从复制+哨兵模式，确保99.9%可用性。
• 存储层：订单数据落盘至分布式文件系统（如Ceph），日志数据通过Kafka异步写入HDFS，实现冷热数据分离。

二、缓存策略：击破性能瓶颈

缓存是10Wqps系统的“第一道防线”，需解决缓存穿透、缓存击穿、缓存雪崩三大问题：

• 多级缓存：本地缓存（Caffeine）存储热点数据（如商品详情），分布式缓存（Redis）存储全局数据（如库存）。例如，某电商系统通过Caffeine的expireAfterWrite策略，将商品详情缓存TTL设为5分钟，减少90%的Redis访问。
• 互斥锁机制：对库存操作加分布式锁（Redisson），防止超卖。代码示例：

  RLock lock = redissonClient.getLock("stock_lock_" + productId);
  try {
    lock.lock(10, TimeUnit.SECONDS);
    if (stock > 0) {
        // 扣减库存
    }
  } finally {
    lock.unlock();
  }

• 异步预热：活动前1小时通过脚本将商品信息、库存预热至Redis，避免活动开始时缓存未命中导致的数据库压力。

三、数据库优化：保障数据强一致

数据库是系统的“最终防线”，需从SQL优化、事务控制、读写分离三方面突破：

• SQL优化：避免SELECT *，仅查询必要字段；为库存字段添加索引，使用EXPLAIN分析执行计划。例如，某系统通过将UPDATE stock SET count = count - 1 WHERE id = ?改为UPDATE stock SET count = count - 1, version = version + 1 WHERE id = ? AND version = ?，解决并发更新问题。
• 事务控制：采用TCC（Try-Confirm-Cancel）模式拆分长事务。例如，抢购流程拆分为：
  • Try阶段：预扣库存（软状态）
  • Confirm阶段：生成订单（硬状态）
  • Cancel阶段：回滚库存（异常时）
• 读写分离：主库负责写操作，从库通过MySQL Router实现读负载均衡。配置read_only=1防止误写，使用pt-online-schema-change工具在线修改表结构。

四、流量控制：平滑请求洪峰

流量控制需实现限流、降级、排队三重保护：

• 令牌桶算法：通过Guava RateLimiter限制单个用户QPS（如每秒5次），防止机器人刷单。代码示例：

  RateLimiter limiter = RateLimiter.create(5.0); // 每秒5个令牌
  if (limiter.tryAcquire()) {
    // 处理请求
  } else {
    // 返回429状态码
  }

• 熔断降级：当库存服务RT超过500ms时，Hystrix自动切换至降级逻辑（如返回“系统繁忙”）。配置circuitBreaker.requestVolumeThreshold=20，即20次请求中50%失败时触发熔断。
• 排队机制：对超卖风险高的商品启用排队队列（如Redis List），用户请求先入队，后端按顺序处理。例如，某银行系统通过排队将瞬时10Wqps降为平稳的2Wqps。

五、异步处理：解耦系统依赖

异步化是提升系统吞吐量的关键，需从消息队列、任务调度、事件驱动三方面设计：

• 消息队列：使用RocketMQ实现订单生成与支付的解耦。生产者发送OrderCreateEvent消息，消费者异步处理支付、通知等逻辑。配置sendMsgTimeout=3s，避免消息发送阻塞。
• 任务调度：通过Elastic-Job实现定时任务（如活动结束后清理未支付订单）。配置shardingTotalCount=3，将任务分片至3个节点并行执行。
• 事件驱动：基于Spring Event发布领域事件（如StockChangedEvent），监听器异步更新缓存、发送短信等。例如，库存变更后触发缓存更新，避免同步调用导致的性能下降。

六、监控与预警：实时掌控系统状态

监控是系统稳定的“眼睛”，需构建全链路监控、异常告警、容量预测体系：

• 全链路监控：通过SkyWalking追踪请求链路，分析耗时分布。例如，某系统通过链路追踪发现数据库查询占60%时间，优化后TPS提升3倍。
• 异常告警：配置Prometheus+Alertmanager，对CPU使用率（>80%）、内存泄漏（>90%）、错误率（>5%）等指标告警。例如，当Redis响应时间超过100ms时，自动触发扩容脚本。
• 容量预测：基于历史数据（如前3次活动QPS）使用ARIMA模型预测本次流量，提前1周完成资源扩容。例如，某系统通过预测将服务器从20台增至50台，成功扛住12Wqps。

实战经验：从0到1构建10Wqps系统

某银行曾面临类似挑战：双十一预约抢购活动预计10Wqps，但原有系统仅支持1Wqps。通过以下步骤实现突破：

1. 压测与瓶颈定位：使用JMeter模拟5Wqps压力，发现数据库连接池耗尽、缓存穿透严重。
2. 架构重构：引入Redis集群、分库分表、异步任务队列，将系统TPS从1.2K提升至8K。
3. 渐进式扩容：活动前3天逐步增加服务器，最终通过50台ECS+20节点Redis集群扛住11Wqps。
4. 应急预案：准备降级页面、备用数据库、CDN回源策略，确保极端情况下系统可降级运行。

结语：技术之外的思考

10Wqps系统不仅是技术挑战，更是业务理解、团队协作、应急能力的综合考验。例如，需与产品经理明确“超卖后如何补偿用户”，与运维团队制定“故障时快速回滚”流程，与安全团队防范“DDoS攻击”。最终，系统的稳定运行源于对细节的极致追求与对风险的充分预判。