1亿人点赞的晚会,如何做技术沉淀?

开发 开发工具
2019猫晚不仅在优酷,还打通手淘、天猫等APP,实现了多屏、多端、双向的互动,将互联网晚会的互动形态推进到3.0时代。如晚会上跑男队和街舞队在一个4×8米的巨型触摸屏上玩起了“好礼对对碰”游戏。

2019猫晚不仅在优酷,还打通手淘、天猫等APP,实现了多屏、多端、双向的互动,将互联网晚会的互动形态推进到3.0时代。如晚会上跑男队和街舞队在一个4×8米的巨型触摸屏上玩起了“好礼对对碰”游戏。优酷和淘宝的网友在APP端也可以选择加入某一战队,游戏比分实时计入明星嘉宾的成绩中,影响节目进程。观众还可以通过互动打赏给喜爱的节目“打call”,优酷直播间63%观看晚会的用户参与了互动,较去年增长7%。 很荣幸,我能有机会参与到双11猫晚项目,借这个机会给大家分享技术在猫晚过程和思考。

[[284276]]

2019“猫晚”现场,图为腾格尔唱《High歌》 

技术目标如何定?

猫晚KO时,总负责人说猫晚是给天猫双11消费者办的晚会及回馈,所以我们目标不仅要给消费者提供视觉盛宴,还要给消费者带来实惠,要给商家带货;虽然自古忠义不能两全,鱼与熊掌不可兼得,但是项目组同学即使执手相看泪眼竟无语凝噎也要咬牙接下有挑战的目标。基于这几个方向团队开始做分解,猫晚产品技术运营设计团队核心要承载晚会的传播影响力、丰富有趣的互动形式、以及进店的引导和让消费者实惠的权益发放。 明确定位后猫晚的核心业务目标相对就清晰了,基于业务目标技术同学进一步分解首要是业务目标支撑,稳定是底线、体验要保证、权益全发放、不能有资损(还有团队有成长、系统有沉淀)。

​ 

业务技术大图

所以猫晚技术目标制定的思考路径是,首先是看行业、看大盘、看业务、看团队;然后分解目标,找到关键指标和抓手及相关团队;最后去量化,定有挑战的指标和倒计时的里程碑。

​ 

制定技术目标图

技术如何保障公平一致的体验?

体验一致是因为晚会公域互动主打手淘、优酷、天猫APP,为即将到来的双11预热,让用户在看晚会时候就能边看边玩、边玩边买,所以主持人口播时候每次都会提醒打开手机摇一摇可以在手淘、天猫和优酷APP参与互动,这就要求多端需要同时弹起和关闭互动、展示内容一致、玩法一致、抽奖时间一致。 基于以上几个需求,猫晚今年的解法是第一次完全一套代码,运行到手淘、天猫和优酷,在优酷侧部署的代理服务只承载转发和适配不做其他任何业务、核心服务部署到集团机房承载所有的互动玩法和权益发放,技术架构图如下:

技术架构图 

提到公平,为什么存在公平性的问题?

核心原因在于因为不可抗力的用户网络延迟、现场信号延迟以及内容生产制作过程中的延迟,如果技术上不处理可能存在的问题大家互动弹起的时间分布完全不同,那么很可能你还没开始游戏或者正在玩游戏,有的人已经把那些一元购以及终极大奖替你还49999花呗的权益抽取完了,这个带来的挫败感和不公平感实在叔可忍婶婶不可忍,所以猫晚引入了以下四个机制来保障:

  1. 客户端和服务端通过CSN及无线RPC网关轮询对表,保障客户端维护的时钟和服务端一致;
  2. 现场布置延迟机,反复实测现场延迟以及内容制作过程中的延迟时间;
  3. 运营操作节目单事件点击和主持人话口与导演组反复沟通及演练对齐;
  4. 最后根据2和3的时间delay在直播流中插入SEI,内容消费端再解析SEI信息,根据节目开始时间弹起互动。

高并发脉冲流量如何抗?

猫晚比较典型的是打底常驻流量一直有,然后每轮互动带来脉冲流量,针对这些场景猫晚这面的核心思路是以下三板斧:多轮全链路压测、应用预热、防刷限流兜底;以上三点可能大家都比较熟悉每次大型活动的默认项,除了以上点还可以聊一聊比较有晚会特色的优化比如削峰、路由、下游保护。

1)路由

猫晚比较典型的打底流量节目单polling,所有同时在线用户每45S都会轮询一次,技术同学准备了路由方案,默认所有请求100%走无线RPC网关,但是可以动态下发路由比例给前端,当无线RPC网关压力较大或者即将超过目标限流值时或者流量评估模型有问题时可以走预案切换比例到轮询CSN,以保障系统稳定性。

总结:根据流量情况动态路由分发是兜底和保证体验的利器。

2)削峰&错峰

★ 错峰:

a、公私域互动在节目进程中叉开投放时间,避免并发同时来临;

b、20点及21点集团有红包雨,和导演组沟通及演练互动错开整点的前后几分钟,防止给权益平台带来集中压力;

c、在私域像红包雨、入场红包、密令红包等互动通过中间件消息下行通道投放,降低私域服务端压力。

★ 削峰:

a、客户端向后台提交数据有压力的点都采用在一定时间范围内随机打散算法;

b、红包雨控制中奖率,同一个用户的多次点击可以配置有效请求数;

c、终极宝箱个数查询提前打散异步15S预查询,避免集中冲击;

d、获得终极宝箱后客户端维护有无标志,挡掉开奖时一部分的集中查询。

总结:削峰和错峰需要体验+业务+技术手段相结合,避免技术上过度设计和优化,ROI低。

3)下游保护

猫晚发放核心依赖权益平台,每轮互动结束后都会有抽奖环节,抽奖就要调用权益平台,比如终极大奖开奖时有两个要求:

a、所有用户都可以参与抽取,如果用户没抽中大奖还可以抽打底奖池;

b、要保证大奖全部发出,否则算资损。

这里如果让所有用户先走全部抽大奖然后不中的再来抽打底,就会两次调用权益平台,对下游的调用直接double而且权益平台大奖奖池口也无法承载这么高的流量(大奖权益平台会直接同步操作DB),无论从性能上还是从价值及成本上来看必要性都不大,基于此判断项目组定了以下三个优化action:

a、从业务规则上告诉用户宝箱越多概率越高;

b、从应用上直接分流宝箱较多用户抽大奖奖池,宝箱较少用户直接抽打底奖池;

c、从技术上实时监控统计宝箱分布情况,在前面轮次一旦发现宝箱分布和预期业务规则不一致,启动提前预案,保证大奖必然全部发放。

总结:下游稳定全链路才能稳定,系统设计时要充分考虑对下游的保护。

现场大屏和小屏联动花絮

这里想给大家分享一个猫晚关于预案的小花絮,提醒每个同学预案一定不能只留在预案平台上,需要可应急、可执行、已演练、甚至需要准备备胎的备胎。 为了让内容和互动更精彩,结合更紧密,项目组同学提出要做双向互动,让用户有更强的参与感,去支持自己喜爱的明星并同步参与一样的游戏,数据实时回流现场影响最终PK结果。 做双向互动以前没有先例,因为有以下问题要解决:

a、现场环境复杂,对设备及通讯等都会有干扰;

b、链路长,可控性差,除猫晚内部团队协同外还涉及导演组、主持人、明星等外部配合;

c、直播现场突发情况多,对应急能力要求高。 果不其然从需求反复调整对齐,CodeReview以及全链路压测,手淘天猫集成,集团技术汇报,直播演练及和导演组对话口一路解决各种风险;等项目组同学进入现场后才发现以前的问题只是毛毛雨,先看下时间轴和现场大屏和直播画面示意图:

  • 9月份就开始提前启动在广州、东莞、虎门等地多次实测现场大屏效果,进场前确认完全没问题;
  • 11.6进入现场第一次排练就发现现场信号嘈杂,触摸屏触摸会失灵,现场每次可以给的检修时间非常有限;
  • 11.8号依然未能修好,和导演组沟通希望尝试预案演练;
  • 11.9号晚明星彩排吊威亚看台同步配合操作,看台给的机位切换,导致看不清大屏操作,演练效果依然不好;
  • 11.10上午导演组一度考虑拿掉该环节;
  • 11.10晚上现场同学顶住压力,完美呈现首次双向联动。
  • [[284278]]

  • [[284279]]

    ​ 

现场和线上双向互动图

​ 

大屏交互示意图

回到现场大屏操作异常时准备的预案,重点说明进场前技术准备的只有一级预案,后面的全是随机应变根据现场情况和产品同学一起讨论临时制定的预案。

一级预案晚会前演练触摸使用,异常检修;

二级预案是无法检修换大屏机器;

三级预案是大屏机器无法更换,需要看台固定1机位,导播车有1人保证机位不会切换,看台口令员和操作员配合键盘同步明星现场操作;

四级预案是操作员1的电脑或键盘异常,热备2机器和热备2同学操作。

总结:

预案一定要可应急、可执行、已演练、甚至需要准备备胎的备胎;

技术要有追求,多想可能的办法,时间越紧张越要把预案做细,做简单。

总结:

一年只用一天的系统如何做技术沉淀?

像天猫双11晚会类似的项目,平时不承载流量,没有专门的维护团队,随着猫晚启动抽调各个团队来共同承担,参与到项目的技术同学该如何让自己成长和收获呢?我自己总结有以下几点:

a、学会思考和制定技术目标;

b、锻炼技术PM能力,不设边界,有技术预判,识别解决风险,保障目标坚决落地;

c、有匠心:对性能和体验及技术方案上需要极致、细致;

d、为后人栽树:工具、组件、产品、组织能力沉淀;

e、复盘能力:复盘从参与项目的第一天开始,思考突破与沉淀;

f、拓宽视野:偶尔跳出专业领域,发现技术外的视角,看其他领域及合作团队的思考,学习周边优秀的小伙伴。

 

责任编辑:武晓燕 来源: 51CTO专栏
相关推荐

2022-10-19 10:08:29

技术汇报研发管理

2020-01-08 10:18:31

阿里技术人互联网

2020-01-10 15:15:53

Redis点赞数据库

2013-11-29 10:15:48

国产虚拟化

2014-04-15 13:16:00

Code Review

2017-11-02 08:54:13

数据存储架构

2023-11-03 09:05:53

2020-12-03 11:00:29

Spring ClouRedis数据库

2020-08-03 08:48:18

技术人阿里专家

2015-02-06 11:08:19

2015-07-30 11:21:16

代码审查

2012-03-12 16:42:54

测试

2018-08-17 14:50:40

2021-07-03 09:21:15

QQ游戏中心宣发平台运营

2022-08-03 09:11:31

React性能优化

2022-08-29 08:08:58

SQLOracleCPU

2024-04-22 08:26:37

协同编辑FigmaOT 算法

2024-01-15 07:42:37

Figma协同编辑算法

2023-01-18 23:52:07

RTA用户粒度运营

2022-05-17 15:05:56

测试测试漏测Bug
点赞
收藏

51CTO技术栈公众号