携程门票：亿级流量挑战下的高可用架构设计与实践

1. 携程门票亿级流量挑战下的高可用架构设计与实践

2.

4. 参与过的大流量场景

5. 系统概述秒杀/活动抢菜双11 节假日抢票疫情抢菜门票/演唱会印象与感受  定时开售  卡顿/提示太火爆/排队  抢不到/抢到被退

6. 系统概述秒杀/活动抢菜双11 疫情抢菜大流量/弱一致性大流量/弱一致性节假日抢票门票/演唱会大流量/强一致性/简单限购大流量/强一致性/复杂限购业务场景特征  大流量/高并发  准时开售/抢热点  保障履约涵盖：订前+订后

7. 大型营销活动案例

8. 历史大型营销活动 2020 8.8-9.1 惠游湖北 · 0元票 2021 瞬时流量超过 1500万 9.14 北京环球影城开业友商：页面卡顿，订单无法确认， 2024 4.10 IU(李知恩)演唱会· 全球售卖携程：预订丝滑 (10秒售罄) 超 300万人成功预约大量退单(PR事件) 韩国女演员全球人气排行TOP2 携程独家，挑战最大，打破历史峰值与友商比，携程最稳且销量最高历史峰值最高

9. 历史大型营销活动营销活动&节假日与日常峰值流量的倍数 2020湖北0元票 2021年9月14日北京环球影城开业 2023年五一 2023年09月15日武汉动物园开业 2023年十一 2024年4月10日 IU 演唱会CT同售 73 45 35 5 20 23 5 5 峰值QPS达到数百万

10. 大流量活动给系统带来的问题

11. 大流量活动常见问题归纳产品视角用户反馈首页/营销页填写页详情页订单详情页确认中预订打开慢、卡顿、宕机支付取消订单付款后不能确认、退款订单确认太慢  页面打开慢、卡顿、宕机  已售罄，实际商品未售完  预订成功，无法确认，被退款  预订成功，订单确认太慢

12. 大流量活动常见问题归纳产品视角填写页详情页首页/营销页订单详情页确认中预订 1 研发视角打开慢、卡顿、宕机 Redis、DB超负载不稳定：供应商系统不稳定取消订单支付不一致: 库存超卖/少卖 2 付款后不能确认、退款 3 海外Trip.com 访问性能差

13. 交易系统在大流量下的架构应对策略

14. 设计目标稳系统稳定保障售卖准数据一致保障履约快预订顺畅体验丝滑

15. 大流量活动常见问题产品视角填写页详情页首页/营销页订单详情页确认中预订 1 研发视角打开慢、卡顿、宕机 Redis、DB超负载不稳定：供应商系统不稳定取消订单支付不一致: 库存超卖/少卖 2 付款后不能确认、退款 3 海外Trip.com 访问性能差

16. 不稳定原因分析网络异常 Loading… 请重试页面打开慢、卡顿 ▪ Redis超负载、缓存热点 ▪ DB超负载 ▪ 供应商系统不稳定

17. 如何保障系统稳定 - 扩容 cluster 技术策略 ▪ Redis 扩容 ▪ DB 隔离/服务隔离 cluster 水平扩容 1 Master:2 Slave 1 Master : 4 Slave 常规手段：水平扩容，让流量分摊到更多实例

18. 缓存热点问题扩容可以降低大多数实例的CPU水位但不能解决热点问题例如：热门商品秒杀时 Redis 各实例 CPU Util

19. 如何保障系统稳定 - 缓存热Key - 原因/危害 Server cluster Service Redis Cache Redis QPS CPU Util 20000 40% 40000 80% 热点效应危害：实例负载不均衡，拖垮服务器缓存热Key影响系统稳定性

20. 如何保障系统稳定 - 缓存热Key - 技术方案技术策略：多级缓存 Server Service 1、主动配置 2、高频访问 L1 Local Cache ReferenceQueue<V> value 引用队列 WriteQueue<ReferenceEntry<K,V>> 最近读队列最近写队列 AccessQueue<ReferenceEntry<K,V>> 有限 LRU 队列 Segment<K,V>[] Redis key 引用队列 ConcurrentLinkedQueue<ReferenceEntry<K,V>> Find Hot Key L2 Redis Cache ReferenceQueue<K> 最近访问队列（LRU队列） Local Cache 数据结构 Local Cache 单位时间内存在的值例如：同一个Key，1秒内单机访问10次总结： 1. 自动发现Hot keys并加入到本地缓存 2. 指定的Key加入到本地缓存

21. 如何保障系统稳定 - 缓存热Key - 组件升级 request response 缓存组件 - 按场景、TTL、容量 - 自动发现 - 埋点、监控 cache strategies TTL、 size Read local cache counter... if not found in local cache Read from redis Redis RPC service1..n

22. 如何保障系统稳定 - 缓存热Key - 效果举例 (不同的Key 效果不一样) 开启多级缓存技术策略：多级缓存耗时：平均降低约25% Redis 访问量 Local Cache 访问量

23. 如何保障系统稳定 - 缓存大Key 以10KB为基准下降的百分比 2.50 18000 AVG 15.7倍 2.00 10000 7.3倍 61% 6000 4倍 76% 3倍 0.50 80% 4000 1.5倍 88% 0.6倍 94% 2000 0 注：多场景压测结果显示，200KB+较10KB以内的性能慢3倍 0.00 key3:value3(5MB) 阻塞网络 8000 ▪ 1.00 内存占用大 ▪ key2:value2(2KB) 37% key1:value1(1KB) 阻塞请求 1.50 Cache ▪ 16000 12000 timeout 危害 request key3 QPS 14000 Applications 以10KB为基准慢的倍数

24. 如何保障系统稳定 - 缓存大Key Applications request key3 timeout Cache key1:value1(1KB) key2:value2(2KB) key3:value3(5MB) 危害技术策略：长期治理 ▪ 阻塞请求 ▪ 拆分大Key ▪ 内存占用大 ▪ 压缩value ▪ 阻塞网络

25. 如何保障系统稳定 - 缓存大Key - 监控

26. 如何保障系统稳定 - 缓存大Key - 效果优化后：Redis 响应耗时明显提升

27. 秒杀时系统不稳定 - DB 超负载瞬间大流量导致DB线程指标异常接口（ RT）变慢读写DB的服务异常商品库的波动导致全业务不可用

28. 如何保障系统稳定 - DB 超负载 - 架构升级 Application request key3 Product Management 商品变更导致缓存失效 - 删除缓存 - 消息量太大 Cache VBooking key1 sync delete key3 Product Service DB (master) response timeout binlog DB (slave) Id Active Id Active 3 F 3 F binlog parser 商品变更导致缓存失效，大量请求打到DB Consumer /Worker

29. 如何保障系统稳定 - DB 超负载 - 架构升级 Application request key3 Product Management 商品变更导致缓存失效 - 删除缓存 - 消息量太大 -> 消息聚合 Cache VBooking -> 缓存更新 key1 key3 Product Service DB (master) response binlog DB (slave) binlog parser set Update logic Consumer /Worker Aggregator Id Active Id Active 3 F 3 F 商品变更新数据覆盖更新

30. 如何保障系统稳定 - 供应商订单对接问题预订商品后台提交订单订单确认订单商品选售维护商品其他渠道上货直连系统 (订单) 直连系统 (商品) 其他确认方式处理订单供应商品供应商系统供应商系统供应商系统订单问题： ▪ 限流 ▪ 系统不稳定订单无法快速提交到供应商系统供应售卖履约

31. 如何保障系统稳定 - 供应商下单设计技术策略：削峰填谷/缓冲池、禁售策略提交订单直连系统 (订单) 100单/分钟直连 30 禁售策略：供应商系统禁售熔断提交订单直连系统 (订单) 限流器缓冲池根据健康度自动禁售 ▪ 定期重试 bt：base time n：惩罚等级，连续第n次下线，首次下线n=1 30 100单/分钟 ▪ 直连供应商系统匀速提交营销场景多为提前售卖，不是立即使用 f(p)：exceptionRate，30分钟内异常率

32. 如何保障系统稳定 - 供应商下单升级 - 效果技术策略：削峰填谷/缓冲池不影响下单吞吐量

33. 流量控制减少不必要的资源投入确保活动的流量水位在安全线内活动+常规流量

34. 如何保障系统稳定 - 大流量冲击活动曝光选售预订提交订单首页/营销页详情页填写页预订支付流量大小高低系统承载能力大小例如：10万人购买5000张票如何限流保障各系统稳定运行？

35. 预订系统 - 自定义限流技术方案：SOA限流 VS 自定义限流 (按活动商品限流） SOA限流自定义限流 100%能力承载 30%能力承载 70%能力承载所有业务秒杀业务非秒杀业务 SOA限流会影响所有业务限流只影响活动商品服务器/开发资源投入可控

36. 如何保障系统稳定 - 限流设计技术策略：自定义限流 (按活动商品限流） 1s 限流 1000QPS 100ms 限制 100QPS 10 个 100ms 滑动窗口，每个滑动窗口限制 100QPS 限流更精准，防止高并发场景对下游带来压力

37. 如何保障系统稳定 - 商品级限流效果突增流量：进排队页面/提示活动限流所有景点：请求被限制/系统超负载请求量单景点/资源限流阈值请求量突增流量 300K 系统最大负载(未提前扩容情况下) 250K 200K 访问时间 150K 请求量 100K 其他景点：正常访问 50K 09:59 10:00 10:01 访问时间商品级限流，超负载也不影响整体的可用性，支持热点商品自动限流访问时间

38. 准数据准确保障履约

39. 高并发系统常见问题产品视角填写页详情页首页/营销页订单详情页确认中预订 1 打开慢、卡顿、宕机研发视角 Redis、DB超负载不稳定：供应商系统不稳定取消订单支付不一致: 库存超卖/少卖 2 付款后不能确认、退款 3 海外Trip.com 访问性能差

40. 如何保障数据的准确 - 扣减库存问题下单限购检查提交限购扣库存问题： ▪ 性能瓶颈 – MySQL热点行扣减库存（行级锁）创单取消限购

41. 如何保障数据的准确 - 扣减库存架构升级技术策略：扣减库存异步化，消除DB行级锁取消订单下单 1 锁定后台管理后台 Service Service Inventory Service Inventory Service 1 1 Redis 2 初始化库存 2 Service Service 3 Inventory Service 5 Redis 初始化 1 否 DB扣失败，重试N次是否成功 4 事务扣减库存 inventory update 记录明细日志 inventory_detail insert 扣库存 Storage 2 2 3 否是否成功无扣库存记录，重试N次是 4 Redis 还库存 3 扣减库存服务V 2.0 4

42. 下单扣减库存升级 - 效果扣减库存异步化，消除行级锁性能瓶颈轻松支持数十万/分钟下单(非极限)

43. 快预订丝滑体验丝滑

44. 秒杀系统常见问题产品视角填写页详情页首页/营销页订单详情页确认中预订 1 打开慢、卡顿、宕机研发视角 Redis、DB超负载不稳定：供应商系统不稳定取消订单支付不一致: 库存超卖/少卖 2 付款后不能确认，退款 3 海外Trip.com访问性能差

45. 海外访问路径 - 改造前 SHA-Region IDC 1 IDC 2 Gateway Gateway HK-NAP SLB SLB NAP 专线 Service DB Service DB 延迟：80ms 单次链路影响小，多次跨洋回源请求对性能影响大 Akamai Trip.com

46. 国内与海外性能差异 - 网络延迟 350 ms 350 ms 100 ms 350 ms 450 ms 200 ms AWS - FRA 450 ms 600 ms 200 ms 500 ms 500 ms 250 ms 300 ms 300 ms 950 ms SHA 150 ms 150 ms 900 ms AWS - SIN 250 ms 250 ms 850 ms

47. 国内与海外性能差异 - 减少跨Region调用提升系统响应速度 Trip.com UDL∈ {N，O，P，…Z} API Router API Router UCS UCS Gateway/SLB Gateway/SLB RESTful RESTful Service Service Cache DB DRC/X-Pipe DB Cache 跨Region数据复制 SGP SHA 方案一：海外跨Region应用数据单元化全量应用（数千个）全量部署，高成本挑战

48. 国内与海外性能差异 - 减少跨Region调用提升系统响应速度 Trip.com UDL∈ {N，O，P，…Z} API Router API Router 跨洋访问多次回源跨洋访问一次回源 A A 80m s B 80ms 80m s B 80m s C 240ms C UCS UCS Gateway/SLB Gateway/SLB RESTful RESTful 400ms Service 1 2 一个完整功能，多次回源聚合为1次 Service Wormhole 提前构建缓存 JOB Cache SGP 方案二：入口服务聚合 + Redis构建轻量化上云（减少回源）兼顾性能，成本下降数百倍 Cache DB SHA

49. 海外访问性能优化 - 效果访问量越大，响应越快

50. 除此之外『高可用』如何实现“可持续性”？架构健康度治理

51. 如何保障高可用可持续性 - 架构健康度治理系统运行健康度 • 服务性能 (API性能) • 服务运行 (线程数/GC/异常) • 服务调用 (限流/熔断/超时) • 数据库 (慢查询/线程数) • 缓存 (大Key/命中率) • 队列 (延迟) • 资源用量 (资源利用率) 系统设计健康度 • 应用规模 - 人均应用数 - 代码行数 • 应用拓扑工程化健康度 • 工程包 - 包大小 - 包依赖数 • 工程效率 - 循环/重复调用 - 编译时长 - 调用链路层级 - 回退时长 - 调用放大系数 - 启动时长 • 应用价值 - 低流量/低发布基于『架构健康度』，分步实现应用架构治理维度、标准和方法的统一

52. 如何保障高可用可持续性 - 完善的稳定性保障体系引入大型活动节假日保障体系日常开发持续优化（风险、性能、瓶颈) 风险项梳理总结大型活动节假日保障压测压测复盘扩容/风险预案节中 P0 优化日常开发 + 大型活动节假日保障形成闭环值班节后

53. 大流量高并发高可用架构设计实践 - 总结系统设计关注点 1 单一职责、独立部署 4 缓存刷新 5 防大流量穿透 3 缓存热点自动发现热Key升级为本地缓存 7 降低峰值，保护系统保障核心服务高可用 2 削峰商品级限流 Redis扣减，异步扣减DB 8 超负载正常运行 6 熔断&降级快速失败降级运行库存扣减秒级生效准时售卖/售罄 9 恶意请求拦截识别非法请求并拦截设计关注点：小问题会被放大，关注读/写瓶颈，要求极高的一致性、实时性与性能重视持续性优化与稳定性保障：日常架构健康度治理 + 大型活动节假日保障

54.