最近我发现在我blog上的一篇关于FastDFS客户端的文章被很多人点击过了。我分析了一下(一厢情愿的),可能是因为DFS没有net的客户端吧!后来联系上了FastDFS的作者,证实确实缺乏“官方”的net客户端,正好以前应用过DFS,也写了一个net的客户端,所以就正式贡献出来开源。
此次开源的FastDFS客户端对应着DFS的V1.21版本。从测试和目前的使用情况来看,V1.21已经比较稳定了,大规模的应用已经没有什么大的问题;据从作者处得知的情况,FastDFS的V1.23版本(具体不确定哪个版本,但是肯定是V1.21以上版本。)以上已经更改过“传输协议”,所以暂时的DFS客户端版本不支持;这里也不敢随便向各位保证什么时候会更改客户端,因为下半年事情比较多。但是我用良心保证V1.21的版本绝对问题不大,而且这个客户端对V1.21绝对支持。
DFS的Net客户端使用Net Framework2.0完成,不提供Net Framework1.1版本。从测试情况来看,使用TCP的短链接会频繁的触发net的GC机制,所以增加了“连接池”的功能。DFS体系中的Tracketr的负载平衡也是通过DFS的客户端完成,目前提供的方式为“轮询”机制(Storage的负载平衡通过DFS的服务器端的配置完成),当然为了提高系统的可用性,会在链接失败和线程池中无可用连接池通过短链接作为补偿机制(该补偿机制通常不出现);在net客户端中增加的BatchUpload方法,这是提供给一个更改版本的FastDFS使用的,从FastDFS官方网站下载的软件中没有此功能(已经和FastDFS的作者联系过,代码也已经提交,不知道是不是已经放进去。)。
查看DFS客户端的朋友可能会发现在客户端中除了一个Upload方法以外没有别的方法,但是FastDFS的服务器端提供了对图片的上传,修改,删除等操作。至于为什么我们没有提供除了upload以外的方法,原因在于:现在Web2.0时代,对于互联网企业,80%的数据都是第一次增加后不会更改的,只有20%的数据会更改,而且一般频繁更改的数据都会放在数据库中或者廉价的存储中,所以对于需要更改的文件,那么我们就让用户再上传一次文件,这种方式更有利的地方是速度快,节省带宽,减少复杂度,而且重复的图片也不会太多,对于存储文件TB级的文件来讲,这些文件的量基本可以忽略不计。
对此已经更改的版本(增加了batchupload功能,增强了DFS的文件管理性),我们已经在考虑将其开源了,因为更改完成后因为工作和时间的问题,到现在都未对其进行测试,所以等测试完毕,我们将对其开源。
最后,为了支持开源,希望各位在使用分布式文件系统时考虑一下国人的劳动成果。
附:
FastDFS:http://code.google.com/p/fastdfs/
FastDFS .Net Client: http://code.google.com/p/fastdfs-net-client/
FastDFS TCP传输协议解析:http://www.cnblogs.com/Seapeak/archive/2010/02/10/1666986.html
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· 单线程的Redis速度为什么快?
· SQL Server 2025 AI相关能力初探
· 展开说说关于C#中ORM框架的用法!
· AI编程工具终极对决:字节Trae VS Cursor,谁才是开发者新宠?