高可用介绍
高可用是分布式系统架构设计中必须考虑的因素之一，它是通过架构设计减少系统
不能提供服务的时间。保证高可用通常遵循下面几点：

1. 单点是系统高可用的大敌，应该尽量在系统设计的过程中避免单点。
2. 通过架构设计而保证系统高可用的，其核心准则是：冗余。
3. 每次出现故障需要人工介入恢复，会增加系统不可用的时间，实现自动故障转移。
   我们现在已经给Redis实现了主从复制，可将主节点数据同步给从节点，从节点此时有两
   个作用：
4. 从节点扩展主节点的读能力，分担主节点读压力。
5. 一旦主节点宕机，从节点作为主节点的备份可以随时顶上来。（高可用)
   6

手动主从切换

环境准备
一旦主节点宕机，就需要把从节点晋升成主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工操作。我们再准备一个从服务，依次执行以下命令：
在虚拟机上下载redis的过程 上一篇文章在虚拟机上安装redis，详细介绍
https://blog.csdn.net/weixin_44927778/article/details/107738520
切换到redis的安装目录
cd /usr/local/redis/
查看redis目录下/bin/redis启动文件
编辑redis.conf文件
修改配置文件
vi redis.conf
#Redis后台启动
修改 daemonize 为 yes
#Redis服务器可以跨网络访问
修改 bind 为 0.0.0.0
#开启aof持久化
appendonly yes
修改完: 按esc 键退出 并输入:wq 退出
把bin文件夹存的redis的服务为主服务
再在redis目录下准备两个从服务,以此执行以下命令:
切换到redis目录 cd /usr local/redis/
准备复制一个redis服务 并命名为redis01
命令: cp -R bin/ redis01

复制成功后 切换到redis01目录
命令: cd redis01
查看: ll或者ls

清空持久化文件

rm -rf appendonly.aof
rm -rf dump.rdb

在确定以下redis01目录下的文件的
命令: ll或者 ls
编辑redis.conf
命令 vi redis.conf 或者 vim redis.conf
修改 port 为 6380
添加 slaveof 192.168.1.200 6379

启动redis服务
./redis-server redis.conf

启动客户端
./redis-cli -h 192.168.1.200 -p 6380

查看redis启动的情况
ps -ef | grep redis
目前有一主一从redis服务器和客户端
再准备一个从服务的过程和上面的步骤一样
切换到redis02目录 cd /usr/local/redis/ 目录
切换到redis02 目录
cd redis02/
# 清空持久化文件
rm -rf appendonly.aof
rm -rf dump.rdb
修改redis配置文件 redis.conf
编辑redis.conf
命令 vi redis.conf 或者 vim redis.conf
修改 port 为 6381
添加 slaveof 192.168.1.200 6379

#启动./redis-server redis.conf

启动客户端：./redis-cli -h 192.168.200.131 -p 6381

#查看有没有服务ps -ef | grep redis
分别进入一主两从服务，执行info命令，看到服务的状态：
主服务器：
Replication
role:master
connected_slaves:2
slave0:ip=192.168.1.200,port=6380,state=online,offset=14386,lag=1
slave1:ip=192.168.1.200,port=6381,state=online,offset=14386,lag=1
master_replid:e55c14d9c3347f4ca6c32ce30d975a15523000e3

从服务器：
#Replication
role:slave
master_host:192.168.1.200
master_port:6379
master_link_status:up

主服务下线
​ 登录6379端口号的主服务，并执行shutdown命令，关闭这个主redis，进入6381从
服务执行info命令，我们可以看到从服务的信息变为：
#Replication
role:slave
master_host:192.168.1.200
master_port:6379
master_link_status:down
可以看到主的状态由原来的up变为down，说明主服务下线了。
主从切换
现在可以把6380升级为主服务，执行命令：slaveof no one
#Replication
role:master
connected_slaves:1
slave0:ip=192.168.1.200,port=6381,state=online,offset=15016,lag=1
master_replid:4ddc373fc91a95b2944e93b2ed28063b577bbc96
修改6381对应的主服务器，执行命令：
slaveof 192.168.1.200 6380
#Replication
role:slave
master_host:192.168.200.131
master_port:6380
master_link_status:up
再次执行 info命令，可以看到主从服务器都切换成功。现在变成了一主一从，对外是正常的。

Sentinel实现高可用

Sentinel介绍
在前面的例子中，主节点宕机，需要把从节点晋升成主节点，同时需要修改应用方
的主节点地址，还需要命令所有从节点去复制新的主节点。
​ 这整个过程都是人工，费事费力，还会造成一段时间内服务不可用，而且需要人一
直都在。这不是一种好的方式，更多时候，我们优先考虑Sentinel（哨兵）。
Sentinel工作模式：
Sentinel 使用
安装
Sentinel 在redis的安装包中有，我们直接使用就可以了，但是先需要修改配置文件，执
行命令：
cd /usr/local/
cd redis-4.0.14

#复制sentinel配置文件 在redis目录下复制 ./是在当前目录下
命令: cp /usr/local/redis-4.0.14/sentinel.conf ./

ps -ef | grep redis

启动主服务器

#修改配置文件：
vi sentinel.conf
在sentinel01.conf配置文件中添加：

外部可以访问

bind 0.0.0.0
sentinel monitor mymaster 192.168.1.200 6379 1
sentinel down‐after‐milliseconds mymaster 10000
sentinel failover‐timeout mymaster 60000
sentinel parallel‐syncs mymaster 1
注意：如果有 sentinel monitor mymaster 192.168.200.129 6379 2配置，则注释掉。
参数说明：
sentinel monitor mymaster 192.168.200.129 6379 1
mymaster 主节点名,可以任意起名，但必须和后面的配置保持一致。
192.168.200.129 6379 主节点连接地址。
1 将主服务器判断为失效需要投票，这里设置至少需要 1个 Sentinel 同意。
sentinel down-after-milliseconds mymaster 10000
设置Sentinel认为服务器已经断线所需的毫秒数。
sentinel failover-timeout mymaster 60000
设置failover（故障转移）的过期时间。当failover开始后，在此时间内仍然没有触发
任何failoer操作，当前
sentinel 会认为此次failoer失败。
sentinel parallel-syncs mymaster 1
设置在执 行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同
步， 这个数字越小，表示同时进行同步的从服务器越少，那么完成故障转移所需的
时间就越长。
如果从服务器允许使用过期数据集， 那么我们可能不希望所有从服务器都在同一时
间向新的主服务器发送同步请求， 因为从服务器在载入主服务器发来的RDB文件
时， 会造成从服务器在一段时间内不能处理命令请求。如果全部从服务器一起对新
的主服务器进行同步， 那么就可能会造成所有从服务器在短时间内全部不可用的情
况出现。
配置文件修改后，执行以下命令，启动sentinel 在redis目录下启动
/usr/local/redis-4.0.14/src/redis-sentinel sentinel.conf
可以看到， 6381是主服务，6380和6379是从服务

原理

Sentinel 主要是监控服务器的状态，并决定是否进行故障转移。如何进行故障转移在
前面的部分已经给大家演示过人工的操作，那么Sentinel是如何判断服务是否下线呢，主
要分为主观下线和客观下线：
主观下线：
概念：
主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服
务器做出的下线判断
特点：
如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间
内， 对向它发送 PING 命令的 Sentinel 返回一个有效回复， 那么 Sentinel 就会将这个服务器标记为主观下线
客观下线
概念：
多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL
is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断
ODOWN。 （一个Sentinel 可以通过向另一个 Sentinel 发送命令来询问对方是
否认为给定的服务器已下线）
特点：
从主观下线状态切换到客观下线状态并没有使用严格的法定人数算法（strong
quorum algorithm），而是使用了流言传播（Gossip）： 如果Sentinel在给定
的时间范围内， 从其他Sentinel那里接收到了足够数量的主服务器下线报告，
那么 Sentinel 就会将主服务器的状态从主观下线改变为客观下线。
注意点：
客观下线条件只适用于主服务器，对于其他类型的 Redis 实例， Sentinel 在将
它们判断为下线前不不需要进行协商， 所以从服务器或者其他 Sentinel 不会达
到客观下线条件。 只要一个 Sentinel 发现某个主服务器进入了客观下线状态，
这个Sentinel就可能会被其他 Sentinel 推选出，并对失效的主服务器执行自动故障迁移操作
Sentinel 三大工作任务
监控（ Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正
常。
提醒（ Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通
过API向管理员或者其他应用程序发送通知。
自动故障迁移（ Automatic failover）： 当一个主服务器不能正常工作时，Sentinel
会开始一次自动故障转移操作， 它会将失效主服务器的其中一个从服务器升级为新
的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器。
当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址，
使得集群可以使用新主服务器代替失效服务器。
互联网冷备和热备
冷备
概念：
冷备发生在数据库已经正常关闭的情况下，当正常关闭时会提供给我们一个完整
的数据库
优点：
非常快速的备份方法（只需拷文件）
低度维护，高度安全
缺点：
单独使用时，只能提供 “某一时间点上”的恢复
在实施备份的全过程中，数据库必须要作备份而不能作其他工作。也就是
说，在冷备份过程中，数据库必须是关闭状态
热备
概念：
热备份是在数据库运行的情况下，采用归档模式(archivelog mode)方式备份数
据库的方法
优点：
备份的时间短
备份时数据库仍可使用