3、redis复制以及哨兵
redis复制
概念
复制时将一台服务器的数据复制到其他一台或者多台服务器上的过程，复制用于解决单节点故障问题，或者满足负载均衡的需求
M：主服务器 S：从服务器
一旦建立复制立马出现上述两种角色，每个从节点只能有一个主节点，而一个主节点不一定只有一个从节点
主从配置方式
1、在运行服务器端变为从服务器
redis-server –slaveof 主服务器ip 主服务器redis端口号
断开服务
配置文件中修改为 bind 0.0.0.0 #允许所有地址访问
[root@localhost redis]# redis-server /usr/src/redis-5.0.5/redis.conf #启动即可从服务1.8
断开服务
配置文件中修改 bind 0.0.0.0 #允许所有地址访问
[root@localhost redis]# redis-server /usr/src/redis-5.0.5/redis.conf --slaveof 192.168.1.7 6379
日志中出现以下四条即成功，而且注意前面pid后的角色变为S
8495:S 19 Dec 2019 13:54:10.831 * MASTER <-> REPLICA sync: receiving 185 bytes from master
8495:S 19 Dec 2019 13:54:10.831 * MASTER <-> REPLICA sync: Flushing old data
8495:S 19 Dec 2019 13:54:10.831 * MASTER <-> REPLICA sync: Loading DB in memory
8495:S 19 Dec 2019 13:54:10.831 * MASTER <-> REPLICA sync: Finished with success然后主服务器也会出现两条日志
67754:M 19 Dec 2019 13:54:10.815 * Replica 192.168.1.8:6379 asks for synchronization
67754:M 19 Dec 2019 13:54:10.831 * Synchronization with replica 192.168.1.8:6379 succeeded在主服务器中可以查看主从信息
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.1.8,port=6379,state=online,offset=154,lag=0
master_replid:2ecc555450f56787a7a773b265f77270c46d6042
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:154
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1542、在redis命令行中输入命令
slaveof 主服务器ip 主服务器的redis端口号
正常登录redis
输入以下变为从服务器
127.0.0.1:6379> slaveof 192.168.1.7 6379
日志同样会更新为第一种方法那种3、在配置文件中直接添加
在找到slaveof时，在其下方添加
slaveof 主服务器ip 主服务器端口号
从服务器直接登录即可
5.0版本是replicaof+ip+端口号
在主从复制中，数据从主服务器流向从服务器，数据为单向形式传送
断开主从复制
slaveof no one 在从服务器中输入，用于断开和主服务器的连接
断开的流程
1、断开和主节点的复制关系
2、从节点晋升为主节点
3、如果现在从服务器进行切换主服务器时，所有数据将会被删除（如果当前从服务器拥有较为重要的内容时，先进行一次备份，持久化，保存数据之后再复制）
4、对新的主节点继续进行复制
redis配置密码
config set requirepass 123.com 关掉服务端后消失config rewrite 写入配置文件，表示永久生效
配置文件中任意地方写入requirepass "123.com" #config rewrite也会自动写入配置文件的末尾
使用密码的方式：
登录时使用
[root@localhost ~]# redis-cli -a 123.com登录后使用
127.0.0.1:6379> auth 123.com如果主服务器带有密码，将主服务器的密码添加到从服务器的配置文件的如下位置masterauth <master-password>
复制的拓扑结构
dump.rdb快照形式的持久化文件将会通过复制的方式发送给从服务器，从服务器得到该数据后在自己的服务器中执行得到所有的数据
1、一主一从
在主服务器中关闭aof持久化，在从服务器开启，也可以将数据进行备份
2、一主多从
优点：主服务器可以将数据放在多个其他服务器中进行保存，也可实现负载均衡等要求
缺点：消耗大量带宽（从不宜太多）
3、树状结构
优点：减小带宽消耗，主服务器可以将数据放在多个其他服务器中进行保存
复制的流程
1、从节点保存主节点的信息 slaveof操作，信息可以从info replication看到
2、从节点通过自身的定时任务每秒进行执行，当发现新的主节点时，将会和新的主节点尝试连接，从节点会建立socket文件用于接收主节点发送的复制命令，当从节点无法与主节点进行连接时，定时任务会无限执行，直接连接成功，或者输入slaveof no one断开和主节点的连接为止
3、当连接成功时，从节点会向主节点发送ping命令，请求首次通信，通信同时，还会检测套接字文件是否可用，检测主节点是否可以接收执行的命令，如果发送ping命令没有得到主节点的pong回复，从节点会断开连接，然后下次定时任务继续重连
4、执行权限认证，密码，ip等
5、同步数据集，主节点将数据发送给从节点
6、持续同步
复制的方式
全量复制
通过info replication可以看到master_replid：
每次重启redis时，该id都会刷新，从节点通过该id判断是否为上一次自己连接的主服务器，如果是执行增量复制，如果不是执行全量复制
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.1.7
master_port:6379
master_link_status:up
master_last_io_seconds_ago:9
master_sync_in_progress:0
slave_repl_offset:0
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:5fae4c123cbbdf4d9ed928f750bb80c7b1eaf350
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:1 #是否开启复制积压缓冲区
repl_backlog_size:1048576 #积压缓冲区的默认大小
repl_backlog_first_byte_offset:1
repl_backlog_histlen:0
增量复制
在使用复制的过程中，命令会追加到复制积压缓冲区，如果从节点丢失的数据可以在复制积压缓冲区中获取，那么主节点将会补发丢失的命令给从节点，如果从节点丢失的数据没有办法在复制积压缓冲区中获取（先进先出，命令写入的偏移量超过了缓冲区的大小，一定会丢失数据），那么执行全量复制
哨兵
概念
监控，用于检测整个集群的状态（包括其他哨兵），如果有节点宕机，执行故障转移，将出现问题的服务器移出当前集群，出现哨兵是因为一旦主节点宕机整个集群崩溃，需要通过人工干预的方式实现切换主服务器的操作，很不智能，哨兵可以帮助程序员自动在从节点上输入slaveof no one，避免长时间没有故障转移的问题，在redis2.8版本之后开始使用
| 概念 | 逻辑结构 | 物理结构 |
|---|---|---|
| 主节点 | redis主服务 | 一个独立的redis进程 |
| 从节点 | redis从服务 | 一个独立的redis进程 |
| 数据节点 | redis主从服务的集合 | 主从节点进程集合 |
| 哨兵节点 | 监控redis数据节点 | 一个独立的哨兵节点 |
| 哨兵节点集合 | 多个redis哨兵的集合 | 若干个哨兵节点集合 |
哨兵的部署数量最少有三个且以奇数形式建立
一主两从实现高可用（哨兵）
1、主节点发生故障，从节点复制失败
2、如果从节点无法正常启动，需要选出一个从节点进行执行slaveof no one成为新的主节点进行对外提供服务
3、原来的从节点成为主节点之后更新信息
4、另外一个从节点变成晋升为当前主节点的从节点
整个过程全为哨兵执行，不需要人工干预
哨兵操作步骤（从服务器中）
[root@localhost ~]# mkdir /sentinel
[root@localhost ~]# cd /usr/src/redis-5.0.5/
[root@localhost redis-5.0.5]# cp sentinel.conf /sentinel/setinel26379.conf
[root@localhost redis-5.0.5]# cp sentinel.conf /sentinel/setinel26380.conf
[root@localhost redis-5.0.5]# cp sentinel.conf /sentinel/setinel26381.conf
[root@localhost ~]# cd /sentinel/
[root@localhost sentinel]# vim setinel26379.conf
添加：bind 0.0.0.0
sentinel monitor mymaster 127.0.0.1 6379 2
#设置哨兵监控的节点信息（只填写主节点信息），mymaster表示监控的节点名字+ip+端口
#2表示哨兵中只要有两个哨兵判定该节点宕机执行故障转移（数量设置为半数哨兵为宜）
sentinel down-after-milliseconds mymaster 30000
#哨兵监控的节点在30000毫秒内没有反应自动执行故障转移
sentinel parallel-syncs mymaster 1
#执行故障转移时全量复制的人数
sentinel failover-timeout mymaster 180000
#故障转移的超时时间，单位：毫秒
以上修改为：
sentinel monitor mymaster 192.168.1.7 6379 2
如果有密码修改此内容：# sentinel auth-pass <master-name> <password>
sentinel down-after-milliseconds mymaster 10000
其他两条不该
[root@localhost sentinel]# vim setinel26380.conf
修改：port 26380
添加：bind 0.0.0.0
修改：
sentinel monitor mymaster 192.168.1.7 6379 2
sentinel down-after-milliseconds mymaster 10000
[root@localhost sentinel]# vim setinel26381.conf
修改：port 26381
添加：bind 0.0.0.0
修改：
sentinel monitor mymaster 192.168.1.7 6379 2
sentinel down-after-milliseconds mymaster 10000
1、多个哨兵可以有效地防止误判发生
2、多个哨兵的部署可以保证整个集群的健壮
==哨兵会定期给监控节点发送ping命令，得到pong回复则正常，收不到回复则认为该机器宕机==
哨兵开启方式
1、redis-sentinel哨兵配置文件
2、redis-server --sentinel 哨兵配置文件
[root@localhost ~]# redis-sentinel /sentinel/setinel26379.conf
[root@localhost ~]# redis-sentinel /sentinel/setinel26380.conf
[root@localhost ~]# redis-sentinel /sentinel/setinel26381.conf
主从日志中都有变化
此时将主节点down掉，等待自己设置的10000毫秒也就是10s，会发现从节点变为了主节点，如果之前的主节点再次上线，会被哨兵设置为从节点
主观宕机：
监控的一台哨兵判定监控的节点宕机
+sdown 有主观宕机
-sdown 服务器重新上线
客观宕机：
监控的半数哨兵判定该节点宕机
+odown 有客观宕机
-odown 服务器重新上线
博客内容遵循 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 协议
