优化思路
1. 让磁盘IO和网络IO时间重叠
见【性能优化的秘密】Hadoop如何将TB级大文件的上传性能优化上百倍，内存生产/消费模式缓冲磁盘写入的数据。
2. 每次写网络的包不能太小
这个不确定，直觉上想如果包小那么overhead占的比例就高，包大overhead的比例就小，但是不确定OS层会不会对网络包做缓存、到达一定大小才发。上文的评论区也有人指出了这点。
3. 避免单文件写入的并发问题
很多存储引擎不支持并发写同一个文件（存储单元），支持也要处理复杂的一致性问题。因此可以把单一大文件拆成多个小文件，并维护一个索引，读取时按索引读所有小文件。可以参考单个大文件的持续生成存储是否可以采用多线程加速？
。对于存储引擎来说，多个文件可以并发写入（如果存储引擎是分布式的，可以并行化的写入）
例如，GFS提供原子性的append操作，但这适合多个机器并发append同一个文件、并不适合对append顺序有严格要求的大文件写入场景。
image.png
又如OSS，从文档描述(以及断点续传上传)上看，OSS sdk提供的并发写文件策略也是将大文件拆分为多个part，从而允许并发上传，都上传完了再合并。不过看这api，是要传一个本地文件路径，而不是传输出流，那岂不是还得先把输出流写到本地大文件，再调API上传？没细研究，如果是这样的话有点扯。
相关资料
没找到书籍/课程。
博客：
文件 IO 操作的一些最佳实践
性能挑战赛
网友评论