注意：在master-slave部署模式下，只需slave实例配置Peplication相关项，各项含义说明如下。
        1) slaveof
        slave实例需要配置该项，指向master的（ip, port）。
        2) masterauth
        如果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的用法并讨论实际使用中可能踩到的坑。