Redis高可用之主从复制&sentinel哨兵模式

文章内容是学习过程中的知识总结，如有纰漏，欢迎指正

文章目录

一、主从复制

1.面临问题

2.解决办法

3.主从复制

 4.常用策略

5.主从复制原理

6.配置主从复制

7.测试主从关系

二、sentinel哨兵模式

总结

---

以下是本篇文章正文内容

一、主从复制

1.面临问题

Redis有两种不同的持久化方式，Redis服务器通过持久化，把Redis内存中持久化到硬盘当中，当Redis宕机时，我们重启Redis服务器时，可以由RDB文件或AOF文件恢复内存中的数据。

问题1：不过持久化后的数据仍然只在一台机器上，因此当硬件发生故障时，比如主板或CPU坏了，这时候无法重启服务器，有什么办法可以保证服务器发生故障时数据的安全性？或者可以快速恢复数据呢？

问题2：容量瓶颈

2.解决办法

针对这些问题，redis提供了复制(replication)的功能，通过"主从(一主多从)"和"集群(多主多从)"的方式对redis的服务进行水平扩展,用多台redis服务器共同构建一个高可用的redis服务系统。

3.主从复制

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave),数据的复制是单向的，只能由主节点到从节点。

 4.常用策略

策略1 ：一主多从 主机(写)，从机(读)

 策略2：薪火相传

5.主从复制原理

 Redis的主从复制是异步复制，异步分为两个方面，一个是master服务器在将数据同步到slave时是异步的，因此master服务器在这里仍然可以接收其他请求，一个是slave在接收同步数据也是异步的。

复制方式

• 全量复制

master服务器会将自己的rdb文件发送给slave服务器进行数据同步，并记录同步期间的其他写入，再发送给slave服务器，以达到完全同步的目的，这种方式称为全量复制。

•  增量复制

因为各种原因master服务器与slave服务器断开后，slave服务器在重新连上master服务器时会尝试重新获取断开后未同步的数据即部分同步，或者称为部分复制。

 工作原理

master服务器会记录一个replicationId的伪随机字符串，用于标识当前的数据集版本，还会记录一个当数据集的偏移量offset，不管master是否有配置slave服务器，replication Id和offset会一直记录并成对存在，我们可以通过以下命令查看replication Id和offset：

> info repliaction

通过redis-cli在master或slave服务器执行该命令会打印类似以下信息(不同服务器数据不同，打印信息不同)：

connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=9472,lag=1
master_replid:2cbd65f847c0acd608c69f93010dcaa6dd551cee
master_repl_offset:9472

当master与slave正常连接时，slave使用PSYNC命令向master发送自己记录的旧master的replication id和offset，而master会计算与slave之间的数据偏移量，并将缓冲区中的偏移数量同步到slave，此时master和slave的数据一致。

而如果slave引用的replication太旧了，master与slave之间的数据差异太大，则master与slave之间会使用全量复制的进行数据同步（repl_backlog_size值调大可以尽量避免）。

6.配置主从复制

注：主从复制的开启，完全是在从节点发起的；不需要我们在主节点做任何事情。

从节点开启主从复制，有3种方式：

（1）配置文件：在从服务器的配置文件中加入：slaveof

（2）redis-server启动命令后加入 --slaveof

（3）Redis服务器启动后，直接通过客户端执行命令：slaveof ，则该Redis实例成为从节点

演示：

①、通过 info replication 命令查看三台节点角色

 初始状态，三台节点都是master

②、设置主从关系，从节点执行命令：SLAVEOF IP(主节点) 6379

 再看主节点信息：

 这里通过命令来设置主从关系，一旦服务重启，那么角色关系将不复存在。想要永久的保存这种关系，可以通过配置redis.conf 文件来配置。

slaveof 主节点IP 6379

7.测试主从关系

①、增量复制

master 操作写入：

 slave操作获取：

 ②、全量复制

通过执行 SLAVEOF 127.0.0.1 6379，如果主节点 6379 以前还存在一些 key，那么执行命令之后，从节点会将以前的信息也都复制过来

③、主从读写分离

尝试slave操作写入：

 原因是在配置文件 6380redis.conf 中对于 slave-read-only 的配置

replica-read-only yes

如果我们将其修改为 no 之后，执行写命令是可以的，但是从节点写命令的数据从节点或者主节点都不能获取的。

④、主节点宕机

主节点 Master 挂掉，两个从节点角色会发生变化吗？

 

 上图可知主节点 Master 挂掉之后，从节点角色还是不会改变的。

⑤、主节点宕机后恢复

主节点Master挂掉之后，马上启动主机Master，主节点扮演的角色还是 Master 吗？

 也就是说主节点挂掉之后重启，又恢复了主节点的角色。

---

二、sentinel哨兵模式

通过前面的配置，主节点Master 只有一个，一旦主节点挂掉之后，从节点没法担起主节点的任务，那么整个系统也无法运行。

如果主节点挂掉之后，从节点能够自动变成主节点，那么问题就解决了，于是哨兵模式诞生了。

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

哨兵模式搭建步骤：

①、在配置文件目录下新建 sentinel.conf 文件，名字绝不能错，然后配置相应内容

sentinel monitor 主服务器器的名字(自己起名字) 主服务ip地址 端口号 得票数

 

 分别配置被监控的名字，ip地址，端口号，以及得票数。上面的得票数为1表示表示主机挂掉后salve投票看让谁接替成为主机，得票数大于1便成为主机

②、启动哨兵

redis-sentinel /redis/sentinel.conf

 接下来，我们干掉主机 6379，然后看从节点有啥变化

 （选主策略：①从库优先级slave-priority配置项、②从库复制进度大的、③ID号小的）

 PS：哨兵模式也存在单点故障问题，如果哨兵机器挂了，那么就无法进行监控了，解决办法是哨兵也建立集群，Redis哨兵模式是支持集群的。

---

总结

主从复制常用策略：

1.一主多从 主机写，从机读

2.薪火相传

主从复制方式：

1.全量复制

2.增量复制