面试题 | 设计youtube

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

1. upload服务 app server：负责任务转发和路由，上传任务放到队列，用户注册读写User DB，查看和评论任务读写metadata DB
2. 消息队列：上传视频先push到队列，然后被消费（编码/生成缩略图/存储）
3. 转码服务：离线转码到多个码率，多种格式
4. 缩略图生成服务
5. video和缩略图存储：分布式存储
6. video metadata storage：存储视频元信息和评论:title/filePath/user/total views/like/dislike
7. User DB：存储用户信息

DB schema

详细设计

1. 如何处理大量读video？

• 读写分离：服务层面分离upload服务；video存储多副本，分散读取压力；metadata 主从MS架构，写master，读取slave节点；
  • 问题：主从会导致staleness问题，slave节点因同步有延迟，但是在youtube系统可以容忍，用户几毫秒后，可以看到新视频；

2.如何处理缩略图大量读？

• 存储：小文件(<5KB)大量读(qps=20K)的存储 - bigtable
• 存储如何选型
  • 合并小文件，减少文件次数，提升seek效率
  • 优化小文件读IO
• 读取优化：热点文件的cache，小文件，内存cache

3. 视频如何存储？

• 分布式文件系统 HDFS

4. 图片上传的效率优化？

• 支持断点续传

Scale

• cache/cdn/LB
  • 热点视频会导致cache servers的负载不均匀，如何解决？
    • 多副本，busy server重定向到less busy servers
      • 重定向的问题？
        • 可能导致多次重定向
        • 增大了时延，视频播放变慢
        • 跨数据中心的重定向可能导致服务变慢
• deplication
• sharding：用userID的缺点1）热点user影响同server的其他用户 2）存储不均匀；
  • 用videoID代替userID，用cache解决热点video的问题；查询某个userID的视频时，从多个server获取视频，再交由一个中心server汇总和排序；

总结

系统最关键的点：缩略图如何存储？

• 读图/视频 = 20/1
• bigtable适合存储大量读的小文件，在读方面做了很多优化，需要研究下