redis如何实现高可用【主从复制、哨兵机制】

心已赠人 2022-01-14 08:30 232阅读 0赞

转载：[https://blog.csdn.net/itcats\_cn/article/details/82428716][https_blog.csdn.net_itcats_cn_article_details_82428716]

## 实现redis高可用机制的一些方法： ##

**保证redis高可用机制需要redis主从复制、redis持久化机制、哨兵机制、keepalived等的支持。**

主从复制的作用：数据备份、读写分离、分布式集群、实现高可用、宕机容错机制等。

## redis主从复制原理 ##

首先主从复制需要分为两个角色：master(主) 和 slave(从) ，注意：redis里面只支持一个主，不像Mysql、Nginx主从复制可以多主多从。

1、redis的复制功能是支持多个数据库之间的数据同步。一类是主数据库（master）一类是从数据库（slave），主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据，一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。

2、通过redis的复制功能可以很好的实现数据库的读写分离，提高服务器的负载能力。主数据库主要进行写操作，而从数据库负责读操作。

主从复制**全量同步的**过程：见下图

![70][]

Redis主从复制可以根据是否是全量分为全量同步和增量同步

Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。

**全量同步过程：**

1：当一个从数据库启动时，会向主数据库发送sync命令，

2：主数据库接收到sync命令后会开始在后台保存快照（执行rdb操作），并用缓存区记录后续的所有写操作

3：当主服务器快照保存完成后，redis会将快照文件发送给从数据库。

4：从数据库收到快照文件后，会丢弃所有旧数据，载入收到的快照。

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

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

**增量同步的过程：**

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

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

**Redis主从复制全量与增量同步的选择：**

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

### redis主从复制如何配置呢？ ###

1.  `修改从服务器redis/conf中的redis.conf文件`
2.   
3.  `修改IP地址和端口号为主服务器的IP和端口`
4.  `slaveof 10.211.55.9 6379`
5.   
6.  `masterauth 123456--- 如果主redis服务器配置了密码,则需要配置`

只需要配置从服务器的redis.conf即可，主服务器无需配置。验证是否成功可以通过1、先登录主服务器redis-cli客户端，输入info。若role显示master、slave0能正常显示从服务器的ip，则表示主从服务配置成功，主从复制配置成功了，也同时实现了读写分离，不信?你看看试试看你的从服务器还能不能写入操作了？答案是：不能。从服务器只有读操作！

## Redis哨兵机制 ##

哨兵机制需要主从复制的支持。

Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:

·        **监控****(Monitoring)**: 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。

·        **提醒****(Notification)**:当被监控的某个Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

·        **自动故障迁移****(Automatic failover)**:当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用**流言协议****(gossipprotocols)**来接收关于Master是否下线的信息,并使用**投票协议****(agreement protocols)**来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master.

每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(**所谓的****”****主观认为宕机****” Subjective Down,****简称****sdown**).

若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(**即****:****客观上的真正****down****机****,Objective Down,****简称****odown**),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置.

虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel).

哨兵(sentinel) 的一些设计思路和zookeeper非常类似

单个哨兵(sentinel)

![70 1][]

### 哨兵模式如何配置? ###

注意：哨兵机制是redis自带的功能，不需要接入第三方实现

实现步骤:                                                               哨兵机制端口号默认为26379

配置之前注意防火墙是否关闭

> 1.修改sentinel.conf配置文件(该文件存在于redis安装包根目录下)
> 
> 注意：初次配置，不需要打开\#sentinel monitor mymaster注释，因为后几行有默认当台服务器为主服务器
> 
> 原配置：sentinel monitor mymaster 127.0.0.1 6379 2 通过这句来修改为：
> 
> sentinel monitor mymaster  10.211.55.3  6379  1   \#主服务器名称 IP 端口号 选举次数(redis集群服务器不多时可以配置成1)
> 
> 2.修改下一行：sentinel auth-pass mymaster 123456 \# 第一个参数mymaster为主节点名称，123456为主服务器密码。
> 
> 3. 修改心跳检测 5000毫秒【默认为30秒】
> 
> sentinel down-after-milliseconds mymaster 5000
> 
> 4.sentinel parallel-syncs mymaster 2 --- 指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
> 
> 5. 启动哨兵模式【cd到redis安装根目录下启动，因为需要运行redis-server】
> 
> ./redis-server sentinel.conf --sentinel &
> 
> 启动后如果打印+ monitor master 主节点名 ip     和    +slave slave  ip则表示启动成功
> 
> ![70 2][]
> 
> 6.可以通过模拟——主服务器进入redis-cli，输入shutdown，观察哨兵所在服务器日志打印。原从服务器本不能写操作，后由于哨兵自动故障迁移把某一个slave服务器升级为master服务器，则该升级后的服务器又可以进行写操作。
> 
> ![70 3][]

光靠redis主从复制和哨兵机制不足以实现redis高可用。为什么呢？

因为若某一节点宕机后，不会实现自动重启。最稳健实现高可用的做法 :

redis主从复制+哨兵机制(监控、提醒、自动故障迁移)+keepalived(自动重启)，若重启多次仍不成功，可以通过邮件短信等方式通知。

[https_blog.csdn.net_itcats_cn_article_details_82428716]: https://blog.csdn.net/itcats_cn/article/details/82428716
[70]: /images/20220114/79b7af9f91d04482a620556bdd0aa569.png
[70 1]: /images/20220114/74ce78dff7d74f22bf18378403110a09.png
[70 2]: /images/20220114/32f8c93618604f4cb39bb08ca863ebe7.png
[70 3]: /images/20220114/a84f4833d2374454bffc95897cce4e26.png