Jack：關(guān)于 trackerd 服務(wù)器的一個問題

happy_fish100

測試了一下 FastDFS  感覺還不錯，配置簡單且實(shí)用，但還沒有做壓力測試，若是可以承受大流量、高并發(fā)的文件訪問請求的話，以后的推廣應(yīng)用就不會成為問題了，哈哈。

　　針對測試后有幾個問題想請教一下：

　　１、現(xiàn)在添加一臺　storage　服務(wù)器可以實(shí)現(xiàn)動態(tài)的增減，不需要去修改其它　storage　和　trackerd 　服務(wù)器的相關(guān)的配置文件，但是現(xiàn)在要是需要添加或減少一臺　trackerd 　服務(wù)器的話就需要去一臺一臺的去修改與這臺　trackerd 　服務(wù)器有關(guān)系的　storage　服務(wù)器，這還只是一方面更重要的是還需要去一臺一臺重起相應(yīng)的　storage　服務(wù)以使配置生效。這對于一個本來設(shè)計(jì)時就是為了提供不間斷文件服務(wù)的存儲系統(tǒng)來說應(yīng)該不要有這樣的情況出現(xiàn)。為了避免這種情況，不知能否為　storage　服務(wù)器做一個動態(tài)增減　trackerd 　服務(wù)器的一個接口，或是在不中斷對外的文件服務(wù)的前提下，重新載入配置文件的功能，以使修改后的配置文件可以生效（主要是對trackerd 相關(guān)參數(shù)的修改），這樣應(yīng)該就可以避免上述的問題出現(xiàn)了，像BIND那樣就會有一個rndc這樣的一個控制接口。不過覺得可能做一個重新載入配置文件的功能可能會更加容易實(shí)現(xiàn)些，呵呵。

　　２、當(dāng)一組 storage　服務(wù)器添加了一臺新的　storage　服務(wù)器后，trackerd 　會從　這一組原來的　storage　服務(wù)器中挑一臺　storage　服務(wù)器把文件全部 PUT 到新添加的 storage　服務(wù)器中。這個過程在這一組　storage　服務(wù)器中所存儲的文件不是很多，（應(yīng)該說成巨多，比喻有將近１Ｔ的數(shù)據(jù)時）這樣的同步方式可能不會有什么問題，當(dāng)數(shù)據(jù)量大后，這樣的同步就出現(xiàn)問題了，當(dāng)數(shù)據(jù)量大后，且單個文件又小時，這樣的問題就嚴(yán)重了，同步完這些數(shù)據(jù)可能會要花好幾天的時候，還有可能要更長的時間�？吹絃OG文件里會有記錄每個文件的時間，同步也應(yīng)該是根據(jù)這個來做的吧，我的意思是能不能讓原來這一組的　storage　服務(wù)器都一起向新添加的　storage　服務(wù)器同步數(shù)據(jù)，同步的文件列表或是時間段可以由 trackerd  服務(wù)器告訴每一臺　storage　服務(wù)器，這樣每一臺　storage　服務(wù)器就知道他要同步哪些文件給新的　storage　服務(wù)器，也不會存在重復(fù)同步文件給新的　storage　服務(wù)器的問題了，這樣也就可以加速文件同步過程，并可以減少出現(xiàn)更大故障的機(jī)率了。

　　以上的兩個問題是在測試FastDFS后的感覺有些疑惑的地方，希望可以得到解答和幫助。哈哈

happy_fish100

happy_fish100：
首先謝謝你對FastDFS的大力支持。
你對FastDFS的理解比較深入的。壓力測試在計(jì)劃中，近期會有結(jié)果出來。

你這兩點(diǎn)建議都挺好的，根據(jù)實(shí)際的需要，可以考慮支持。比如，實(shí)際運(yùn)行中發(fā)現(xiàn)效果的確一般，可以考慮改進(jìn)，呵呵。

fcsoe

這兩個問題很關(guān)鍵，有沒有好的解決方式呢