往期文章
一、 拜托!面试请不要再问我Spring Cloud底层原理
二、 【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问?
三、 【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战
四、 微服务架构如何保障双11狂欢下的99.99%高可用
五、 兄弟,用大白话告诉你小白都能听懂的Hadoop架构原理
六、 大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问
七、 【性能优化的秘密】Hadoop如何将TB级大文件的上传性能优化上百倍
欢迎关注我的公众号:石杉的架构笔记(ID:shishan100)java
周一至五早8点半!精品技术文章准时送上!面试
1、写在前面数组
2、原始的文件上传方案性能优化
3、大规模分布式系统对大文件上传的性能优化网络
(1)Chunk缓冲机制数据结构
(2)Packet数据包机制多线程
(3)内存队列异步发送机制架构
4、总结并发
上一篇文章,咱们聊了一下Hadoop中的NameNode里的edits log写机制。异步
主要分析了edits log写入磁盘和网络的时候,是如何经过分段加锁以及双缓冲的机制,大幅度提高了多线程并发写edits log的吞吐量,从而支持高并发的访问。
若是没看那篇文章的同窗,能够回看一下:大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问。
这篇文章,咱们来看看,Hadoop的HDFS分布式文件系统的文件上传的性能优化。
首先,咱们仍是经过一张图来回顾一下文件上传的大概的原理。
由上图所示,文件上传的原理,其实说出来也简单。
好比有个TB级的大文件,太大了,HDFS客户端会给拆成不少block,一个block就是128MB。
这个HDFS客户端你能够理解为是云盘系统、日志采集系统之类的东西。
好比有人上传一个1TB的大文件到网盘,或者是上传个1TB的大日志文件。
而后,HDFS客户端把一个一个的block上传到第一个DataNode
第一个DataNode会把这个block复制一份,作一个副本发送给第二个DataNode。
第二个DataNode发送一个block副本到第三个DataNode。
因此你会发现,一个block有3个副本,分布在三台机器上。任何一台机器宕机,数据是不会丢失的。
最后,一个TB级大文件就被拆散成了N多个MB级的小文件存放在不少台机器上了,这不就是分布式存储么?
今天要讨论的问题,就是那个HDFS客户端上传TB级大文件的时候,究竟是怎么上传呢?
咱们先来考虑一下,若是用一个比较原始的方式来上传,应该怎么作?
大概能想到的是下面这个图里的样子。
不少java的初学者,估计都知道这样来上传文件,其实无非就是不停的从本地磁盘文件用输入流读取数据,读到一点,就立马经过网络的输出流写到DataNode里去。
上面这种流程图的代码,估计刚毕业的同窗均可以立马写出来。由于对文件的输入流最多就是个FileInputStream。
而对DataNode的输出流,最多就是个Socket返回的OutputStream。
而后中间找一个小的内存byte[]数组,进行流对拷就好了,从本地文件读一点数据,就给DataNode发一点数据。
可是若是你要这么弄,那性能真是极其的低下了,网络通讯讲究的是适当频率,每次batch批量发送,你得读一大批数据,经过网络通讯发一批数据。
不能说读一点点数据,就立马来一次网络通讯,就发出去这一点点的数据。
若是按照上面这种原始的方式,绝对会致使网络通讯效率极其低下,大文件上传性能不好。
为何这么说呢?
至关于你可能刚读出来几百个字节的数据,立马就写网络,卡顿个好比几百毫秒。
而后再读下一批几百个字节的数据,再写网络卡顿个几百毫秒,这个性能不好,在工业级的大规模分布式系统中,是没法容忍的。
好,看完了原始的文件上传,那么咱们来看看,Hadoop中的大文件上传是如何优化性能的呢?一块儿来看看下面那张图。
首先你须要本身建立一个针对本地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采起的大文件上传机制,是否是感受设计的很巧妙?
说白了,工业级的大规模分布式系统,都不会采起特别简单的代码和模式,那样性能很低下。
这里都有大量的并发优化、网络IO优化、内存优化、磁盘读写优化的架构设计、生产方案在里面。
因此你们观察上面那个图,HDFS客户端能够快速的将tb级大文件的数据读出来,而后快速的交给HDFS的输出流写入内存。
基于内存里的chunk缓冲机制、packet数据包机制、内存队列异步发送机制。绝对不会有任何网络传输的卡顿,致使大文件的上传速度变慢。
反而经过上述几种机制,能够上百倍的提高一个TB级大文件的上传性能。
若有收获,请帮忙转发,您的鼓励是做者最大的动力,谢谢!
一大波微服务、分布式、高并发、高可用的原创系列
文章正在路上,欢迎扫描下方二维码,持续关注:
石杉的架构笔记(id:shishan100)
十余年BAT架构经验倾囊相授