頻繁的全量複製（1）

　　問題現象：

　　　　伴隨著系統的執行，master的資料量會越來越大，一旦master重啟，runid將發生變化，會導致全部slave的全量複製操作

內部優化調整方案：

　　1. master內部建立master_replid變數，使用runid相同的策略生成，長度41位，併發送給所有slave

　　2. 在master關閉時執行命令 shutdown save，進行RDB持久化,將runid與offset儲存到RDB檔案中

　　　　（1）repl-id           repl-offset

　　　　（2） 通過redis-check-rdb命令可以檢視該資訊

　　3. master重啟後加載RDB檔案，恢復資料。重啟後，將RDB檔案中儲存的repl-id與repl-offset載入到記憶體中

　　　　（1）master_repl_id = repl                    master_repl_offset = repl-offset

　　　　（2）通過info命令可以檢視該資訊

　　作用：本機儲存上次runid，重啟後恢復該值，使所有slave認為還是之前的master

頻繁的全量複製（2）
　　問題現象：

　　　　 網路環境不佳，出現網路中斷，slave不提供服務

　　 問題原因：

　　　　 複製緩衝區過小，斷網後slave的offset越界，觸發全量複製

　　最終結果： 

　　　　slave反覆進行全量複製

　　解決方案：

　　　　 修改複製緩衝區大小

repl-backlog-size

　　 建議設定如下：

　　　　1. 測算從master到slave的重連平均時長second

　　　　2. 獲取master平均每秒產生寫命令資料總量write_size_per_second

　　　　3. 最優複製緩衝區空間 = 2 * second * write_size_per_second

頻繁的網路中斷（1）

　　 問題現象：

　　　　 master的CPU佔用過高 或 slave頻繁斷開連線

　　 問題原因：

　　　　（1） slave每1秒傳送REPLCONF ACK命令到master

　　　　（2） 當slave接到了慢查詢時（keys * ，hgetall等），會大量佔用CPU效能

　　　　（3） master每1秒呼叫複製定時函式replicationCron()，比對slave發現長時間沒有進行響應

　　 最終結果：

　　　　 master各種資源（輸出緩衝區、頻寬、連線等）被嚴重佔用。

　　 解決方案：

　　　　通過設定合理的超時時間，確認是否釋放slave

repl-timeout//該引數定義了超時時間的閾值（預設60秒），超過該值，釋放slave

頻繁的網路中斷（2）

 問題現象：

　　　　slave與master連線斷開

　　 問題原因：

　　　　（1）  master傳送ping指令頻度較低

　　　　（2）  master設定超時時間較短

　　　　（3） ping指令在網路中存在丟包

　　 解決方案：

　　　　 提高ping指令傳送的頻度

repl-ping-slave-period//超時時間repl-time的時間至少是ping指令頻度的5到10倍，否則slave很容易判定超時

 資料不一致

　　問題現象：

　　　　 多個slave獲取相同資料不同步

　　 問題原因：

　　　　 網路資訊不同步，資料傳送有延遲

　　 解決方案：

　　　　 （1）優化主從間的網路環境，通常放置在同一個機房部署，如使用阿里雲等雲伺服器時要注意此現象

　　　　（2） 監控主從節點延遲（通過offset）判斷，如果slave延遲過大，暫時遮蔽程式對該slave的資料訪問

slave-serve-stale-data yes|no//開啟後僅響應info、slaveof等少數命令（慎用，除非對資料一致性要求很高）