|
|
本帖最后由 IDCLAYER 于 2018-11-30 20:10 编辑
又又又一个CDN集群管理系统...... 视频CDN/点播CDN 最近完成的事
这次完善了CDN视频这块的支持
这个不知道怎么说.... 考虑到一些因素, 能算独立的系统吧
后面在讨论原因
先汇报测试数据
日志服务器的数据量
===========================================================
我这个测试日志服务器配置是
Xeon E5-2560/ 64G内存 / 6 x 300G SSD / HW Raid+10
这个量目前查询都是毫秒级别,没有压力
视频日志服务器这块用户提供给客户计费,都是计流量费用
所以就存储了5个字段,算非常迷你了
time 时间
vhost 域名
byte 字节
cache 缓存命中
code 状态代码
经过一段时间的测试,日志服务器占用情况
最高的记录了单天完成了1751千万请求日志, 合计占用1G硬盘
平均就算按
3千万条日志记录 = 2G硬盘
30亿=200G硬盘
300亿=2000G
HW卡 + 4块 1T 硬盘 = 最少存储500亿记录
单机虽然慢些但是作为计费凭证,还是有必要的长期存储的
成本并不高....
在讨论
业务逻辑图
视频后端服务器模式
==================================================
第一种模式
用户使用自己的存储服务器
我们缓存用户的内容到服务器缓存节点
和正常CDN业务一样
第二种模式
用户使用我们的存储服务器
搭配我们专用后端存储服务器
用户上传MP4格式的文件
我们的后端存储实时处理(0等待)
生成
MP4
MSS
HLS
Dash
RTMP
等协议
实现全媒体平台的播放支持
生成的文件,提供给CDN节点缓存使用,并不占硬盘!
这个方案 优势明显
如果一个1G的MP4文件,你希望提供5个点播协议
正常的方案 1Gx5个副本 = 5G
我们的方案 1Gx5个副本 = 1G 节省4G
影片容量大的话,成本节省还是很明显的
专用后端存储服务器 (硬盘IOPS和内存有要求)
亿级请求,没有性能瓶颈
视频CDN主要的管理功能
====================================================
加速资源管理
0.png
资源摘要
1.png
源站配置
2.png
流量分析
3.png
数字证书
4.png
安全相关
5.png
流量和速度限制相关
6.png
缓存策略
7.png
内存缓存策略 针对MP4文件
7-1.png
页面定制,忽略这个 流媒体用不到.....
遇到的大坑
/////////////////////////////////////////////////////
1. MP4文件的Meta信息 atom这个问题
我之前也回复过某人
这里写个详细的分析
选择你最大目录下的MP4文件
分析有很多工具
qtfaststart AtomicParsley 都可以
[ol] wget http://zebulon.bok.net/Bento4/binaries/Bento4-SDK-1-5-1-627.x86_64-unknown-linux.zip unzip Bento4-SDK-1-5-1-627.x86_64-unknown-linux.zip cd Bento4-SDK-1-5-1-627.x86_64-unknown-linux 分析文件 bin/mp4dump aaaa.mp4[/ol]复制代码
得到 类似这种数据
10.png
那个
源头数据 [moov] size=8+319945
视频数据 [mdat] size=8+23403101
并且注意那个顺序
moov应该在前面,如果不在,视频只能下载完成才看
qt-faststart和MP4Box就是干这个工作的,
把文件中的moov移到开头
就是这个视频计算 moov大小
然后换算下
[ol] function bcsum { local -i bytes=$1; if [[ $bytes -lt 1024 ]]; then echo "${bytes}B" elif [[ $bytes -lt 1048576 ]]; then echo "$(( (bytes + 1023)/1024 ))KiB" else echo "$(( (bytes + 1048575)/1048576 ))MiB" fi } echo -e "moov size:" $(bcsum 319945) echo -e "mdat size:" $(bcsum 23403101) [root@dev]# echo -e "moov size:" $(bcsum 319945) moov size: 313KiB [root@dev]# echo -e "mdat size:" $(bcsum 23403101) mdat size: 23MiB[/ol]复制代码
这个就是表示
如果想看在线观看MP4,你在线观看这个视频, 必须下载完moov的313k,然后才能看视频
按比例
20M = 300k
200M=3M
2000M=30M
一个2G的视频文件,访客必须先要下载完约30M的moov索引才能开始看视频
这个就是为什么你看视频慢的原因
对应的 nginx中 MP4 Block
mp4;
mp4_buffer_size 5m;
mp4_max_buffer_size 30m; #这个30M就是改为你最大MOOV值
如果小于 日志里,就会出现
"moov atom is too large: 99999999
这个错误, 且视频播放失败
2. MP4文件的分段缓存问题
官方的说明在这里
https://www.nginx.com/blog/smart-efficient-byte-range-caching-nginx/
分段缓存
看起来很美好,压根不是那么回事
针对MP4文件
启用分段的时候
一个1G大小的MP4文件
使用缓存KEY + $slice_range, 可能出现缓存硬盘占用超N倍的情况
因为缓存KEY的变为
http://cache/10Mb.txtbyte0-1048576
就是根据内容长度, 用户请求的哪段就缓存哪段 问题在于用户请求的长度无规律的
会出现重复特定段的问题
虽然官方的说明有设置锁定和更新期限,但是还是有各种问题,除非你仅使用内网缓存
对CDN节点硬盘读写I/O也有压力
如果开启了分段缓存
哈哈
你访问m3u8索引和ts/key文件 都会出现这个问题
2018/11/30 01:02:18 [error] 11142#11142: *554 unexpected range in slice response: 0-1048576 while sending to client,
因为这个的问题 slice 1m;
这个定义了1M 就是 1048576 字节 , 返回长度小于这个的会出错,无限循环
如果你slice定义的小 100k? HLS AES 的key只有几k
并且内容分段为100k 那么分段本身已经毫无意义了....
解决办法:
把这个配置移动到mp4的BLOCK里
只对MP4和FLV这类大文件生效,当然你MP4文件如果小于1M...
所以正确的方式是 slice值 设置为你最小的 size
我是先定义一个全局变量
如果在mp4 block区域追加$slice_range
如果有必要的话,因为测试我暂时已经关闭了已经
未完待续 |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？立即注册
×
|
发表于 2018-11-30 20:02:05
