2024年6月12日发(作者：)
特
约
专
题
北京中电高科技电视发展有限公司
刘 冰 邵 玮
摘 要
CCTV微视作为央视新媒体矩阵中的一份子，在世界
一 行业领先的系统架构设计
杯期间提供了稳定支撑亿级流量的能力。本文介绍了CCTV
微视的系统架构设计，对消息逻辑、服务和机器优化、数
CCTV微视在直播互动上，不但能够通过文字、语音、
据处理机制、直播平台等进行了详细分析。
图片、点亮，礼物等方式来满足用户的基本沟通需要，还
独有贴卡片方式可以让用户一边观看直播一边参与竞猜、
投票、抽奖、呐喊、游戏等多种互动方式。在直播互动系
关键词
统搭建之初，针对业务逻辑灵活的需求，CCTV微视在做
CCTV微视 系统架构 直播互动
系统设计时进行了妥善处理，使得架构可随需求调整互动
方式，也可以根据用户的实时反馈调整更符合当前情况的
本届世界杯，开启了“手机看世界杯的元年”。对于
互动环节。这一切极大地提升了用户的参与感与带入感，
身处互联网时代的很多人而言，这或许是第一次告别电
让观看直播的趣味性大大增强，犹如置身于志同道合的人
视机，在手机、平板电脑等移动端上，在公交车里、地铁
群中边玩边看。
里观看一场高清精彩的世界杯赛事，并通过指尖发表着
然而在世界杯这样的热门直播中，大量的在线用户，
自己的观点，宣泄着自己的情绪。用户观看方式的改变，
如此丰富的互动形式势必会给直播间造成很大的并发压力。
意味着一种新体验的诞生，意味着一个新的直播互动时
据统计，CCTV微视的并发请求会经常在数十万级别，通
代到来。
常的直播产品会出现视频卡顿，互动停滞等问题。针对此
CCTV微视作为央视新媒体矩阵中的一份子，为中国
情况，CCTV微视可以灵活调整直播间的架构，使用户感
大陆地区球迷带来完整精彩赛事的直播，凭借着高清、稳
受不到一丝卡顿，热点峰值时段，可以应对一秒钟产生过
定、流畅的直播观看体验和丰富多彩的直播间互动，使
千万的消息，丝毫不会影响直播间用户的参与热情。这一
上千万球迷享受了这一足球盛事。开赛当日，CCTV微视
切都得益于CCTV微视的直播互动业务逻辑设计和架构搭
即在苹果应用商店社交类中排行榜首，逾百万的球迷通
建，下面将对相关技术进行解析。
过CCTV微视观看了世界杯开幕式及揭幕战。赛程刚刚过
半，通过CCTV微视客户端已有2000多万人进行了超过
二 消息逻辑设计
3亿次的世界杯内容观看。在CCTV微视的直播间，用户
送出的互动礼物合计更是超过了4亿件。稳定支撑亿级流
消息是直播互动系统最重要的元素，消息处理做得好
量能力，是CCTV微视的直播互动技术在业界领先的最佳
不好会直接影响用户体验。
佐证。
从业务逻辑时序图上来看，A客户端是发消息方、服
实现这些，CCTV微视又有哪些独门秘籍呢？
务端是CCTV微视后端平台、B客户端是接收消息方。首先，
现代电视技术
48
2018.8
特约专题
俄罗斯世界杯央视转播全解析
取，此时客户端展现的顺序
和服务端存储的顺序是一致
的。实际上消息的顺序会关
系到业务系统的逻辑保证，
比如说：直播间内出现了一
条违规的消息，但是此条消
息已经被下发至客户端，正
常情况下是无法将这条消息
收回的，此时可以通过一些
额外逻辑处理，如下发一条
“追回撤销这条消息的消
息”，这样就可以将这条消
息从客户端抹除，避免不必
要的麻烦。
1
业务逻辑时序图
3. 多条消息可合并
客户端向服务端发送消息，服务端接收消息并进行消息验
实际上消息下发时不包含消息实体，是通过同步的方
证，消息验证里面包含了高危词、敏感词的过滤，反垃圾
式进行消息同步，这个过程有点类似于版本控制软件，一
系统的执行以及权限验证，当消息通过后，对消息优先进
次同步可能拿到很多次的更改。消息也有同样的好处，当
行存储，再向A客户端返回应答，告知消息已经发送成功。
消息很密集的时候下发一条通知，一次性会同步
50条或
这时服务端会遍历成员分发通知，值得注意的是，此
者100条，这样的话可以将客户端与服务器的交互次数降
时还没有向客户端发送消息实体，当接收客户端接收消息
低下来。
通知时，会从本地存储里面拿到当前直播间最新的消息版
本号，同时向服务器发起同步请求，服务器获取客户提交
4. 消息下发条数可控
的版本号后，会以这个版本号为起点到最新版本号把所有
我们可以通过同步控制下发的消息条数，提升客户端
消息全部拿回来返回给客户端，客户端收到这个消息进行
互动体验。例如当客户端设定只能接收100条消息的情况
消息展示以及存储这个最新版本号。
下只返还100条，即使是服务端存储1000条消息，因为返
整个通讯流程版本号的获取方式，跟常用版本控制软
还剩余的900条对客户端的体验并不好。
件比较类似。为什么要把流程设计的如此复杂呢？主要原
因如下文所述。
5. 以存储分级实现消息分级
消息包含分级，同时也会按照分级的方式进行存储，
1. 通知消息无需服务保证
在服务器上主要分为 “高、中、低”三个等级，中和低
因为在通知过程中没有携带消息实体，客户端在下一
级会进行数量控制。例如客户端展示100条消息，我们会
次收到通知后同样可以将所有消息同步下去，所以对于通
优先在中级获取消息80条，会在低级获取剩余的20条。
知来说则不需要质量保证。之前做的正常消息系统都是推
通过这种方式可以保障中优先级成功到达客户端，除此之
送实体，就会存在一个问题，如果当服务器在超时范围之
外，高优先级的消息全部返回，不会进行条数控制。
外没有收到客户端的应答推送之后，服务器可能会进行重
置操作，对于通知来讲则不存在这样的问题。
6. 在线用户数量决定服务器规模
通过此业务逻辑，主要解决的问题就是不再以下发消
2. 服务端与客户端消息顺序一致
息来控制服务器，而是以在线用户数进行考量，因为无论
CCTV微视的消息是按照唯一且递增的客户版本号进
消息多少，用户一次同步就可以把消息全部同步，这样的
行存储的，客户端在获取消息的时候也会按照这个顺序收
话只以在线用户数作为服务器资源计算就可以保证系统的
49
Advanced Television
Engineering
2018/8
Operation & Maintenance
Industry Topics
特
约
专
题
时，通过哈希确定性可以确定用户所在
的服务节点，快速对问题用户进行定位
排查，并自动发现故障节点。当某个服
务节点发生变更的情况下，该节点数据
会进行迁移，可以达到在用户对故障无
感知的前提下排查解决。每个服务节点
包含部分用户关系。整个直播消息服务
构建了一个整体成员关系，等同于直播
消息服务上的一个节点。这层除分发通
知外，还负责客户端同步获取的消息。
四 服务和集群优化
2
架构设计图
1. 利用单机缓存
稳定运行，无论是对成本核算还是服务器模型的计算都会
CCTV微视现在的服务大部分都依赖于一致性哈希方
变得简单。
式，由于哈希的确定性可以充分利用单机的内存进行缓
存，缓存会进行LRU内存淘汰机制的数据保护，防止内存
三 系统架构设计
溢出。由于这种内存的加数方式，可以将服务器配置得相
对低一些，同时由于没有网络IO的存在，CCTV微视的单
CCTV微视目前使用的架构分为连接服务层、业务服
机处理能力可以说是业内领先的。
务层和存储层及ZooKeeper（服务发现）构建成整个大的集
群并进行通讯服务。连接服务层主要是负责客户端与服务
2. 消息由SkipList转换为环形队列
器保持长连接，同时将客户端的协议与内部服务协议进行
每条消息有唯一且递增版本号，消息按照版本号顺序
相互转化。存储层主要负责直播服务维持成员关系在Redis
存储。这样的数据在内存存储情况下，跳表是一种非常合
上的备份，由于应对不同类型的直播活动，CCTV微视需
适的数据结构。但是，跳表时间复杂度和空间复杂度比较
要进行频繁的服务器扩容，新上线的服务需要拿到全部的
大，同时往跳表中插入数据时使用的锁范围非常大，会对
原始数据，所以增加了额外的存储层。
服务器产生一些额外的开销。之后，由跳表演进成一种类
业务服务层负责即时通讯相关业务处理，整体采用微
似环形队列的数据结构，对服务器性能开销提升很多。
服务架构。每个服务节点通过ZooKeeper进行配置同步及
服务发现。所有服务在扩容之后自动向ZooKeeper内进行
3. 复合数据结构
注册，关联服务会自动获取服务节点变化，通过预留的服
Map与队列构建复合数据结构，降低无意义消费。服
务器可以短时间内进行大规模扩容。
务端下发通知，对于通知来讲在这一时刻无论有多少条消
CCTV微视的直播互动场景主要包含如下三项服务：
息，每个用户只有一条通知，通过Map与队列构建这样的
z
上行控制服务，主要目的是用于处理接收的上行客
复合结构进行存储。队列里面存储是数据的指针，Map
存
户端的消息，进行敏感词和高危词的过滤，这个服务的负
储用于下发的通知实体，Map使用的key为用户标识，这
载方式采用的是随机分配的负载方式；
样可以降低无意义的消费。
z
直播服务，负责维护直播间成员关系和负责接收上
行控制服务给它的消息，上行控制服务会先期进行消息抛
4. 数据的预处理
弃，抛弃到直播服务可以接收的范围之内，将消息下发到
当服务端接收消息之后优先对数据进行序列化以及存
直播服务，直播服务再广播到直播消息服务；
储，序列化消息和要下发的客户端数据要保持一致，通过
z
直播消息服务，负责向用户进行分发通知，是以用
这种预处理方式，CCTV微视将CPU的使用率在当前基础
户ID进行一致性哈希方式进行负载。在问题或故障发生
上降低了30%。
现代电视技术
50
2018.8
特约专题
俄罗斯世界杯央视转播全解析
五 5大数据处理机制为世界杯保驾护航
也不会丢失，确保送达。
在世界杯高密度的赛事期间，CCTV微视客户端持续高
4. 抛弃机制
负荷运行。以小组赛阿根廷对阵冰岛的比赛为例，观看比
在产生海量互动消息超过平台预设承载能力时，或者
赛直播用户达150万，同时在线并参与互动用户达20万人。
超过客户端接收消息能力时，我们也可以采用抛弃机制来
任意用户的一句发言，一个送礼物行为，均需通过CCTV
保障用户互动的流畅性。CCTV微视的平台可以自动甄选
微视的直播互动平台，瞬时传递到20万用户的手机终端设
消息，主动抛弃掉无用户属性及低优先级的消息，减轻平
备上。秒内并发亿级消息需求，给平台带来了海量的数据
台压力的同时，还可以保障主持人、嘉宾消息和互动内容
传输和处理压力，如何才能保证其有序进行呢？CCTV微
消息的传递，确保用户可以收到最重要的消息。
视技术团队将处理机制归纳为以下几点：
5. 自动退出机制
1. 归并机制
直播间中用户在离线30秒后或离线后直播间中产生30
即世界杯期间通过消息集归并方式来降低CCTV微视
条消息时会被自动退出直播间。将有效释放直播间资源，
后台压力。
降低直播间的压力。
直播间作为一个特殊的场景，其消息分发量是海量
的，比如有10万用户的一个直播间，如果其中一万用户发
六 最安全HI-FUN直播平台
送了献花或礼物等互动消息，则将会出现10亿的消息并发。
如果有一个VIP入场，也会有10万条VIP进场消息从系统
在保证了架构和消息处理后，还要确保CCTV微视的
发出。如此频繁、庞大的消息并发送会对平台造成很大压
直播互动是在“最安全”的环境下运行的，为此设立如下
力。因此我们优化了消息发送方式，将消息归并发送，控
安全处理手段：
制客户端和服务器端的发送频率。例如常见的送礼物消息，
用户可能会非常快速地发送送礼物请求，我们会每两秒发
1. 数据安全
送给一次送礼物信息，消息中包含了此用户在这两秒的送
CCTV微视将服务集群部署在私有云中，保证数据自
花数量，如此不但有效地缓解了平台压力，还减少了客户
持，安全可靠。利用CCTV微视现有的硬件资源构建云服
端的渲染量，节省流量及电量。
务，从而大幅降低扩容成本；通过私有云部署，可随时访
问数据，减少传统的资源交换，提高资源的利用率。
2. 分桶机制
在热点高峰时段，当直播间的用户量过多并且互动频
2. 消息传输链路加密安全
繁时，会产生巨量的互动消息，给平台造成很大压力，出
在消息传输的链路上，CCTV微视采用的是私有二进
现卡顿，互动延迟的情况，CCTV微视平台会预先对此情
制通信协议，结合链路安全校验与数据加密机制，可防止
况做出预案，对直播间人数进行设置，当一个直播间满员
数据被窃听、篡改，以确保数据信息的传输安全。
时，系统会自动创建子直播间，并将主持人、嘉宾消息和
互动内容消息在所有子直播间内同步。这样当新用户访问
3. 内容安全
直播间时，会自动分配到子直播间中。但是，从用户的角
在直播间内容审核方面，CCTV微视经过多年反垃圾
度看，用户不会感知进入的是子直播间，也不会感知直播
与内容审核经验的积累，拥有上亿的云化DNA库，海量反
间还有人员上限的情况。
垃圾特征数据沉淀，可以精准识别过滤色情、低俗、涉政、
广告、灌水等内容，以“智能过滤”+“人工审核”的双保险，
3. 优先级机制
保障业务安全运行。
CCTV微视的消息量巨大，消息类型众多，为了确保
今年是央视转播世界杯四十周年，在大屏向小屏转换的衔
重要消息不会丢失，我们将消息分为两类，高优先级和低
接中，互动直播技术的应用赋予了世界杯这一超级盛典以创
优先级。 还可以设置用户白名单，确保白名单用户的每一
新的元素，让直播+社交的丰富想象力最终落地，进入亿万
条消息都是高优先级。这样即使在高并发情况，重要信息
用户的大小屏幕中。在这一点，CCTV微视一直在努力。
51
Advanced Television
Engineering
2018/8
Operation & Maintenance
Industry Topics
发布评论