FastDFS中的数据维护的几个疑问

wwwlovekaikai

1.在tracker_server中，storage_groups_new.dat描述了group的 storage_http_port=8888 ,store_path_count=1,subdir_count_per_path=256等，这些信息实际在用么？如果在用，那storage配置不一致的话，情况会是怎么样的呢？
2.同一组内只有两个节点，启动时的初始化信息：
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
有一点不明白，为什么先启动的Storage的src是后启动的呢？请指点，谢谢~

happy_fish100

回复 1# wwwlovekaikai

同一个group中storage server的关键配置必须保持一致啊，否则会出问题的。
比如你帖子中列举的两个参数，就必须保持一致。

wwwlovekaikai

首先，谢谢BZ的回复。
由于我的表述问题，第2个问题可能BZ没能看明白我说的情况。我重新表述一下子。是这样的：
从启动的参数上，A的storage_join_time要比B的storage_join_time小，也就是说A先加入的。
但A的sync_src_server=192.168.8.34，而B的sync_src_server却是空。我认为sync_src_server这个参数是tracker告诉它，谁是它的源并源给它同步数据,即：sync_src_server的值起码比本节点更早加入，我就是感觉这反了。是不是我的思路出现问题了?
那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  这些参数能帮忙解释一下么，谢谢BZ!!

happy_fish100

回复 3# wwwlovekaikai

二者加入的时间戳相差只有10多秒，谁先ACTIVE就为成为改group另外一台storage server的源。
加入时间相差太短，几乎可以认为是同时加入的，这个就不要纠结了吧。

wwwlovekaikai

谢谢BZ,我现在正在学习阶段，请谅解~，哈哈

还有一问题不明白，就是上传一个文件后，在还没有被同步的情况下，用户去下载，Tracker可以返回源Storage地址。
那么，请问，源的地址是保存在fileId中么？（我目前知道fileId由组名+目录+文件名组成），难到fileId还是其它的信息？如果这里不成立，仅靠storage的同步时间来判断，可以找到这个文件的源么？

归结就两点：
        1.fileId具体保存哪些数据信息？
        2.tracker如何找到上传文件源的？

希望快乐的鱼帮助解释一下

happy_fish100

回复 5# wwwlovekaikai

FastDFS介绍PPT中有介绍的啊！LZ先看一下吧。
文件ID中包含了哪些字段，FAQ中应该也是有解答的吧。

wwwlovekaikai

ppt，我看过的。里面对fileId的组成只是说：组、文件名（包括目录）组成的。

wwwlovekaikai

回复 #9 happy_fish100 的帖子
哥们，你这个系统做得貌似简单其实精巧！

仔细看了下机制，明白文件命名的好处了：
数据文件名由系统自动生成，包括4部分：存储服务器IP地址、当前时间（Unix时间戳）、文件大小（字节数）和随机数。文件名长度为22字节。

step1，tracker收到下载文件的请求时，从v1.2开始就可以直接从请求的文件名内解析出storage_ip和文件上传时间（Unix时间戳）、结合请求传来的的group；

step2.然后从该group存活的storage列表中找这个storage_ip（即该文件原来上传的ip，源ip），要是这个storage_ip停掉了即查找失败，则取该group内的存活的下一个storage_ip1并且比较文件上传时间和该storage_ip1同步时间戳,没有符合条件的好像会取该group内一个存活的ip给客户端。代码内这个机制要是注释清楚一些就更好了：）

step3，storage定期向tracker通报自己的最新做完的文件同步时间戳，这个时间戳需要退出tracker时才flush到storage_servers.dat，运行时我等了十来分钟都没看到更新进去。
storage_servers.dat中记录storage server相关信息，字段依次为：
……
16. stat.last_source_update：最近一次源头更新时间（更新操作来自客户端）
17. stat.last_sync_update：最近一次同步更新时间（更新操作来自其他storage server的同步）

非常感谢快乐鱼


上面是happy_fastdfs的一个回复BZ,FastDFS同步机制的一个回帖。
这个回贴是正确的么？如果正确，那么像这样的fileId:group1/M00/00/05/wKgEIk7oZ4XnI7_JAAFbsTBcHDA572.jpg.我们从哪里知道时间及storageIP的呢？还是后面的文件名是加密处理了？

wwwlovekaikai

我看看storage_service.c 的相关函数，明白了。

谢谢BZ!

happy_fish100

赞LZ的钻研精神！
LZ看了代码后的解释，非常准确啊！