第十章 Redis主从复制

一、Redis集群概述

由于单机Redis存储能力受单机限制，以及无法实现读写操作的负载均衡和读写分离，无法保证高可用。本篇就来介绍 Redis 集群搭建方案及实现原理，实现Redis对数据的冗余备份，从而保证数据和服务的高可用。主从复制是哨兵和集群的基石，因此我们循序渐进，由浅入深一层层的将Redis高可用方案抽丝剥茧展示在大家面前。

二、Redis主从复制介绍

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器，主从是哨兵和集群模式能够实施的基础。前者称为主节点(master)，后者称为从节点(slave),数据的复制是单向的，只能由主节点到从节点。默认情况下，每台Redis服务器都是主节点；且一个主节点可以有零个或多个从节点(0+个从节点)，但一个从节点只能有一个主节点。一般主节点负责接收写请求，从节点负责接收读请求，从而实现读写分离。主从一般部署在不同机器上，复制时存在网络延时问题，使用参数repl-disable-tcp-nodelay选择是否关闭TCP_NODELAY,默认为关闭：
	
1.关闭：无论数据大小都会及时同步到从节点，占带宽，适用于主从网络好的场景。
2.开启：主节点每隔指定时间合并数据为TCP包节省带宽，默认为40毫秒同步一次，适用于网络环境复杂或带宽紧张，如跨机房。

三、主从复制作用

1.数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

2.故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

3.负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务，分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

4.读写分离：主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量。

5.高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础。

四、主从复制特点

1.使用异步复制。
2.一个主服务器可以有多个从服务器。
3.从服务器也可以有自己的从服务器。
4.复制功能不会阻塞主服务器。
5.可以通过复制功能来让主服务器免于执行持久化操作，由从服务器去执行持久化操作即可。

#详细版本
1）Redis 使用异步复制。从 Redis2.8开始，从服务器会以每秒一次的频率向主服务器报告复制流（replication stream）的处理进度。
2）一个主服务器可以有多个从服务器。
3）不仅主服务器可以有从服务器，从服务器也可以有自己的从服务器，多个从服务器之间可以构成一个图状结构。
4）复制功能不会阻塞主服务器：即使有一个或多个从服务器正在进行初次同步， 主服务器也可以继续处理命令请求。
5）复制功能也不会阻塞从服务器：只要在 redis.conf 文件中进行了相应的设置， 即使从服务器正在进行初次同步， 服务器也可以使用旧版本的数据集来处理命令查询。
6）在从服务器删除旧版本数据集并载入新版本数据集的那段时间内，连接请求会被阻塞。
7）还可以配置从服务器，让它在与主服务器之间的连接断开时，向客户端发送一个错误。
8）复制功能可以单纯地用于数据冗余（data redundancy），也可以通过让多个从服务器处理只读命令请求来提升扩展性（scalability）： 比如说，繁重的SORT命令可以交给附属节点去运行。

五、主从复制的原理

#1.redis低版本
1.从服务器向主服务器发送 SYNC 命令
2.主库接到 SYNC 命令会调用 BGSAVE 命令创建一个 RDB 文件
3.主库将新的数据记录到缓冲区
4.主库将 RDB 文件传输到从库
5.从库拿到 RDB 文件以后，会清空自己的数据 
6.从库读取 RDB 文件并导入数据
7.主库将新的数据从缓冲区传到从库进行同步

#2.redis高版本
1、主从复制过程大体可以分为3个阶段
	1)连接建立阶段（即准备阶段）
	2)数据同步阶段
	3)命令传播阶段

2、在从节点执行 slaveof 命令后，复制过程便开始按下面的流程运作
	1)保存主节点信息：配置slaveof之后会在从节点保存主节点的信息。
	2)主从建立socket连接：定时发现主节点以及尝试建立连接。
	3)发送ping命令：从节点定时发送ping给主节点，主节点返回PONG。若主节点没有返回PONG或因阻塞无法响应导致超时，则主从断开，在下次定时任务时会从新ping主节点。
	4)权限验证：若主节点开启了ACL或配置了requirepass参数，则从节点需要配置masteruser和masterauth参数才能保证主从正常连接。
	5)同步数据集：首次连接，全量同步。
	6)命令持续复制：全量同步完成后，保持增量同步。

3、 当节点被当做从节点的时候，需要注意！！
当节点被当做从节点的时候，需要将从节点设置为只读，这样做的目的是保证集群的数据一致性。

六、主从复制的机制

#SYNC与PSYNC

1）在 Redis2.8版本之前，断线之后重连的从服务器总要执行一次完整重同步（fullresynchronization）操作。
2）从 Redis2.8开始，Redis使用PSYNC命令代替SYNC命令。
3）PSYNC比起SYNC的最大改进在于PSYNC实现了部分重同步（partial resync）特性：
在主从服务器断线并且重新连接的时候，只要条件允许，PSYNC可以让主服务器只向从服务器同步断线期间缺失的数据，而不用重新向从服务器同步整个数据库。

PSYNC这个特性需要主服务器为被发送的复制流创建一个内存缓冲区（in-memory backlog）， 并且主服务器和所有从服务器之间都记录一个复制偏移量（replication offset）和一个主服务器 ID（master run id），当出现网络连接断开时，从服务器会重新连接，并且向主服务器请求继续执行原来的复制进程：
1）如果从服务器记录的主服务器ID和当前要连接的主服务器的ID相同，并且从服务器记录的偏移量所指定的数据仍然保存在主服务器的复制流缓冲区里面，那么主服务器会向从服务器发送断线时缺失的那部分数据，然后复制工作可以继续执行。
2）否则的话，从服务器就要执行完整重同步操作。

#PSYNC优点：
1）PSYNC只会将从服务器断线期间缺失的数据发送给从服务器。两个例子的情况是相同的，但SYNC 需要发送包含整个数据库的 RDB 文件，而PSYNC 只需要发送三个命令。
2）如果主从服务器所处的网络环境并不那么好的话（经常断线），那么请尽量使用 Redis 2.8 或以上版本：通过使用 PSYNC 而不是 SYNC 来处理断线重连接，可以避免因为重复创建和传输 RDB文件而浪费大量的网络资源、计算资源和内存资源。

七、Redis多实例安装

1.创建多实例目录

[root@db01 ~]# mkdir /service/redis/{6380,6381}

2.配置多实例配置文件

#第一台多实例配置
[root@db01 ~]# vim /service/redis/6379/redis.conf 
bind 172.16.1.51 127.0.0.1
port 6379
daemonize yes
pidfile /service/redis/6379/redis_6379.pid
loglevel notice
logfile /service/redis/6379/redis_6379.log
dir /service/redis/6379
dbfilename dump.rdb
save 900 1
save 300 10
save 60 10000

#第二台多实例配置
[root@db01 ~]# vim /service/redis/6380/redis.conf 
bind 172.16.1.51 127.0.0.1
port 6380
daemonize yes
pidfile /service/redis/6380/redis_6380.pid
loglevel notice
logfile /service/redis/6380/redis_6380.log
dir /service/redis/6380
dbfilename dump.rdb
save 900 1
save 300 10
save 60 10000

#第三台多实例配置
[root@db01 ~]# vim /service/redis/6381/redis.conf 
bind 172.16.1.51 127.0.0.1
port 6381
daemonize yes
pidfile /service/redis/6381/redis_6381.pid
loglevel notice
logfile /service/redis/6381/redis_6381.log
dir /service/redis/6381
dbfilename dump.rdb
save 900 1
save 300 10
save 60 10000

3.启动多实例

[root@db01 ~]# redis-server /service/redis/6379/redis.conf 
[root@db01 ~]# redis-server /service/redis/6380/redis.conf 
[root@db01 ~]# redis-server /service/redis/6381/redis.conf

4.检测启动

[root@db01 ~]# netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      14002/redis-server  
tcp        0      0 172.16.1.51:6379        0.0.0.0:*               LISTEN      14002/redis-server  
tcp        0      0 127.0.0.1:6380          0.0.0.0:*               LISTEN      15541/redis-server  
tcp        0      0 172.16.1.51:6380        0.0.0.0:*               LISTEN      15541/redis-server  
tcp        0      0 127.0.0.1:6381          0.0.0.0:*               LISTEN      15545/redis-server  
tcp        0      0 172.16.1.51:6381        0.0.0.0:*               LISTEN      15545/redis-server   

[root@db01 ~]# ps -ef | grep redis
root      14002      1  0 Aug04 ?        00:01:34 redis-server 172.16.1.51:6379
root      15541      1  0 11:50 ?        00:00:00 redis-server 172.16.1.51:6380
root      15545      1  0 11:50 ?        00:00:00 redis-server 172.16.1.51:6381

5.连接多实例

[root@db01 ~]# redis-cli -p 6379
127.0.0.1:6379> quit

[root@db01 ~]# redis-cli -p 6380
127.0.0.1:6380> quit

[root@db01 ~]# redis-cli -p 6381
127.0.0.1:6381> quit

八、多实例配置主从

配置主从可以在命令行或配置文件中配置，上面提到主节点负责写，从节点负责读，因此推荐开启从服务器的只读配置，否则的话在从节点的写操作不会同步到主节点会导致数据不一致。

1.准备环境

角色	主机	端口
主库	172.16.1.51	6379
从库	172.16.1.51	6380
从库	172.16.1.51	6381

2.连接三台机器

[root@db01 ~]# redis-cli -p 6379
[root@db01 ~]# redis-cli -p 6380
[root@db01 ~]# redis-cli -p 6381

3.查看主从状态

127.0.0.1:6379> 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:6380> 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> 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

4.配置主从

127.0.0.1:6380> SLAVEOF 172.16.1.51 6379
OK
127.0.0.1:6381> SLAVEOF 172.16.1.51 6379
OK

5.查看主从状态

#查看主库
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=172.16.1.51,port=6380,state=online,offset=263,lag=0
slave1:ip=172.16.1.51,port=6381,state=online,offset=263,lag=1
master_repl_offset:263
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:262

#查看从库
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:172.16.1.51
master_port:6379
master_link_status:up		# up:链接成功，down:链接失败
master_last_io_seconds_ago:9
master_sync_in_progress:0
slave_repl_offset:319
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

九、常见Redis主从

1.一主两仆

#1.思考点：
切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?

从机是否可以写？set可否？ 

主机shutdown后情况如何？从机是上位还是原地待命？

主机又回来了后，主机新增记录，从机还能否顺利复制？ 

其中一台从机down后情况如何？依照原有它能跟上大部队吗？

2.薪火相传

#1.思考点：
上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。

用 slaveof  <ip><port>

中途变更转向:会清除之前的数据，重新建立拷贝最新的

风险是一旦某个slave宕机，后面的slave都没法备份

主机挂了，从机还是从机，无法写数据了

3.反客为主

#1.思考点：
当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。

用 slaveof  no one  将从机变为主机。需要手动进行故障转移

十、 全量复制与部分复制

1.全量复制

redis全量复制的原理是，首先将master本身的RDB文件同步给slave，而在同步期间，master写入的命令也会记录下来（master内部有一个复制缓冲区，会记录同步时master新增的写入），当slave将RDB加载完后，会通过偏移量的对比将这期间master写入的值同步给slave。

2. 部分复制

当master和slave断开连接时，master会将期间所做的操作记录到复制缓存区当中（可以看成是一个队列，其大小默认1M）。待slave重连后，slave会向master发送psync命令并传入offset和runId，这时候，如果master发现slave传输的偏移量的值，在缓存区队列范围中，就会将从offset开始到队列结束的数据传给slave，从而达到同步，降低了使用全量复制的开销。

3. 全量复制的开销

1.bgsave的开销，每次bgsave需要fork子进程，对内存和CPU的开销很大
2.RDB文件网络传输的时间（网络带宽）
3.从节点清空数据的时间
4.从节点加载RDB的时间
5.可能的AOF重写时间（如果我们的从节点开启了AOF，则加载完RDB后会对AOF进行一个重写，保证AOF是最新的）

4. 主从复制存在的问题

1.手动故障转移
2.写能力和存储能力受限