FastDFS中的數(shù)據(jù)維護(hù)的幾個(gè)疑問(wèn)

wwwlovekaikai

1.在tracker_server中，storage_groups_new.dat描述了group的 storage_http_port=8888 ,store_path_count=1,subdir_count_per_path=256等，這些信息實(shí)際在用么？如果在用，那storage配置不一致的話，情況會(huì)是怎么樣的呢？
2.同一組內(nèi)只有兩個(gè)節(jié)點(diǎn)，啟動(dòng)時(shí)的初始化信息：
A:
storage_join_time=1322723465
sync_old_done=1
sync_src_server=192.168.8.34
sync_until_timestamp=1322724887
last_ip_addr=192.168.8.35
last_server_port=23000
last_http_port=8888
current_trunk_file_id=0
B:
storage_join_time=1322723477
sync_old_done=1
sync_src_server=
sync_until_timestamp=0
last_ip_addr=192.168.8.34
last_server_port=23000
last_http_port=8888
current_trunk_file_id=0
有一點(diǎn)不明白，為什么先啟動(dòng)的Storage的src是后啟動(dòng)的呢？請(qǐng)指點(diǎn)，謝謝~

happy_fish100

回復(fù) 1# wwwlovekaikai

同一個(gè)group中storage server的關(guān)鍵配置必須保持一致啊，否則會(huì)出問(wèn)題的。
比如你帖子中列舉的兩個(gè)參數(shù)，就必須保持一致。

wwwlovekaikai

首先，謝謝BZ的回復(fù)。
由于我的表述問(wèn)題，第2個(gè)問(wèn)題可能BZ沒(méi)能看明白我說(shuō)的情況。我重新表述一下子。是這樣的：
從啟動(dòng)的參數(shù)上，A的storage_join_time要比B的storage_join_time小，也就是說(shuō)A先加入的。
但A的sync_src_server=192.168.8.34，而B的sync_src_server卻是空。我認(rèn)為sync_src_server這個(gè)參數(shù)是tracker告訴它，誰(shuí)是它的源并源給它同步數(shù)據(jù),即：sync_src_server的值起碼比本節(jié)點(diǎn)更早加入，我就是感覺(jué)這反了。是不是我的思路出現(xiàn)問(wèn)題了?
那storage_join_time=1322723465
   sync_old_done=1
   sync_src_server=192.168.8.34
   sync_until_timestamp=1322724887
   last_ip_addr=192.168.8.35
   last_server_port=23000
   last_http_port=8888
   current_trunk_file_id  這些參數(shù)能幫忙解釋一下么，謝謝BZ!!

happy_fish100

回復(fù) 3# wwwlovekaikai

二者加入的時(shí)間戳相差只有10多秒，誰(shuí)先ACTIVE就為成為改group另外一臺(tái)storage server的源。
加入時(shí)間相差太短，幾乎可以認(rèn)為是同時(shí)加入的，這個(gè)就不要糾結(jié)了吧。

wwwlovekaikai

謝謝BZ,我現(xiàn)在正在學(xué)習(xí)階段，請(qǐng)諒解~，哈哈

還有一問(wèn)題不明白，就是上傳一個(gè)文件后，在還沒(méi)有被同步的情況下，用戶去下載，Tracker可以返回源Storage地址。
那么，請(qǐng)問(wèn)，源的地址是保存在fileId中么？（我目前知道fileId由組名+目錄+文件名組成），難到fileId還是其它的信息？如果這里不成立，僅靠storage的同步時(shí)間來(lái)判斷，可以找到這個(gè)文件的源么？

歸結(jié)就兩點(diǎn)：
        1.fileId具體保存哪些數(shù)據(jù)信息？
        2.tracker如何找到上傳文件源的？

希望快樂(lè)的魚幫助解釋一下

happy_fish100

回復(fù) 5# wwwlovekaikai

FastDFS介紹PPT中有介紹的啊！LZ先看一下吧。
文件ID中包含了哪些字段，F(xiàn)AQ中應(yīng)該也是有解答的吧。

wwwlovekaikai

ppt，我看過(guò)的。里面對(duì)fileId的組成只是說(shuō)：組、文件名（包括目錄）組成的。

wwwlovekaikai

回復(fù) #9 happy_fish100 的帖子
哥們，你這個(gè)系統(tǒng)做得貌似簡(jiǎn)單其實(shí)精巧！

仔細(xì)看了下機(jī)制，明白文件命名的好處了：
數(shù)據(jù)文件名由系統(tǒng)自動(dòng)生成，包括4部分：存儲(chǔ)服務(wù)器IP地址、當(dāng)前時(shí)間（Unix時(shí)間戳）、文件大�。ㄗ止�(jié)數(shù)）和隨機(jī)數(shù)。文件名長(zhǎng)度為22字節(jié)。

step1，tracker收到下載文件的請(qǐng)求時(shí)，從v1.2開始就可以直接從請(qǐng)求的文件名內(nèi)解析出storage_ip和文件上傳時(shí)間（Unix時(shí)間戳）、結(jié)合請(qǐng)求傳來(lái)的的group；

step2.然后從該group存活的storage列表中找這個(gè)storage_ip（即該文件原來(lái)上傳的ip，源ip），要是這個(gè)storage_ip停掉了即查找失敗，則取該group內(nèi)的存活的下一個(gè)storage_ip1并且比較文件上傳時(shí)間和該storage_ip1同步時(shí)間戳,沒(méi)有符合條件的好像會(huì)取該group內(nèi)一個(gè)存活的ip給客戶端。代碼內(nèi)這個(gè)機(jī)制要是注釋清楚一些就更好了：）

step3，storage定期向tracker通報(bào)自己的最新做完的文件同步時(shí)間戳，這個(gè)時(shí)間戳需要退出tracker時(shí)才flush到storage_servers.dat，運(yùn)行時(shí)我等了十來(lái)分鐘都沒(méi)看到更新進(jìn)去。
storage_servers.dat中記錄storage server相關(guān)信息，字段依次為：
……
16. stat.last_source_update：最近一次源頭更新時(shí)間（更新操作來(lái)自客戶端）
17. stat.last_sync_update：最近一次同步更新時(shí)間（更新操作來(lái)自其他storage server的同步）

非常感謝快樂(lè)魚


上面是happy_fastdfs的一個(gè)回復(fù)BZ,FastDFS同步機(jī)制的一個(gè)回帖。
這個(gè)回貼是正確的么？如果正確，那么像這樣的fileId:group1/M00/00/05/wKgEIk7oZ4XnI7_JAAFbsTBcHDA572.jpg.我們從哪里知道時(shí)間及storageIP的呢？還是后面的文件名是加密處理了？

wwwlovekaikai

我看看storage_service.c 的相關(guān)函數(shù)，明白了。

謝謝BZ!

happy_fish100

贊LZ的鉆研精神！
LZ看了代碼后的解釋，非常準(zhǔn)確��！