每秒高达千万分发，如何应对直播互动平台中海量消息挑战？

【稿件】由于直播平台的特点，对系统功能设计的可靠性要求更高，同时，如何在直播火热的当下快速实现直播平台的构建，成为很多企业的现实需求。本文主要分享融云直播互动系统的设计与实践，详细介绍礼物、红包等以消息为基础的互动方案设计思路和实践方案并阐述如何结合融云自身技术优势，助力直播企业快速布局市场。

直播互动平台的特点

融云于 2014 年成立时，国内直播平台还未大批兴起，当时我们只提供聊天室服务。2015 年，源于大量客户对直播互动的需求，融云预见直播平台未来会有很好的前景，于是开始与客户积极交流来挖掘需求，最终我们将聊天室转变为直播互动平台。经历了 2016 年一个完整的直播元年，直播互动系统也正式步入了成熟期。

目前，融云主要做实时通信云平台，就是所谓的 IM 云，提供包含单聊、群聊、客服、推送、公众账号、直播平台等云服务。得益于 2016 年直播市场的异常火热，平台每天可达到对外产生 2200 亿条消息，峰值每小时 450 亿，每秒高达千万的分发。

直播互动平台的特点是什么呢?我们做视频直播的时候，可能有用户需要跟主播以及其他用户发一些文字消息、点赞消息等等进行互动，由于这些消息的存在，把以前单纯的只是受众于视频的应用这种视频直播，变成了可以进行互动的平台。

用户在平台发消息进行互动，这个互动场景和聊天室类似，就是用户加入聊天室，可收到别人的消息，同时也可发送消息，用户下线时消息不再进行推送，这个场景实际上可以满足简单的直播互动。

相较其他 IM 来讲，没有离线消息存储，也没有离线消息 Push，在业务形态来讲，聊天室比较简单一些。

如下是直播互动平台的主要特性：

• 直播互动平台的用户量实际是无上限的，因为不可能去限制一个主播加入观众的成员数量。
• 通过把消息进行分级控制的方式来保证礼物、红包等消息传输的可靠性。
• 瞬时消息吞吐量大，融云某个聊天室曾经一秒钟产生过近千万的消息。
• 针对伸缩及稳定性方面的高要求。

消息平台的逻辑设计及设计原理

消息是直播互动系统最重要的元素，消息处理做的好不好会直接影响用户的体验。融云的消息平台逻辑设计是怎样的呢?

如上图，我用一张时序图针对这个问题进行了解答。A 客户端是发消息方，服务端是融云整个后端平台，B 客户端是接收消息方。

首先，客户端向服务端发送消息，服务端接收消息先进行消息验证，消息验证里面包含了高危词、敏感词的过滤，反垃圾系统对消息进行反垃圾的过滤及权限验证。

当消息通过之后，对消息优先进行存储，之后会给 A 客户端返回应答，告知消息已经发送成功，这时服务端会遍历成员分发通知。

值得注意的是，现在还没有向客户端发送消息实体，当接收客户端接收消息通知时，会从自己本地存储里面拿到当前直播间里面最新的消息版本号。

同时向服务器发起同步请求，服务器获取客户提交的版本号之后，会以这个版本号为起点，到最新版本号把所有消息全部拿回来返回给客户端，客户端收到这个消息进行消息展示以及存储这个最新版本号。

整个通信流程，版本号获取方式，跟常用版本控制软件比较类似。之所以把流程变得这么复杂，在发送完通知之后再同步消息，主要原因如下：

• 通知的推送重试可以依赖 TCP 的重试，无须逻辑保障。
• 服务器端存储的消息顺序与到达的客户端顺序一致。
• 当消息密集时可以将多条消息进行合并。
• 可以控制下发的消息条数。
• 以存储分级实现消息分级。
• 不以消息数量衡量服务器规模，以在线用户数量做为考量。

消息平台在服务端实现细节及最佳应用实践

直播消息系统在服务端的实现细节，主要从数据预处理、消息分级、消息存储和消息分发队列四方面进行介绍，但在实际服务开发过程中，还有很多优化。

数据预处理

当服务端接收消息之后，优先对数据进行序列化以及存储，序列化消息和要下发的客户端数据要保持一致，通过这种预处理的方式，CPU 的使用率在当前基础上降低了 30%。

消息分级存储

根据消息类型按照中、高、低序列进行分级存储。

Skiplist 转化为环形队列存储

每条消息有唯一且递增版本号，消息按照版本号顺序存储。这样的数据在内存存储情况下，跳表是一种非常合适的数据结构。

但是，跳表时间复杂度和空间复杂度比较大，同时往跳表中插入数据时使用的锁范围非常大，会对服务器产生一些额外的开销。之后，由跳表演进成一种类似环形队列的数据结构，会对服务器性能开销提升很多。

Map 与队列构建复合数据结构，降低无意义消费

服务端下发通知，对于通知来讲在这一时刻无论有多少条消息，每个用户只有一条通知，通过 Map 与队列构建这样的复合结构进行存储。

队列里面存储是数据的指针，Map 存储用于下发的通知实体，Map 使用的 key 为用户标识，这样可以降低无意义的消费。

融云线上直播互动平台的整体架构

直播互动平台的 2.1 架构

如上图，是融云线上 2.1 架构图，可分为连接层、业务层和存储层等，连接层和业务层构建成整个大的集群，然后进行服务。

连接层主要是负责客户端与服务器保持长连接，同时将客户端的协议与内部服务的协议进行相互转化。

业务层负责 IM 相关业务处理，采用的是微服务架构，线上服务有 40 多个类型，但对于直播互动平台包含如下三项服务：

• 上行控制服务。主要目的是用于处理接收的上行客户端的消息，进行敏感词和高危词的过滤。这个服务的负载方式采用的是随机分配。
• 直播服务。负责维护直播间的成员关系和负责接收上行控制服务给它的消息，上行控制服务会先期进行消息抛弃，抛弃到直播服务可以接收的范围之内，然后将消息下发到直播服务，直播服务再广播到直播消息服务。
• 直播消息服务。负责给用户进行分发通知，是以用户 ID 进行一致的哈希方式进行负载。每个服务节点包含部分用户关系。

整个直播消息服务构建了一个整体成员关系，等同于直播消息服务上的一个节点。这层除分发通知外，还负责客户端同步拉取获取的消息。

存储层主要职责是用来存储各种消息，数据等，含多个数据库。

线上 2.1 架构和之前的架构相比，降低了直播服务压力和上行总量的控制，但面临的问题是需要更高的网络质量要求。

直播互动平台的网络优化

如下图，是链路架构 1.0：

链路架构 1.0，线上进行网络加速主要是加速海外业务。融云选购了第三方海外专线链路，涉及全球五个国家，覆盖欧洲、美洲以及中东、日本等等。

实现国际链路优化，就近区域接入的同时，又出现专线的流量过大，成本过高，跨国消息延时等问题。

如下图，是链路架构 2.0：

链路架构 2.0 采用模拟 CDN 模式进行数据分发，专线内只跑上行消息和广播消息的方式。

融云提供的是直播互动平台，是一个基础的 PAAS 服务，本身并不会去做直接面对用户的直播 APP。未来，它也会不停地向前探索，如降低专线的依赖，数据中心进行链路选择等。

以上内容根据李淼老师在 WOTA2017 “高性能直播系统架构”专场的演讲内容整理。

负责融云后端服务平台的设计和架构工作，2007-2013 年就职于移动飞信团队，历任高级技术经理，架构师，一直关注大规模高并发系统设计和研究。

【原创稿件，合作站点转载请注明原文作者和出处为.com】

本文题目：每秒高达千万分发，如何应对直播互动平台中海量消息挑战？
转载来源：http://www.shufengxianlan.com/qtweb/news31/359281.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联