关于分布式文件系统 之前已经写过一些随笔 不过没怎么用心 本篇详细的整理一下
背景
海量存储、系统负载的迁移、服务器吞吐的瓶颈等等 让文件系统独立于业务系统 提高整个项目的扩展性以及可维护性
目前主流的方案 MFS FASTDFS GFS LUSTRE HADOOP等等
我选择的是FASTDFS 用一句广告语来说 “免费、快速、找得到”。FASTDFS的作者是淘宝的资深架构师余庆，很诙谐、很有爱！！！其他方案还没玩过 暂不评论。
简介
FastDFS是一款开源的轻量级分布式文件系统纯C实现，支持Linux、FreeBSD等UNIX系统类google FS，不是通用的文件系统，只能通过专有API访问，目前官方提供了C、Java和PHP API为互联网应用量身定做，追求高性能和高扩展性,FastDFS可以看做是基于文件的key value pair存储系统，称作分布式文件存储服务更为合适。
特点：
分组存储，灵活简洁
对等结构，不存在单点
文件ID由FastDFS生成，作为文件访问凭证。FastDFS不需要传统的name server
和流行的web server无缝衔接，FastDFS已提供apache和nginx扩展模块
大中小文件均可以很好支持，支持海量小文件存储
存储服务器上可以保存文件附加属性
名词解释：
Tracker Server：跟踪服务器，主要做调度工作，在访问上起负载均衡的作用。在内存中记录集群中group和storage server的状态信息，是连接Client和Storage server的枢纽。 因为相关信息全部在内存中，Tracker server的性能非常高，一个较大的集群（比如上百个group）中有3台就足够了。
Storage Server：存储服务器，文件和文件属性（meta data）都保存到存储服务器上。
实践-服务端
系统：ubuntu
开发工具：vim
web服务：nginx
基于socket自定义通信协议
服务端的安装参考官方文档 有不懂的可以联系虫子 这里说下问题比较多的2个地方 一个是libevent的版本问题 另一个是ubuntu最新版本中对于libpthread等库文件的存放位置问题
安装完fastdfs以后 假设你的服务端程序安装在/usr/local目录
我们会在bin目录下找到以下文件
storage服务器启动命令 /usr/local/bin/fdfs_storaged /FastDFS/conf/storage.conf
tracker服务器启动命令 /usr/local/bin/fdfs_trackerd /FastDFS/conf/tracker.conf
我们运行monitor查看下配置信息
group count: 1
Group 1:
group name = test
free space = 5 GB
storage server count = 2
active server count = 2
storage_port = 23000
storage_http_port = 0
store path count = 1
subdir count per path= 3
current write server index = 0
Host 1:
ip_addr = 192.168.234.139 (ubuntu) ACTIVE
total storage = 9GB
free storage = 5GB
total_upload_count = 2
success_upload_count = 2
total_set_meta_count = 0
success_set_meta_count = 0
total_delete_count = 0
success_delete_count = 0
total_download_count = 0
success_download_count = 0
total_get_meta_count = 0
success_get_meta_count = 0
total_create_link_count = 0
success_create_link_count = 0
total_delete_link_count = 0
success_delete_link_count = 0
last_heart_beat_time = 2012-01-05 18:45:50
last_source_update = 2012-01-05 01:20:28
last_sync_update = 1969-12-31 16:00:00
last_synced_timestamp= 1969-12-31 16:00:00
Host 2:
ip_addr = 192.168.234.140 ACTIVE
total storage = 18GB
free storage = 12GB
total_upload_count = 16
success_upload_count = 16
total_set_meta_count = 0
success_set_meta_count = 0
total_delete_count = 0
success_delete_count = 0
total_download_count = 0
success_download_count = 0
total_get_meta_count = 0
success_get_meta_count = 0
total_create_link_count = 0
success_create_link_count = 0
total_delete_link_count = 0
success_delete_link_count = 0
last_heart_beat_time = 2012-01-05 18:45:50
last_source_update = 2012-01-05 01:54:02
last_sync_update = 1969-12-31 16:00:00
last_synced_timestamp= 1969-12-31 16:00:00
|
storage.conf整理汉化版
tracker.conf整理汉化版
Web服务
FastDfs本身提供了组的概念，不同的组可以用不同的域名，如果是图片等类型资源，利用多个子域名在网站优化中是很有帮助的。不过如果你想在一个域名下实现多个服务器的分布式方案，可以利用nignx的反向代理来做urlrewrite。
举个简单的例子
server {
listen 80;
server_name 192.168.234.140;
index index.html index.htm index.php;
root /app/test;
location /g1{
proxy_pass http://192.168.234.139;
}
}
|
分布式算法
和memcached这些分布式系统不同。Fastdfs的分布式算法是在服务端实现，Fish也在不断改良着算法。最新的是avl树。不过貌似有整rbtree的趋势。
负载均衡，同步
fastdfs还内置了组内的同步功能，不过我觉得对于我的项目可用性不大，因为我要实现的是狭义的分布式文件系统只要能保证海量的可扩展存储方案就可以了，同步、负载均衡之类的就交给专业的运维们吧。
同步功能没有开关配置，在同步时间设置上作手脚就可以了。
sync_start_time，sync_end_time
实践-客户端
系统：windowsXP
开发工具：VS2008
首先我们来看下基本功能
找张mm图片 -_____-
上传成功 对比一下
然后再看看分布式结果
192.168.234.139上
192.168.234.140上
web上浏览
性能方面 和服务器本身的带宽 吞吐都有关系 不过作为文件系统 对稳定性的要求更大 而fastdfs的很多实例都证明了这一点
看完上面 是不是觉得很容易入手 当然 fastdfs的深度应用还有很多
对于.net下 fastdfs的应用 大家有什么疑问可以联系我
本篇先到此 希望对大家有帮助
本文转自 熬夜的虫子 51CTO博客，原文链接:http://blog.51cto.com/dubing/760388
