redis的主从复制以及哨兵模式

我不是不努力
353 阅读10分钟

什么是主从复制

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

默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。(必须在同一个网段上)

主从复制的作用

  1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
  2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
  3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。(实现一种另类的读写分离)
  4. 读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量；
  5. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

主从复制启用方式

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

  1. 配置文件： 在从服务器的配置文件中加入：slaveof (我们最常用的)
  2. 启动命令： redis-server启动命令后加入 --slaveof
  3. 客户端命令： Redis服务器启动后，直接通过客户端执行命令：slaveof ，则该Redis实例成为从节点。

通过 info replication 命令可以看到复制的一些信息

主从复制过程

主从复制过程大体可以分为3个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段。

  1. 从节点执行 slaveof 命令(从redis日志中可以看出来)

  2. 从节点只是保存了 slaveof 命令中主节点的信息，并没有立即发起复制

​ 从节点内部的定时任务发现有主节点的信息，开始使用 socket 连接主节点**(建立了一个端口为51234的套接字，专门用于接受主节点发送的复制命令。)**

  1. 连接建立成功后，从节点发送 ping 命令(检测套接字以及是否可接受可处理命令)，希望得到 主节点pong 命令响应，否则会进行重连

  2. 如果主节点设置了权限(requirepass密码)，那么从节点(masterauth参数)就需要进行权限验证；如果验证失败，复制终止。

  3. 权限验证通过后，进行数据同步，这是耗时最长的操作，主节点将把所有的数据全部发送给从节点。

  4. 当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

简单实例演示

准备了三台虚拟机，分别为192.168.153.129 192.168.153.130 192.168.153.131

首先我确定了192.168.153.129是我的主redis节点，192.168.153.130和192.168.153.131分别是从redis节点

我选用的是主从复制方式的第一种方式

  • 修改192.168.153.130===>redis.conf 核心配置文件

  • 验证主从同步

从上面的从redis可以看出已经读到了主redis节点设置的值，但是它不能写了，体现了读写分离的思想

  • 另一台同理设置！

注：从redis也可以设置自己的从redis，比如192.168.153.131的slaveof可以设置为192.168.153.130

数据间的同步

redis同步有两个命令：

sync 和 psync，前者是 redis 2.8 之前的同步命令，后者是 redis 2.8 为了优化 sync 新设计的命令。当然了，我们要重点关注 2.8 的 psync 命令。

执行psynv命令需要有3个方面的支持：

主从节点各自复制偏移量

主节点复制积压缓冲区

主节点运行 ID(服务器运行ID)

具体解释：

主从节点各自复制偏移量

复制偏移量包括master复制偏移量和slave复制偏移量，当初次同步过后两个数据库的复制偏移量相同，之后master执行一次写命令，那么master的偏移量+1，master将写命令给slave，slave执行一次，slave偏移量+1，这样版本就能一致。

主节点复制积压缓冲区

复制积压缓冲区是由master维护的固定长度的先进先出的队列。默认大小 1MB。
这个队列在 slave 连接是创建。当slave发送psync，会将自己的偏移量也发送给master，当slave的偏移量之后的数据在缓冲区还存在，就会返回+continue通知slave进行部分重同步。当slave的偏移量之后的数据不在缓冲区了，就会进行完整重同步。
他的作用就是用于部分复制和复制命令丢失的数据补救。通过 info replication 可以看到相关信息。

主节点运行 ID(服务器运行ID)

每个redis服务器开启后会生成一个40位的运行ID。
运行 ID 的主要作用是用来识别 Redis 节点。
当进行初次同步时，master会将自己的ID告诉slave，slave会记录下来，当slave断线重连后，发现ID是这个master的就会尝试进行部分重同步。当ID与现在连接的master不一样时会进行完整重同步

注意：在上面的解释中，我们有几个新的名词关于同步：部分重同步以及完整重同步

同步的理解

在理解同步之前，我们先了解一下psync命令是如何使用以及执行的：

使用方式：

命令格式为 psync{runId}{offset}

runId：从节点所复制主节点的运行 id (也就是上面的主节点运行ID)

offset：当前从节点已复制的数据偏移量

执行流程：

从节点发送 psync 命令给主节点，runId 就是目标主节点的 ID，如果没有默认为 -1，offset 是从节点保存的复制偏移量，如果是第一次复制则为 -1.

  1. 如果回复 +FULLRESYNC ，那么从节点将触发全量同步流程。
  2. 如果回复 +CONTINUE，从节点将触发部分同步。
  3. 如果回复 +ERR，说明主节点不支持 2.8 的 psync 命令，将使用 sync 执行全量同步
  • (初次)全量同步

什么是初次全量同步，说白了就是就是第一次从redis节点连接主redis节点的过程；具体过程我画了一个流程图：

初次全量同步就是载入RDB的过程。什么是RDB快照，简单点就是类似一个库，联系到我们的配置文件中，

就是一个叫做dump.rdb的一个文件！

  • 部分重同步

什么时候会出现部分重同步呢？

当从节点正在复制主节点时，如果出现网络闪断和其他异常，可能会导致slave断开连接，这时候如果重新连接，从节点会让主节点补发丢失的命令数据，主节点只需要将复制缓冲区的数据发送到从节点就能够保证数据的一致性，相比较全量复制，成本小很多。

假如从节点出现网络中断，超过了 repl-timeout 时间，主节点就会中断复制连接

  1. 主节点会将请求的数据写入到“复制积压缓冲区”，默认 1MB。
  2. 当从节点恢复，重新连接上主节点，从节点会将 offset 和主节点 id 发送到主节点
  3. 主节点校验后，如果偏移量的数后的数据在缓冲区中，就发送 cuntinue 响应 —— 表示可以进行部分复制
  4. 主节点将缓冲区的数据发送到从节点，保证主从复制进行正常状态。

哨兵模式(心跳机制)

原理：

一看见哨兵模式，大家最先想到的就是我们生活中的哨兵，或者理解为年少的时候干坏事放哨的小伙伴哈哈~

字面意思就是类似于监控或者说监督的一种机制。

当然了在实际运用中，哨兵是作为一个分布式系统来运用。

这种系统机制就是用来管理一个Redis集群，这种机制一般执行三种任务：

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

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

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

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

每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂。

若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡",通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置.

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

===========================话不多说，来一个单哨兵的流程图==================================

哨兵模式修改配置

因为哨兵模式本身就是一个应用程序，所以我可以直接拿一台redis服务器进行配置：

修改sentinel.conf配置文件：

使用redis-server加载sentinel.conf文件开启哨兵模式：

为了测试哨兵机制是否开启，我将配置了哨兵机制的redis服务器也设置为子redis：

首先我将我的master主机(192.168.153.128)down掉或者关机，进行选举的测试：

说明将192.168.153.130选举为master，查看进行测试：

至此结束！！

尾语

鉴于自己是回忆并整理redis，有不足请多指正，说实话哈，这部分就是Linux上的搭建哈

avatar
文章
阅读
粉丝