Jack：关于 trackerd 服务器的一个问题

happy_fish100

测试了一下 FastDFS  感觉还不错，配置简单且实用，但还没有做压力测试，若是可以承受大流量、高并发的文件访问请求的话，以后的推广应用就不会成为问题了，哈哈。

　　针对测试后有几个问题想请教一下：

　　１、现在添加一台　storage　服务器可以实现动态的增减，不需要去修改其它　storage　和　trackerd 　服务器的相关的配置文件，但是现在要是需要添加或减少一台　trackerd 　服务器的话就需要去一台一台的去修改与这台　trackerd 　服务器有关系的　storage　服务器，这还只是一方面更重要的是还需要去一台一台重起相应的　storage　服务以使配置生效。这对于一个本来设计时就是为了提供不间断文件服务的存储系统来说应该不要有这样的情况出现。为了避免这种情况，不知能否为　storage　服务器做一个动态增减　trackerd 　服务器的一个接口，或是在不中断对外的文件服务的前提下，重新载入配置文件的功能，以使修改后的配置文件可以生效（主要是对trackerd 相关参数的修改），这样应该就可以避免上述的问题出现了，像BIND那样就会有一个rndc这样的一个控制接口。不过觉得可能做一个重新载入配置文件的功能可能会更加容易实现些，呵呵。

　　２、当一组 storage　服务器添加了一台新的　storage　服务器后，trackerd 　会从　这一组原来的　storage　服务器中挑一台　storage　服务器把文件全部 PUT 到新添加的 storage　服务器中。这个过程在这一组　storage　服务器中所存储的文件不是很多，（应该说成巨多，比喻有将近１Ｔ的数据时）这样的同步方式可能不会有什么问题，当数据量大后，这样的同步就出现问题了，当数据量大后，且单个文件又小时，这样的问题就严重了，同步完这些数据可能会要花好几天的时候，还有可能要更长的时间。看到LOG文件里会有记录每个文件的时间，同步也应该是根据这个来做的吧，我的意思是能不能让原来这一组的　storage　服务器都一起向新添加的　storage　服务器同步数据，同步的文件列表或是时间段可以由 trackerd  服务器告诉每一台　storage　服务器，这样每一台　storage　服务器就知道他要同步哪些文件给新的　storage　服务器，也不会存在重复同步文件给新的　storage　服务器的问题了，这样也就可以加速文件同步过程，并可以减少出现更大故障的机率了。

　　以上的两个问题是在测试FastDFS后的感觉有些疑惑的地方，希望可以得到解答和帮助。哈哈

happy_fish100

happy_fish100：
首先谢谢你对FastDFS的大力支持。
你对FastDFS的理解比较深入的。压力测试在计划中，近期会有结果出来。

你这两点建议都挺好的，根据实际的需要，可以考虑支持。比如，实际运行中发现效果的确一般，可以考虑改进，呵呵。

fcsoe

这两个问题很关键，有没有好的解决方式呢