- 论坛徽章:
- 0
|
想上fastdfs或者类fastdfs分布式文件系统的，大抵是网站和文件数到了一定规模，原有集中存储无法满足扩容和备份需求。也就不得不面对一个问题，老系统如何迁移问题。
在其它帖子里也有人问过，我今天重新把自己的思路和大家探讨下，希望得到些更广泛的讨论。
我的应用场景：
网站大量小文件，大部分是图片，还有一部分是Html页面。
图片应用有大图，小图，中图不同的尺寸。需要切图。
原来使用盘柜集中存储，5T (ibm 3400 盘柜 ， SAS硬盘)，存储上启NFS服务，mount了6台应用。
问题：
盘柜故障，硬盘偶尔会坏
NFS性能问题，应用再扩的话，性能上和管理性上面，都麻烦，另外nfs有bug,一旦服务端有点什么问题，mount上来的机器都可能扶起无响应。
原系统使用3级目录存放文件，访问地址类似
http://img.a.b.c.com/01/02/03/xxxxxxx.jpg
http://img.a.b.c.com/01/02/03/xxxxxxx.thumb.jpg
分别访问大图和小图。
上分布式要解决的问题：
a.老系统http://img.a.b.c.com/01/02/03/xxxxxxx.jpg 这种URL schema的支持。
b.切图服务重新要改成使用fastdfs的api访问，取得原图，再切图，再返回。
上FastDFS的技术方案：
1. 实现名字空间。使用目前比较成熟和高性能的redis key/value 来存储老名字url和fastdfs返回的fileid对应。
图片访问：访问http://img.a.b.c.com/01/02/03/xxxxxxx.jpg ， 写一个nginx模块，先从redis取得fileid，然后再调用api取得分布式存储里的图片。
应用改造：保存文件里使用api返回fileid后再以01/02/03/xxxxxxx.jpg 按md5或者其它什么高效的算法进行hash作为key, value=fileid, 存一次redis.
2. 实现切图服务。写一nginx模块，按规则解析出这是访问一张小图的地址，再按1的规则取出原图，实时切出小图，并返回。
性能优化：为了降低高并发调用同一张图片，再加一道文件cache,这可以用squid，或者nginx cache模块都好配置。不再细说。再加上cdn，这样真正需要实际访问存储的请求就非常少了，在几天内同一张图片只需要读取一次。
3. 历史数据迁移。等1.和2.都做到了，不再往老存储里写数据。新的按1.的方式写到新文件系统里。
再写一个迁移程序，对老系统里的01/02/03/xxxxxxx.jpg这种风格的文件迁到新文件系统里。
我们系统里大概是1.5亿个文件数，可能导得慢点，但不影响生产系统，反正就开起来让它24小时跑着，总有一天老系统将全部迁移完成。
技术选型的考虑:
redis本身有很多大公司生产系统都在用了，其稳定性和可靠性不用自己再当小白鼠。承受我们网站的访问量和1个亿级别的key/value，我想问题不大。
其实上面的方案对其它不支持名字空间或者posix兼容的分布式文件系统也适用，比如淘宝的tfs，但当我2年再一次看fastdfs，我还是想选fastdfs. 顺带一句感概，09年我就想上fastDFS,可是阴差阳错，当时不知道什么原因的原因，没能上成而上了ibm的盘柜；如今2.5年过去了，现在都2012了. 又一次回看fastdfs,有一种时光倒转的感觉。我想我和fastdfs，应该还是有些缘份。扯蛋结束，请各位拍砖。
|
|
免费注册
发表于 2012-01-17 00:11
怎么看出公司有钱。