Redis 主从复制

概念

主从复制：

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点 (master/leader)，后者称为从节点 (slave/follower)；数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave以读为主。

默认情况下：

每台Redis服务器都是主节点；
且一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。

主从复制的作用主要包括：

数据冗余：
- 主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
故障恢复：
- 当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
负载均衡：
- 在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
高可用（集群）基础：
- 除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

复制类型：

全量复制：将所有的数据全部复制分发到slave上去，然后将其存盘并载入内存中。每一次绑定主节点的时候都会自动进行一次全量复制。
增量复制：每一次主节点增删改值的时候，会将该次的值的改动情况分发到slave上，只有本次值改动情况，每一次主节点进行操作的时候都会自动进行一次增量复制

手动配置集群

info replication
- 查看当前主机主从配置信息
Slaveof <host> <port>
- 通过该命令可以让本机成为 <host：port> 的从机 Slave
- 也就是跟随指定的主机当小弟
Slaveof no one
- 该命令声明本机自己是master而不跟随任何主机

哨兵模式（重点）

首先，手动配置会非常的麻烦，且如果主节点宕机，那么无法写入会造成较大的影响。且如果就算及时发现，手动切换也会造成一段时间内的集群不可用。

方法：

当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预、费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel（哨兵）架构来解决这个问题。

哨兵模式的自动化功能：

哨兵能够后台监控主机是否故障，如果故障了，根据投票数自动将从库转为主库。

哨兵模式原理：

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令。哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

主观下线

假设主服务器宕机，哨兵1在指定时间内(可配置)没有收到主服务器的有效回复，那么这个哨兵会把服务器标记为下线，叫做主观下线SDOWN。

注意此时只有一个哨兵标记为下线，实际上哨兵没有收到回复原因可能有很多，可能是服务器确实挂了，也有可能是服务器并没有挂，由于网络原因没有收到回复，总之，一个哨兵没有收到回复并不能证明主服务器宕机。

客观下线

哨兵2也发送了Ping命令，同样也没有收到回复，哨兵2也会将主服务器标记为SDOWN。这个时候，3个哨兵中有2个哨兵上报了SDOWN，哨兵们在彼此交流之后，认为已经有足够数量的实例证明该服务已经不可用，因此，哨兵实例会将该服务器标记为客观下线ODOWN。

这里的足够数量是可配置的，一般是哨兵个数的一半加1，比如3个哨兵则就设置为2

投票选举，故障转移

当哨兵实例将服务标记为客观下线时，会进行一次选举。在剩下的从服务器实例中，选出一个作为主节点，并同时修改其余从服务器的配置文件，将新的主节点作为数据同步的来源，然后重新启动服务，完成切换。

至此，一个完整的哨兵自动进行故障转移的过程就完成了。

配置哨兵模式

首先一个哨兵需要一个配置文件，多个哨兵就需要准备多个配置文件来对应哨兵。

sentinel.conf

# sentinel monitor <被监控的名称> <master_host> <master_port> <number>
sentinel monitor myredis <master_host> <master_port> 1

哨兵整体配置

#修改port
port 26381 
 
#开启守护线程 后台运行
daemonize yes
 
#进程文件
pidfile /var/run/redis-sentinel-26381.pid

#哨兵日志文件
logfile "/var/log/sentinel.log"
 
#sentinel monitor <master-group-name> <ip> <port> <quorum>
#master-group-name是集群名称，可以自定义，
#ip：master主机ip地址
#quorum哨兵数量，是需要同意主节点不可用的Sentinel的数量，一般是哨兵数量减1
#比如2表示，当至少有2个哨兵发现master的redis挂了，
#               那么就将此master标记为宕机节点。
#               这个时候就会进行故障的转移，将其中的一个从节点变为master
 
sentinel monitor mymaster 127.0.0.1 6380 2

# master中redis的密码
sentinel auth-pass mymaster 123456

# 哨兵从master节点宕机后，等待多少时间（毫秒），认定master不可用。
# 默认30s，这里为了测试，改成10s
sentinel down-after-milliseconds mymaster 10000

# 当替换主节点后，剩余从节点重新和新master做同步的并行数量，默认为 1
sentinel parallel-syncs mymaster 1

# 主备切换的时间，若在3分钟内没有切换成功，换另一个从节点切换
sentinel failover-timeout mymaster 180000


# 客户端重新配置主节点参数脚本
# 说明：
- 当一个 `master` 由于 `failover` 而发生改变时，这个脚本将会被调用，通知相关的客户端关于 `master` 地址已经发生改变的信息。
- 以下参数将会在调用脚本时传给脚本：
# 参数说明：
1. `<state>` 总是 `"failover"`。
2. `<role>` 是 `"leader"` 或 `"observer"` 中的一个。
3. 参数 `from-ip, from-port, to-ip, to-port` 是用来表示旧的 `master` 和新的 `master`（即旧的 `slave`）通信的。
# 注意：这个脚本应该是通用的，能被多次调用，不是针对性的。

# 配置示例：
sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

测试

当配置了哨兵模式后，master下线一段时间内，哨兵将会选举另一台slave作为master

==原master==回来后，哨兵检测到下线的==原master==重新上线，会将==原master==作为slave跟随当前master