本文探讨了设计YouTube系统的关键点，包括上传、分享、搜索视频，处理赞踩和评论，以及高可用和低延迟的要求。面临挑战如存储、读写比例、元数据扩展性。采用upload服务、消息队列、转码服务、缩略图生成服务等组件。存储方面，视频使用分布式存储，缩略图利用bigtable优化大量读取。系统通过缓存、CDN、LB进行扩展，解决热点视频负载不均问题，并使用视频ID进行sharding以平衡存储。关键在于缩略图的高效存储和读取策略。
Use Cases
-
上传 视频
-
分享/查看 视频
-
基于title搜索
-
记录视频状态：赞/踩，播放数量
-
评论
-
高可靠
-
高可用AP
-
低时延，不卡顿
约束
- 500M用户，DAU 1M
- 单条视频100MB，1M/day，存储=100TB，上传qps=11.3
- 视频 r/w = 100/1， 读qps=1100
- 评论 10M ，每条1KB 存储 10G，qps=110
- 存储增长：100TB / 3PB / 36PB / 180PB
- 元数据：vedio / comment/ user 易扩展
High Level
upload服务app server：负责任务转发和路由，上传任务放到队列，用户注册读写User DB，查看和评论任务读写metadata DB- 消息队列：上传视频先push到队列，然后被消费（编码/生成缩略图/存储）
- 转码服务：离线转码到多个码率，多种格式
- 缩略图生成服务
- video和缩略图存储：分布式存储
- video metadata storage&#x
最低0.47元/天 解锁文章
扫一扫
7万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
