要设计抖音或一个类似抖音的系统主要需要处理好以下几个问题，即功能需求：
视频上传
视频存储
视频分享
当然每个问题背后都有隐藏的性能要求或非功能要求，像视频类网站，数据一致性要求并不高，仅需满足数据的“最终一致性”，即用户可以接受经过一段时间后可以访问到更新后的数据。容错级别要求较高，作为一个用户遍布全球的视频分享网站，哪怕大陆区所有数据中心都坏了也不能影响到终端用户，即RTO几乎为零。最后是性能要求，视频创作者是UGC网站的重要甚至是唯一资源，互联网时代的内容创作者是极为严苛的，因为信息价值会随时间快速贬值，对于观众亦是如此，哪一端的延迟都会直接影响到内容价值。为了不影响视频创作者的效率，视频支持后台上传，成功/失败都触发相应通知。
抖音在创建之初对标国外的Instagram，日活用户估算在1000万，其中百分之一（即10万）为视频创作者/团队，因此读写需求比例在100:1。
在系统设计时我们先考虑功能，一部视频的存放需要考虑到创作者个人的结构化数据，这跟所用用户一样，包括ID、地区、语言、关注的其他用户列表、视频收藏列表、关联的创作列表等等；视频的元数据，包括标题、拍摄时间、时长、标签等等，凡是可以排序或指定的特征，都需要提前定义好该字段，并且可被快速搜索。
最后是视频本体，由于数据量非常大，需要考虑分级存储。针对这三类存储的不同需求，用户数据可以选择结构化数据库，方便建立键值关联，如MySQL，MS SQL Server等；视频元数据可以选择KV数据库，方便快速查找各种标签，也方便以后视频有新特征时快速扩展（例如视频删除时间、视频描述修改），产品上可选用MongoDB，CouchDB等等；视频内容可以选择对象存储，可用性高，可冷热分离，可结合CDN按用户分布部署缓存以减少延时，如亚马逊S3，Azure的Blob存储等。
然后考虑上述需求的非功能性部分，当用户批量上传时视频的各部分数据分拣处理会面临并发压力，比较好的处理方式是使用队列，将并发任务转成线性任务。
有了上述的这些组件设计，别的功能就非常容易实现了。例如推荐功能就是按照用户最近浏览视频的标签元数据关联有相同标签的视频，好比现在微信公众号的内容也有39大分类，但同样允许内容创作者自定义话题标签。
上传逻辑设计好了，接下去是视频格式问题，抖音支持四种视频格式，三种解析度，那对于一个视频就有4*3=12个文件。刚才说了抖音有10万短视频创作者，假设平均每天上传两个视频，就是20万条新记录，短视频的原始大小在1M左右，低解析度的文件容量要小一点，我们算他六倍于原始大小，那一天的增量数据在1.2TB。
格式转换的工作由并行计算Worker完成，这点在抖音不是很明显，因为视频总长也不超过一分钟，在B站会比较明显，原始视频会被拆解成30秒分段的一堆Chunk，然后分配到各自的Worker处理格式和解析度的转换。
每个标黄的Worker会有各自的阈值监控，当计算资源无法满足时，该处理工作会拓展出新的Worker以协助完成该格式该解析度的转换工作。
大型视频网站通常会有CDN节点，它除了缓存视频文件外还可以缓存近期比较热门的标签数据，比如#李云迪，#双11以超前部署视频缓存。
长按，识别二维码，加关注
