【.com原创文章】由于直播平台的特点，系统功能设计的可靠性更高。同时，如何快速实现直播平台的搭建成为了众多企业的实际需求。本文主要分享融云直播互动系统的设计与实践，详细介绍礼物、红包等消息类交互方案的设计思路和实战方案，并阐述如何结合融云自身技术优势助力直播公司迅速布局市场。直播互动平台特点2014年融云成立时，国内直播平台还未大量涌现。当时，我们只提供聊天室服务。2015年，由于大量客户对直播互动的需求，融云预见到直播平台大有可为，于是开始积极与客户沟通，挖掘需求，最终我们对聊天室进行了改造成为直播互动平台。经过2016年完整的直播元年，直播互动系统正式进入成熟阶段。融云目前主要做实时通讯云平台，也就是所谓的IM云，提供包括单聊、群聊、客服、推送、公众号、直播平台等云服务。得益于2016年异常火爆的直播市场，平台每天可产生2200亿条消息，峰值可达每小时450亿条，每秒消息数千万条。直播互动平台有哪些特点？我们在做视频直播的时候，可能有一些用户需要和主播等用户进行一些互动，比如发送一些短信，比如消息等，由于这些消息的存在，使得之前的纯观众这类视频直播的应用在视频已成为互动的平台。用户通过在平台上发送消息进行交互。这种交互场景类似于聊天室，即用户加入聊天室后，可以接收和发送其他人的消息。当用户离线时，不会推送消息。这个场景其实可以满足简单的直播交互。与其他IM相比，没有离线消息存储，也没有离线消息推送。在业务形态上，聊天室比较简单。以下是直播互动平台的主要特点：直播互动平台的用户数量实际上是无限的，因为无法限制主持人可以加入观众的会员数量。通过对消息进行分级控制，保证礼物、红包等消息传输的可靠性。即时消息吞吐量大，曾在融云某聊天室每秒产生近千万条消息。满足对拉伸和稳定性的高要求。消息平台逻辑设计与设计原则消息是直播交互系统中最重要的元素，消息处理的好坏直接影响用户体验。融云消息平台的逻辑设计是怎样的？如上图所示，我用时序图来回答这个问题。客户端A是消息的发送者，服务端是融云整个后台平台，客户端B是消息的接收者。首先，客户端向服务端发送消息，服务端收到消息后首先进行消息校验。邮件验证包括高危词和敏感词的过滤，反垃圾邮件系统对邮件进行反垃圾邮件过滤和权限验证。消息传递后，先存储消息，然后返回响应给客户端A，通知消息发送成功。这时服务器会遍历成员分发通知。值得注意的是，消息实体还没有发送到客户端。接收客户端收到消息通知后，会从本地存储中获取当前直播间最新的消息版本号。同时向服务器发起同步请求。服务端获取到客户端提交的版本号后，会以这个版本号为起点，将所有消息返回最新的版本号，返回给客户端。客户端收到此消息进行消息显示和存储。最新版本号。整个通信过程和获取版本号的方法与普通的版本控制软件类似。通知发送后同步消息的过程如此复杂的主要原因如下：通知推送重试可以依赖TCP重试，没有逻辑保证。消息存储在服务器端的顺序与它们到达客户端的顺序相同。当消息密集时，可以合并多条消息。您可以控制发送的消息数量。消息分级是通过存储分级来实现的。服务器规模不是以消息数来衡量的，而是以在线用户数来衡量的。服务端消息平台实现细节及最佳应用实践服务端消息平台实现细节主要从数据预处理、消息分类、消息存储、消息分发队列四个方面进行介绍。但是在实际的服务开发过程中，也有很多的优化。数据预处理当服务器收到消息时，它优先对数据进行序列化和存储。序列化后的消息必须与要传递的客户端数据一致。通过这种预处理方式，CPU使用率比现在高。减少30%。消息的分级存储是根据消息的类型按照中、高、低的顺序进行的。Skiplist转化为一个环形队列来存储每条消息，版本号是唯一且递增的，消息按照版本号的顺序存储。当这样的数据存储在内存中时，跳转表是一种非常适合的数据结构。但是跳表的时间复杂度和空间复杂度都比较大。同时，向跳表插入数据时使用的锁范围非常大，会对服务器造成一些额外的开销。之后，跳秀演变成类似环形队列的数据结构，会大大增加服务器的性能开销。Map和queue构建复合数据结构，减少无意义的消费。服务器发送通知。对于通知来说，无论此时有多少条消息，每个用户只有一条通知，通过Map和队列构建这样一个复合结构来存储。.数据的指针存储在队列中，用于传递地图的通知实体存储，地图使用的key是用户ID，可以减少无意义的消费。融云在线直播互动平台整体架构直播互动平台2.1架构如上图所示，为融云在线2.1架构图，分为连接层、业务层和存储层。集群，然后服务。连接层主要负责维护客户端和服务端的长连接，同时转换客户端的协议和内部服务的协议。业务层负责IM相关的业务处理。它采用微服务架构。在线服务有40多种，但直播互动平台包括以下三种服务：上行控制服务。主要目的是对接收到的上行客户端报文进行处理，过滤敏感词和高危词。此服务的加载方法是随机分配的。现场服务。负责维护直播间的会员关系，负责接收上行控制服务的消息。上行控制服务会提前丢弃消息，在直播服务可以接收的范围内丢弃，然后将消息发送给直播服务，直播服务再广播给一个直播消息服务。实时消息服务。它负责向用户分发通知，用户ID用于一致性哈希。每个服务节点都包含用户关系的一个子集。整个直播消息服务构建了一个整体会员，相当于直播消息服务上的一个节点。这一层除了分发通知外，还负责同步拉取客户端获取的消息。存储层的主要职责是存储各种消息、数据等，包括多个数据库。在线2.1架构相比之前的架构，减轻了直播业务的压力和上行总量的控制，但面临的问题是对网络质量要求更高。直播互动平台的网络优化如下图所示，为链路架构1.0：链路架构1.0，在线网络加速主要是加速海外业务。融云购买了第三方海外专线链接，涉及全球五个国家，覆盖欧美、中东、日本等。实现国际链路的优化，在连接就近区域的同时，存在专线流量过大、费用高、跨境报文延迟等问题。下图为LinkArchitecture2.0：LinkArchitecture2.0采用模拟CDN方式进行数据分发，在专线只跑上行报文和广播报文。融云提供的是一个直播互动平台，是一个基础的PaaS服务。它并没有做一个直接面向用户的直播APP。未来会继续向前探索，比如减少对专线的依赖，数据中心的链路选择等。以上内容根据李淼老师在WOTA2017《高性能直播系统架构》的演讲内容整理而成。负责融云后端服务平台的设计和架构。2007-2013年就职于中国移动飞信团队。曾任高级技术经理和架构师。一直专注于大规模高并发系统的设计与研究。【原创稿件，合作网站转载请注明原作者和出处为.com】
