redis主从复制实践讲解

如果是想要在一台机器上面开多个端口去进行一个主从复制的测试以下的命令需要进行一个修改，最好进行以下配置的修改

## 更改端口
port 6380
##  是否已守护进程的方式运行
daemonize yes
## 如果上面配置的是yes 则下面的这个也需要进行一个修改
pidfile /var/run/redis_6380.pid
## logfile也进行一个修改 如果到时候运行时提示权限不够 加上sudu即可
logfile "6380.log"
## 如果开启了rdb模式，那么rdb的文件名字也换一下
dbfilename dump6380.rdb
## 如果开启了aof，appendfilename也换一下
appendfilename "appendonly.aof"
## 配置masterip 和maser的端口
slaveof <masterip> <masterport>
## 如果主机有密码 则需要配置主机的密码
masterauth <master-password>

如果不是的话 只需要配置

slaveof <masterip> <masterport>
## 如果主机有密码 则需要配置主机的密码
masterauth <master-password>

查看当前服务的主从复制的状态

## 显示主从复制的状态
info replication

1.主从最基本的配置就是一主二从

主从复制，一般主机用来写，丛机用来读，如果只有一主一从，如果主机挂掉了之后，读写分离也会失效，所以至少要有两台机器，当主机挂掉了之后，哨兵模式会进行选举，选出一台丛机作为主机，而另一个从机就作为那台新晋主机的从机。

2.全量复制，增量复制讲解

1.全量复制
Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下：

• 1）从服务器连接主服务器，发送SYNC命令；

• 2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；

• 3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；

• 4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；

• 5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；

• 6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

通过 replicaof （即以前的 slaveof）选项可以将 Redis 实例设置为其他 Redis 服务端的副本。

完成上面几个步骤后就完成了从服务器数据初始化的所有操作，从服务器此时可以接收来自用户的读请求。

2 增量同步

Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。

增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

3 Redis主从同步策略

主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

注意点

1.数据不一致问题
1.我们知道一般主机是进行写操作，从机是进行读操作。由于网络的延迟性，所以会导致短暂的数据不一致，
2.数据过期问题
先简单介绍下Redis过期数据的删除问题，Redis删除过期数据的策略有以下两种：

惰性删除：访问缓存数据时，如果数据过期，执行删除
定时删除：Redis定时扫描一定量的key，删除过期数据
在Redis主从复制环境下，且从节点配置为只读模式，访问从节点上的过期数据，从节点不会执行物理删除，外部请求是否能够看到从节点的上的过期数据，和Redis的版本有关。在Redis3.2之前，访问从节点上的过期数据，Redis会返回缓存数据。Redis 3.2之后的版本，访问从节点上的过期数据，会返回空值，但不会物理删除。

1.如果多个Slave断线了，需要重启的时候，因为只要Slave启动，就会发送sync请求和主机全量同步，当多个同时出现的时候，可能会导致Master IO剧增宕机。
2.尽量避免全量复值
1.第一次全量复制是不可避免的，那么怎么降低开销呢？

• 方案1：小主节点，例如我们把redis分成2G一个节点，这样一来，会加速RDB的生成和同步，同时还可以降低我们fork子进程的开销（master会fork一个子进程来生成同步需要的RDB文件，而fork是要拷贝内存快的，如果主节点内存太大，fork的开销就大）。
• 方案2：既然第一次不可以避免，那我们可以选在集群低峰的时间（凌晨）进行slave的挂载。
  2.当主机宕机后，其RunID发生变化，之前进行连接的时候从机保存了主机的RunID，当其认为RunID不一致时，也会进行一个全量复制。
• 解决办法：对于这类问题，我们只有是做一些故障转移的手段，例如master发生故障宕掉，我们选举一台slave晋升为master（哨兵或集群）

2.复制积压缓冲区不足
master生成RDB同步到slave，slave加载RDB这段时间里，master的所有写命令都会保存到一个复制缓冲队列里（如果主从直接网络抖动，进行部分复制也是走这个逻辑），待slave加载完RDB后，拿offset的值到这个队列里判断，如果在这个队列中，则把这个队列从offset到末尾全部同步过来，这个队列的默认值为1M。而如果发现offset不在这个队列，就会产生全量复制。
解决办法：增大复制缓冲区的配置 rel_backlog_size 默认1M，我们可以设置大一些，从而来加大我们offset的命中率。这个值，我们可以假设，一般我们网络故障时间一般是分钟级别，那我们可以根据我们当前的QPS来算一下每分钟可以写入多少字节，再乘以我们可能发生故障的分钟就可以得到我们这个理想的值。