前言
本周项目上线了，遇到了一些问题，这些问题应该具有普遍性的意义，做下思路整理并记录下来
架构
目前因为同时观看人数较少，所以架构相对简单一些，推流Server（源站）、边缘节点、cdn等，但问题集中出现在几个相对较小的点上。
- 网络流量
- 缓存
- 客户端接入速度
- 播放器策略
网络流量
由于缺乏统一的网络拓扑结构图以及相关的底层监控，所以对网络的流量问题查询时间比较长，最开始怀疑是服务器本身异常导致播放器下载慢，但按照流量数据和观看人数计算，刚好问题出现在某一个点，简单的计算一下，就容易发现问题在服务器带宽上，但因接手这个项目几天时间，对整个直播网络架构没有一个清晰的了解，所以一边询问运维部署方式，一边上机器查询网络流量，果然这里有问题，但网络调整并不是立即能够进行的。
缓存
CDN可以对hls的分片进行缓存，但目前尚未对m3u8进行缓存，因为m3u8的文件较小，且变动较为频繁，缓存的意义不是很大，能够想到的优化方式有两种
-
对m3u8放置内存中，映射到磁盘上，可以提高读取和写入速度（前端访问使用使用nginx）
-
将m3u8的访问方式修改为接口访问，可成数量级的提高性能，目前较为主流的访问方式
客户端接入速度
接入速速对客户端网络及带宽都已依赖
-
网速
客户端对于若干接入点的速度测试，可以采用客户端抽样测试上报，后台统一调配的方式进行，缺点是数据样本需要大，且需要用专门的server去计算，并将结果以某种方式通知客户端。
还可以使用客户端轮训测速的逻辑，但推流端好做，观看方相对难以实现，或许cdn能够解决问题，但更加精细控制的逻辑还是需要自己实现。
-
带宽
不同地区的网络差异性较大，且存在运营商穿越的问题，所以简单的可以通过cdn来调配，负责的还是需要明确客户端的带宽及后台带宽。最好经过简单的计算和测试，至少拥有一些测试工具，当出现问题的时候，可以请用户帮忙测试并反馈，就可以做到简单的调度逻辑
播放器策略
以前对播放器的了解并不是很多，现在才发现，不用的hls library的区别还是比较大的，播放器我不是很熟悉，所以当出现卡顿的时候，如果是明确是播放器的问题，可以尝试换个library或者是增加分片预缓存的方式解决
last
目前暂时遇到这些问题，但可以想象，观看人数越多，问题也就越多，但基本的网络架构固定了，后面就是一些调度优化的问题。hls简单在于cdn国内外都有成熟的方案，而rtmp的cdn加速只有国内做的比较好，海外包括amazon和akami都没有跟上
望自勉