起因：
当我们部署FastDFS丛集多个storage节点环境时，有这么一种情况，上传一张图片后，立马访问有时会出现图片不存在的情况，当然这个立马访问指的是程式去呼叫，也就是图片路径返回后及时去访问。这一系列步骤都是通过程式去实现的，手动操作肯定是赶不上这速度的。这种情况是由档案同步延迟导致的。
一、档案同步延迟问题
FastDFS同组内storage server资料是同步的， Storage server中由专门的执行绪根据binlog进行档案同步。为了最大程度地避免相互影响以及出于系统简洁性考虑，Storage server对组内除自己以外的每台服务器都会启动一个执行绪来进行档案同步。档案同步采用增量同步方式，系统记录已同步的位置（binlog档案偏移量）到标识档案中。标识档名格式：{dest storage IP}_{port}.mark，例如：192.168.1.14_23000.mark。Storage server采用binlog档案记录档案上传、删除等更新操作。binlog中只记录档名，不记录档案内容。档案同步只在同组内的Storage server之间进行，采用push方式，即源头服务器同步给目标服务器。只有源头资料才需要同步，备份资料并不需要再次同步，否则就构成环路了。有个例外，就是新增加一台Storage server时，由已有的一台Storage server将已有的所有资料（包括源头资料和备份资料）同步给该新增服务器。客户端将一个档案上传到一台Storage server后，档案上传工作就结束了。由Storage server根据binlog中的上传记录将这个档案同步到同组的其他Storage server。这样的档案同步方式是异步方式，异步方式带来了档案同步延迟的问题。新上传档案后，在尚未被同步过去的Storage server上访问该档案，会出现找不到档案的现象。
二、FastDFS对档案同步延迟问题的解决方案
需要说明的是，一个组包含的Storage server不是通过配置档案设定的，而是通过Tracker server获取到的。客户端和Storage server主动连线Tracker server。Storage server主动向Tracker server报告其状态资讯，包括磁盘剩余空间、档案同步状况、档案上传下载次数等统计资讯。Storage server会连线丛集中所有的Tracker server，向他们报告自己的状态。Storage server启动一个单独的执行绪来完成对一台Tracker server的连线和定时报告。另外，每台storage server都会定时向tracker server报告它向同组的其他storage server同步到的档案时间戳。当tracker server收到一台storage server的档案同步报告后，它会依次找出该组内各个storage server被同步到的档案时间戳最小值，作为storage的一个属性记录到内存中。
根据上述情况FastDFS提供下面简单解决方案：
1、和档案更新一样，优先选择源Storage server下载档案即可。这可以在Tracker server的配置档案中设定，对应的引数名为download_server。
2、选择Storage server的方法是轮流选择（round-robin）。当Client询问Tracker server有哪些Storage server可以下载指定档案时，Tracker server返回满足如下四个条件之一的Storage server：
a、该档案上传到的源Storage server，档案直接上传到该服务器上的；
b、档案建立时间戳
c、档案建立时间戳=Storage server被同步到的档案时间戳，且（当前时间—档案建立时间戳） > 一个档案同步完成需要的最大时间（如5分钟）；
d、（当前时间—档案建立时间戳） > 档案同步延迟阈值，比如我们把阈值设定为1天，表示档案同步在一天内肯定可以完成。
并且该引数的预设值为0，也就是round-robin模式。
引数
我只需要将download_server引数预设值修改为1，然后重启便可。
