亿级并发下的抢票系统架构：从DDD到微服务的实战解析

1. 抢票系统的业务挑战与技术痛点每年春运期间12306系统都要面对全球最严苛的高并发考验。2019年春运最高峰日点击量达到1495亿次相当于每个中国人当天点击了100多次。这种量级的并发请求如果直接打到数据库上就算是把阿里云所有服务器加起来也扛不住。我在参与某票务平台架构升级时发现抢票业务有几个特殊痛点首先是库存动态性比如北京到上海的高铁有1000个座位但系统需要支持任意两站间的组合售票北京-南京、天津-上海等这意味着库存计算不是简单的加减法而是需要实时计算区间重叠率。其次是状态复杂性一张票从查询、锁定、支付到出票要经历7-8个状态转换每个状态都要保证强一致性。最要命的是峰值不确定性当热门演唱会门票开售时瞬时流量可能是日常的10万倍。去年帮某平台做周杰伦演唱会抢票系统优化时我们监测到开票瞬间的QPS突破200万这相当于双11峰值流量的1/5但集中在短短3分钟内爆发。2. DDD的战略设计与领域建模2.1 事件风暴工作坊实践我们团队采用DDD方法论时会先组织业务、技术、产品三方进行事件风暴Event Storming。用便签纸把抢票流程中的所有领域事件贴满整面墙比如余票查询触发、座位锁定成功、支付超时释放库存等。这个过程会发现很多隐藏的业务规则比如某票务平台原来不知道改签操作实际上要先退票再购票这个隐性流程。通过分析这些事件我们识别出几个核心子域票务核心域处理车次、座位、票价等核心业务逻辑订单处理域管理订单状态机和支付流程风控子域负责防机器人和黄牛刷票通知子域处理短信、邮件等触达2.2 限界上下文划分技巧划分上下文边界时有个实用技巧看两个操作是否需要强一致性。比如扣减库存和生成订单必须在一个事务里完成这就应该放在同一个上下文而发送出票通知可以异步处理自然就划到另一个上下文。我们曾用上下文映射图梳理出30多个服务间的交互关系其中最关键的是票务核心域与订单域的协作。采用客户-供应商模式定义清晰的接口契约比如订单服务调用票务服务时必须通过/api/tickets/lock这个明确端点并遵循特定的参数规范。3. 微服务架构的战术落地3.1 服务拆分与数据隔离按照DDD划定的边界我们把系统拆分成多个微服务。这里有个血泪教训某次我们把用户服务和权限服务拆太细导致一次登录操作要跨5个服务调用反而拖垮性能。后来总结出服务粒度原则单个服务代码不超过3万行团队规模遵循两个披萨原则6-8人数据库事务边界就是服务边界对于票务这种强事务场景我们采用共享数据库独立Schema的折中方案。比如所有服务都用同一个MySQL集群但每个服务有自己专属的schema这样既保证跨服务查询效率又避免服务间直接操作对方表结构。3.2 分布式事务解决方案抢票最复杂的莫过于处理锁定座位→生成订单→支付成功这个分布式事务。我们对比过几种方案TCC模式开发成本高但性能最好。实际编码时要定义Try/Confirm/Cancel三个接口比如Try阶段先临时锁定座位Confirm才真正扣减库存。SAGA模式适合长事务通过事件驱动状态流转。每个步骤触发下一个事件失败时执行补偿操作。本地消息表最易实现但有延迟。我们在支付服务中建了个transaction_log表配合定时任务实现最终一致性。最终选择TCCSAGA混合方案对于核心的票务操作用TCC保证强一致边缘业务如通知服务用SAGA实现最终一致。实测下来在200万QPS下事务成功率保持在99.99%以上。4. 高并发场景下的关键技术4.1 多级缓存体系设计缓存设计不当会导致严重的库存超卖。我们构建了四级缓存防御客户端缓存静态车次信息缓存24小时CDN边缘缓存将余票查询结果缓存在全国30多个CDN节点Redis集群缓存采用Lua脚本实现原子化的库存扣减本地缓存使用Caffeine做JVM级缓存应对Redis抖动特别要注意缓存一致性问题。我们开发了缓存版本号机制每次库存变更时先让所有缓存失效再通过消息队列异步更新。虽然会有短暂不一致但结合预扣减策略用户体验上完全无感知。4.2 动态限流与熔断在流量洪峰来临时我们实现了立体化限流策略用户维度通过令牌桶算法限制单个用户每秒请求数接口维度对查询和下单接口设置不同阈值热点维度自动识别热门车次实施特殊限流策略熔断配置也有讲究初期我们设置服务错误率超过50%就熔断结果发现正常流量也被误杀。后来改为渐进式熔断先降级非核心功能如座位选择再限制部分用户最后才全熔断。配合Hystrix的滑动窗口统计系统稳定性提升40%。5. 性能优化实战案例5.1 库存服务优化历程第一版库存服务直接用MySQL行锁5000QPS就扛不住了。后来演进到第四代架构分桶计数将1000个座位分成20个桶每个桶50个座位并发更新不同桶Redis原子计数用INCRBY/DECRBY实现原子操作本地库存异步同步每个服务实例维护部分库存通过Kafka同步变更分段锁优化对热门区间如北京-上海单独加锁冷门区间不加锁最终实现单机10万QPS的库存操作错误率低于0.001%。关键技巧是避免全局锁通过业务拆分降低冲突概率。5.2 网关层优化技巧API网关是系统的咽喉要道我们通过以下优化将延迟从80ms降到9ms零拷贝技术使用Netty的ByteBuf替代传统IO流协议优化用Protobuf替代JSON体积缩小60%智能路由基于实时监控数据自动将流量导到健康节点连接池优化微服务间采用长连接TCP连接数减少90%特别重要的是提前预热在抢票开始前5分钟我们就逐步增加服务线程数避免瞬间扩容导致的雪崩。