案例分析——快手百万在线直播

一、前言

首先分享出原文链接http://www.infoq.com/cn/news/2017/09/streaming-Pipeline-kuaishou。自己平时并未用过快手，但是通过“宇宙中心”——五道口快手巨大的LOGO以及老家小伙伴的聊天内容来看，快手还是相当火爆的。虽然，直播这个技术看起来很简单，但是能够同时支撑百万人的实时直播就需要很强的技术功力了。

二、博文整理

挑战：通常情况下主播都是用手机，网速无法保证，如何保证观众观看的流畅度

解决方案：实时监测主播手机网络状态，根据网络状态动态调整视频码率。因为视频的录制、编辑（美颜、水印等）、编码压缩等操作都是在主播手机上发生的，因此直播视频的码率还需要根据主播的手机配置（CPU，摄像头像素等）调整，在保证直播流畅的前提下尽量的提升画质。另一方面，就需要购买足够的带宽、CDN等资源了。

挑战：主播和观众互动的时候，如果解决跨线路、CDN的数据不同步的问题（秒杀顺序问题）

解决方案：主播的直播内容会推送到一个CDN源，然后这个CDN源将编码后的视频流分发到各个CDN厂商的服务器上，观众通过连接CDN厂商的服务器来获取直播内容；在分发视频源的过程中，需要保证各个CDN得到的视频与直播信号的延时以及各个CDN之间传输的延时在一个可接受的范围内（需要与每个CDN厂商协调），这样才能保证不同地区的用户同步（相差不大）看到直播。最好的方法是：自建CDN；

链路运行监控

解决方案：在直播端，统计主播手机的各个参数信息，直播过程中将手机CPU、内存、视频帧率等信息上传到监控中心；视频向CDN源站推送的过程中，监测连接质量以及网络延时。用户播放端，统计DNS解析、网络延时（从发送请求到收到应答包）、缓冲区大小（缓冲区越大，一次请求传输的数据越多，播放效果越流畅）。

从手机端统计到的监控数据会发送到监控中心的服务器，数据处理流程是：kafka作为可靠的消息队列负责接收上报的统计数据，kafka中的数据可以被消费两次，一次是用于实时处理展示（通过Flink从kafka消费数据并进行清洗，然后写入到Elastic Search集群，利用Kibana实时展示Elastic Search中存储的信息，存储量小导致只能保存最近一段时间的数据），另一种是非实时的（Hadoop集群消费Kafka中的数据并进行对应的处理，将处理后的数据写入Hive数据库，实时性差但是存储量大）主要用于存储历史数据供后期复盘分析使用。

监控数据分析、使用

解决方案：利用Elastic Search或者Hive中存储的数据可以从两个维度来进行分析展示：1、用户体验质量（QoE）：直播在线人数、直播跳出率等，通过分析这些数据以及相关的直播内容，可以推断出这些指标的变化是直播内容（无聊、违规等）导致的还是技术原因导致的。利用这些监控指标，可以及时的处理一些违规直播内容或者找出产品存在的某些缺陷。2、服务质量（QoS）：纯技术参数（如视频帧率变化、直播延迟等问题），很多时候可以结合QoE来精确定位一些问题。

上线流程

解决方案：添加新模块、bug修复等操作完成后，需要通过灰度验证、AB测试的方式进行上线，上线前需要测试回滚流程以保证在灰度的过程中出现BUG可以很快的回滚到之前可用版本。（PS：阿里内部灰度步骤是：5% 10% %30 %50 %100，每个步骤之间通常会间隔4个小时左右，用以确认灰度效果）

开播跳帧优化

解决方案：通常情况下CDN直播服务器都会缓存一小部分内容（延时），一遍用户在任何时候打开都可以立即获取到内容。每个客户端从CDN拉取的数据都会存到接收缓冲区，这个缓冲区只能接收一定长度的数据，而CDN服务器为了使直播尽量流畅，每次都会向用户多发数据，如果超出缓冲区的长度，数据就会被丢弃，如果下次请求接收被丢弃的数据，直播延时就会进一步增大（观众无法参与互动），如果拉取新数据就会出现跳帧等情况，效果非常差。制定统一的发送数据长度与app上的接收缓冲区匹配，协调每个CDN厂商配合修改。另外还可以在客户端播放时，通过提高播放帧数来加速播放，解决与直播相差加大的问题。

DNS解析耗时过长

解决方案：通常情况下，用户访问一个互联网资源DNS解析都是必须的，但是由于标准的DNS解析服务器没有负载、延时监测，会造成后端DNS负载不均衡的情况，间接影响到了直播流畅度。采用app内置内部的DNS（改进后的）地址，来加快DNS解析速度，解决负载不均衡问题。

三、个人总结

整个分享的文章中，个人感觉最受益的是：

全链路监控以及监控数据可视化，这对于一个庞大的分布式系统来讲是相当重要的。
大数据的运用，分析用户的观看行为可以对直播内容以及资源配置进行有针对性地优化，增加用户粘性的同时降低资产成本。在这个互联网时代，每个人都需要了解一些大数据的东西。
这一点是我自己想的，运用机器学习等现代方法对海量数据进行挖掘，找出一些有用的信息。
上线的整个过程需要认真学习，这都是经验之谈。
要么有钱（自建CDN），要么有人（运用技术解决CDN、DNS等问题）

上学的时候，写过一个简单的聊天工具，无界面、无认证的方式，当时觉得想要做出一款聊天软件只需要加上界面以及登录认证就可以了。工作后，接触的东西多了，才发现同样的一件事，并发100和并发100w有着天壤之别。任何一个小事被放大100w倍之后，都是很大的一件事。写程序时，必须提前做好设计，考虑多种情况，然后严格测试、灰度上线、故障回滚。这些东西都是需要很深的技术、工程积累的。

转载于:https://www.cnblogs.com/sxhlinux/p/7523398.html

案例分析——快手百万在线直播相关推荐

中国在线直播教育行业发展形势与竞争策略研究报告2022-2028年
中国在线直播教育行业发展形势与竞争策略研究报告2022-2028年 ··························· <修订日期>:2022年1月 <专员对接>:周文文 ...
Comcast：美国电视行业变革分析，在线直播市场前景巨大
OTT在美国已经出现了有一段时间,它的历史已经能够有足够的数据可以做一做一些未来的预测.很多人觉得OTT会完全地消灭和颠覆传统行业,很多人很加紧去做转型,去加入这个OTT产业.但是实际上根本不是这样子 ...
87cloud案例分析：阿里云国际服务器如何支持在线教育
云如何支持在线学习平台并为其增加价值高峰流量增长了十倍多.任何在线教育公司都面临着巨大的风险,因为这样的流量激增.为了继续下去,在线教育机构必须确保在面临此类挑战时拥有足够数量的员工,包括教师和助教 ...
明晚直播预告丨一则ORA-600案例分析
一则ORA-600案例分析--1月20日20:00 大多数的ORA-00600都比较晦涩难懂,碰到了以后让人感觉无从下手,如果直接MOS,是有可能快速找到问题,但是要靠运气,大多数的600错误是无法直 ...
20日直播预告丨一则ORA-600案例分析
一则ORA-600案例分析--1月20日20:00 大多数的ORA-00600都比较晦涩难懂,碰到了以后让人感觉无从下手,如果直接MOS,是有可能快速找到问题,但是要靠运气,大多数的600错误是无法直 ...
php主动推送弹幕_百万在线的美拍直播弹幕系统的实时推送技术实践之路
1.内容概述 1.jpg (30.13 KB, 下载次数: 321) 2 年前上传直播弹幕是直播系统的核心功能之一.如何迅速作出一个有很好扩展性的弹幕系统?如何应对业务迅速发展?相信很多工程师/架 ...
hp服务器硬盘离线改在线,HP服务器硬盘不在线数据恢复案例分析
原标题:HP服务器硬盘不在线数据恢复案例分析 [数据恢复故障描述] HP DL360G5 一台,其中希捷 146G SAS硬盘 5块,raid 信息丢失,所有物理硬盘不再是ONLINE状态.这种情况 ...
万字拆解自嗨锅：造价近百万的直播间，是单场直播GMV破100万的法门吗？
自嗨锅抖音自播仅一个月,就可以做到连续三场 GMV 单场破100万的成绩.自嗨锅为什么能能有这样的成绩,有哪些点对于新进入抖音电商的食品直播策略有借鉴意义呢?来看看自嗨锅在抖音自播方面究竟做对了 ...
揭秘 | 百万并发直播网站龙珠的性能秘籍
客户背景: 龙珠直播是由苏州游视网络科技有限公司打造的游戏直播平台,于2015年2月1日正式上线,主要为游戏玩家提供网游视频直播和音乐直播等服务.目前龙珠直播与韩国职业电子竞技协会(KeSPA).游戏 ...

案例分析——快手百万在线直播

案例分析——快手百万在线直播相关推荐

最新文章

热门文章