1分钟售出5万张票!电影节抢票技术揭破

[亡魂溺海] 提交于 2020-04-02 14:03:54

感谢参考原文-http://bjbsair.com/2020-04-01/tech-info/18222.html

背景介绍

对于电影爱好者来说,每次的电影节、影展活动,都是抢票大战的开启,出票速度几乎可 以用“秒空”来形容,例如上海国际电影节线上开售的记录是 60 秒售出 5 万张。

本文主要围绕售票环节,讲述阿里文娱的云智系统是如何支撑高流量并发,保障系统的稳定,不出现重卖等实现方案背后的技术。

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

架构设计思考的方向

1.让业务赢

在分层设计上,分成渠道接入层、业务层和服务层。在业务层,对外业务和管理后台功能 独立,职责清晰,快速支撑业务;服务层沉淀基础服务,构成稳定的业务和基础服务。

(图 1 业务技术大图)

2.让系统稳定

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

(图 2 技术架构图)

实现方案与技术解析

1.高并发流量如何抗?

电影节的流量是非常典型的秒杀场景,瞬时流量非常高,对于系统的高性能要求就注定很 高,在云智中,我们是如何抗高并发流量的?我们通过以下三点来进行阐述:热点数据隔离、 流量削峰漏斗、多级缓存。

1)热点数据隔离

在热点隔离这块,云智选择的策略包括:数据隔离和业务隔离。

数据隔离:是把查询已售卖座位和已锁定座位等库存相关的热点数据,隔离出来,单独业 务数据库,且使用分库分表,减少系统性能压力,提高吞吐量。

业务隔离:电影节的业务数据,独立的业务数据生成能力,圈定参与活动的业务数据,进 行缓存预热,起到隔离的效果。

2)流量削峰漏斗

关键词是“分层削峰”,漏斗式的减少请求流量,在业务链路的过程中,我们会进行业务校验,层层过滤,如用户的账号安全、购买资格,影院、影厅等基础信息状态是否正常,要购买的商品信息状态是否正常、秒杀是否已经结束等,每个层次都尽可能的过滤掉非法的请求,只 在最后端处理真正有效的请求,最终减少请求到数据库 DB 的写操作流量,保证系统处理真正 有效的请求。

以锁座流程为例子:

(图 3 流量削峰漏斗示例图)

3)多级缓存

在分层漏斗的前提下,云智采用分布式缓存和本地缓存 LocalCache 多级缓存的方案来抵抗 高并发流量,以下简要介绍一下在系统中使用的策略:

a)缓存预热。在指定参加活动的场次后,会在限定时间内停止变更,在开售前,会自动进 行预热缓存,避免激增流量击穿缓存;

b)缓存失效时长控制,对基础数据实体的 VO 对象和 DO 对象采用失效时间长短的缓存控 制,静态数据和 DO 实体使用长失效时长的策略:不失效或 24H;动态数据和实体 Info 使用比 较短的失效时长策略:分钟级,比如幂等性 KEY 的缓存时间为 2min;

c)本地缓存 LocalCache 使用的缓存时长策略分 3 种:2s,60s,122s。优先读本地的缓存, 其次读远程分布式的缓存,使得系统可以抵抗瞬间的高并发流量。

示例图如下所示:

(图 4 多级缓存示例图)

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

2.系统的稳定性、高可用性如何保证?

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

1)保障备战体系

(图 5 保障备战体系图)

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 做为唯一键。锁定座位时,如果座位已经售卖,会报出数据库异常,不允许某一个座位重复售卖。

总结

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

  • 让业务赢 = 完整的业务应用 + 支撑核心业务;

  • 高性能、高可用 = 流量削峰 + 限流降级 + 多级缓存;

  • 平台成熟化 = 完善的监控 + 保障方案。在这个过程中,我们沿着让系统稳定、让业务赢的设计思想,不断的思考和落地这些技术细节,沉淀核心技术,以达到让用户体验流畅的抢票过程。


易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!