论坛徽章:: 0

1楼 [报告]

发表于 2012-02-27 20:54 |显示全部楼层

本帖最后由独臂剑客于 2012-02-27 21:00 编辑

看了<<分布式文件系统FastDFS>>简介，不错，赞一个

1：不支持并行写，这个比较合理，chubby实现看也有不小缺点。
2：看文档好像不支持修改操作，不过看有追加写API，修改实现应该也会在那个版本会支持吧。
3：有没有考虑对不同磁盘介质如SATA、SAS、SSD等做一些配置、读写合并优化等。
4：不支持用户自定义文件名，对于一些可以用KEY生成文件名的公司业务，如果业务有太多小文件，业务自己存文件名就要重新搭一套SQL/NoSQL，FastDFS是否可以内部搭建索引帮业务完成，现在都有比较成熟的nosql开源借鉴，不过看作者如何考虑。
5：组内文件同步机制如何完成？如果和rsync类实现机制，对于强一致性的业务虽然可以从源数据访问，但对于高并发业务还是有局限性，是否考虑在storage前加一层cache模块？tracker下载时间戳判断来看逻辑任务比较重了。
6：如果新加一组服务器，是否业务新写请求都落到新加入组，扩容系统是否有自动均匀存储，自动平衡迁移的能力？
7：如果组内每一台服务器盘异常或文件块损坏，是否有自动恢复能力？
8：发现没有预上传接口，对于重复存储文件，FastDFS如何处理的？
9：下载文件以及存储读取这些都要询问tracker，tracker网络在大并发业务处理会成为屏劲，前端client有没有缓冲？
10：热点文件前端http模块有没有处理？

就随便列几点吧，祝福FastDFS日益成熟，不知是否有开源组织和LZ一起完善？

独臂剑客

家境小康

论坛徽章:: 0

2楼 [报告]

发表于 2012-02-28 12:36 |显示全部楼层

回复 31# happy_fish100

>>3：有没有考虑对不同磁盘介质如SATA、SAS、SSD等做一些配置、读写合并优化等。
A：底层文件系统，已经实现了读写合并等优化策略。FastDFS暂时没有这方面的优化考虑。
--------------------------------------
不同磁盘介质在合并优化写方面差异还是很大，VFS的IO调度策略也各不相同，写操作没成为屏劲问题到不大。

>>9：下载文件以及存储读取这些都要询问tracker，tracker网络在大并发业务处理会成为屏劲，前端client有没有缓冲？
A：tracker server非常轻量级，支持的并发数完全可以超过5K。4核CPU上，QPS完全可以达到5w/s

SET点多了以后，如果所有API操作都依赖tracker，tracker就需要考虑IDC分布了，网络波动外部环境都会影响业务体验，个人理解tracker相当于一个配置中心，既然是一个配置逻辑规则处理中心，为啥前端client不缓冲一份，如果配置中心配置或逻辑变化，client再重新拉取即可。