关于FastDFS的可扩展性的疑问
我阅读了FastDFS的介绍资料后，据说FastDFS的扩展性很好。。。我对此有些疑问。。。
按说FastDFS中，文件ID进行hash后可得到文件存储在哪个卷（volume）。当系统需要扩容时，如果新增加卷，则是否需要对hash函数进行改动呢？如果是的话，则需对所有客户端进行更新，开销较大，可扩展性不好。
请高手帮我分析一下，谢谢！
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
用户端有没有保存各个storage server的ip地址呢？
如果没有，那就是需要从Trackerserver得到吧，这样Trackerserver在负责负载均衡和调度工作的同时，也提供了文件的位置信息（文件索引）啊。。。
谢谢！
回复 6# Ivy就是长青草
还包括两点：对等结构和分组方式
具体的讲解参阅《分布式文件系统FastDFS架构剖析》一文。
回复 4# happy_fish100
如果我把FastDFS最主要的特点归结为：
轻量级
支持高并发访问
高可扩展性
正确吗？
回复 4# happy_fish100
谢谢！
本帖最后由 happy_fish100 于 2011-02-17 14:12 编辑
回复 3# Ivy就是长青草
存储文件，不需要采用hash分布的方式吧。
如果你是存储key value pair，按key进行hash分布，是比较合理的。
FastDFS 3.0将对小文件进行优化，到时才会引入文件存储偏移量，谢谢！
回复 2# happy_fish100
谢谢！我还想再请问一下：
TFS中的文件ID，是对block ID和File ID等进行编码得到的，请问FastDFS中的文件ID是否也是对卷号、偏移量、文件名等进行了编码呢？
还有一个问题，如果使用hash的方式，可能会降低可扩展性吧，但应该也会有些优点吧，能否帮忙分析一下？
谢谢！
回复 1# Ivy就是长青草
FastDFS对文件存储时，并没有采用hash方式。
tracker server作为中心服务器，起作负载均衡和调度作用。
理论上，group可以无限扩容。FastDFS支持上K的group数，没有任何问题。