Redis的replication机制允许slave从master那里通过网络传输拷贝到完整的数据备份。具有以下特点：
异步复制
可以配置一主多从
可以配置从服务器可以级联从服务器，既 M->S->S
M replication时是非阻塞的（在replication期间，M依然能够处理客户端的请求）
S replication期间也是非阻塞的（也可以接受来自客户端的请求，但是它用的是之前的旧数据）可以通过配置来决定S是否在进行replication时用旧数据响应客户端的请求，如果配置为否，那么slave将会返回一个错误消息给客户端。不过当新的数据接收完全后，必须将新数据与旧数据替换，即删除旧数据，在替换数据的这个时间窗口内，slave将会拒绝客户端的请求和连接
能够通过replication来避免master每次持久化时都将整个数据集持久化到硬盘中。只需把master配置为不进行save操作，然后连接上一个slave，这个slave则被配置为不时地进行save操作的。不过需要注意的是，在这个用例中，必须确保master不会自动启动
二、Master持久化功能关闭时Replication的安全性
当有需要使用到replication机制时，一般都会强烈建议把master的持久化开关打开。即使为了避免持久化带来的延迟影响，不把持久化开关打开，那么也应该把master配置为不会自动启动的
为了更好地理解当一个不进行持久化的master如果允许自动启动所带来的危险性。可以看看下面这种失败情形：
假设我们有一个redis节点A，设置为master，并且关闭持久化功能，另外两个节点B和C是它的slave，并从A复制数据。
如果A节点崩溃了导致所有的数据都丢失了，它会有重启系统来重启进程。但是由于持久化功能被关闭了，所以即使它重启了，它的数据集是空的。而B和C依然会通过replication机制从A复制数据，所以B和C会从A那里复制到一份空的数据集，并用这份空的数据集将自己本身的非空的数据集替换掉。于是就相当于丢失了所有的数据
即使使用一些HA工具，比如说sentinel来监控master-slaves集群，也会发生上述的情形，因为master可能崩溃后迅速恢复。速度太快而导致sentinel无法察觉到一个failure的发生
数据的安全很重要、持久化开关被关闭并且有replication发生的时候，应该禁止实例的自启动
三、M/S replication的工作原理
当master和slave启动时，不管这个slave是否是第一次连接上Master，它都会发送一个SYNC命令给master请求复制数据
master收到SYNC命令后，会在后台进行数据持久化，持久化期间，master会继续接收客户端的请求，它会把这些可能修改数据集的请求缓存在内存中。当持久化进行完毕以后，master会把这份数据集发送给slave，slave会把接收到的数据进行持久化，然后再加载到内存中。然后，master再将之前缓存在内存中的命令发送给slave
当master与slave之间的连接由于某些原因而断开时，slave能够自动重连Master，如果master收到了多个slave并发连接请求，它只会进行一次持久化，然后再把这一份持久化的数据发送给多个并发连接的slave
当master和slave断开重连后，一般都会对整份数据进行复制。但从redis2.8版本开始，支持部分复制
数据部分复制
从2.8版本开始，slave与master能够在网络连接断开重连后只进行部分数据复制。
master会在其内存中创建一个复制流的等待队列，master和它所有的slave都维护了复制的数据下标和master的进程id，因此，当网络连接断开后，slave会请求master继续进行未完成的复制，从所记录的数据下标开始。如果进程id变化了，或者数据下标不可用，那么将会进行一次全部数据的复制。支持部分数据复制的命令是PSYNC
不需硬盘参与的Replication
一般情况下，一次复制需要将内存的数据写到硬盘中，再将数据从硬盘读进内存，再发送给slave。对于速度比较慢的硬盘，这个操作会给master带来性能上的损失。Redis2.8版本开始，实验性地加上了无硬盘复制的功能。这个功能能将数据从内存中直接发送到slave，而不用经过硬盘的存储。不过这个功能目前处于实验阶段，还未正式发布
四、配置M/S
slaveof <masterip> <masterport>
slave实例需要配置该项，指向master的（ip, port）
masterauth <master-password>
如果master实例启用了密码保护，则该配置项需填master的启动密码；若master未启用密码，该配置项需要注释掉
slave-serve-stale-data
指定slave与master连接中断时的动作。默认为yes，表明slave会继续应答来自client的请求，但这些数据可能已经过期（因为连接中断导致无法从master同步）
若配置为no，则slave除正常应答"INFO"和"SLAVEOF"命令外，其余来自客户端的请求命令均会得到"SYNC with master in progress"的应答，
直到该slave与master的连接重建成功或该slave被提升为master。
slave-read-only
指定slave是否只读，默认为yes。若配置为no，这表示slave是可写的，但写的内容在主从同步完成后会被删掉
repl-ping-slave-period
Redis部署为Replication模式后，slave会以预定周期（默认10s）发PING包给master，该配置可以更改这个默认周期
repl-timeout
有2种情况的超时均由该配置指定：1) Bulk transfer I/O timeout; 2) master data or ping response timeout
需要特别注意的是：若修改默认值，则用户输入的值必须大于repl-ping-slave-period的配置值，否则在主从链路延时较高时，会频繁timeout
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
slave-priority
指定slave的优先级。在不只1个slave存在的部署环境下，当master宕机时，Redis Sentinel会将priority值最小的slave提升为master
需要注意的是，若该配置项为0，则对应的slave永远不会被Redis Sentinel自动提升为master
replication相关的配置比较简单，只需要把下面一行加到slave的配置文件中
slaveof 192.168.1.1 6379