4、redis.conf中replication配置項說明

注意：在master-slave部署模式下，只需slave實例配置Peplication相關項，各項含義說明如下。
        1) slaveof <masterip> <masterport>
        slave實例需要配置該項，指向master的（ip, port）。
        2) masterauth <master-password>
        如果master實例啟用了密碼保護，則該配置項需填master的啟動密碼；若master未啟用密碼，該配置項需要注釋掉
        3) slave-serve-stale-data
        指定slave與master連接中斷時的動作。默認為yes，表明slave會繼續應答來自client的請求，但這些數據可能已經過期（因為連接中斷導致無法從master同步）。若配置為no，則slave除正常應答"INFO"和"SLAVEOF"命令外，其余來自客戶端的請求命令均會得到"SYNC with master in progress"的應答，直到該slave與master的連接重建成功或該slave被提升為master。
        4) slave-read-only
        指定slave是否只讀，默認為yes。若配置為no，這表示slave是可寫的，但寫的內容在主從同步完成后會被刪掉。
        5) repl-ping-slave-period
        Redis部署為Replication模式后，slave會以預定周期（默認10s）發PING包給master，該配置可以更改這個默認周期。
        6) repl-timeout
        有2種情況的超時均由該配置指定：1) Bulk transfer I/O timeout; 2) master data or ping response timeout。
        需要特別注意的是：若修改默認值，則用戶輸入的值必須大于repl-ping-slave-period的配置值，否則在主從鏈路延時較高時，會頻繁timeout。
        7) repl-disable-tcp-nodelay
        指定向slave同步數據時，是否禁用socket的NO_DELAY選項。若配置為yes，則禁用NO_DELAY，則TCP協議棧會合并小包統一發送，這樣可以減少主從節點間的包數量并節省帶寬，但會增加數據同步到slave的時間。若配置為no，表明啟用NO_DELAY，則TCP協議棧不會延遲小包的發送時機，這樣數據同步的延時會減少，但需要更大的帶寬。通常情況下，應該配置為no以降低同步延時，但在主從節點間網絡負載已經很高的情況下，可以配置為yes。
        備注：socket的NO_DELAY選項涉及到TCP協議棧的擁塞控制算法—Nagle's Algorithm。
        8) slave-priority
        指定slave的優先級。在不只1個slave存在的部署環境下，當master宕機時，Redis Sentinel會將priority值最小的slave提升為master。需要注意的是，若該配置項為0，則對應的slave永遠不會被Redis Sentinel自動提升為master。

        關于Replication，需要明確的幾點（以下內容主要總結自這里）：
        a. Redis的Replication跟cluster的概念不同。假如S是M的slave，則M不能把自己設置成為S的slave。若S掛掉，則M正常工作；相反，若M掛掉，則S可能會停止正常工作，這里用"可能"，是因為S的具體行為由其配置文件中的slave-serve-stale-data來決定。
        b 假設共2個節點，M為master，S為slave，若M掛掉，則合理的處理方式是將S提升為master（通過SLAVE NO ONE命令）。當原來的master M恢復后，將M設置為S的slave。當然，實際處理方式并不限于這里的建議。
        c. 假設共3個節點，M為master，S1和S2均為slave，若M掛掉，合理的處理方式是將其中1個slave提升為master，同時，需將另一個slave的master重新設置為新的master實例。

        現在，新問題來了：如何得知M已經掛掉了？
        這就涉及到Redis的監控，所幸的是，我們可以借助Redis官方發布的工具Redis Sentinel完成監控任務。

          下篇筆記會說明sentinel的用法并討論實際使用中可能踩到的坑。