这是我参与「第五届青训营 」伴学笔记创作活动的第 28 天
本篇文章归档于 “第五届字节跳动青训营”，主要是为了完成和记录掘金的 “伴学笔记创作活动” 活动，如果你对我的其他文章感兴趣，可以去我的 专栏 中逛逛看有没有你想要的东西。
- 第 1 篇 - Kitex 口水话
- 第 2 篇 - Hertz 口水话
- 第 3 篇 - 微服务口水话
- 第 4 篇 - Kafka 口水话
- 第 5 篇 - BMQ 口水话
- 第 6 篇 - RecketMQ 口水话
- 第 7 篇 - 数据库口水话
- 第 8 篇 - RDBMS 口水话
- 第 9 篇 - TOS 口水话
- 第 10 篇 - tinyTikTok 环境配置
- 第 11 篇 - tinyTikTok 规范设计
- 第 12 篇 - tinyTikTok 项目管理
- 第 13 篇 - tinyTikTok 认证授权
- 第 14 篇 - tinyTikTok 服务功能
- 第 15 篇 - tinyTikTok 测试分析
- 第 16 篇 - tinyTikTok 项目总结
TOS 的应用场景
对于 TikTok 来说，短视频的生产和消费链路无疑是重中之重，这需要一种能同时满足易用、海量和便宜的方式来存储视频。
单从海量来说，就能排除单机存储和单机分布式了，而对于只适合存储（半）结构化的数据库来说，也是不符合该场景需求的，因此，我们应该在分布式文件存储和分布式对象存储中做抉择：
- 易用：
- HDFS：伪 Posix 文件接口，开发略复杂非云原生，搭建维护较麻烦视频/图片相关生态接入略复杂；
- TOS：Restful HTTP 接口，开发极简单云原生，按需申请使用，视频/图片相关生态丰富；
- 海量：
- HDFS：支持 PB -> EB 海量存储，文件数量受 Name Node 限制；
- TOS：支持 >EB 海量存储，对象数量无限制；
- 便宜：
- HDFS：使用普通X86服务器，成本低；
- TOS：使用普通X86服务器，具备冷热数据分级存储能力，成本更低。
因此，TOS 更适合视频存储的场景。
TOS 的相关概念
使用对象存储的流程：申请 Bucket -> 业务逻辑开发 -> 上线测试。这里的 Bucket 就相当于 Map，它经常出现在很多存储细节的优化上，比如 go map 的扩容过程。
申请好 Bucket 后，一般是以 RESTful 风格开发一套 HTTP 接口，这也是为什么 TOS 相对 HDFS 更易上手，因为很多规范已经提前约定好了。
不可避免的，会存在网络抖动下的大视频传输场景，为了保障传输完整性和降低重试成本，TOS 还提供了 MultiUpload 接口，相当于把大视频分为多个小视频进行传输。
TOS 也提供了 Listprefix 接口来查看桶内对象，这是一个分页接口，循环调用便可查看桶内的对象。
当然，更多细节可以参考一下 minio
放到最后的话
实际上，字节对于内部的 TOS 还做了很多展望，比如容量治理、成本优化、大数据生态和稳定性提高等。想来还有很多内部文档没法细看，笔记写得有点抽象，可惜不是字节人:(
