Redis学习笔记16----redis集群(主从复制)

Posted 2021-06-20 iostreamzl

互联网的“三高”架构

• 高并发
• 高性能
• 高可用
  • 可用性 ：
    $$可用性=\frac{全年总时间-全年服务器不能提供服务的总时间}{全年总时间}$$

单机redis的问题于风险

• 问题1：机器故障
  • 现象：硬盘故障，系统崩溃
  • 本质：数据丢失，很可能对业务造成灾难性的打击
  • 结论：基本上会放弃redis的使用
• 问题2：容器瓶颈
  • 现象：内存不足，从16G升级到64G，从64升级到128G，无限制升级内存
  • 本质：穷，硬件条件跟不上
  • 结论：放弃使用redis
• 结论：为了避免单点redis服务器故障，准备多台服务器，互相连接，将数据复制多个副本保存在不同的服务器上，所有服务器连接在一起，并保证数据的同步性 ，即使其中一台服务器宕机，其他服务器依然可以提供服务，实现redis高可用，同时实现数据冗余备份

多台服务器连接方案

• 提供数据方：master(主服务器，主节点，主库，主客户端)
• 接受数据方：slave(从服务器，从节点，从库，从客户端)
• 需要解决的问题：数据同步
• 核心工作：master数据复制到slave中

主从复制简介

主从复制即将master中的数据复制到slave中
特征：一个master可以拥有多个slave，一个slave只能有一个master
职责：
　　　* master
　　　　　* 写数据(最主要的功能)
　　　　　* 执行写操作将出现变化的数据同步到slave中
　　　　　* 读数据(可忽略)
　　　* slave:
　　　　　* 都数据(核心功能)
　　　　　* 写数据(一般禁用操作)

高可用集群

• 当其中一台从机出现问题时，其他的从机会继续提供服务。对整体的影响不会很大，大大提高了可用性
• 当主机出现问题，会临时推选一台从机来当作主机，由该机器来提供原来主机的工作，大大提高可用性

主从复制的作用

• 读写分离：master写，slave读，提高服务器的读写负载能力
• 负载均衡：基于主从结构，配合读写分离，由slave分担master负载，改变slave的数量，通过多个节点分担数据读取负载，大大提高redis服务器的数据数据吞吐量与并发量
• 故障恢复：当master出现故障后，由slave提供服务实现快速的故障恢复
• 数据冗余：实现数据热备份，是持久化之外的一种数据备份方式
• 高可用基石，基于主从复制，构件哨兵模式与集群，实现redis的高可用方案

主从复制的工作流程

阶段一：建立连接

• 建立slave到master的连接，使得master能够识别slave，并保存slave的端口号
  

主从连接

• 方式1：客户端连接

slaveof <masterip> <masterport>

slave客户端执行命令后，主机master服务端显示如下信息

slave服务端显示如下信息

此时已经连接成功了。可以做一个测试验证一下。
在master机器写数据，在slave取数据。可以看到的是slave是可以获取数据的


通过info命令查看服务器信息
master显示：

slave显示：

• 方式二：启动服务器参数

redis-server [配置文件/启动参数] --slaveof <masterip> <masterport>
# 效果与方法一一样

• 方式三：服务器配置

# 主流方法
slaveof <masterip> <masterport>
# 在slave服务器配置文件中添加上面的语句, 启动服务器时通过配置文件启动
# 例如slaveof 127.0.0.1 6379

• 断开连接

# 在slave端执行该命令
slaveof no one
# 断开后数据将不再同步

• salve 系统信息
  • master_link_down_since_seconds
  • masterhost
  • masterport
• master系统信息
  • slave_listening_port(多个)

授权访问

• master配置文件设置密码

# 配置文件中添加
requirepass <password>

• master客户端通过指令设置密码

config set requirepass <password>
config get requirepass

• slave 客户端发送命令验证密码

auth <password>

• slave配置文件验证密码

masterauth <password>

• 启动客户端时验证密码

redis-cli -a <password>

阶段二：数据同步

• 将slave数据库状态更新为master当前数据库状态
  

数据同步阶段master说明

• 如果master数据量很大，数据同步阶段应该避开流量高峰期，避免造成master阻塞，影响业务正常执行
• 复制缓冲区大小设置不合理，会导致数据溢出。如果进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的情况，必须进行第二次全量复制，致使slave进入死循环状态
• 设置缓冲区大小的指令：repl-backlog-size 1mb(默认)
• master单机内存占用主句内存比例不应该过大，建议使用50%----70%的内存，留下30%----50%的内存用于执行bgsave命令和创建缓冲区

数据同步阶段slave说明

• 为避免slave进行全量复制，部分复制时slave服务器响应阻塞或数据不同步，建议关闭此期间的对外服务，命令：slave-server-stale-data yes|no
• 数据同步阶段master发送给slave信息可以理解为master是slave的一个客户端，主动向slave发送命令
• 多个slave同时向master请求数据同步，master发送的RDB文件增多，会对带宽造成巨大的冲击，如果master带宽不足，因此数据同步需要根据业务需求适量错峰
• slave过多时建议调整拓扑结构，由一主多从结构变为树状结构，中间节点即是master又是slave，注意使用树状结构时，由于层级深度，导致深度越深，slave与顶层master之间的数据同步延迟越大，数据一致性变差，应谨慎选择树形结构

阶段三：命令传播阶段

• 当master数据库状态被修改后，导致主从服务器的状态不一致，此时需要让主从数据同步到一致的状态，同步过程称为命令传播
• master将受到的数据变更指令发送给slave，slave接受命令后执行

命令传播阶段的部分复制

• 命令传播阶段出现断网现象

  • 闪断闪联 忽略
  • 短时间网络中断 部分复制
  • 长时间网络中断 全量复制

• 部分复制的三个核心要素

  • 服务器运行的id(run id)
  • 主服务器的复制积压缓冲区
  • 主服务器的复制偏移量

服务器运行id

• 概念：服务运行id是每一天服务器每次运行的身份识别码，一台服务器多次运行可生成多个运行id
• 组成：40位字符，是一个随机的16进制字符串
• 作用：用于在服务器之间传输识别身份
• 实现方式：运行id在每台服务器启动时自动生成，master在首次连接slave时，会将自己的运行id发送给slave，slave保存此id，通过info Server命令可以查看run id

复制缓冲区

心跳机制

• 进入命令传播阶段，master与slave之间要进行信息交换，使用心跳机制进行维护，实现双方连接保持在线
• master心跳：
  • 指令：PING
  • 周期：由repl-ping-slave-period决定，默认10秒
  • 作用：判断slave是否在线
  • 查询：info Replication，获取slave最后一次连接时间间隔，lag维持在0或1都是正常的
• slave心跳任务：
  • 指令：REPLCONF ACK{offset}
  • 周期：1秒
  • 作用1：汇报slave最新的复制偏移量，获取最新的数据变更指令
  • 作用2：判断master是否在线

心跳阶段注意事项

• 当slave多数掉线或延迟高时，master为保障数据稳定性，将拒绝所用的数据同步操作

min-slaves-to-write 2
min-slaves-max-lag 8
# slave数量少于2，或者slave延迟都大于等于8秒时，强制停止数据同步

• slave的数量由slave发送REPLCONF ACK命令确认
• slave延迟由slave发送REPLCONF ACK命令确认