海量小文件网络传输copy优化

今天部署集群环境，拷贝了一下编译好的文件

利用scp拷贝这个文件环境，然后分发到2个节点上去，然后就是刷屏的log，小文件一个一个被传输。

但是速度极慢，突然发现我忘记了，编译出来的类文件太多了，这样拷贝非常慢，马上联想到hadoop中要避免map的输出有很多小文件，因为随后要进行网络传输。

查到问题总结出2个原因：

1. 磁盘IO寻址：

    原因：

    因为小文件太多，造成了大量的磁盘IO，意味着大量的开和关。磁盘的寻道和寻址都要占据很大一部分时间。

    就好比洗衣服一样，洗好多件衣服比洗一件衣服要慢很多，因为很多时间都浪费在你去找衣服的时间里了。

   优化策略：

2.TCP慢启动

    原因：

    我们对每个文件都采用独立的TCP连接来传输（循环使用scp拷贝就是这个例子的实际场景，很常见的用法）。那么工作过程应该是，每传输一 个文件建立一个连接，然后连接处于慢启动阶段，传输小文件，每个小文件几乎都处于独立连接的慢启动阶段被传输，这样传输过程所用的TCP包的总量就会增 多。更细致的说一说这个事，如果在慢启动过程中传输一个小文件，我们可能需要2至3个小包，而在一个已经完成慢启动的TCP通道中（TCP通道已进入在高 速传输阶段），我们传输这个文件可能只需要1个大包。网络拷贝文件的时间基本上全部消耗都在网络传输的过程中（发数据过去等对端ACK，ACK确认归来继 续再发，这样的数据来回交互相比较本机的文件读写非常耗时间），撇开三次握手和四次握手那些包，粗略来说，慢启动阶段传输这些文件所用的包的数目是高速通 道传输这些文件的包的数目的2-3倍！那么时间上应该也是2-3倍的关系！如果文件的量足够大，这个总时间就会被放大到需求难以忍受