阿里卖电影票 架构思路

出处： 同样是卖票，为啥阿里卖电影票就不卡？技术上做了啥？？？

 

一、背景介绍
　　先简单分析一下电影节的抢票业务，典型特征是在大流量抢购、高并发的场景下，让用户极快的锁定座位然后出票，特别是热门的影片，会异常的火爆。第一道压力是查询已售座位列表和锁座，需要能快速的支撑用户的锁座请求，且实时查询到已售卖的座位列表，避免发起无效的锁座请求；第二道压力是出票，如果锁座成功，但一直出票失败，会给用户带来很不好的体验。 

二、架构设计思考的方向
1．让业务赢
　　在分层设计上，分成渠道接入层、业务层和服务层。在业务层，对外业务和管理后台功能独立，职责清晰，快速支撑业务；服务层沉淀基础服务，构成稳定的业务和基础服务。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　图2：业务技术大图

2．让系统稳定
　　在架构设计上，接入统一网关让系统安全，有限流，对库存中心和订单中心进行数据隔离，且加入多级缓存方案，让系统稳定。 

　　　　　　　　　　　　　　　　　　　　　　　　　　图3：技术架构图
三、实现方案与技术解析
1．高并发流量如何抗？
　　电影节的流量是非常典型的秒杀场景，瞬时流量非常高，对于系统的高性能要求就注定很高，在云智中，我们是如何抗高并发流量的？我们通过以下三点来进行阐述：热点数据隔离、流量削峰漏斗、多级缓存。
 1）热点数据隔离
　　在热点隔离这块，云智选择的策略包括：数据隔离和业务隔离。
　　数据隔离：是把查询已售卖座位和已锁定座位等库存相关的热点数据，隔离出来，单独业务数据库，且使用分库分表，减少系统性能压力，提高吞吐量。
　　业务隔离：电影节的业务数据，独立的业务数据生成能力，圈定参与活动的业务数据，进行缓存预热，起到隔离的效果。
 2）流量削峰漏斗
　　关键词是“分层削峰”，漏斗式的减少请求流量，在业务链路的过程中，我们会进行业务校验，层层过滤，如用户的账号安全、购买资格，影院、影厅等基础信息状态是否正常，要购买的商品信息状态是否正常、秒杀是否已经结束等，每个层次都尽可能的过滤掉非法的请求，只在最后端处理真正有效的请求，最终减少请求到数据库DB的写操作流量，保证系统处理真正有效的请求。
以锁座流程为例子： 

 

　　　　　　　　图4：流量削峰漏斗示例图
 3）多级缓存
　在分层漏斗的前提下，云智采用分布式缓存和本地缓存LocalCache多级缓存的方案来抵抗高并发流量，以下简要介绍一下在系统中使用的策略：
　　a）缓存预热。在指定参加活动的场次后，会在限定时间内停止变更，在开售前，会自动进行预热缓存，避免激增流量击穿缓存；
　　b）缓存失效时长控制，对基础数据实体的VO对象和DO对象采用失效时间长短的缓存控制，静态数据和DO实体使用长失效时长的策略：不失效或24H；动态数据和实体Info使用比较短的失效时长策略：分钟级，比如幂等性KEY的缓存时间为2min；
　　c）本地缓存LocalCache使用的缓存时长策略分3种：2s，60s，122s。优先读本地的缓存，其次读远程分布式的缓存，使得系统可以抵抗瞬间的高并发流量。
示例图如下所示： 

 　　　　　　　　　　　　　　图5：多级缓存示例图
将缓存分2层结构：

• 第一层是本地缓存结构：用户、权限、基础信息等静态数据，我们优先选择本地缓存；
• 第二层是全量的缓存实体信息的DO和VO信息，这层采用的是Tair分布式缓存。

2．系统的稳定性、高可用性如何保证？
　　对于任何档期或者活动，系统的稳定性都是第一要素，针对电影节的活动场景，我们使用了很多设计上的稳定性模式，其中比较核心的有：多轮全链路压测、限流、降级、动态扩容、流量调度、减少单点、依赖简化等方式；除了以上几点，本节我们重点聊一聊我们在电影节过程中是如何保障备战的？
1）保障备战体系

　　　　　　　　　　　　　　　　　　　　 图6：保障备战体系图
a）在战前阶段
　这个阶段的工作会比较多，只有做到事前充分准备，才能有更好的保障结果，主要包括以下几个部分：
　　（1）梳理薄弱点，包括系统架构、系统薄弱点、核心主流程，识别出来后制定应对策略；
　　（2）全链路压测，对系统进行全链路压测，找出系统可以承载的最大QPS；
　　（3）限流配置，为系统配置安全的、符合业务需求的限流阀值；
　　（4）应急预案，收集各个域的可能风险点，制作应急处理方案；
　　（5）安全保障，主要聚焦在账号权限管控，以最小够用原则为准，防止权限滥用，安全无小事；
　　（6）战前演练，通过演练来检验保障体系是否完善，演练开票现场，提高团队响应和处理能力；
　　（7）作战手册，制定作战手册，明确作战流程和关键点节点的任务以及沟通机制。

 

　b）在战中阶段
　　活动开售，我们也称为战中，整个项目组主要专注三件事情，即“监控““响应”和“记录”。项目组的同学都必须要保持作战状态，严格按照应用owner机制，负责巡检应用情况，及时同步技术数据和业务数据是否有异常。同时，在战中，我们临时组建“保障虚拟小组”，用于应对大促期间可能出现的紧急客诉等问题，及时做出决策，控制影响范围，同时也能提高整体作战能力。记录，是在战中过程中必须要记录下各应用的峰值，及时沉淀技术数据，为后续系统建设，流量评估等提供参考借鉴。
　c）在战后阶段
　　这个阶段的主要工作是项目复盘，复盘的内容主要包括：项目结果、项目回顾、项目沉淀和改进，将项目过程中收集到的问题和故障进行详细分析，并将项目过程中沉淀出来的，关于系统稳定性保障的经验沉淀到日常，让活动保障的常态化逐步落地。

2）最佳实践
　a）精准监控
　　通过监控，实时发现各个服务是否触发限流值，及时进行Review，调整限流值，保证业务成功率和系统稳定。
　　对系统基础值班和业务量指标进行精准监控，如load，内存，PV，UV，错误量等，避免因内存泄露或代码的Bug对系统产生影响，精准监控，提前感知内存泄露等问题。
　b）数据大盘
　　通过数据大盘，实时汇总数据，展示业务数据，为系统、为业务提供更加直观的业务支持，也可以更加有效的进行业务备战。

 

3．如何保证不出现重卖？
在业务过程中，我们实现了很多业务，解决了很多困难，我们重点阐述以下两个痛点，一个是恶意锁座，一个是防止超卖。
　1）如何解决恶意锁座？
　　首先我们采用的扣减库存方式是预扣库存，用户操作锁定座位时即锁定库存，那我们如何解决恶意锁座呢？
　　　　a）锁座订单中会生成一个“库存失效时间”，超过该时间，锁座订单会失效释放库存；
　　　　b）限制用户购买数量，一人最多只能购买6张票；
　　　　c）接入黄牛防控系统；
　2）如何防止库存超卖？
　　电影票不同于电商业务普通的标品，是不允许出现超卖的情况，否则会出现重票，从而引发客诉舆论问题，所以在库存数据一致性上，需要保障在高并发情况下不出现重票，我们的解决方案是：
　　　　a）使用分布式缓存，在分布式缓存中预减库存，减少数据库访问；
　　　　b）使用数据库唯一键，在锁座表中，设定场次Id和座位Id作为唯一键。锁定座位时，如果座位已经售卖，会报出数据库异常，不允许某一个座位重复售卖。

四、总结
　回顾电影节抢票，我们首先想到的是能抗高并发流量，能让系统稳定。通过上述章节我们揭开了高性能、高可用等背后的技术，展示了一个典型抢票大战的技术方案，核心技术包括：

• 让业务赢 = 完整的业务应用 + 支撑核心业务
• 高性能、高可用 = 流量削峰 + 限流降级 + 多级缓存
• 平台成熟化 = 完善的监控 + 保障方案

　在这个过程中，我们沿着让系统稳定、让业务赢的设计思想，不断的思考和落地这些技术细节，沉淀核心技术，以达到让用户体验流畅的抢票过程。