前几天因为工作的关系给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”就行了。
