每个 Redis 服务器实例都可以配置多个 slave 节点，slave 服务器也可以拥有次级 slave 节点, 可以组织成复杂的树状结构（虽说生产环境下极少有人这么做）。

为了尝试配置主从复制，我们至少需要两个 redis 服务器实例。最简单的方法是在 redis 官网下载 redis-server 二进制可执行文件，分别放在 master 和 slave 目录中。

在每个目录中分别创建 redis.conf 配置文件。master 实例的配置文件采用默认即可， 在 slave 实例中进行主从复制配置:

使用redis-server redis.conf 命令分别启动 redis-server 实例。 使用redis-cli -p 6380命令连接从服务器:

SLAVEOF host port 可以动态改变从服务器所属的 master 节点。SLAVEOF NO ONE 关闭复制功能，并从 slave 服务器转变回 master 服务器，原来同步所得的数据集不会被丢弃。在当主服务器故障时，可以使用SLAVEOF NO ONE命令将 slave 服务器提升为 master。

在 Redis 2.8 之前的版本里，Redis 仅支持全量复制不支持增量复制，这极大的影响了主从同步的性能。

Redis 2.8 之前的版本主从复制流程如下:

Redis 2.8 开始使用 PSYNC 命令代替 SYNC 命令， PSYNC 具有全量复制和增量复制功能。

master 和 slave 节点均拥有一个 runid 作为自己的唯一标识。

master 和 slave 会各自维护一个复制偏移量，在增量复制时标识同步进度。

master 会维护一个 FIFO 的复制缓冲区(replication backlog)，默认大小 1mb。

接下来我们可以开始说明 PSYNC 命令执行的流程:

简单的主从复制架构在 master 故障后会不可用，Redis 官方提供了哨兵(sentinel)机制自动实现主备切换保证高可用。

哨兵机制通过一组哨兵节点监控主从节点的运行状态，并在主节点故障后选举新的主节点。

哨兵节点定时执行3个任务:

若哨兵节点发现 master 节点心跳响应超时，则认为 master 主观下线。此时，master 可能真的已经崩溃也可能仅仅是此哨兵节点与 master 之间出现网络故障。

认为 master 主观下线的哨兵会向其它哨兵发送sentinel is-master-down-by addr询问 master 是否下线。若半数以上的哨兵认为 master 已经下线则认为 master 客观下线。

哨兵节点会选举自己第一个收到的 is-master-down-by 命令的发送者为哨兵领导者。若某一个节点得到过半投票则会成为哨兵领导者，若没有节点得到半数以上票则会进入下一轮投票。此选举流程与 Paxos 算法类似。

哨兵领导者负责选择一个slave节点提升为新 master 节点, 选择逻辑为:

新的 master 节点选出后会执行提升流程: