DFS选型及功能扩展始末

       前几天因为工作的关系给dfs增加了“批量上传功能”,另外前段时间为了让dfs文件拥有更好的可管理性,给dfs目录前面加上了“YYYYMM”的文件前置符。这些工作都是基于dfs1.21版本开发的,但也可以在任一一个版本中加入使用。下面就讲讲完成这些工作的做法,想法,和为什么这么做的原因。

      代码前一段时间已经公开出来,有兴趣的同志可以去看我前几篇相关的blog。

       在写批量上传功能之前,我先预览了一下dfs的源代码,并且需求了其作者的帮助。大致的了解了dfs最重要的传输协议,服务器端和客户端相互之间的解析机制等等。在此还要谢谢dfs的作者在我增加批量增加功能时不厌其烦的为我解决问题。

      先说怎么选中的dfs吧。当初在选型的时候,考虑了很多的相关软件,比如mfs,hadoop等等。但是最后还是选中了dfs,原因有以下几点:

      1.dfs能满足我们现在的实际需求;

      2.dfs用全c编写,在我们的控制范围之内,并且好扩展;

      3.dfs和mfs或者hadoop等比起来,我们能很容易的联系到作者;

      4.dfs的性能,功能测试过关;

      再说说为什么要加这个批量上传功能。我们在开始的时候就考虑到实际环境中,这个批量上传功能是必须的。现在很少的站点是一次上传一个图片的,特别是一些电子商务站点,为了更为清楚的展示商品的细节,往往一次会上传n张的图片(n>5)。所以从网络的链接性能考虑,这个功能也是必要的。就算是你使用了连接池,网络的连接性能还是没有批量上传一次连接服务器的开销小。所以在真实环境上实验过dfs后,我们才开始着手扩展批量上传功能。

       还增加的一个功能是在原有的路径前面加上“年月”的标签。增加此功能的原因是方便我们对于图片的管理。很多的站点,特别是现在“统一号称web2.0”的站点,图片是难以想象的量啊!对于电子商务站点,图片是有时间属性的。也就是说过一段时间,图片会过期。这个时间段一般由业务决定,但是一般最多也就是半年(不知道taobao的时间是多少?)。对于一些发布单-订单的B2C站点,时间往往还要短,发布单被订单购买,表示此交易结束,发布单或者订单的图片生命周期就结束了。当然了不包括一些身份证明的图片,其实这些图片是跟用户走的,所以严格意义上讲不能说是交易流程的图片。因为图片有时间属性,所以时间化管理图片变的势在必行。最简单的方法就是在原有的路径前加上“YYYYMM”格式化的路径名。这种改法最少的改动了dfs的源代码,保持了dfs原本所有的特性,也方便了dfs的升级。那么我们的路径就从groupname\data\00\00\img.jpg更改为groupname\data\YYYYMM\00\00\img.jpg.这样的目地就是我们就能在一定的时间内归档我们的“过期(业务过期)”图片。从而节省我们线上的阵列资源,减小我们的管理难度。

        以前还有一个准备增加的功能,就是在客户端和服务器端增加一个心跳功能,检测dfs中tracker的健康状况,可是后来一想,客户端对于tracker而言,只要连接上tracker就算是tracker健康,连接不上就停止一段时间内对于此tracker的请求,这个功能完全能全部由客户端实现,没有必要更改dfs的服务器端代码。实现方式就是:只要客户端加一个事件和心跳程序(因为连接池我们在实现dfs客户端的时候就已经考虑到了)。事件是当我们正常从连接池中取得连接后,连接tracker失败时触发,事件的内容是置位连接池中刚刚连接失败的tracker全部为挂起状态;然后触发心跳事件,每隔一段时间(比如5分钟)去连接一次挂起的tracker,连接成功后置位挂起的tracker为可用,并且注销心跳事件,这个功能短连接也能使用,不是非得使用连接池。使用短连接的话,就是把刚刚说明中的连接池更换为维护一个“挂起tracker连接list”就行了。

你可能感兴趣的:(DFS)