大家好,又见面了,我是你们的朋友全栈君。
1.P2P系统
服务 | 功能 |
---|---|
Tracker | 存储服务,存储文件和活跃P2P上传用户(以下简称矿机、Peer)的连接信息对应关系,用户信息包括用户标识、所连接Proxy的地址、地域、运营商、NAT类型等信息。实际上Tracker上的用户信息表是一个多级表,查找Peer的操作会根据文件HashId、地域、运营商、NAT类型等索引到合适的用户信息。 |
Proxy | 代理服务,非flashp2p矿机会跟Proxy保持长连接以保证能够接收到打洞的推动请求,P2P系统内部的所有服务都通过Proxy对外提供服务。每个Proxy内部保存所有Tracker的一致性哈希表,并保持跟所有Tracker的连接,在下载用户查找Peer时会根据所查找资源的HashId哈希到某个Tracker,并在对应Tracker上调用实际的搜索请求。 |
Log | 日志服务,用于存储客户端上报的日志。 |
Statistic | 统计服务,统计各个平台的用户在线情况、接口调用信息。 |
RtmfpServer | Rtmfp服务,用于flashp2p客户端直接之间的打洞,flashp2p矿机会跟RtmfpServer保持长连接。 |
Rtmfp-DB | Rtmfp数据库,存储所有连接到Rtmfp Server的用户id到其Candidates的映射。 |
Gateway | 入口服务,用于向客户端提供地域、运营商匹配的Proxy和Rtmfp服务,Proxy和Rtmfp服务信息由Center服务通知。 |
Center | 中心服务,用于管理所有可用资源,主要功能有: 1.Tracker连通性测试,建立Tracker一致性哈希表,并通知到Proxy; 2.Proxy连通性测试,并将Proxy服务信息通知到Gateway; 3.Rtmfp连通性测试,并将Rtmfp服务信息通知到Gateway。 |
2.客户端视角
搜狐视频P2P客户端并非单纯的只走P2P的客户端,由于需要向播放器提供数据,并且P2P通道质量的不确定性,需要使用CDN来弥补数据,因此产生了节约比这个指标。节约比,又叫分享率,从微观上来讲就是在一次播放中,通过P2P下载的媒体数据占据总数据量(P2P CDN)的比例,宏观上指在一段时间内P2P系统提供的带宽占据视频网站总可用带宽(P2P CDN)的比例。对播放器来说,比较重要的指标是流畅率,流畅率往往和节约比是相互制约的关系,播放器P2P客户端的一个重要任务就是寻找一个兼顾流畅率和节约比的平衡点。
服务 | 功能 |
---|---|
StunServer | 用于探测NAT类型、公网地址。 |
Navigation | 配置服务,存储不同平台的P2P客户端配置,在P2P客户端内部很多流控逻辑会参考很多阈值,这些阈值主要从这个服务获取。 |
Pingback | Qs业务上报服务,主要收集带宽、节约比、流畅率等信息,这些信息入库后由后台统计服务进行进一步加工,最后展示成Qs页面,是业务数据的主要来源。 |
HotVrs | 搜狐视频的所有非自媒体剧集的数据查找服务,相当于一个数据库,会根据视频的vid和清晰度给客户端返回剧集的分段信息,以及相应的调度服务地址。P2P客户端正是以该分段信息中的分段HashId为索引向P2P系统查找到缓存了该分段的Peer,然后打洞、获取数据,如果获取不到Peer,则请求调度地址,获得靠近的CDN边缘节点,然后使用CDN下载数据。对自媒体,也有对应的接口,只是域名和服务有所区别。 |
Dispatch | 调度服务,CDN系统的调度服务会根据用户的地域、运营商、CDN负载等信息向用户返回最合适的CDN边缘节点。 |
CDN节点 | 实际存储文件的节点,主要分为边缘节点和源节点。搜狐视频的CDN回源策略是主推,结合拉。也就是说,在一个剧上线后,会主动从源站推送到各边缘节点,个别新上的边缘节点无法命中的情况下才会回源,减少回源的压力。 |
3.数据格式
搜狐视频CDN内部存储的是按照一定参数转码后的MP4格式,主要参数有:
- 时长(5min);
- I帧间隔(10s);
- 各个清晰度的分辨率;
- 水印……
每个剧会被切成最大5分钟的分段,这么切的目的是为了P2P的缓存,不希望客户端缓存一个大文件,当然也不能太小,以5分钟为单位是一个权衡。无论是CDN节点还是P2P矿机都存储了5分钟的mp4分段,Tracker存储了mp4分段的HashId(使用了SHA1)到存储该mp4分段的Peer信息,因此一个P2P的下载客户端去下载的时候,不管是从CDN还是从P2P都将获得一致的数据。
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/150742.html原文链接:https://javaforall.cn