携程门票秒杀系统优化实践

分享内容

1. 业务场景
2. 业务激增对系统架构的考验
3. 系统架构的优化路径，读热点、写入性能瓶颈、流量精细化控制等问题解决方案
4. 确保系统高可用性与持续性的治理措施
5. 总结

一、业务背景

后疫情时代旅游行业快速复苏，各类营销秒杀活动变得越发频繁，面对亿级流量的冲击，系统架构面临挑战。研发团队需要保障大流量下的功能稳定性，为国内外用户提供流畅的预订体验，因此需要对核心的预订交易系统进行应用架构升级，从而确保系统在高并发情况下仍能稳定高效运行。

本次分享将介绍在应对流量高峰、突破系统瓶颈、强化系统稳定性等方面的应对策略与优化效果。

二、秒杀活动案例分析

回顾大家曾经参与过的秒杀或大促活动，如双十一、618、12306 节假日抢票、演唱会抢票时，会有相似的感受：

1. 紧张刺激：活动通常定时开售，期待与紧张并存。
2. 系统压力：在高峰期，系统容易出现卡顿、宕机或提示 “太火爆” 或需要排队等待，让人倍感焦虑。
3. 结果未知：尽管全力以赴，但结果往往不尽如人意，有时抢到了票无法支付或者可能被退单。

这些活动在预订交易系统中也会呈现相似的特征：

1. 大流量、高并发：大流量、高并发、强事务性，对系统性能提出严峻挑战。
2. 时间敏感性：准时开售，用户争抢热点资源，系统需要确保实时、准确地响应。
3. 履约保障：从订前到订后，系统需要确保履约的顺利进行，避免用户因系统问题而遭受损失。

与传统电商相比，携程门票交易系统具有两大特点：

1. 强一致性：用户预订后保证出票且尽可能快速确认，确保每一笔交易都能履约。
2. 多维度和跨商品组合限购：限购规则复杂多变，例如多维度和跨商品组合限购，保障每位用户有公平购票的机会，避免囤票行为。

接下来回顾历史上有过的携程门票大型秒杀 / 活动案例。

1. 2020 年 8 月 8 日~ 9 月 1 日：“惠游湖北” 活动，携程独家承办，首次面对日常流量 45 倍 (数十万 QPS) 峰值的流量挑战，虽然刚开始系统出现不稳定的情况，但最终还是成功应对。
2. 2021 年 9 月 14 日：北京环球影城开业开售活动，携程门票在与其他友商的同期竞争中，成为唯一稳定出票且销量最高的交易平台。
3. 2023 年 9 月 15 日：武汉动物园开园，在供应商系统出现异常、友商页面卡顿有大量退单的情况下，携程门票预订依然能保持顺畅下单。
4. 2024 年 4 月 10 日：IU（李知恩）全球演唱会门票在 Ctrip.com 和 Trip.com 国际站同时秒杀，携程门票再次表现稳定，预订过程丝滑流畅，10 秒内售罄。

以下是部分历史秒杀活动峰值流量与日常峰值流量的对比数据：

数据显示出活动的流量激增通常远超系统日常处理的极限，如果没有针对预订交易系统进行优化，用户可能会遇到各种问题，例如：

1. 页面打开慢、卡顿、宕机：直接影响用户购物体验，系统会出现 Redis 或 DB 超负载，供应商接口不稳定等情况。
2. 付款后不能确认 / 退款：付款后，无法及时确认订单状态或进行退款操作，系统出现库存超卖 / 少卖等情况。

要避免出现上述情况，就要求系统具备高度的可扩展性和灵活性，同时在架构、缓存、数据库、流量控制等多方面进行全面优化。接下来我们通过具体场景来分析系统遇到的问题和应对策略，了解系统架构设计与演进过程。

三、系统架构设计与演进

整体而言，预订交易系统的目标是：稳、准、快。

• 稳：确保系统稳定可靠，保障售卖流程无间断。
• 准：实现数据一致性，确保履约准确无误。
• 快：提供流畅的预订体验，实现快速确认。

在大流量高并发场景下，要达到这些目标就可以进行有针对性的改造升级，接下来展开阐述。

3.1 系统稳定性挑战与应对策略

当系统遇到洪峰流量时，容易出现页面打开慢、卡顿等问题，主要原因有以下几点：

1. Redis 超负载与缓存热点。
2. 数据库超负载。
3. 供应商系统不稳定。

接下来针对这 3 个常见问题，阐述相应的应对策略。

问题一：Redis 超负载与缓存热点

当 Redis 面临负载问题时，可以使用水平扩容这种常规手段让流量分摊到更多实例。然而扩容虽能降低大多数实例的 CPU 使用率，但在处理特定热点数据时，各实例的 CPU 使用率仍然可能出现不均衡的情况，即缓存热点问题；此外还会存在缓存大 Key 问题。

1) 缓存热点问题

如下图所示，node-1 节点存在 2 个热点访问，请求量远高于其他节点。缓存热点会导致实例负载不均衡，从而严重影响响应速度。

缓存热点应对方案：热点识别自动构建多级缓存

将单位时间内高频访问的 Key，识别出来。例如：同一个 Key，1 秒内单机访问 10 次。

如上图所示，自动发现 Hot keys 或将指定的 Key 加入到本地缓存。