共计 2784 个字符,预计需要花费 7 分钟才能阅读完成。
摘要:本文将演示主从复制如何配置、实现以及实现原理,Redis 主从复制三大策略,全量复制、局部复制和立刻复制。
本文分享自华为云社区《Redis 主从复制实际总结》,原文作者:A 梦多啦 A。
复制简介
Redis 作为一门非关系型数据库,其复制性能和关系型数据库 (MySQL) 来说,性能其实都是差不多,无外乎就是实现的原理不同。Redis 的复制性能也是绝对于其余的内存性数据库 (memcached) 所具备特有的性能。
Redis 复制性能次要的作用,是集群、分片性能实现的根底;同时也是 Redis 实现高可用的一种策略,例如解决单机并发问题、数据安全性等等问题。
服务介绍
在本文环境演示中,有一台主机,启动了两个 Redis 示例。
实现形式
Redis 复制实现形式分为上面三种形式:
1. 服务启动时配置
该形式通过在启动 Redis 服务时,通过命令行参数,进行启动主从复制性能。该形式的弊病是不能实现配置长久化,当服务停掉之后,启动服务时,须要增加雷同的命令参数。
1.1 master 服务器当时在 redis.confg 减少 requirepass 项。
requirepass 6379
1.2 启动从服务器。
redis-server --port 6380 --replicaof 192.168.2.102 6379
2. 命令行配置
该形式通过应用 redis-cli 进入操作行界面,进行配置。该形式的弊病是不能实现配置长久化,当服务停掉之后,启动服务须要执行同样的命令。
2.1 master 服务器执行。
127.0.0.1:6379> config set requirepass 6379
OK
2.2 从服务器执行。
127.0.0.1:6380> replicaof 192.168.2.102 6379
OK
127.0.0.1:6380> config set masterauth 6379
OK
3. 配置文件配置
该形式是通过 redis.conf 配置文件进行设置,可能实现配置的长久化,是一种举荐应用的形式。
3.1 配置主服务器,redis.config。
requirepass 6379
3.2 配置从服务器,redis.config。
masterauth 6379
replicaof 192.168.2.102 6379
4. 配置阐明
1.masterauth:设置 redis.confi 连贯明码,如果设置了该值。其余客户端在连贯该服务器时,须要增加明码才能够拜访。
2.requirepass:设置主服务器的连贯明码,和 1 中 masterauth 统一。
3.replicaof:从服务器连贯到服务器的 IP 地址 + 端口号。
成果测试
1. 主服务器增加数据。
2. 从服务器获取数据。
实现原理
// uml 图
@startuml
从服务器 -> 主服务器: 1. 保留配置
从服务器 -> 主服务器: 2. 建设 socket 连贯
从服务器 -> 主服务器: 3. 发送 ping 命令
从服务器 -> 主服务器: 4. 权限验证
从服务器 -> 主服务器: 5. 同步数据
从服务器 -> 主服务器: 6. 继续复制数据
@enduml
主从复制次要实现的一个流程如上图:
1. 第一步,从服务器保留主服务器的配置信息,保留之后待从服务器外部的定时器执行时,就会触发复制的流程。
2. 第二步,从服务器首先会与主服务器建设一个 socket 套字节连贯,用作主从通信应用。前面主服务器发送数据给从服务器也是通过该套字节进行。
3. 第三步,socket 套字节连贯胜利之后,接着发送鉴权 ping 命令,失常的状况下,主服务器会发送对应的响应。ping 命令的作用是为了,保障 socket 套字节是否能够用,同时也是为了验证主服务器是否承受操作命令。
4. 第四步,接着就是鉴权验证,判断从节点配置的主节点连贯明码是否正确。
5. 第五步,鉴权胜利之后,就能够开始复制数据了。主服务器此时会进行全量复制,将主服务的数据全副发给从服务器,从服务器保留主服务器发送的数据。
6. 接下来就是继续复制操作。主服务器会进行异步复制,一边将写的数据写入本身,同时会将新的写命令发送给从服务器。
实现策略
Redis 主从复制次要分为三种弄策略形式,不同的策略形式都是针对不同的场景下进行应用。三种场景形式别离如下:
1. 全量复制。全量复制用在主从复制刚建设时或者从切主服务器时,从服务器没有主服务器的数据,主服务器会将本身的数据通过 rdb 文件形式发送给从服务器,从服务器会清空本身数据,接着将主服务器发送的数据加载到本身中。
// uml 图
@startuml
从服务器 -> 主服务器: 1.psync ? -1
主服务器 -> 从服务器: 2.fullsync runid offset
从服务器: 3. 保留 runid offset
主服务器: 4. 执行 bgsave 生成 rdb
主服务器 -> 从服务器: 5. 发送 rdb
从服务器: 6. 清空本身老数据
从服务器: 7. 加载主服务器数据
@enduml
2. 局部复制。局部复制用在一些异常情况下,例如主从提早、从服务宕机之后重新启动接管主服务器发送的局部数据。
局部复制的实现次要依赖于复制缓存区、主服务的 runid、主从服务器各自的复制偏移量(offset)。
复制缓存区:主服务在接管写命令时,会将命令写入缓存区,以便从服务器在异常情况下,缩小数据的失落。当从服务器失常连贯之后,主服务器会将缓存区内的数据发送给从服务器。这里的缓存区是一个长队列。
主服务器 runid:主服务器会在每次服务启动之后,会生成一个惟一的 ID,作为本身标识。从服务器会将该标识保存起来,发送局部复制命令时,会应用该 runid。
psync runid offset
主从复制各自偏移量:主从服务在建设复制之后,都会有本身的偏移量。从节点会每秒钟发送本身复制的偏移量给从节点,主节点在发送写命令之后,从节点也会减少本身的复制偏移量。主节点在每次进行了写命令之后,也会减少本身的偏移量。这里的偏移量是通过命令的字节长度累加计算。
3. 异步复制。异步复制是针对主从建设复制关系之后,主从服务器持续保持复制关系。
场景问题
1. 数据安全。
// 从服务器只读
replica-read-only yes
// 从服务器连贯明码
masterauth
2. 数据提早。
默认的状况下主节点存在新数据不会立刻发送给从服务器,如果开启,则会了解发送给从服务器。默认的工夫回绝与 Linux 内核。
// 复制提早
repl-disable-tcp-nodelay yes
3. 主从节点连贯状态。
主从节点一旦建设连贯之后,会定时模仿成对方的客户端,检测对方的服务状态。主节点能够通过设置 repl-ping-replica-period 配置参数进行设置。默认的频率是 10s。
从节点咋执行 replconf ack {offsetid}时,也会将本身的复制偏移量发送给主服务器,主服务依据偏移量进行判断数据提早。存在数据提早就会从复制积压缓冲区的数据汇中,将对应的数据补发给从节点。
点击关注,第一工夫理解华为云陈腐技术~