一、背景

即时消息 (IM) 零碎是直播零碎重要的组成部分，一个稳固的，有容错的，灵便的，反对高并发的音讯模块是影响直播零碎用户体验的重要因素。IM 长连贯服务在直播零碎有施展着无足轻重的作用。

本篇文章针对秀场直播，简略地形容一下音讯模型，阐明一下咱们音讯模型的架构，并联合咱们一年以来，通过解决不同的业务线上问题，来进行演进式的音讯模型架构的降级与调整，将此整顿成文，并分享給大家。

在目前大部分支流的直播业务中，推拉流是实现直播业务最根本的技术点，音讯技术则是实现观看直播的所有用户和主播实现互动的关键技术点，通过直播 IM 零碎模块，咱们能够实现公屏互动，黑白弹幕，全网送礼播送，私信，PK 等外围秀场直播的性能开发。”IM 音讯 ” 作为用户和用户，用户和主播之间 ” 沟通 ” 的信息桥梁，如何保障 ” 信息桥梁 ” 的在高并发场景下保持稳定牢靠，是直播零碎演进过程中一个重要的话题。

二、直播音讯业务

在直播业务中，有几个外围的对于音讯模型的概念，咱们先简略地介绍一下，不便大家对直播相干的音讯模型有一个整体上的了解。

2.1 主播与用户

主播和观众，对于 IM 零碎来说，都是一个普通用户，都会有一个惟一用户标识，也是 IM 散发到点对点音讯的重要标识。

2.2 房间号

一个主播对应一个房间号(RoomId), 主播在开播之前，进行身份信息验证之后，就会绑定惟一的房间号，房间号是 IM 零碎进行直播间音讯散发的重要标识。

2.3 音讯类型划分

依照直播业务个性，IM 音讯划分的形式有很多形式，例如依照接管方维度进行划分，依照直播间音讯业务类型进行划分，依照音讯的优先级，存储形式都能够进行不同的划分等等形式。

通常，咱们依照接管方维度进行划分有如下几个类型的音讯：

• 点对点音讯(单播音讯)
• 直播间音讯(群播音讯)
• 播送音讯

依照具体的业务场景有如下几个类型的音讯：

• 礼物音讯
• 公屏音讯
• PK 音讯
• 业务告诉类音讯

音讯可能实时精确地散发到对应的群体或者单个用户终端都是十分必要的。当然好一点的 IM 音讯模型也可能赋能业务一些新的能力，例如如下的能力：

• 统计每个直播间的实时在线人数
• 捕捉用户进出直播间的事件
• 统计每个用户实时进入直播间的工夫

2.4 音讯优先级

直播的音讯是有优先级的，这一点是很重要的，与微信，QQ 等聊天 IM 产品不一样的中央是直播间音讯是分优先级的。

微信等聊天音讯产品，不论是私聊还是群聊，每个人发送音讯的优先级基本上是一样的，不存在谁的音讯优先级高，谁的音讯优先级低，都须要将音讯精确实时地散发到各个业务终端，然而直播因为业务场景的不同，音讯散发的优先级也是不一样的。

举例来说，如果一个直播间每秒只能渲染 15~20 个音讯，如果一个热点直播间一秒钟产生的音讯量大于 20 条或者更多，如果不做音讯优先级的管制，间接实时散发音讯，那么导致的后果就是直播间公屏客户端渲染卡顿，礼物弹框渲染过快，用户观看体验大幅降落，所以咱们要针对不同业务类型的音讯，给出不同的音讯优先级。

举例来说，礼物音讯大于公屏音讯，等同业务类型的音讯，大额礼物的音讯优先级又大于小额礼物的音讯，高等级用户的公屏音讯优先级高于低等级用户或者匿名用户的公屏音讯，在做业务音讯散发的时候，须要依据理论的音讯优先级，选择性地进行音讯精确地散发。

三、音讯技术点

3.1 音讯架构模型

3.2 短轮询 VS 长链接

3.2.1 短轮询

3.2.1.1 短轮询的业务模型

首先咱们先简略地形容一下短轮询工夫的过程和根本设计思维：

• 客户端每隔 2s 轮询服务器接口，参数是 roomId 和 timestamp，timestamp 第一次传递 0 或者 null。
• 服务器依据 roomId 和 timestamp 查问该房间在 timestamp 工夫戳后产生的音讯事件，返回限定条数的音讯例如（例如返回 10~15 条，当然在这个 timestamp 之后产生的音讯数远远大于 15 条，不过因为客户端渲染能力无限和过多的音讯展现，会影响用户体验，所以限度返回的条数），并且同时返回这些音讯中最初一条音讯产生的工夫戳 timestamp，作为客户端下次申请服务器的基准申请工夫戳。
• 以此重复，这样就能够每隔 2s 依照各个终端要求，更新每个直播间的最新消息了

整体的主体思维如上图所示，不过具体的工夫能够再做精细化解决，后续再做具体的阐明和细节阐明。

3.2.1.2 短轮询的存储模型

短轮询的音讯存储与失常的长连贯的音讯存储有肯定的区别，不存在音讯扩散的问题，咱们须要做的音讯存储须要达到如下的业务指标：

• 音讯插入工夫复杂度要绝对比拟低；
• 音讯查问的复杂度要绝对比拟低；
• 音讯的存储的构造体要绝对比拟小，不能占用太大的内存空间或者磁盘空间；
• 历史音讯可能依照业务须要做磁盘长久化存储；

联合上述 4 点的技术要求，毕竟通过小组成员的探讨，咱们决定应用 Redis 的 SortedSet 数据结构进行存储，具体实现思路：依照直播间产品业务类型，将业务音讯划分为如下四大类型：礼物，公屏，PK，告诉。

一个直播间的音讯应用四个 Redis 的 SortedSet 数据结构进行存储，SortedSet 的 key 别离是 ”live::roomId::gift”,”live::roomId::chat”,”live::roomId::notify”,”live::roomId::pk”，score 别离是音讯实在产生的工夫戳，value 就是序列化好的 json 字符串，如下图所示：

客户端轮询的时候，服务端查问的逻辑如下所示：

很多同学会疑难，为什么不实用 Redis 的 list 的数据结构呢？如下图会进行具体的阐明：

最初咱们再比照一下 Redis 的 SortedSet 和 Redis 的 List 这两个数据结构在直播音讯存储的时候，工夫复杂度的相干剖析。

以上，就是咱们应用 Redis 的 SortedSet 数据结构进行音讯存储的一些简略的设计思考，后续咱们也会提到端轮询的编码时候，须要的留神点。

3.2.1.3 短轮询的工夫管制

短轮询的工夫管制及其重要，咱们须要在直播观众观看体验 QoE 和服务器压力之间找到一个很好的平衡点。

轮询的间隔时间太长，用户体验就会降落很多，直播观看体验就会变差，会有 ” 一顿一顿 ” 的感觉。短轮询的频率过高，会导致服务器的压力过大，也会呈现很屡次 ” 空轮询 ”，所谓的 ” 空轮询 ” 就是有效轮询，也就是在上一秒无效轮询返回无效音讯之后，间隔期直播间没有产生新的音讯，就会呈现有效的轮询。

vivo 直播目前每日的轮询次数是 10+ 亿次，晚观看直播高峰期的时候，服务器和 Redis 的 CPU 负载都会回升，dubbo 的服务提供方的线程池始终处于高水位线上，这块须要依据机器的和 Redis 的实时负载的压力，做服务器的程度扩容和 Redis Cluster 的节点扩容，甚至让一些超高热度值的直播间负载到指定的 Redis Cluster 集群上，做到物理隔离，享受到 ”VIP” 服务，确保各个直播间的音讯互相不影响。

直播人数不一样的直播间，轮询的工夫也是能够配置的，例如人数比拟少的直播，百人以下的直播间，能够设置比拟高频的轮询频率，例如 1.5s 左右，超过 300 人以上的，1000 人以下能够 2s 左右，万人直播间能够设置 2.5s 左右，这些配置应该都能够通过配置核心实时下发，客户端可能实时更新轮询的工夫，调整的频率能够依据理论直播间用户体验的成果，并且联合服务器的负载，找到一个轮询距离的绝对最佳值。

3.2.1.4 短轮询的留神点

1）服务端须要校验客户端传递过去的工夫戳：这一点十分重要，试想一下，如果观众在观看直播的时候，将直播退出后盾，客户端轮询过程暂停，当用户复原直播观看画面过程的时候，客户端传递过去的工夫就会是十分老旧甚至过期的工夫，这个工夫会导致服务器查问 Redis 时呈现慢查，如果呈现大量的服务器慢查的话，会导致服务器连贯 Redis 的连贯无奈疾速开释，也会拖慢整个服务器的性能，会呈现一瞬间大量的轮询接口超时，服务质量和 QoE 会降落很多。

2）客户端须要校验反复音讯：在极其状况下，客户端有可能收到反复的音讯，产生的起因可能如下，在某一个时刻客户端收回 roomId=888888&timestamp=t1 的申请，因为网络不稳固或者服务器 GC 的起因，导致该申请解决比较慢，耗时超过 2s，然而因为轮询工夫到了，客户端又收回了 roomId=888888&timestamp=t1 的申请，服务器返回雷同的数据，就会呈现客户端反复渲染雷同的音讯进行展现，这样也会影响用户体验，所以每一个客户端有必要对反复音讯进行校验。

3）海量数据无奈实时返回渲染的问题：构想一下，如果一个热度极大的直播间，每秒钟产生的音讯量是数千或者上万的时候，依照下面的存储和查问思路是有破绽的，因为咱们每次因为各个因素的限度，每次只返回 10~20 条音讯，那么咱们须要很长的工夫能力把这热度很多的一秒钟的数据全副返回，这样就会造成最新的音讯无奈疾速优先返回，所以轮询返回的音讯也能够依照音讯优先级进行选择性抛弃。

客户端轮询服务服务器查问直播间的音讯的益处是不言而喻的，音讯的散发是十分实时和精确的，很难呈现因为网络颤动导致音讯无奈达到的场景，不过害处也是非常明显的，服务器在业务高峰期的负载压力很大，如果直播间的所有音讯都是通过轮询散发的，长期以往，服务器是很难通过程度扩容的形式来达到线性增长的。

3.2.2 长连贯

3.2.2.1 长连贯的架构模型

从流程上来说，如上图所示，整体直播长连贯的流程：

手机客户端首先通过 http 申请长连贯服务器，获取 TCP 长连贯的 IP 地址，长连贯服务器依据路由和负载策略，返回最优的可连贯的 IP 列表。

手机客户端依据长连贯服务器返回的 IP 列表，进行长连贯的客户端的连贯申请接入，长连贯服务器收到连贯申请，进而建设连贯。

手机客户端发送鉴权信息，进行通信信息的鉴权和身份信息确认，最初长连贯建设实现，长连服务器须要对连贯进行治理，心跳监测，断线重连等操作。

长连贯服务器集群的根本架构图如下所示，依照地区进行业务划分，不同地区的终端机器按需接入；

3.2.2.2 长连贯建设和治理

为了使音讯即时、高效、平安地触达用户，直播客户端和 IM 零碎建设了一条加密的全双工数据通路，收发音讯均应用该通道，当大量用户在线的时候，保护这些连贯、放弃会话，须要用到大量内存和 CPU 资源。

IM 接入层尽量放弃性能简洁，业务逻辑下沉到前面逻辑服务中进行解决，为了避免公布的时候，重启过程会导致大量的外网设施从新建设连贯，影响用户体验。接入层提供热更新的公布计划：连贯保护，账号治理等不常常改变的根底逻辑放入主程序中，业务逻辑采纳 so 插件的形式嵌入到程序的，批改业务逻辑时只须要从新加载一次插件即可，能够保障与设施的长连贯不受影响。

3.2.2.3 长连贯保活

长连贯建设后，如果两头网络断开，服务端和客户端都无奈感知，造成假在线的状况。因而保护好这个“长连贯”一个要害的问题在于可能让这个“长连贯”可能在两头链路呈现问题时，让连贯的两端可能疾速失去告诉，而后通过重连来建设新的可用连贯，从而让咱们这个长连贯始终放弃高可用状态。IM 在服务端开启了 keeplive 保活探测机制和在客户端启用了智能心跳。

• 利用 keeplive 保活探测性能，能够探知客户端解体、两头网络端开和中间设备因超时删除连贯相干的连贯表等意外状况，从而保障在意外产生时，服务端能够开释半关上的 TCP 连贯。
• 客户端启动智能心跳不仅能在耗费极少的电和网络流量条件下，告诉服务器客户端存活状态、定时的刷新 NAT 内外网 IP 映射表，还能在网络变更时主动重连长连贯。

3.2.3 直播间 IM 音讯散发

IM 长连贯散发音讯的整体流程图

在整合客户端，IM 长连贯服务器模块和直播业务服务器模块这三个模块的时候，整体音讯的散发逻辑遵循如下的根本准则：

• 单播，群播，播送音讯所有的音讯都是由直播业务服务器调用 IM 长连贯服务器的接口，将须要散发的音讯散发到各个业务直播间。
• 业务服务器对直播间产生的事件进行对应的业务类型做响应的解决，例如送礼扣减虚构货币，发送公屏进行文本衰弱校验等。
• 客户端承受直播业务服务器的信令管制，音讯是通过长连贯通道散发还是 http 短轮询散发，都是由直播业务服务器管制，客户端屏蔽底层音讯获取的形式细节，客户端下层承受对立的音讯数据格式，进行对应的业务类型音讯解决渲染。

3.2.3.1 直播间成员治理和音讯散发

直播间成员是直播间最重要的根底元数据，单个直播间的用户量实际上是无下限的，且出现大直播若干个(大于 30W 同时在线）、中直播间几百个、小直播几万个这样散布，如何治理直播间成员是一个直播间零碎架构中外围性能之一，常见的形式有如下两种：

1. 为直播间调配 固定分片，用户与具体的分片存在映射关系，每个分片中保留用户绝对随机。

采纳固定分片的形式算法实现简略，然而对于用户少的直播间有可能分片承载的用户数量少，对于用户大的直播间有可能分片承载用户量又比拟大，固定分片存在人造伸缩性差的特点。

2.动静分片，规定分片用户数，当用户数超过阈值时，减少一个新的分片，分片数量能够随着用户数减少而变动。

动静分片能够依据直播间人数主动生成分片，满了就开拓新片，尽量使每个分片的用户数达到阈值，但已有分片的用户数量随着用户进出直播间变动，保护复杂度比拟高。

3.2.3.2 直播间音讯散发

直播间中有进出场音讯、文本音讯、礼物音讯和公屏音讯等多种多样音讯，音讯的重要水平不一样，可为每个音讯设定相应的优先级。

不同优先级的音讯放在不同的音讯队列中，高优先级的音讯优先发送给客户端，音讯沉积超过限度时，抛弃最早、低优先级的音讯。另外，直播间音讯属于实时性音讯，用户获取历史音讯、离线音讯的意义不大，音讯采纳读扩散的形式存储组织。直播间音讯发送时，依据直播间成员分片告诉对应的音讯发送服务，再把音讯别离下发给分片中对应的每一个用户，为了实时、高效地把直播间音讯下发给用户，当用户有多条未接管音讯时，下发服务采纳批量下发的形式将多条音讯发送给用户。

3.2.3.3 长连贯的消息压缩

在应用 TCP 长连贯散发直播间音讯的时候，也须要留神音讯体的大小，如果某一个时刻，散发音讯的数量比拟大，或者同一个音讯在做群播场景的时候，群播的用户比拟多，IM 连贯层的机房的进口带宽就会成为音讯散发的瓶颈。所以如何无效的管制每一个音讯的大小，压缩每一个音讯的大小，是咱们也须要思考的问题，咱们目前通过两种形式来来做相干音讯体构造的优化：

应用 protobuf 协定数据交换格局

雷同类型的音讯进行合并发送

通过咱们线上测试，应用 protobuf 数据交换格局，均匀每一个音讯节俭 43% 的字节大小，能够大大帮忙咱们节俭机房进口带宽。

3.2.3.4 块音讯

所谓块音讯，也是咱们借鉴其余直播平台的技术计划，也就是多个音讯进行合并发送，直播业务服务器不是产生一个音讯就立马调用 IM 长连贯服务器集群间接进行音讯的散发。次要思维，就是以直播间为维度，每隔 1s 或者 2s，以匀速的工夫距离将在这个时间段业务零碎产生的音讯进行散发。

每秒散发 10~20 个音讯，如果每秒中，业务服务器积攒到的音讯大于 10~20 个，那就依照音讯的优先级进行抛弃，如果这 10~20 个音讯的优先级都比拟高，例如都是礼物类型的音讯，则将音讯放在后一个音讯块进行发送，这样做的益处有如下三个；

合并音讯，能够缩小传输多余的音讯头，多个音讯一起发送，在自定义的 TCP 传输协定中，能够共用音讯头，进一步缩小音讯字节数大小；

防止出现音讯风暴，直播业务服务器能够很不便的管制音讯散发的速度，不会无限度的散发音讯到直播客户端，客户端无奈解决如此多的音讯；

敌对的用户体验，直播间的音讯因为流速失常，渲染的节奏比拟平均，会带来很好的用户直播体验，整个直播成果会很晦涩

3.3 音讯抛弃

不论是 http 短轮询还是长连贯，在高热度值直播间呈现的时候，都会存在音讯抛弃的状况，例如在游戏直播中，有呈现比拟精彩霎时的时候，评论公屏数会霎时减少，同时送低价值的礼物的音讯也会霎时减少很多，用来示意对本人选手精彩操作的反对，那么服务器通过 IM 长连贯或者 http 短轮询每秒散发的音讯数就会数千或者上万，一瞬间的音讯突增，会导致客户端呈现如下几个问题；

客户端通过长连贯获取的音讯突增，上行带宽压力突增，其余业务可能会受到影响（例如礼物的 svga 无奈及时下载播放）；

客户端无奈疾速解决渲染如此多的礼物和公屏音讯，CPU 压力突增，音视频解决也会受到影响；

因音讯存在积压，导致会展现过期已久音讯的可能，用户体验（QoE）指标会降落。

所以，因为这些起因，音讯是存在抛弃的必要的，举一个简略的例子，礼物的优先级肯定是高于公屏音讯的，PK 进度条的音讯肯定是高于全网播送类音讯的，高价值礼物的音讯又高于低价值礼物的音讯。

依据这些业务实践，咱们在实在代码开发中，能够做如下的管制：

联合具体业务特点，给各个业务类型的音讯划分出不同等级，在音讯散发触发流控的时候，依据音讯优先级选择性抛弃低优先级音讯。

音讯构造体新增创立工夫和发送工夫两个字段，在理论调用长连贯通道的时候，须要判断以后工夫与音讯的创立工夫是够距离过大，如果过大，则间接抛弃音讯。

增益音讯(纠正音讯)，在业务开发中，音讯的设计中，尽量地去设计增益音讯，增益音讯指的是后续达到的音讯可能蕴含前续达到的音讯，举例来说，9 点 10 的音讯，主播 A 和主播 B 的 PK 值是 20 比 10，那么 9 点 11 分散发的 PK 音讯值就是 22 比 10，而不能散发增量音讯 2:0，心愿客户端做 PK 条的累加（20+2：10+0），然而存在音讯因为网络颤动或者前置音讯抛弃，导致音讯抛弃，所以散发增益音讯或者纠正音讯会可能帮忙业务从新恢复正常。

四、写在最初

任何一个直播零碎，随着业务的倒退和直播间人气一直的减少，音讯零碎遇到的问题和挑战也会随之而来，不论是长连贯的音讯风暴，还是海量 http 短轮询的申请，都会导致服务器压力的剧增，都是咱们须要一直解决和优化的。咱们要针对每一个期间的业务特点，做直播音讯的继续降级，做可演进的音讯模块，确保音讯散发的能力可能确保业务的继续倒退。

vivo 直播音讯模块也是逐渐演进的，演进的能源次要来自于因为业务的倒退，随着业务状态的多样化，观看的用户数越来越多，零碎的性能也会逐渐增多，也会遇到各种性能瓶颈，为了解决理论遇到的性能问题，会逐个进行代码剖析，接口性能瓶颈的剖析，而后给出对应的解决方案或者解耦计划，音讯模块也不例外，心愿这篇文章可能给大家带来相干直播音讯模块的设计启发。

作者：vivo 互联网技术 -LinDu、Li Guolin