由于本地环境的使用，所以搭建一个本地的Redis集群，本篇讲解Redis主从复制集群的搭建，使用的平台是Windows，搭建的思路和Linux上基本一致！
（精读阅读本篇可能花费您15分钟，略读需5分钟左右）
Redis主从复制简单介绍
为了使得集群在一部分节点下线或者无法与集群的大多数节点进行通讯的情况下， 仍然可以正常运作， Redis 集群对节点使用了主从复制功能： 集群中的每个节点都有 1 个至 N 个复制品（replica）， 其中一个复制品为主节点（master）， 而其余的 N-1 个复制品为从节点（slave）。[ 摘自 Redis 集群中的主从复制 ]
那么上面是主从复制呢，简单的来说就是一个主节点master可以拥有一个甚至多个从节点的slave，而一个slave又可以拥有多个slave，如此下去，形成了强大的多级服务器集群架构。
其中主节点以写为主(可写也可以读)，从节点只能读不可写入！【读写分离场景】
其中主节点写入的数据会同步（不是准实时的）到salve上，这样如果主节点出现故障，数据丢失，则可以通过salve进行恢复。【容灾恢复场景，注：因为数据不是实时同步的，可能会存在从salve恢复数据后有数据丢失问题】
综上：下面是关于redis主从复制的一些特点：
1.一个master可以有多个slave
2.除了多个slave连到相同的master外，slave也可以连接其他slave形成图状结构
3.主从复制不会阻塞master。也就是说当一个或多个slave与master进行初次同步数据时，master可以继续处理client发来的请求。相反slave在初次同步数据时则会阻塞不能处理client的请求。
4.主从复制可以用来提高系统的可伸缩性,我们可以用多个slave 专门用于client的读请求，比如sort操作可以使用slave来处理。也可以用来做简单的数据冗余
5.可以在master禁用数据持久化，只需要注释掉master 配置文件中的所有save配置，然后只在slave上配置数据持久化。
6.可以用于读写分离和容灾恢复。
Redis主从复制的常用的几种方式
一主二仆 A(B、C) 一个Master两个Slave
薪火相传（去中心化）A - B - C ，B既是主节点（C的主节点），又是从节点（A的从节点）
反客为主（主节点down掉后，手动操作升级从节点为主节点） & 哨兵模式（主节点down掉后，自动升级从节点为主节点）
本次主要介绍一主二仆，和反客为主的操作，薪火相传不做介绍。哨兵模式后面专门写一篇进行介绍！
Redis主从复制的搭建（一主二仆）
1.下载Windows环境的Redis安装包，自己百度下载
2.下载完成进行解压
解压收的目录如下图：
3.相关配置操作
（1）复制三份解压后Redis
我自己本地修改了名称，复制后文件夹名称显示如下：
Redis-x64-3.2.100-6379
Redis-x64-3.2.100-6380
Redis-x64-3.2.100-6381
（2）修改redis.windows.conf
6379文件夹，不做修改！
6380文件夹，修改如下：
port 6380
# slaveof <masterip> <masterport>
slaveof 127.0.0.1 6379
6381文件夹，修改如下：
port 6381
slaveof 127.0.0.1 6379
我默认大家是知道redis.xx.conf的相关配置的！如果不知道，请看：
Redis学习——redis.conf 配置文件介绍
（3）加入简单的window脚本，方便快速启动！
在对应的redis文件夹下面新建
startRedisServer.bat
脚本的内容为：
@echo off
redis-server.exe redis.windows.conf
@pause
然后在redis文件夹同级的目录下在新建
start6379.cmd
@echo off
cd Redis-x64-3.2.100-6379
startRedisServer.bat
然后6380和6381和上面操作一样，操作完成后如下图：
4.启动测试
启动规则：先启动主节点，然后在启动从节点！
（1）可以使用命令启动
进入相应的文件夹目录，使用启动命令：
（2）使用脚本启动
如上面图片，分别执行start6379.cmd，
start6380.cmd，start6381.cmd。
（3）如果使用以上的方法无法同时在本机启动三台redis,那么请看这里
先启动Master。使用客户端登录，查看信息如图：
然后启动6380和6381，然后可以看到：如图
在此查看6378的主从复制信息：如图
在登录6380和6381的客户端，查看节点信息：如图
测试读写，【主节点可读可写，从节点只能读不可写】，如下图：
测试当主节点shutdown后，从节点的状态【从节点可读，从节点也不会升级为主节点】：
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:15
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381>
127.0.0.1:6381> get hello
"world"
测试当主节点重新启动后，从节点的状态【从节点依然可以连接主节点】：
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=43,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=43,lag=0
master_repl_offset:43
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:42
127.0.0.1:6379>
小插曲【反客为主】
测试当主节点shutdown后，使用slaveof no one 是的6380成为主节点,但是也只是主节点，没有任何从节点！：如图
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:155
master_link_down_since_seconds:jd
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381>
127.0.0.1:6381>
127.0.0.1:6381> slave no one
(error) ERR unknown command 'slave'
127.0.0.1:6381> slaveof no one
OK
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381> set test 11
OK
127.0.0.1:6381> get test
"11"
127.0.0.1:6381>
详细可以参考 Redis主从复制 中的内容！
Redis主从复制的原理
第一种介绍
当设置好slave服务器后,slave会建立和master的连接，然后发送sync命令。
Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步。
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。（第一次全量）
增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步。（之后增量）
但是只要是重新连接master,一次完全同步（全量复制)将被自动执行。
当设置好slave服务器后，slave会建立和master的连接，然后发送sync命令。无论是第一次同步建立的连接还是连接断开后的重新连接，master都会启动一个后台进程，将数据库快照保存到文件中，同时master主进程会开始收集新的写命令并缓存起来。后台进程完成写文件 后，master就发送文件给slave，slave将文件保存到磁盘上，然后加载到内存恢复数据库快照到slave上。接着master就会把缓存的命令转发给slave。而且后续master收到的写命令都会通过开始建立的连接发送给slave。从master到slave的同步数据的命令和从 client发送的命令使用相同的协议格式。当master和slave的连接断开时slave可以自动重新建立连接。如果master同时收到多个 slave发来的同步连接命令，只会使用启动一个进程来写数据库镜像，然后发送给所有slave。
第二种介绍：
图片内容来源网络：
第三种介绍：
Redis 主从同步有两种方式（或者所两个阶段）：全同步和部分同步。
主从刚刚连接的时候，进行全同步；全同步结束后，进行部分同步。当然，如果有需要，Slave 在任何时候都可以发起全同步。Redis 策略是，无论如何，首先会尝试进行部分同步，如不成功，要求从机进行全同步，并启动 BGSAVE……BGSAVE 结束后，传输 RDB 文件；如果成功，允许从机进行部分同步，并传输积压空间中的数据。
Redis主从复制（一主两从/一主多从）的分析
IO剧增
每次slave断开以后（无论是主动断开，还是网路故障）再连接master都要将master全部dump出来rdb，在aof，即同步的过程都要重新执行一遍；所以要记住多台slave不要一下都启动起来，否则master可能IO剧增（间隔1-2分）
复制延迟
由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
可用性不高
当有主节点发生异常情况，就会导致不能写入，导致业务出错！[解决方法是可以使用Redis-Sentinel模式，详情见系列文章第二篇]
注意：
Redis 集群不保证数据的强一致性（strong consistency）Redis 集群的一致性保证（guarantee）： 在特定条件下， Redis 集群可能会丢失已经被执行过的写命令。
————————————————
版权声明：本文为CSDN博主「阿飞云」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u010648555/article/details/79427606