这段时间公司使用的hadoop组件hdfs存储图片经常出现上传超时的问题，经过分析后发现了原因：

先说下情况吧，

目前公司有一个Namenode，1个secondarynamenode和4个datanode。  应用端通过一个hadoopservice去上传图片，上传是应用直接连hdfs的。service里已经对上传加了锁，这个上传不仅编辑会用，前端的网友也会上传，所以有时并发还是比较大的，上传时没有做分布式锁，所以上传时会将图片全部改名通过时间戳和其他使得文件名称不冲突。

 

发生上传超时时，datanode报错，报错如下：

 

当应用端客户端有上传文件请求时，请求图如下：

 

而同时datanode 会利用心跳机制去和namenode联系，以保证namenode实时连接datanode的情况，datanode在汇报前需要搜集本机上block 及硬盘空间等情况，这个在之前的日志里曾写过。这个时间会比较长，所以client直连datanode过来后，或者datanode连下一个datanode 传输文件时就可能会超时。

说实话 4个datanode做为集群 确实很寒酸的，但是公司对服务器要求紧啊 ，所以小规模运营。集群文件分数还是默认的3份，保存3份也是我们赞成的，所以这块并没改，这样其实就造成一个情况，4台机器，每次文件上传，其实有4台中的3个是要占用的，只有一个相对空闲些，造成负载比较大。而且这种情况随着block越来越多就越发显现。

 

目前集群内共1384056 files and directories, 1131452 blocks = 2515508 total

 

搜索资料也发现有人碰到这种问题，都是通过修改客户端的超时时间的，这个对我们线上应用来说不太合适。

所以又和主管一起和公司要了2台，有了6台datanode！！！ 哎  已经很给面子了  哈哈。

添加了后，这段时间超时基本没出现，编辑们没有在提出 呵呵。

光增加服务器其实是不够的，大家都知道，hadoop 最重要是作为云计算中数据分析来用，而hdfs作为分布式文件存储，他的机制其实是不利于实时性高的应用的，所以我们必须想其他方法，增加机器只是一方面。

 

在原有client和hadoop之间增加了一个失效保障的服务，这个服务独立于应用，与应用部署在一台服务即可。

设计思想：client上传hadoop失败是不可消除的，就是说虽然会偶尔出现，但是还是会出现，不能因为这个让用户再重传或者等好长时间才能上传成功，这些都对用户不友好。增加失效保障的目的就是，在client上传超时或失败情况下，client将失败任务通过调用该服务接口传入失效队列，client任务就完成了。当然，client上传时第一个工作是要在本地将文件写入硬盘。随后，失效保障可以通过定时服务，去扫描队列，通过队列获取硬盘中文件，继而再次上传到hdfs中。如果再次失败将不会再队列中消除，上传成功的即在队列中删除。

这样，在用户角度，上传文件时，client首先写入本地硬盘，然后去访问hdfs，如果超时（该超时不是hdfs的超时，是在应用设置的），或失败，即将任务写入失效保障中，返回用户，对用户而言，这个上传是短时间内完成的。