视频上传系统设计
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
视频网站架构设计
架构设计的主要考虑
•常规问题:视频流媒体处理、网站基础架构
•视频编码、视频播放协议等流媒体文件的处理
视频基础子系统--上传系统设计
•系统组成模块
逻辑架构
•媒资系统:它是对与音视频等媒体文件有关子系统的统称,这个系统主要完成与媒体文件有关的功能,包括文件上传、转码、分发与存储几个的组成部分。
•业务应用系统:这个系统是为媒资系统与业务产品线服务,做为业务产品线对媒资系统的需求入口,并且提供基础的应用服务。例如:视频分辨率、视频码流、文件输出格式列表、文件最大体积等。做为业务产品线的下游接口,该系统需要对业务产品线的需求进行分类与抽象。
•上传开放接口系统:开放接口完成对媒体系统的接口管理,用户授权与验证,以及基于新浪播客的视频转码及存储与社交分享这几项功能。
业务处理流程
媒资系统
•媒资系统要完成文件上传、转码、分发与存储等任务。
•文件上传
–视频文件传输
•让用户就近访问,提升用户的访问性能
•将接收文件上传的设备进行分布式部署–原始视频文件的存储
•互联网视频到iPad视频
•对已经转码的文件再次转码,视频播放质量下降
音视频文件转码
•不同的播放器支持不同的音视频编码格式,例如FlashPlayer在9.0.115.0以上的版本才支持H.264的视频编码
文件分发与存储
•文件分发与存储
–视频网站播放基本都是由CDN完成
–将热点视频缓存到各地CDN节点,并尽可能提高缓存命中率
开发架构
•平台
1. Twice –前端基于python开发web缓存.
(/p/twicecache/)未公布源码
2. XFS –分布式文件系统.
3. HAProxy–软件负责均衡.
4. LVS –传统的Linux虚拟服务器.
5. Ruby on Rails –应用服务器
6. Nginx–web 服务器
7. PostgreSQL–数据库服务器.
8. MongoDB–NoSql数据库,用网站于内部分析工具.
9. MemcachedDB–数据库缓存.
10. Syslog-ng–日志系统.
11. RabitMQ–任务调度系统.
12. Puppet -中心化配置管理系统.
13. Git–分布式源码版本控制服务器.
14. Wowza–基于Flash/H.264/Java编写的视频服务器.
15. Usher –用于客户定义视频播放业务逻辑处理.
单一流媒体服务的架构图
多格式的流媒体服务架构系统架构
网站针对了来自不同的国家、地区的用户做了CDN访问策略,比如:中国用户就会自动的
跳转到网址上,这样不同地区的用户就会访问不同的服务器。用户通
过HAProxy进行负载分配,在访问后端的视频服务器,分流、分载是这个架构的主要特点。
前端Web架构
前端Web架构设计考虑
•网站采用Ruby on Rails用作前端Web应用程序,缓存策略采用自主研发的产品Twicet,Twicet是系统中一个分布式缓存插件,可以根据每个用户定制化进行缓存服务,在整个系统中有超过95%的网页使用Twicet进行缓存。另外,Twicet还充当反向代理和模板系统。这是为了能让每个页面被缓存后很将来容易的合并。
•网站记录用户每一次点击、页面浏览和停留时间来衡量当前服务提供的质量和如何改进日后服务。日志消息从前端通过中间应用层转换成syslog-ngto日志,并通过系统进行转发到一个ngto日志主机。最后存放到MongoDB中提供内部人员进行查询、分析。
•PostegreSQL是他们的主数据库。结构很简单设置了主从关系。PostgreSQL数据库结合MemcachedDB用于处理类似浏览计数器。因此网站的写没有超过读,所以可以尽量采用缓存系统处理的内容。