1. L/O/G/O
视频CDN的同步、调
岷@土豆网

2. Content Delivery Network
注服务类似土豆网的视频文件的CDN
– 支持UGC内容，视频数量庞大
– 截至2012年8月，7000万视频
主要 注三个方面：
– 文件同步：文件如何移动
– 访问调度：如何 定用户最终的访问
– Web服务：web server最终如何从把文件吐给用

3. 目录
• 视频CDN
– 用图片CDN服务视频文件可能遇到的问题
– 视频同步
– 访问调度
– Web服务
• 土豆的做法
– 视频同步
– 访问调度

4. 视频CDN的特点
• 单个视频文件相对较大
– 下载时间比较长
• 带宽特点
– 带宽成本比较敏感
– 机房多，IDC商务谈判不可控
– 带宽质量稳定性对用户体验影响比较大
• 协议多样性：

5. 土豆图片CDN
①
Client
DNS
②
边缘节点1 LB设备
③
边缘服 边缘服 边缘服
务器1 务器2 务器3
④
源站

6. 视频在图片CDN上的问题
• 每个机房的带宽相对总量
①
Client 较小，且富余量小，容易
DNS
满
②
• ②的带宽质量对于用户体
边缘节点1 LB设备
验影响大，运营要求调度
③
更 活
边缘服 边缘服 边缘服
务器1 务器2 务器3 • 如果边缘节点的命中率
低，总是要回源去拿文
④ 件，那么：
源站 – ④的带宽被浪费

7. 视频同步
• 使命：
– 要让用户就近访问视频
– 删除用户不再访问的视频
• 同步的模型

8. pull模式 vs push模式
边缘节点
源站

9. pull模式
边缘服务器
源站

10. push模式
边缘服务器
源站

11. pull模式 分析
• pull模式特点
– 同步是被动的
– 调度不用管边缘节点存在 些文件
• 优点
– 调度相对简单
– 同步文件简单
• 缺点

12. push模式 分析
• Push模式特点
– 要主动同步/删除文件
– 调度必须知道缘节点存在 些文件
• 优点
– 不要求边缘节点有 高的命中率
– 不要求回源带宽，不要求节点大小，可以带宽/机房
选择 活性大
• 缺点

13. 同步需要解决的问题
• 提高边缘节点命中率
• 处理增 节点/服务器的情况
• 处理硬件故障的情况

14. 访问调度
• 访问调度的目的
– 让用户就近访问
– 负载均衡

15. 视频CDN调度特点
• 骨干网变动对于用户体验影响大
• 机房容易 满
• 处理边缘服务器当机的情况
• 需要一定的 活性

16. Web 服务
• 边缘节点要提供稳定的输出
– 同时会有很多读和一些写入
• 边缘节点要提供多协议支持
– HTTP
– HLS

17. 土豆的做法
• 中心控制
– 中心服务器知道所有文件的位置
– 中心服务器知道所有机房/服务器/硬盘的状态
– 文件同步和删除都由中心服务器控制
• 同步采用PUSH模式
• 实时调度
• 自行 发web服务器
– 优化IO

18. 土豆的同步系统
• 土豆视频CDN是一个分布式文件系统
– 没有“源站”
– 文件分布在所有的CDN节点上
• 土豆视频CDN同步采用PUSH模式
– 同步文件和删除文件完全由同步中央服务器控制
– 同步中央服务器从调度器处实时获取用户访问行
为

19. 同步的下载器
• 就近下载
• 支持多点，多源下载
• 合并入Web服务器
– 优化写入大小
– 优化磁盘调度
– 读优先

20. 土豆的访问调度
• 调度器知道每个视频的位置
• 所有CDN服务器实时上报CDN服务器情况：
（带宽使用/机器负载/硬盘监控等）
• 调度器根据CDN状况和调度策略对每个请求
进行调度
• 调度器把用户请求反馈给同步系统

21. 实时调度系统 – 数据
视频文件分
用户的请求
布数据 同步系统
求信
用户请
用户 IP 息
http://.../video.flv
实时调度系统 给出用户最合适的
URL
视频ID
当前CDN的 策略
状态

22. 实时调度系统 – 实现
• 高峰期压力：10000+/s
• 实时收集每个节点的带宽，动态调度每个播
放请求，实时计算，不缓存
• 丢弃数据库，丢弃memcached
• 数据横向Partition，共享内存多实例
• 数据、计算和策略分

23. 实时调度系统 – 系统结构
• 数据单元负责提供调度时的数据。
数据 数据
数据被加载到内存中，做横向 单元 单元
partition，数据量庞大；需求最稳
定，重启代价大
• 计算单元直接接收用户端发来的调 计算 计算 计算
度请求，从数据单元获取数据，通
过计算（过滤、排序）把播放链接
返回给用户。计算负责，需求相对
策略单元
稳定；无状态，重启代价小
• 策略单元向计算单元提供策略，不
接收用户请求，计算量很小，但逻
辑相对 杂且策略多变，重启无代
价

24. Web 服务
• 在高并发下，每个请求都提供稳定的输出
• 支持多协议
– HTTP
– HLS

25. Web 服务
• 如果一台服务器的额定输出是500mbps，加
上冗余系数，比如1.6，那么一台机器要能吐
出800mbps
• 假设用户的下载速度是800kbps，那么每块
硬盘需要同时服务1000个用户
• 很不幸的是这时候还时不时要往硬盘里写
• 文件访问很不均匀

26. 原因分析
• lighttpd是通用服务器，使用sendfile直接把文
件fd和socket的fd中写入
• ssize_t sendfile(int out_fd, int in_fd, off_t
*offset, size_t count);
• 当大量的位于不同硬盘的文件被sendfile同时
发送给网络时，操作系统很难办

27. 提高单台机器的服务能力
• 服务器配置：2core+10sata+4G内存+2个千
兆网卡
• 分析600并发瓶颈的原因：lighttpd使用
sendfile，disk I/O由操作系统调度
• 可能的改进点：
– 能否控制一次磁盘读取大小？
– 能否根据不同的硬盘做优化？

28. 土豆的做法
网络 磁盘
send(fd) buffer read(fd)
epoll 调度
• 使用read/send来读磁盘和发送数据，增加单次read读取大小
• 自己实现对读磁盘操作的调度
– 针对硬盘做调度优化
– 针对网络层buffer中的不同链接数据量的差 做调度优化
– 生产者（读磁盘）消费者（写网络）模型
• 当消费者队列满时，挂起生产者
• 当消费者队列空时，提高生产者优先级
• 合并Web服务器和同步下载器
– 统一读写队列

29. 土豆做法的好处
• 纯分布式系统不需要拥有全部文件的源站
• 采用push模型
– 避免了pull对于回源链路的依赖，提高IDC机房选
择的 活性
– 由于服务端存有所有文件的位置信息，所以节点
和服务器的增删非常容易实现
– 硬件失效不敏感

30. 土豆做法的缺点
• 杂
– 同步系统要管copy，还要管删除
– 调度器要知道所有文件的位置，单次调度计算量
大

31. L/O/G/O
谢谢

32. L/O/G/O
32