今天我們就按照如圖所示，添加一臺新的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上去找到文件。
目前的邏輯圖如下：
必須要64的nginx啓動了，你纔可以通過63訪問得到文件
胡哥我是怎麼知道這個祕密的呢？在於觀察，請看下圖。
連續上傳同一個文件，發現有些規律可循。就猜測，應該與這個返回值有關。
那怎麼去驗證我的猜想呢？那就請各位想辦法去驗證。胡哥我就驗證出來了。^_^
接下來我們繼續驗證一下同步。修改邏輯狀態如下：
接下來繼續訪問一下
證明，63爲啥能訪問得到，是因爲64是正常的，但是63因爲一直是offline的狀態，所以63本機並沒有保存副本。
現在我們將機器恢復正常狀態，如下圖：
狀態都是正常的了，OK我們繼續來關閉64服務器
證明，當63和64正常的時候，同步就會進行，即便文件的source ip是64，當64出故障的時候，因爲63上有副本，這樣一樣可以訪問得到。