吴岷 视频cdn分发、调度与服务的探讨
TRANSCRIPT
LOGO
视频CDN的同步调吴岷土豆网
Content Delivery Network 关注服务类似土豆网的视频文件的CDN
ndash支持UGC内容视频数量庞大ndash截至2012年8月7000万视频
主要关注三个方面ndash文件同步文件如何移动ndash访问调度如何确定用户最终的访问ndash Web服务web server最终如何从把文件吐给用
目录bull 视频CDN
ndash 用图片CDN服务视频文件可能遇到的问题ndash 视频同步ndash 访问调度ndash Web服务
bull 土豆的做法ndash 视频同步ndash 访问调度
视频CDN的特点bull 单个视频文件相对较大
ndash下载时间比较长
bull 带宽特点ndash带宽成本比较敏感ndash机房多IDC商务谈判不可控ndash带宽质量稳定性对用户体验影响比较大
bull 协议多样性
土豆图片CDN
源站
边缘节点1 LB设备
DNS
边缘服务器1
Client①
②
③
④
边缘服务器2
边缘服务器3
bull 每个机房的带宽相对总量较小且富余量小容易跑满
bull ②的带宽质量对于用户体验影响大运营要求调度更灵活
bull 如果边缘节点的命中率低总是要回源去拿文件那么ndash ④的带宽被浪费源站
边缘节点1 LB设备
DNS
边缘服务器1
Client①
②
③
④
边缘服务器2
边缘服务器3
视频在图片CDN上的问题
视频同步bull 使命
ndash要让用户就近访问视频ndash删除用户不再访问的视频
bull 两种同步的模型
pull模式 vs push模式
源站
边缘节点
pull模式
源站
边缘服务器
push模式
源站
边缘服务器
pull模式 分析bull pull模式特点
ndash同步是被动的ndash调度不用管边缘节点存在哪些文件
bull 优点ndash调度相对简单ndash同步文件简单
bull 缺点
push模式 分析bull Push模式特点
ndash 要主动同步删除文件ndash 调度必须知道缘节点存在哪些文件
bull 优点ndash 不要求边缘节点有极高的命中率ndash 不要求回源带宽不要求节点大小可以带宽机房选择灵活性大
bull 缺点
同步需要解决的问题bull 提高边缘节点命中率bull 处理增减节点服务器的情况bull 处理硬件故障的情况
访问调度bull 访问调度的目的
ndash让用户就近访问ndash负载均衡
视频CDN调度特点bull 骨干网变动对于用户体验影响大bull 机房容易跑满bull 处理边缘服务器当机的情况bull 需要一定的灵活性
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
Content Delivery Network 关注服务类似土豆网的视频文件的CDN
ndash支持UGC内容视频数量庞大ndash截至2012年8月7000万视频
主要关注三个方面ndash文件同步文件如何移动ndash访问调度如何确定用户最终的访问ndash Web服务web server最终如何从把文件吐给用
目录bull 视频CDN
ndash 用图片CDN服务视频文件可能遇到的问题ndash 视频同步ndash 访问调度ndash Web服务
bull 土豆的做法ndash 视频同步ndash 访问调度
视频CDN的特点bull 单个视频文件相对较大
ndash下载时间比较长
bull 带宽特点ndash带宽成本比较敏感ndash机房多IDC商务谈判不可控ndash带宽质量稳定性对用户体验影响比较大
bull 协议多样性
土豆图片CDN
源站
边缘节点1 LB设备
DNS
边缘服务器1
Client①
②
③
④
边缘服务器2
边缘服务器3
bull 每个机房的带宽相对总量较小且富余量小容易跑满
bull ②的带宽质量对于用户体验影响大运营要求调度更灵活
bull 如果边缘节点的命中率低总是要回源去拿文件那么ndash ④的带宽被浪费源站
边缘节点1 LB设备
DNS
边缘服务器1
Client①
②
③
④
边缘服务器2
边缘服务器3
视频在图片CDN上的问题
视频同步bull 使命
ndash要让用户就近访问视频ndash删除用户不再访问的视频
bull 两种同步的模型
pull模式 vs push模式
源站
边缘节点
pull模式
源站
边缘服务器
push模式
源站
边缘服务器
pull模式 分析bull pull模式特点
ndash同步是被动的ndash调度不用管边缘节点存在哪些文件
bull 优点ndash调度相对简单ndash同步文件简单
bull 缺点
push模式 分析bull Push模式特点
ndash 要主动同步删除文件ndash 调度必须知道缘节点存在哪些文件
bull 优点ndash 不要求边缘节点有极高的命中率ndash 不要求回源带宽不要求节点大小可以带宽机房选择灵活性大
bull 缺点
同步需要解决的问题bull 提高边缘节点命中率bull 处理增减节点服务器的情况bull 处理硬件故障的情况
访问调度bull 访问调度的目的
ndash让用户就近访问ndash负载均衡
视频CDN调度特点bull 骨干网变动对于用户体验影响大bull 机房容易跑满bull 处理边缘服务器当机的情况bull 需要一定的灵活性
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
目录bull 视频CDN
ndash 用图片CDN服务视频文件可能遇到的问题ndash 视频同步ndash 访问调度ndash Web服务
bull 土豆的做法ndash 视频同步ndash 访问调度
视频CDN的特点bull 单个视频文件相对较大
ndash下载时间比较长
bull 带宽特点ndash带宽成本比较敏感ndash机房多IDC商务谈判不可控ndash带宽质量稳定性对用户体验影响比较大
bull 协议多样性
土豆图片CDN
源站
边缘节点1 LB设备
DNS
边缘服务器1
Client①
②
③
④
边缘服务器2
边缘服务器3
bull 每个机房的带宽相对总量较小且富余量小容易跑满
bull ②的带宽质量对于用户体验影响大运营要求调度更灵活
bull 如果边缘节点的命中率低总是要回源去拿文件那么ndash ④的带宽被浪费源站
边缘节点1 LB设备
DNS
边缘服务器1
Client①
②
③
④
边缘服务器2
边缘服务器3
视频在图片CDN上的问题
视频同步bull 使命
ndash要让用户就近访问视频ndash删除用户不再访问的视频
bull 两种同步的模型
pull模式 vs push模式
源站
边缘节点
pull模式
源站
边缘服务器
push模式
源站
边缘服务器
pull模式 分析bull pull模式特点
ndash同步是被动的ndash调度不用管边缘节点存在哪些文件
bull 优点ndash调度相对简单ndash同步文件简单
bull 缺点
push模式 分析bull Push模式特点
ndash 要主动同步删除文件ndash 调度必须知道缘节点存在哪些文件
bull 优点ndash 不要求边缘节点有极高的命中率ndash 不要求回源带宽不要求节点大小可以带宽机房选择灵活性大
bull 缺点
同步需要解决的问题bull 提高边缘节点命中率bull 处理增减节点服务器的情况bull 处理硬件故障的情况
访问调度bull 访问调度的目的
ndash让用户就近访问ndash负载均衡
视频CDN调度特点bull 骨干网变动对于用户体验影响大bull 机房容易跑满bull 处理边缘服务器当机的情况bull 需要一定的灵活性
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
视频CDN的特点bull 单个视频文件相对较大
ndash下载时间比较长
bull 带宽特点ndash带宽成本比较敏感ndash机房多IDC商务谈判不可控ndash带宽质量稳定性对用户体验影响比较大
bull 协议多样性
土豆图片CDN
源站
边缘节点1 LB设备
DNS
边缘服务器1
Client①
②
③
④
边缘服务器2
边缘服务器3
bull 每个机房的带宽相对总量较小且富余量小容易跑满
bull ②的带宽质量对于用户体验影响大运营要求调度更灵活
bull 如果边缘节点的命中率低总是要回源去拿文件那么ndash ④的带宽被浪费源站
边缘节点1 LB设备
DNS
边缘服务器1
Client①
②
③
④
边缘服务器2
边缘服务器3
视频在图片CDN上的问题
视频同步bull 使命
ndash要让用户就近访问视频ndash删除用户不再访问的视频
bull 两种同步的模型
pull模式 vs push模式
源站
边缘节点
pull模式
源站
边缘服务器
push模式
源站
边缘服务器
pull模式 分析bull pull模式特点
ndash同步是被动的ndash调度不用管边缘节点存在哪些文件
bull 优点ndash调度相对简单ndash同步文件简单
bull 缺点
push模式 分析bull Push模式特点
ndash 要主动同步删除文件ndash 调度必须知道缘节点存在哪些文件
bull 优点ndash 不要求边缘节点有极高的命中率ndash 不要求回源带宽不要求节点大小可以带宽机房选择灵活性大
bull 缺点
同步需要解决的问题bull 提高边缘节点命中率bull 处理增减节点服务器的情况bull 处理硬件故障的情况
访问调度bull 访问调度的目的
ndash让用户就近访问ndash负载均衡
视频CDN调度特点bull 骨干网变动对于用户体验影响大bull 机房容易跑满bull 处理边缘服务器当机的情况bull 需要一定的灵活性
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
土豆图片CDN
源站
边缘节点1 LB设备
DNS
边缘服务器1
Client①
②
③
④
边缘服务器2
边缘服务器3
bull 每个机房的带宽相对总量较小且富余量小容易跑满
bull ②的带宽质量对于用户体验影响大运营要求调度更灵活
bull 如果边缘节点的命中率低总是要回源去拿文件那么ndash ④的带宽被浪费源站
边缘节点1 LB设备
DNS
边缘服务器1
Client①
②
③
④
边缘服务器2
边缘服务器3
视频在图片CDN上的问题
视频同步bull 使命
ndash要让用户就近访问视频ndash删除用户不再访问的视频
bull 两种同步的模型
pull模式 vs push模式
源站
边缘节点
pull模式
源站
边缘服务器
push模式
源站
边缘服务器
pull模式 分析bull pull模式特点
ndash同步是被动的ndash调度不用管边缘节点存在哪些文件
bull 优点ndash调度相对简单ndash同步文件简单
bull 缺点
push模式 分析bull Push模式特点
ndash 要主动同步删除文件ndash 调度必须知道缘节点存在哪些文件
bull 优点ndash 不要求边缘节点有极高的命中率ndash 不要求回源带宽不要求节点大小可以带宽机房选择灵活性大
bull 缺点
同步需要解决的问题bull 提高边缘节点命中率bull 处理增减节点服务器的情况bull 处理硬件故障的情况
访问调度bull 访问调度的目的
ndash让用户就近访问ndash负载均衡
视频CDN调度特点bull 骨干网变动对于用户体验影响大bull 机房容易跑满bull 处理边缘服务器当机的情况bull 需要一定的灵活性
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
bull 每个机房的带宽相对总量较小且富余量小容易跑满
bull ②的带宽质量对于用户体验影响大运营要求调度更灵活
bull 如果边缘节点的命中率低总是要回源去拿文件那么ndash ④的带宽被浪费源站
边缘节点1 LB设备
DNS
边缘服务器1
Client①
②
③
④
边缘服务器2
边缘服务器3
视频在图片CDN上的问题
视频同步bull 使命
ndash要让用户就近访问视频ndash删除用户不再访问的视频
bull 两种同步的模型
pull模式 vs push模式
源站
边缘节点
pull模式
源站
边缘服务器
push模式
源站
边缘服务器
pull模式 分析bull pull模式特点
ndash同步是被动的ndash调度不用管边缘节点存在哪些文件
bull 优点ndash调度相对简单ndash同步文件简单
bull 缺点
push模式 分析bull Push模式特点
ndash 要主动同步删除文件ndash 调度必须知道缘节点存在哪些文件
bull 优点ndash 不要求边缘节点有极高的命中率ndash 不要求回源带宽不要求节点大小可以带宽机房选择灵活性大
bull 缺点
同步需要解决的问题bull 提高边缘节点命中率bull 处理增减节点服务器的情况bull 处理硬件故障的情况
访问调度bull 访问调度的目的
ndash让用户就近访问ndash负载均衡
视频CDN调度特点bull 骨干网变动对于用户体验影响大bull 机房容易跑满bull 处理边缘服务器当机的情况bull 需要一定的灵活性
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
视频同步bull 使命
ndash要让用户就近访问视频ndash删除用户不再访问的视频
bull 两种同步的模型
pull模式 vs push模式
源站
边缘节点
pull模式
源站
边缘服务器
push模式
源站
边缘服务器
pull模式 分析bull pull模式特点
ndash同步是被动的ndash调度不用管边缘节点存在哪些文件
bull 优点ndash调度相对简单ndash同步文件简单
bull 缺点
push模式 分析bull Push模式特点
ndash 要主动同步删除文件ndash 调度必须知道缘节点存在哪些文件
bull 优点ndash 不要求边缘节点有极高的命中率ndash 不要求回源带宽不要求节点大小可以带宽机房选择灵活性大
bull 缺点
同步需要解决的问题bull 提高边缘节点命中率bull 处理增减节点服务器的情况bull 处理硬件故障的情况
访问调度bull 访问调度的目的
ndash让用户就近访问ndash负载均衡
视频CDN调度特点bull 骨干网变动对于用户体验影响大bull 机房容易跑满bull 处理边缘服务器当机的情况bull 需要一定的灵活性
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
pull模式 vs push模式
源站
边缘节点
pull模式
源站
边缘服务器
push模式
源站
边缘服务器
pull模式 分析bull pull模式特点
ndash同步是被动的ndash调度不用管边缘节点存在哪些文件
bull 优点ndash调度相对简单ndash同步文件简单
bull 缺点
push模式 分析bull Push模式特点
ndash 要主动同步删除文件ndash 调度必须知道缘节点存在哪些文件
bull 优点ndash 不要求边缘节点有极高的命中率ndash 不要求回源带宽不要求节点大小可以带宽机房选择灵活性大
bull 缺点
同步需要解决的问题bull 提高边缘节点命中率bull 处理增减节点服务器的情况bull 处理硬件故障的情况
访问调度bull 访问调度的目的
ndash让用户就近访问ndash负载均衡
视频CDN调度特点bull 骨干网变动对于用户体验影响大bull 机房容易跑满bull 处理边缘服务器当机的情况bull 需要一定的灵活性
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
pull模式
源站
边缘服务器
push模式
源站
边缘服务器
pull模式 分析bull pull模式特点
ndash同步是被动的ndash调度不用管边缘节点存在哪些文件
bull 优点ndash调度相对简单ndash同步文件简单
bull 缺点
push模式 分析bull Push模式特点
ndash 要主动同步删除文件ndash 调度必须知道缘节点存在哪些文件
bull 优点ndash 不要求边缘节点有极高的命中率ndash 不要求回源带宽不要求节点大小可以带宽机房选择灵活性大
bull 缺点
同步需要解决的问题bull 提高边缘节点命中率bull 处理增减节点服务器的情况bull 处理硬件故障的情况
访问调度bull 访问调度的目的
ndash让用户就近访问ndash负载均衡
视频CDN调度特点bull 骨干网变动对于用户体验影响大bull 机房容易跑满bull 处理边缘服务器当机的情况bull 需要一定的灵活性
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
push模式
源站
边缘服务器
pull模式 分析bull pull模式特点
ndash同步是被动的ndash调度不用管边缘节点存在哪些文件
bull 优点ndash调度相对简单ndash同步文件简单
bull 缺点
push模式 分析bull Push模式特点
ndash 要主动同步删除文件ndash 调度必须知道缘节点存在哪些文件
bull 优点ndash 不要求边缘节点有极高的命中率ndash 不要求回源带宽不要求节点大小可以带宽机房选择灵活性大
bull 缺点
同步需要解决的问题bull 提高边缘节点命中率bull 处理增减节点服务器的情况bull 处理硬件故障的情况
访问调度bull 访问调度的目的
ndash让用户就近访问ndash负载均衡
视频CDN调度特点bull 骨干网变动对于用户体验影响大bull 机房容易跑满bull 处理边缘服务器当机的情况bull 需要一定的灵活性
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
pull模式 分析bull pull模式特点
ndash同步是被动的ndash调度不用管边缘节点存在哪些文件
bull 优点ndash调度相对简单ndash同步文件简单
bull 缺点
push模式 分析bull Push模式特点
ndash 要主动同步删除文件ndash 调度必须知道缘节点存在哪些文件
bull 优点ndash 不要求边缘节点有极高的命中率ndash 不要求回源带宽不要求节点大小可以带宽机房选择灵活性大
bull 缺点
同步需要解决的问题bull 提高边缘节点命中率bull 处理增减节点服务器的情况bull 处理硬件故障的情况
访问调度bull 访问调度的目的
ndash让用户就近访问ndash负载均衡
视频CDN调度特点bull 骨干网变动对于用户体验影响大bull 机房容易跑满bull 处理边缘服务器当机的情况bull 需要一定的灵活性
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
push模式 分析bull Push模式特点
ndash 要主动同步删除文件ndash 调度必须知道缘节点存在哪些文件
bull 优点ndash 不要求边缘节点有极高的命中率ndash 不要求回源带宽不要求节点大小可以带宽机房选择灵活性大
bull 缺点
同步需要解决的问题bull 提高边缘节点命中率bull 处理增减节点服务器的情况bull 处理硬件故障的情况
访问调度bull 访问调度的目的
ndash让用户就近访问ndash负载均衡
视频CDN调度特点bull 骨干网变动对于用户体验影响大bull 机房容易跑满bull 处理边缘服务器当机的情况bull 需要一定的灵活性
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
同步需要解决的问题bull 提高边缘节点命中率bull 处理增减节点服务器的情况bull 处理硬件故障的情况
访问调度bull 访问调度的目的
ndash让用户就近访问ndash负载均衡
视频CDN调度特点bull 骨干网变动对于用户体验影响大bull 机房容易跑满bull 处理边缘服务器当机的情况bull 需要一定的灵活性
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
访问调度bull 访问调度的目的
ndash让用户就近访问ndash负载均衡
视频CDN调度特点bull 骨干网变动对于用户体验影响大bull 机房容易跑满bull 处理边缘服务器当机的情况bull 需要一定的灵活性
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
视频CDN调度特点bull 骨干网变动对于用户体验影响大bull 机房容易跑满bull 处理边缘服务器当机的情况bull 需要一定的灵活性
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
Web 服务bull 边缘节点要提供稳定的输出
ndash同时会有很多读和一些写入
bull 边缘节点要提供多协议支持ndash HTTPndash HLS
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
土豆的做法bull 中心控制
ndash 中心服务器知道所有文件的位置ndash 中心服务器知道所有机房服务器硬盘的状态ndash 文件同步和删除都由中心服务器控制
bull 同步采用PUSH模式bull 实时调度bull 自行开发web服务器
ndash 优化IO
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
土豆的同步系统bull 土豆视频CDN是一个分布式文件系统
ndash没有ldquo源站rdquo
ndash文件分布在所有的CDN节点上
bull 土豆视频CDN同步采用PUSH模式ndash同步文件和删除文件完全由同步中央服务器控制ndash同步中央服务器从调度器处实时获取用户访问行为
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
同步的下载器bull 就近下载bull 支持多点多源下载bull 合并入Web服务器
ndash优化写入大小ndash优化磁盘调度ndash读优先
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
土豆的访问调度bull 调度器知道每个视频的位置bull 所有CDN服务器实时上报CDN服务器情况（带宽使用机器负载硬盘监控等）
bull 调度器根据CDN状况和调度策略对每个请求进行调度
bull 调度器把用户请求反馈给同步系统
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
用户的请求
实时调度系统 ndash 数据
实时调度系统
用户 IP
视频ID
当前CDN的状态
httpvideoflv给出用户最合适的URL
视频文件分布数据
策略
用户请求信
息
同步系统
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
实时调度系统 ndash 实现bull 高峰期压力10000+s
bull 实时收集每个节点的带宽动态调度每个播放请求实时计算不缓存
bull 丢弃数据库丢弃memcached
bull 数据横向Partition共享内存多实例bull 数据计算和策略分开
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
实时调度系统 ndash 系统结构
计算
数据单元
策略单元
bull 数据单元负责提供调度时的数据数据被加载到内存中做横向partition数据量庞大需求最稳定重启代价大
bull 计算单元直接接收用户端发来的调度请求从数据单元获取数据通过计算（过滤排序）把播放链接返回给用户计算负责需求相对稳定无状态重启代价小
bull 策略单元向计算单元提供策略不接收用户请求计算量很小但逻辑相对复杂且策略多变重启无代价
计算计算
数据单元
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
Web 服务bull 在高并发下每个请求都提供稳定的输出bull 支持多协议
ndash HTTPndash HLS
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
Web 服务bull 如果一台服务器的额定输出是500mbps加上冗余系数比如16那么一台机器要能吐出800mbps
bull 假设用户的下载速度是800kbps那么每块硬盘需要同时服务1000个用户
bull 很不幸的是这时候还时不时要往硬盘里写bull 文件访问很不均匀
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
原因分析bull lighttpd是通用服务器使用sendfile直接把文件fd和socket的fd中写入
bull ssize_t sendfile(int out_fd int in_fd off_t offset size_t count)
bull 当大量的位于不同硬盘的文件被sendfile同时发送给网络时操作系统很难办
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
提高单台机器的服务能力bull 服务器配置2core+10sata+4G内存+2个千兆网卡
bull 分析600并发瓶颈的原因lighttpd使用sendfiledisk IO由操作系统调度
bull 可能的改进点ndash能否控制一次磁盘读取大小ndash能否根据不同的硬盘做优化
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
土豆的做法
bull 使用readsend来读磁盘和发送数据增加单次read读取大小bull 自己实现对读磁盘操作的调度
ndash 针对硬盘做调度优化ndash 针对网络层buffer中的不同链接数据量的差异做调度优化ndash 生产者（读磁盘）消费者（写网络）模型
bull 当消费者队列满时挂起生产者bull 当消费者队列空时提高生产者优先级
bull 合并Web服务器和同步下载器ndash 统一读写队列
read(fd)buffersend(fd)网络 磁盘
epoll 调度
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
土豆做法的好处bull 纯分布式系统不需要拥有全部文件的源站bull 采用push模型
ndash避免了pull对于回源链路的依赖提高IDC机房选择的灵活性
ndash由于服务端存有所有文件的位置信息所以节点和服务器的增删非常容易实现
ndash硬件失效不敏感
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
土豆做法的缺点bull 复杂
ndash同步系统要管copy还要管删除ndash调度器要知道所有文件的位置单次调度计算量大
LOGO
谢谢
LOGO
32
LOGO
谢谢
LOGO
32
LOGO
32