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

亿级流量挑战下的高可用架构设计与实践 目录 01.系统概述 熟知的大流量场景 02.营销活动的特点 背景|设计原则|目标及范围 03.交易系统在大流量下的架构应对策略 稳|准|快|海外访问性能优化 04.如何让高可用具备“可持续性”？ 架构健康度治理|稳定性保障体系 05.总结 参与过的大流量场景 系统概述 印象与感受 定时开售抢不到/抢到被退卡顿/提示太火爆/排队 系统概述 业务场景特征 大型营销活动案例 历史大型营销活动 历史大型营销活动 大流量活动给系统带来的问题 大流量活动常见问题归纳 用户反馈 页面打开慢、卡顿、宕机预订成功，无法确认，被退款已售罄，实际商品未售完预订成功，订单确认太慢 大流量活动常见问题归纳 交易系统在大流量下的架构应对策略 大流量活动常见问题 不稳定 原因分析 ▪Redis超负载、缓存热点▪DB超负载▪供应商系统不稳定 Loading…网络异常 请重试 页面打开慢、卡顿 如何保障系统稳定-扩容 技术策略 ▪Redis扩容▪DB隔离/服务隔离 缓存热点问题 扩容可以降低大多数实例的CPU水位 例如：热门商品秒杀时 如何保障系统稳定-缓存热Key-原因/危害 如何保障系统稳定-缓存热Key -技术方案 总结： 1.自动发现Hotkeys并加入到本地缓存2.指定的Key加入到本地缓存 如何保障系统稳定-缓存热Key -组件升级 缓存组件 -按场景、TTL、容量-埋点、监控-自动发现 如何保障系统稳定-缓存热Key -效果 如何保障系统稳定-缓存大Key 技术策略：长期治理 危害 如何保障系统稳定-缓存大Key -效果 如何保障系统稳定-DB超负载-架构升级 商品变更导致缓存失效 -删除缓存-消息量太大 如何保障系统稳定-DB超负载-架构升级 商品变更导致缓存失效 -删除缓存-消息量太大->缓存更新->消息聚合 如何保障系统稳定-供应商订单对接问题 如何保障系统稳定-供应商下单设计 如何保障系统稳定-供应商下单升级-效果 技术策略：削峰填谷/缓冲池 流量控制 减少不必要的资源投入确保活动的流量水位在安全线内活动+常规流量 如何保障系统稳定-大流量冲击 预订系统-自定义限流 技术方案：SOA限流VS自定义限流(按活动商品限流） 如何保障系统稳定-限流设计 技术策略：自定义限流(按活动商品限流） 1s限流1000QPS 100ms限制100QPS 如何保障系统稳定-商品级限流效果 数据准确准保障履约 高并发系统常见问题 如何保障数据的准确-扣减库存问题 ▪性能瓶颈–MySQL热点行扣减库存（行级锁） 如何保障数据的准确-扣减库存架构升级 技术策略：扣减库存异步化，消除DB行级锁 下单扣减库存升级-效果 扣减库存异步化，消除行级锁性能瓶颈轻松支持数十万/分钟下单(非极限) 预订丝滑快体验丝滑 秒杀系统常见问题 海外访问路径-改造前 国内与海外性能差异-网络延迟 国内与海外性能差异-减少跨Region调用提升系统响应速度 国内与海外性能差异-减少跨Region调用提升系统响应速度 海外访问性能优化-效果 除此之外 『高可用』如何实现“可持续性”？架构健康度治理 如何保障高可用可持续性-架构健康度治理 系统设计健康度 系统运行健康度 •服务性能(API性能)•服务运行(线程数/GC/异常)•服务调用(限流/熔断/超时)•数据库(慢查询/线程数)•缓存(大Key/命中率)•队列(延迟)•资源用量(资源利用率) •应用拓扑 -循环/重复调用-调用放大系数-调用链路层级 基于『架构健康度』，分步实现应用架构治理维度、标准和方法的统一 如何保障高可用可持续性-完善的稳定性保障体系 大流量高并发高可用架构设计实践-总结 设计关注点：小问题会被放大，关注读/写瓶颈，要求极高的一致性、实时性与性能 重视持续性优化与稳定性保障：日常架构健康度治理+大型活动节假日保障