摘要
随着互联网业务规模持续扩张，秒杀抢购、在线票务、直播互动等业务场景会短时间涌入突增峰值流量。高并发场景下单纯依靠增加服务器实例无法稳定承载业务，极易引发响应时间飙升、服务资源耗尽、数据库瓶颈、缓存击穿、服务雪崩与数据不一致等连锁故障。本文结合本人参与的线上票务抢购系统项目，从缓存策略、异步处理、限流熔断降级、数据库优化、服务拆分、水平扩容六个维度，分析各类技术方案适用场景与取舍权衡，完整复盘性能瓶颈定位、方案选型、落地实施与指标验证全过程，总结高并发系统设计与性能优化的实践经验。
一、项目概述
本人参与开发维护的线上票务抢购系统，核心业务为热门演出门票限时抢购。业务流量特征为：日常流量平稳，在开票瞬间产生瞬时流量尖峰，QPS 短时间暴涨数十倍；大量用户同时查询库存、提交订单，读请求远大于写请求；业务强约束库存不能超卖，订单数据需要最终一致性。
在项目中，我担任后端开发工程师，负责核心抢购链路开发、性能压测、瓶颈定位，参与架构方案评审，落地缓存改造、异步削峰、数据库优化、限流策略开发，配合运维完成集群扩容与线上验证。
二、高并发系统核心技术方案分析
2.1 缓存策略
适用场景：读多写少、数据变更频率低、允许短暂数据不一致的场景，例如商品 / 票务基础信息、库存预加载数据。 常用方案包含本地缓存、分布式 Redis 缓存，缓存模式分为 Cache Aside、Read/Write Through、Write Back。 取舍要点：缓存可以大幅降低数据库读压力，但引入缓存会带来缓存穿透、缓存击穿、缓存雪崩三大经典问题。需要权衡数据一致性与性能：强一致性场景不适合使用缓存；同时要考虑缓存过期策略、内存淘汰机制，热点 key 问题需要做分片、本地二级缓存兜底。如果缓存和数据库双写，要选择合适更新策略，在更新延迟和并发冲突之间做取舍。
2.2 异步处理
适用场景：不需要同步返回结果、流程耗时较长的业务逻辑，例如订单创建后的消息通知、日志记录、支付回调、库存扣减后的统计。 主流实现方案：消息队列（RocketMQ/Kafka）异步解耦，将同步长流程拆分为 “同步提交 + 后台异步消费”。 取舍要点：异步化可以削平流量峰值，将瞬时洪峰流量缓冲在消息队列，避免同步链路被压垮。代价是系统由同步变为异步，业务从强一致性转为最终一致性，需要额外处理消息丢失、重复消费、消息堆积问题，增加链路复杂度，需要设计重试、死信队列，业务需要适配异步状态通知。
2.3 限流、熔断与降级
适用场景：流量突增、依赖服务不稳定的场景，属于高并发系统的保护手段。
- 限流：控制请求进入系统的速率，保护系统不被打垮，常用令牌桶、漏桶算法；分为接口限流、用户维度限流。
- 熔断：当下游依赖服务失败率过高时，快速失败，停止继续调用下游，避免级联故障。
- 降级：流量高峰期，关闭非核心业务功能，保障核心链路可用，例如关闭订单详情推荐、用户积分查询等次要功能。 取舍要点：三者是系统的 “自保手段”，牺牲部分用户体验，保障核心业务可用。限流阈值、熔断阈值需要基于压测数据配置，阈值设置过高无法起到保护作用，过低会误杀正常流量；降级需要提前梳理业务优先级，区分核心链路和非核心链路。
2.4 数据库优化
适用场景：数据库成为读写瓶颈，所有业务最终数据落地依赖数据库。 优化手段：合理索引设计、SQL 语句优化、分库分表、读写分离、减少事务粒度。读压力大采用读写分离，写压力大、单表数据量大采用分库分表。 取舍要点：索引可以加速查询，但会降低写入性能；分库分表可以突破单库性能上限，但带来分布式事务、跨库查询、分片路由、数据迁移等复杂问题，提升开发运维成本。读写分离存在主从延迟，不能用于强一致性查询场景。事务范围尽可能缩小，长事务会占用锁资源，引发数据库锁等待。
2.5 服务拆分
适用场景：单体应用代码耦合，业务模块资源争抢，某一个非核心模块故障导致整个应用不可用。 将单体按照业务域拆分为独立微服务：库存服务、订单服务、用户服务、支付服务，服务之间通过 RPC 或者消息通信。 取舍要点：服务拆分实现故障隔离，便于单独扩容；但带来分布式系统复杂度，需要处理服务发现、远程调用异常、分布式事务、链路追踪问题。拆分粒度要合理，过度拆分带来大量跨服务调用，增加网络开销，反而降低性能。
2.6 水平扩容
适用场景：无状态服务，CPU、内存等资源瓶颈，通过增加实例节点提升整体承载能力。无状态 API 服务最适合水平扩容；有状态服务（数据库、缓存）扩容难度更高。 取舍要点：水平扩容是最简单直接的扩容手段，无状态服务可以快速增加机器提升 QPS 上限。但扩容存在上限：如果瓶颈在数据库这类有状态底层资源，单纯扩容应用节点无法解决问题；扩容同时需要配套负载均衡，注意会话、全局 ID 等有状态数据处理，扩容会增加运维成本。
三、项目性能优化复盘
3.1 瓶颈定位
项目初期为单体架构，票务抢购全链路同步执行。压测模拟开票峰值流量时，系统出现响应缓慢，部分请求超时。 通过压测工具、链路追踪、数据库慢查询日志、监控指标定位瓶颈：
- 大量并发请求直接查询 MySQL 库存，数据库 CPU 瞬间打满，成为最大瓶颈；大量相同库存查询请求打到数据库，出现缓存击穿风险。
- 下单链路同步执行库存扣减、订单写入、消息推送、积分记录，同步链路太长，RT 高。
- 缺少限流保护，压测流量无限制涌入，一旦数据库阻塞，请求堆积，引发服务雪崩。
- 单体应用所有模块共用资源，用户查询模块的流量波动会影响抢购核心链路。
3.2 方案权衡设计
针对定位到的瓶颈，进行多方案对比权衡：
- 库存数据：放弃每次查询数据库，提前将库存预加载到 Redis 分布式缓存，库存扣减在 Redis 执行，数据库异步落库；接受库存数据短暂不一致，通过定时任务对账，防止超卖。
- 下单流程改造：同步只保留 Redis 库存校验、订单号生成；订单持久化、消息通知等操作交给消息队列异步消费，缩短同步链路 RT。
- 增加多层防护：网关层限流 + 接口限流，基于用户 ID 做限流；引入熔断组件，当数据库、Redis 异常时触发熔断；高峰期关闭推荐、积分等非核心功能降级。
- 服务拆分：把库存、订单模块拆分为独立微服务，实现故障隔离；应用服务无状态化，支持水平扩容。
- 数据库：订单表做分表，优化索引；主库负责写，读请求走从库，做读写分离。 权衡取舍：为了扛住峰值流量，接受业务短暂最终一致性，牺牲部分非核心功能；评估分布式事务成本，不使用重的分布式事务方案，采用消息 + 对账补偿保证数据正确性。
3.3 优化实施步骤
- 缓存改造：开发 Redis 库存预加载逻辑，开票前预热库存；增加互斥锁防止缓存击穿，设置合理过期时间，增加缓存降级兜底。
- 链路异步化：接入消息队列，改造下单流程，将非核心逻辑异步化；开发消息消费、重试、死信处理逻辑。
- 限流熔断降级开发：网关接入限流组件，配置 QPS 阈值；开发熔断规则，梳理降级开关。
- 服务拆分：拆分库存、订单微服务，改造 RPC 调用，部署服务注册中心。
- 数据库优化：新建订单分表，优化 SQL，搭建主从架构，改造读请求路由到从库。
- 多轮压测验证：分阶段压测，从小流量逐步加压，观察监控指标，调整阈值，修复压测中暴露的缓存、消息堆积问题。
3.4 效果指标验证
优化前后对比：
- 系统可承载峰值 QPS：优化前只能承载约 300QPS，优化后稳定支撑 3000QPS 峰值流量。
- 接口平均响应时间：下单接口平均 RT 由原来的 800ms 下降至 120ms。
- 错误率：峰值场景接口错误率由 18% 降至 0.1% 以内。
- 稳定性：连续多轮压测，数据库 CPU 峰值控制在 60% 以内，不再出现数据库被打满的现象；峰值流量下核心抢购链路可用，非核心功能按需降级。
- 数据正确性：上线后对账程序校验，未出现库存超卖问题，保证业务数据准确。
四、总结
高并发系统设计不是单一技术的堆砌，而是在性能、一致性、开发成本、可用性之间不断权衡。本票务抢购项目通过缓存减轻数据库压力，异步消息削峰，限流熔断降级做系统保护，数据库读写分离与分表优化，配合服务拆分与水平扩容，解决了瞬时峰值流量带来的稳定性问题。高并发优化应当遵循先定位瓶颈，再选择方案；优先优化热点链路，并且所有方案必须经过压测验证；同时做好系统兜底保护，在极端流量下保障核心业务可用。
