Redis学习笔记（5）-主从复制

Redis主从复制

1. 基本介绍

ps：这是我的个人笔记地址：TinkerBell学习笔记

主机数据更新后根据配置和策略， 自动同步到备机的 master/slaver 机制，Master 以写为主，Slaver 以读为主，即主服务器承担写操作，复制的若干 从服务器 则承担读操作。

2.特点

• 读写分离，性能扩展

  • 主机读写，从机分担读压力

• 容灾快速恢复

  • 某个从服务器发生故障，那么会快速切换到另一个从服务器中，不影响读操作的进行

• 一主多从

  • 只有一台主服务器，供其他从服务器进行复制

3. 搭建主从模式

• 1.创建文件目录

/opt/etc

• 2.将 redis.conf 复制到当前目录

cp /etc/redis.conf /opt/etc/

• 3.创建 3 个 redis.conf 配置文件

redis6379.conf

redis6380.conf

redis6381.conf

# redis6379.conf

include /opt/etc/redis.conf  #这里指包含原reids配置文件，并用以下配置覆盖redis中的个别配置

pidfile /var/run/redis_6379.pid   #线程名

port 6379  #端口号

dbfilename dump6379.rdb  #持久化后的文件名 （RDB模式下）


# redis6380.conf

include /opt/etc/redis.conf

pidfile /var/run/redis_6380.pid

port 6380

dbfilename dump6380.rdb


# redis6381.conf

include /opt/etc/redis.conf

pidfile /var/run/redis_6381.pid

port 6381

dbfilename dump6381.rdb

• 4.启动 3 台 redis 服务器

• 5.查看主机运行情况

info replication  #这个命令的意思是，查看当前结点的slaves从节点信息，目前还没有配置，所以显示0个，后面会演示

• 6.配从不配主（建立主从关系）
  在从机中进行设置，成为谁的从机

slaveof  <ip> <port>
# 成为某个实例的从服务器

这里选用6379端口的redis服务器为主机，所以分别在6380,6381进行配置

• 7.再次查看主机运行情况

• 8.搭建完成 Bingo！

3.1 一主二从

3.1.1 特点：

主机 6379，从机 6380 和 6381。

• 1.假设从机 6380 挂掉。（从机挂掉）

  • 当6380重启后，6380不再是6379的从机，而是作为新的master；（从机重启后，不再是某个主机的从机，其自身就是一个主机）
  • 当再次把6380作为6379的从机加入后，从机才会把数据从头到尾复制。（从机重启后，需要再输入成为从机的指令）

• 2.假设主机 6379 挂掉。（主机挂掉）

  • 6380和6381仍然是6379的从机，不会做任何事；（从机不会改变）
  • 当6379重启后，既然是主服务器。（主机重启后，还是主机）

3.1.2 主从复制原理(重点)

完整版：

• slave 启动成功连接到 master 后会发送一个 sync 命令（同步命令）。

• master 接到命令启动后台的存盘进程，对数据进行持久化操作，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master 将传送整个数据文件（rdb）到 slave，以完成一次完全同步。

• 当主服务进行写操作后，和从服务器进行数据同步。

• 全量复制： slave 服务在接收到数据库文件数据后，将其存盘并加载到内存中。

• 增量复制：master 继续将新的所有收集到的修改命令依次传给 slave，完成同步。

• 只要是重新连接 master，一次完全同步（全量复制）将被自动执行。

全量复制：是从机主动去请求主机进行同步操作，是一开始连接的时候

增量复制：主机进行一次写操作之后，就主动同步从机

注意：两个**“主动”，第一个主动是从机主动请求全量复制，第二个主动，主机将新增数据主动**发送给从机

简单示意图

3.2 薪火相传

上一个 slave 可以是下一个 slave 的 master（从机是另一个从机的主机，并由这个担任主机的从机，进行数据同步），slave 同样可以接收其他 slave的连接和同步请求，那么该 slave 作为了链条中下一个的 master，可以有效减轻 master 的写压力，去中心化降低风险。

slaveof <ip> <port>

举个案例说明薪火相传：

假如从机数量很多，达到几十几百，在数据同步的时候，主机需要一次同步几十几百个从节点，服务器压力大。

现实生活中例子：班级班主任收作业，找班长或者学委，学委找各个组的小组长，实现层级管理，降低单个“管理员”带来的压力

---

• 上一个slaves是下一个slaves的主机，并担任这个（下一个slaves）从机的主机，对它进行数据同步

• 弊端：当担任某个主机的slave宕机了，其挂在后面的所有slave都没法进行备份，造成冗余

3.3 反客为主

当一个 master 宕机后，后面的 slave 可以立刻升为 master，其后面的 slave 不用做任何修改。（需要手动完成，如果不手动执行的话，那么从机没有任何动作，主机重新启动后，还依旧是主机）

使用命令：将从机变为主机

slaveof no one  #接下来会讲到哨兵模式，自动上位

3.4 哨兵模式

反客为主的自动版，即能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

搭建哨兵模式

• 1.创建 sentinel.conf 文件

 vi /opt/etc/sentinel.conf

• 2.配置哨兵

sentinel monitor mymaster 172.16.xx.xxx 6379 1

# mymaster：给监控对象起的服务器名称
# 1：至少有多少个哨兵同意迁移的数量

• 3.启动哨兵

redis-sentinel  /opt/etc/sentinel.conf 

主机挂掉，哨兵监控到之后，会按照选举规则，从 从机 中选举中产生新的主机，原来挂掉的主机会变成新主机的从机。

注意：

• 1.当选举完新主机，哨兵会向其他所有从机发送一个slave of当前主机的命令

• 2.当已经下线的原主机重新上线了，他不能重新成为主机，而是变为现在主机的从机 （原理如上）

3.4.1 选举规则

选择条件依次为：

• 根据优先级别，slave-priority/replica-priority，优先选择优先级靠前的。（越小优先级越高）

• 根据偏移量，优先选择偏移量大的。（偏移量是指获得原主机数据最全的）

• 若前两个条件相同，那么选择 runid 最小的，优先选择最小的服务

  • 每个redis实例启动后，都会随机生成一个40位的runid

3.4.2 复制延时

由于所有的写操作都是先在 master 上操作，然后同步更新到 slave 上，所以从 master 同步到 slave 从机有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，slave 机器数量的增加也会使这个问题更加严重。

ps：下一章节【Redis集群】解决复制延时问题，引入无中心化集群方案