三管齐下！TB级文件的上传性能瞬间被优化了100倍！

ゝ一世哀愁。 2021-12-04 06:47 83阅读 0赞

公众号后台回复“**学习**”，获取作者独家秘制精品资料

![640?wx\_fmt=png][640_wx_fmt_png]

多年好友心血力作，阿里资深技术专家十余年JVM生产实践经验

**《从零开始带你成为JVM实战高手》**

限时优惠：**88元**（**正在进行ing**）

**专栏目录**参见文末

扫下方海报进行**试读**

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg]

通过我的海报购买，**再返你24元**

领取方式：加微信号：Giotto1245，暗号**：**返现

**注：今天是购买返现的最后一天**

![640?wx\_fmt=png][640_wx_fmt_png]

**目录：**

1.  写在前面
2.  原始的文件上传方案
3.  如何对大文件上传做性能优化？

*  Chunk缓冲机制
 *  Packet数据包机制
 *  内存队列异步发送机制

总结

**一、写在前面**

这篇文章我们来看看，世界上最优秀的分布式文件系统HDFS，是如何对超大文件的上传做性能优化的？

首先，我们还是通过一张图来看一下文件上传的大概的原理。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 1]

由上图所示，文件上传的原理，其实说出来也简单。

比如有个TB级的大文件，太大了，**HDFS客户端会给拆成很多block**，一个block就是128MB。

这个HDFS客户端你可以理解为是云盘系统、日志采集系统之类的东西。

比如有人上传一个1TB的大文件到网盘，或者是上传个1TB的大日志文件。

然后，HDFS客户端把一个一个的block上传到第一个DataNode

第一个DataNode会把这个block复制一份，做一个副本发送给第二个DataNode。

第二个DataNode发送一个block副本到第三个DataNode。

所以你会发现，**一个block有3个副本**，分布在三台机器上。任何一台机器宕机，数据是不会丢失的。

最后，一个TB级大文件就被拆散成了N多个MB级的小文件存放在很多台机器上了，这就是分布式存储

**二、原始的文件上传方案**

今天要讨论的问题，就是HDFS客户端上传TB级大文件时候，是怎么上传呢？

我们先来考虑一下，如果用一个比较原始的方式来上传，应该怎么做？

大概能想到的是下面这个图里的样子。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 2]

很多java的初学者，估计都知道这样来上传文件。

其实无非就是不停的从本地磁盘文件用输入流读取数据，读到一点，就立马通过网络的输出流写到DataNode里去。

上面这种流程图的代码，估计刚毕业的同学都可以立马写出来。因为对文件的输入流最多就是个FileInputStream。而对DataNode的输出流，最多就是个Socket返回的OutputStream。

然后中间找一个小的内存byte\[\]数组，进行流对拷就行了，从本地文件读一点数据，就给DataNode发一点数据。

但是如果你要这么弄，**性能是极其低下的**，网络通信讲究的是适当频率，每次batch批量发送。

你得读一大批数据，通过网络通信发一批数据，不能说读一点点数据，就立马来一次网络通信，就发出去这一点点的数据。

所以如果按照上面这种原始的方式，绝对会导致网络通信效率极其低下，大文件上传性能很差，为什么这么说？

相当于你可能刚读出来几百个字节的数据，立马就写网络，卡顿个比如几百毫秒。

然后再读下一批几百个字节的数据，再写网络卡顿个几百毫秒，这个性能很差，**在工业级的大规模分布式系统中，是无法容忍的**。

**三、如何对大文件上传进行性能优化？**

好，看完了原始的文件上传，我们来看看Hadoop中分布式文件系统HDFS，是如何对大文件上传进行性能优化的？

一起来看看下面那张图。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 3]

首先你需要自己创建一个针对本地TB级磁盘文件的输入流，然后读到数据之后立马写入HDFS提供的FSDataOutputStream输出流。

这个FSDataOutputStream输出流在干啥？大家觉得他会天真的立马把数据通过网络传输写给DataNode吗？

**答案当然是否定的了！**这么干的话，不就跟之前的那种方式一样了！

1.  Chunk缓冲机制

首先，数据会被写入一个chunk缓冲数组，这个**chunk是一个512字节大小的数据片段**，你可以这么来理解。

然后这个缓冲数组可以容纳多个chunk大小的数据在里面缓冲。

光是这个缓冲，首先就可以让客户端快速的写入数据了，不至于说几百字节就要进行一次网络传输，想一想，是不是这样？

2. Packet数据包机制

接着，当chunk缓冲数组都写满了之后，就会把这个chunk缓冲数组进行一下**chunk切割**，切割为一个一个的chunk，一个chunk是一个数据片段。

然后多个chunk会直接一次性写入另外一个内存缓冲数据结构，就是**Packet数据包**

一个Packet数据包，设计为可以容纳127个chunk，大小大致为64mb。所以说大量的chunk会不断的写入Packet数据包的内存缓冲中。

通过这个Packet数据包机制的设计，又可以在内存中容纳大量的数据，**进一步避免了频繁的网络传输影响性能**

3. 内存队列异步发送机制

当一个Packet被塞满了chunk之后，就会将这个Packet放入一个**内存队列**来进行排队。

然后有一个DataStreamer线程会不断的获取队列中的Packet数据包，通过网络传输直接写一个Packet数据包给DataNode。

如果一个Block默认是128mb的话，那么一个Block默认会对应两个Packet数据包，每个Packet数据包是64MB。

也就是说，**传送两个Packet数据包给DataNode之后，就会发一个通知说，一个Block的数据都传输完毕。**

这样DataNode就知道自己收到一个Block了，里面包含了人家发送过来的两个Packet数据包。

**四、总结**

OK，大家看完了上面的那个图以及Hadoop的HDFS采取的大文件上传机制，是不是感觉设计的很巧妙？

说白了，工业级的大规模分布式系统，都不会采取特别简单的代码和模式，那样性能很低下。

这里都有大量的并发优化、网络IO优化、内存优化、磁盘读写优化的架构设计、生产方案在里面。

所以大家观察上面那个图，HDFS客户端可以快速的将tb级大文件的数据读出来，然后快速的交给HDFS的输出流写入内存。

基于内存里的**chunk缓冲机制、packet数据包机制、内存队列异步发送机制**。绝对不会有任何网络传输的卡顿，导致大文件的上传速度变慢。

反而通过上述几种机制，可以上百倍的提升一个TB级大文件的上传性能。

**END**

**如有收获，请划至底部，点击“在看”，谢谢！**

![640?wx\_fmt=png][640_wx_fmt_png]

**《从****零****开始带你成为JVM实战高手》**

专栏详细目录

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 4]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 5]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 6]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 7]

![640?wx\_fmt=png][640_wx_fmt_png]

欢迎长按下图关注公众号**石杉的架构笔记**，后台回复“**学习**”

获取作者独家秘制精品资料

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 8]

**BAT架构经验倾囊相授**

[640_wx_fmt_png]: /images/20211204/512828c4d45041648b79426517b295e9.png
[640_wx_fmt_jpeg]: /images/20211204/b54c5c1c46d44f77a48cfc08b2eb27c0.png
[640_wx_fmt_jpeg 1]: /images/20211204/1d24598ebe9b47688cc9923c0dd27be5.png
[640_wx_fmt_jpeg 2]: /images/20211204/5f23fa3af06c4197b5f544f23fa336b7.png
[640_wx_fmt_jpeg 3]: /images/20211204/3c4a39604610481da35eb6bb758cce94.png
[640_wx_fmt_jpeg 4]: /images/20211204/74ab88d702b94707953756313c1fcf64.png
[640_wx_fmt_jpeg 5]: /images/20211204/84b248b52cf44e6d9ffbe50ea0a81b10.png
[640_wx_fmt_jpeg 6]: /images/20211204/b081eaeac92b4b36a4b91a1f870b97a9.png
[640_wx_fmt_jpeg 7]: /images/20211204/3e65f0b0c1274f7ab51d02c0858aa09f.png
[640_wx_fmt_jpeg 8]: /images/20211204/2fc1815083914525883d09f41227e03a.png