Redis的主从复制&哨兵模式
一、概述
二、集群搭建（单机伪集群）——一主二从
（一）创建和修改启动配置文件
1. 复制多份配置文件
[root@izwz93jpghqh4vdu29xzxkz redisConfig]# cp redis.conf redis79.conf
[root@izwz93jpghqh4vdu29xzxkz redisConfig]# cp redis.conf redis80.conf
[root@izwz93jpghqh4vdu29xzxkz redisConfig]# cp redis.conf redis81.conf
[root@izwz93jpghqh4vdu29xzxkz redisConfig]# ls -l
total 256
-rw-r--r-- 1 root root 61798 Aug 8 20:34 redis79.conf
-rw-r--r-- 1 root root 61798 Aug 8 20:34 redis80.conf
-rw-r--r-- 1 root root 61798 Aug 8 20:34 redis81.conf
-rw-r--r-- 1 root root 61798 Aug 1 23:25 redis.conf
2. 修改配置文件参数
pidfile /var/run/redis_6380.pid -- 修改pid文件生成路径，避免冲突
logfile "redis80.log" -- 设置日志的文件名
dbfilename dump80.rdb -- 设置rdb文件文件名
port 6380 -- 配置端口号，防止冲突
bind 127.0.0.1 -- 如果是多台服务器的话，需要配置ip，这里的话因为是单机多服务，所以不用配
依次修改3份配置文件
vim redis79.conf
vim redis80.conf
vim redis81.conf
（二）启动3个Redis服务
redis-server redisConfig/redis79.conf
redis-server redisConfig/redis80.conf
redis-server redisConfig/redis81.conf
ps -ef | grep redis -- 查看redis是否正常启动
root 12251 1 0 20:52 ? 00:00:00 redis-server 127.0.0.1:6379
root 12260 1 0 20:52 ? 00:00:00 redis-server 127.0.0.1:6380
root 12267 1 0 20:52 ? 00:00:00 redis-server 127.0.0.1:6381
root 12274 11879 0 20:52 pts/0 00:00:00 grep --color=auto redis
使用info replication命令查看某个redis服务的情况
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
master_replid:2e34fdd82a027914f4555458a1ba3bef78104b99
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
我们可以看到，每个redis服务启动的时候，默认自己就是一台主机（master）
（三）配置主从（通过命令行）
由于redis在启动的时候已经默认自己为一台主机，所以我们配置主从的时候，只需要手动配置从节点即可。
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
同理，配置6381的主节点为6379端口的redis服务
使用info replication查看是否绑定成功
127.0.0.1:6381> info replication
# Replication
role:slave -- 可以看到，此处的role角色已经变为slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:6
master_sync_in_progress:0
slave_repl_offset:154
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:e959acf39a0370252e92e1df83509d5d46e3035c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:154
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:141
repl_backlog_histlen:14
主节点info信息如下：
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2 -- 可以看到，主节点下有两个从节点
slave0:ip=127.0.0.1,port=6380,state=online,offset=378,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=378,lag=1
master_replid:e959acf39a0370252e92e1df83509d5d46e3035c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:378
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:378
（四）验证主从服务器的读写是否同步
主服务器
127.0.0.1:6379> set name xiaoming
OK
从服务器
127.0.0.1:6381> get name --从服务器可以拿到master存储的value值
"xiaoming"
127.0.0.1:6381> set age 18 -- slave服务不能执行写操作
(error) READONLY You can't write against a read only replica.
注意，在真实的开发过程中，基本都是通过配置文件的方式，写入集群主从节点的相关配置，在服务启动的过程中根据配置文件内容进行配置。我们通过命令行的方式只是暂时配置，服务一关就没了
需要配置的内容为：
replicaof <masterip> <masterport> -- 配置主服务器的ip和端口
masterauth <master-password> -- 如果主服务器有密码，需要配置一下密码
（五）主从机的宕机问题
问题1：主机挂了，（未配置哨兵模式的话）从节点会怎么样呢？
127.0.0.1:6379> shutdown --关闭主机
not connected>
从机仍然保留slave的角色
127.0.0.1:6380> 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:2594
master_link_down_since_seconds:199
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:e959acf39a0370252e92e1df83509d5d46e3035c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:2594
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:2594
同时，重启主机后，从机仍然可以获取到主机新存入的值
问题2：如果是从机挂了，重启后还是slave角色吗
如果没有预先在配置文件配置且启动，只是通过命令行方式启动的话，从机将恢复原样，即变为主机。
-- 主机现在变为只有一个slave
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=294,lag=0
master_replid:2e915314bd2cf2bf8525989adc52aac97728b272
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:294
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:294
问题3：当恢复master的服务重新绑定为slave时，可以获取到主机原有的值吗
答： 可以
复制原理
Slave 启动成功连接到master后会发送一个sync同步命令
Master街道命令，启动后台的存盘进程，同时手机所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。
全量复制：slave服务在接收到数据库文件数据后，将其存盘并加载带内存中
增量复制：master继续将新的所有搜集到的修改命令依次传给slave，完成同步
只要是重新连接master，一次完全同步（全量复制）将被自动执行
三、哨兵模式
（一）前言
通过前面的实验我们可以知道，当主节点挂掉后，从节点并不能自动的转为主节点，redis集群不能再执行写操作（因为从节点只可以读），我们只能手动切换从服务器为master
127.0.0.1:6380> SLAVEOF no one --使用该命令解绑原主机
OK
127.0.0.1:6381> SLAVEOF 127.0.0.1 6380 --给原从服务器配置新的主节点
OK
（二）哨兵模式概述
其实简单理解的话，哨兵模式就是用于处理主节点宕机后从节点自动升级为主节点的解决方案。当主节点挂掉后，我们不需要再手工的再去配置新的主节点（当集群中节点数量比较大的情况下，手动配置效率不高，而且我们也不知道什么时候主机会挂掉）
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行，其原理是哨兵通过发送命令，等待redis服务器响应，从而监控运行多个redis实例
这里的哨兵有两个作用
通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
用文字描述一下故障切换（failover）的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。
[图片上传中...(image.png-f08408-1596898798891-0)]
（三）哨兵模式配置
1. 新增（修改）配置文件sentinel.conf
# sentinel monitor 主机名（可以随意取） ip号 port号 1 -- 1表示，当主机挂掉后，由slave投票选举出一个从机来当主机
sentinel monitor master 127.0.0.1 6379 1
2. 启动哨兵进程
redis-sentinel redisConfig/sentinel.conf
-- 启动后，状态如下：
14189:X 08 Aug 2020 22:36:44.813 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
14189:X 08 Aug 2020 22:36:44.813 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=14189, just started
14189:X 08 Aug 2020 22:36:44.813 # Configuration loaded
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 5.0.5 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in sentinel mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 26379
| `-._ `._ / _.-' | PID: 14189
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
14189:X 08 Aug 2020 22:36:44.814 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
14189:X 08 Aug 2020 22:36:44.817 # Sentinel ID is 6cacca8ab85d59be701c1992e62bfc004529a28e
14189:X 08 Aug 2020 22:36:44.817 # +monitor master master 127.0.0.1 6380 quorum 1
-- 下面的信息显示了一共有几个从节点
14189:X 08 Aug 2020 22:36:44.817 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ master 127.0.0.1 6380
14189:X 08 Aug 2020 22:36:44.820 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ master 127.0.0.1 6380
关闭主节点后，哨兵进程显示选举过程如下
14189:X 08 Aug 2020 22:38:31.021 # +sdown master master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:31.021 # +odown master master 127.0.0.1 6380 #quorum 1/1
14189:X 08 Aug 2020 22:38:31.021 # +new-epoch 1
14189:X 08 Aug 2020 22:38:31.021 # +try-failover master master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:31.023 # +vote-for-leader 6cacca8ab85d59be701c1992e62bfc004529a28e 1
14189:X 08 Aug 2020 22:38:31.023 # +elected-leader master master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:31.023 # +failover-state-select-slave master master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:31.079 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:31.079 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:31.138 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:32.084 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:32.084 # +failover-state-reconf-slaves master master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:32.140 * +slave-reconf-sent slave 127.0.0.1:6379 127.0.0.1 6379 @ master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:33.088 * +slave-reconf-inprog slave 127.0.0.1:6379 127.0.0.1 6379 @ master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:33.088 * +slave-reconf-done slave 127.0.0.1:6379 127.0.0.1 6379 @ master 127.0.0.1 6380
14189:X 08 Aug 2020 22:38:33.170 # +failover-end master master 127.0.0.1 6380
-- 选举出了6381端口的服务作为最新的主节点
14189:X 08 Aug 2020 22:38:33.170 # +switch-master master 127.0.0.1 6380 127.0.0.1 6381
14189:X 08 Aug 2020 22:38:33.170 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ master 127.0.0.1 6381
14189:X 08 Aug 2020 22:38:33.170 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ master 127.0.0.1 6381
14189:X 08 Aug 2020 22:39:03.184 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ master 127.0.0.1 6381
问题：如果原有的主节点恢复后，会重新回到集群中作为主节点吗
答：不会，原有的主节点已经被替换为其他节点了，当79服务重启后，将不会有其他从节点
（四）哨兵模式优缺点小结
优点：
- 哨兵集群给予主从复制模式，所有主从配置优点，其都具备（就是高可用）
- 哨兵模式实现了自动化的主从复制，更加方便和自动化
缺点： - redis的在线扩容比较麻烦，集群容量一旦达到上限，在线扩容就十分麻烦
- 需要自己配置好哨兵的相关配置（如果有哨兵集群的话，需要配置的就更多了）
关于多哨兵模式详情，可以参考：https://www.jianshu.com/p/06ab9daf921d
