楔子：某个时间，由于不清不楚的某些原因，导致了一次严重的线上事故。后来，开发不清不楚的配合把项目升级到了 Redis 高可用集群的哨兵模式（Redis-Sentinel），再后来，我们逐渐的又不清不楚的淡忘了这件事。节点化的工作很容易导致一定程度上只知其然而不知其所以然，这是项目开发中的一个众相。回想起来，我还是想记点什么。

该篇可以为以下应用场景提供解决方案：

读写分离场景：其中主节点以写为主（可读可写），从节点只能读不可写
Redis 容灾：如果主节点出现故障，数据丢失，则可以通过 salve 进行恢复（其中主节点写入的数据会同步到从节点 salve 上，但不准时，因为数据不是实时同步，所以主节点可能会存在从 salve 恢复数据后有数据丢失问题）

1. Redis 枝繁叶茂

为了使得集群在一部分节点下线或者无法与集群的大多数节点进行通讯的情况下，仍然可以正常运作， Redis 集群对节点使用了主从复制功能：集群中的每个节点都有 1 个至 N 个复制品（replica），其中一个复制品为主节点（master），而其余的 N-1 个复制品为从节点（slave）。[ 摘自 Redis 集群中的主从复制 ]

简单的来说，就是一个主节点（master）可以拥有一个甚至多个从节点 slave，而一个 slave 也可以拥有多个 slave，就像一棵枝繁叶茂的大树般，树叉生树叉，最终形成织罗密布的强大的多级服务器集群架构。

Redis 主从复制同步的几种方法：

一主二仆：一个 Master 两个 Slave
薪火相传：A - B - C ，B既是C的 Master，又是A的 Slave 从节点，即上一个 Slave 是下一个 Slave 的 Master
反客为主：主节点挂掉后，手动升级从节点为主节点
哨兵模式：主节点挂掉后，自动升级从节点为主节点（反客为主）

这篇主要介绍 一主二仆 和 手动反客为主。哨兵模式后面另开一篇进行介绍。Redis 安装操作如有疑问请参考 Redis进击（一）从0到1，Redis的安装与使用

2. Redis 一主二仆

2.1. 配置操作

2.1.1 准备三份 Redis

解压已经下载好的 Redis 资源，然后再复制两份，都放在同一目录下。我本地修改了复制后的文件夹名称，以端口号区分。如下：

2.1.2 修改 redis.windows.conf

不需要修改 redis.windows.conf 配置文件的 6379：

6379 的文件夹，这里不需要修改 redis.windows.conf 配置文件

需要修改 redis.windows.conf 配置文件的 6380、6381：

该配置文件的第约40行，需要修改端口号
该配置文件的第约200行，需要增加子节点（后面用作 master 的从节点）

6380 的文件夹，修改 redis.windows.conf 如下：

# Accept connections on the specified port, default is 6379.
# If port 0 is specified Redis will not listen on a TCP socket.
port 6380

......

# slaveof <masterip> <masterport>
slaveof 127.0.0.1 6379

6381 的文件夹，修改 redis.windows.conf 如下：

# Accept connections on the specified port, default is 6379.
# If port 0 is specified Redis will not listen on a TCP socket.
port 6381

......

# slaveof <masterip> <masterport>
slaveof 127.0.0.1 6379

port 端口的配置分别是 6379、6380、6381，都分别与目录上的端口相对应。故障转移统一配置成指向 6379：slaveof 127.0.0.1 6379