使用HDFS来进行线上应用的文件存储

使用HDFS来进行线上应用的文件存储

分类： 云计算 2011-07-06 17:57   721人阅读   评论(0)   收藏   举报

hadoop 任务 集群 存储 数据分析 服务器

这段时间公司使用的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的超时，是在应用设置的），或失败，即将任务写入失效保障中，返回用户，对用户而言，这个上传是短期内完成的。