简述
在关系型数据库中，主从复制很常见，多是Master负责写数据，Slave负责读数据，从而提供数据库性能。Redis同样也采用了主从复制的方式，如果不考虑Redis Cluster（集群）或者Sentinel（哨兵模式）提供的高可用特性，基本的主从复制（leader-follower）很容易使用和配置。
机制
主要机制：
- 当Master-Slave连接正常时，客户端写操作、key值失效等任何Master上的数据集变更动作都会同步到Slave上。
- 当Master-Slave连接异常时，如果是网络或者请求超时等问题，Slave会自动重新连接，并尝试同步缺失数据。
- 如果部分缺失数据同步失败时，Slave会请求完全重新同步，Master会创建一个包含全部数据的快照并发送给Slave，然后继续发送新的数据集更改命令。
Redis默认使用异步复制，具有更低的延迟和更高的性能，但是Master不会等待确认Slave是否同步成功，因此，如果需要，可选用同步复制。
随着负载不断上升，Master可能无法很快地更新所有Slave，Slave重新连接和重新同步将导致Master系统超载。为了解决这个问题，可以创建一个中间层来分担Master的复制工作。中间层的服务器是最上层服务器的Slave，又是最下层服务器的Master，称之为主从链。
过程
每个Redis Master会有一个Replication ID：一个大的伪随机字符串，用来表示特定的数据集。
所谓“随机码”，就是无论这个码有多长都不会出现循环的现象，而“伪随机码”在码长达到一定程度时会从其第一位开始循环，由于出现的循环长度相当大，例如CDMA采用42位的伪随机码，重复的可能性为4.4万亿分之一，所以可以当成随机码使用。
在Replication ID的基础上，还有一个offset（偏移量），两者一起标识了Master上数据集的一个确切版本。也就是说如果Master和Slave的Replication ID，offset完全一致，便可以认为两者的数据完全一致。
Replication ID, offset主从复制的大致流程如下：
- Slave连接Master，首次连接会进行完全同步。Master创建一个RDB文件（快照方式），发送给Slave，并在发送期间使用缓冲区记录执行的写命令。RDB发送完毕之后，开始向Slave发送存储在缓冲区中的写命令；
- Slave丢弃所有旧数据，载入Master发来的RDB文件，之后开始接受Master发来的写命令。Master每执行一次写命令，将向Slave发送相同的写命令；
- 如果Slave中断后重新启动，向Master请求数据，会先发送自己的Replication ID及offset与Master进行对比，如果Replication ID一致，即可在offset的基础上进行部分缺失数据同步。
配置
Redis replication很简单，只需要在Slave的redis.conf文件中添加如下配置：
slaveof <masterip> <masterport>或者启动Slave时添加slaveof参数
./redis-server --slaveof 192.168.1.1 6379如果Master使用默认设置启动，Slave连接时可能会出现以下问题（Master和Slave不在同一主机，如Master：192.168.1.1，Slave：192.168.1.2）：
Error condition on socket for SYNC: Connection reset by peer打开Master的redis.conf文件，修改bind参数为”0.0.0.0”即可（默认为”127.0.0.1”）