今天我们就按照如图所示，添加一台新的storage（163.64）到group1中。
其实过程很简单，与之前的新建storage过程一模一样，这里就不在累述。
另外还有nginx的配置，这里也不多说了，请参考我的《FastDFS--简易配置（一）》。
现在查看一下访问文件的效果
可以正常访问滴。
接下来我们模拟一下其中一台storage下线了，看看是否有影响访问。
163.63已经下线了，那么理论上来说63应该不会得到同步。好吧，我们接下来上传一个图片试试，看看63是否真的不会得到同步
接下来我们访问一下61（负载均衡）63（storage1）64（storage2）
都能访问得到这个刚上传的图片？
那不应该呀，63不是offline了吗？怎么还会同步的呢？
稍安勿躁。我们来看看刚上传文件的信息吧。
source ip是在64上。
为啥访问63也可以得到结果呢？秘密在于我们上传的时候返回的这个ID信息。这里就有这个文件保存的地址。我们安装的这个模块fastdfs-nginx-module-master.zip，就会从这个source ip上去找到文件。
目前的逻辑图如下：
胡哥我是怎么知道这个秘密的呢？在于观察，请看下图。
连续上传同一个文件，发现有些规律可循。就猜测，应该与这个返回值有关。
那怎么去验证我的猜想呢？那就请各位想办法去验证。胡哥我就验证出来了。^_^
接下来我们继续验证一下同步。修改逻辑状态如下：
接下来继续访问一下
证明，63为啥能访问得到，是因为64是正常的，但是63因为一直是offline的状态，所以63本机并没有保存副本。
现在我们将机器恢复正常状态，如下图：
证明，当63和64正常的时候，同步就会进行，即便文件的source ip是64，当64出故障的时候，因为63上有副本，这样一样可以访问得到。
