Redis笔记(三)常见的持久化开发运维问题 & Redis复制的原理与优化 & Redis Sentinel

本文深入探讨Redis在运维过程中常见的持久化问题及其优化策略,包括fork操作、AOF追加阻塞等,并详解Redis复制原理及故障处理方法。同时,介绍了RedisSentinel的架构、配置与故障转移机制,确保Redis服务的高可用性和读写分离的有效实施。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

常见的持久化开发运维问题 & Redis复制的原理与优化 & Redis Sentinel

在这里插入图片描述

第6章 常见的持久化开发运维问题

本章探讨了常见的持久化问题进行定位和优化,最后结合Redis常见的单机多实例部署场景进行优化

6-1 常见问题目录

  1. fork操作
  2. 进程外开销
  3. AOF追加阻塞
  4. 单机多实例部署

6-2 fork

  1. 同步操作
  2. 与内存量息息相关:内存越大,耗时越长(与机器类型有关)
  3. info:latest_fork usec #查询 上一次持久化所消耗的时间

改善fork

  1. 优先使用物理机或者高效支持fork操作的虚拟化技术
  2. 控制Redis实例最大可用内存:maxmemory
  3. 合理配置Linux内存分配策略:Vm.overcommit_memory=1 #但还有足够内存是允许进行分配
  4. 降低fork频率:例如放宽AOF重写自动触发时机,不必要的全量复制

6-3 子进程开销和优化

  1. CPU:
    开销:RDB和AOF文件生成,属于CPU密集型
    优化:不做CPU绑定,不和CPU密集型部署
  2. 内存
    开销:fork内存开销,copy-on-write。
    优化:echo never>/sys/kernel/mm/transparent_ hugepage/enabled
  3. 硬盘
    开销:AOF和RDB文件写入,可以结合iostat,iotop分析

硬盘优化

  1. 不要和高硬盘负载服务部署一起:存储服务、消息队列等
  2. no-appendfsync-on-rewrite=yes #在aof重写期间不要进行追加的操作 可以减少内存开销
  3. 根据写入量决定磁盘类型:例如ssd
  4. 单机多实例持久化文件目录可以考虑分盘

6-4 AOF阻塞

在这里插入图片描述

AOF阻塞定位
  1. 通过日志
Redis日志:
Asynchronous AOF fsync is taking too long(disk is busy?).
Writing the AOF buffer without waiting for fsync to complete,
this may slow down Redis
  1. 通过info Persistence
127.0.0.1:6379>info persistence
  1. 直接查看是否紧张

在这里插入图片描述

第7章 Redis复制的原理与优化

复制是实现高可用的基石,但复制同样是运维的痛点,本部分详细分析复制的原理,讲解运维过程中可能遇到的问题。

7-1 目录

7-2 什么是主从复制

单机有什么问题?

  • 机器故障
  • 容量瓶颈
  • QPS瓶颈

一主一从
在这里插入图片描述
一主多从
在这里插入图片描述
主从复制作用

  • 数据副本
  • 扩展读性能

7-3 复制的配置

两种实现方式

方式一:slaveof命令

使用命令进行实现
在这里插入图片描述
取消复制
在这里插入图片描述

redis-6380>slaveof no one
OK

执行该命令后 6379新写入的数据将不会再同步到 6380

redis-6380> slaveof 127.0.0.1 6379
OK
方式二:修改配置
slaveof ip port #成为某一台机器的从节点
slave-read-only yes#从节点只做读的操作 保证主从节点的一致性 

两种方式比较
在这里插入图片描述

实验

对应 Redis笔记(三)实验部分 : 主从复制的配置与实现

7-4 全量复制和部分复制

全量复制

将主节点在复制过程中写入的数据也同步给从节点

在第一次请求中 由于不知道主节点的 runid和偏移量 所以要发送 psync? -1 然后主节点 发送给从节点runid和偏移量 然后从节点进行保存主节点的基本信息
然后主节点执行bgsava 而在rdb生成到rdb传输的这段时间内的新增命令需要进行一个保存(在buffuf区中)然后在发送 rdb之后 会send buffer最后在进行数据写入
在这里插入图片描述
全量复制开销

  1. bgsave时间
  2. RDB文件网络传输时间
  3. 从节点清空数据时间
  4. 从节点加载RDB的时间
  5. 可能的AOF重写时间
部分复制

如果在全量复制的过程中发生网络抖动 就需要再次进行全量复制效率较低 而部分复制如果在连接的过程中主从节点断开 主节点就会向缓冲区中写入命令
当从节点再次连接上主节点之后 从节点会发送pysnc{offset}{runld} 此时主节点如果发现从节点的偏移量是在他的buffer范围内则会返回从偏移量开始到结束的数据
在这里插入图片描述

7-5 故障处理

故障处理:故障转移
故障分为两种

slave 宕掉

在这里插入图片描述

master 宕掉

在这里插入图片描述
解决方案:将主节点进行迁移
在这里插入图片描述

7-6 主从复制常见问题

◆读写分离
  1. 读写分离:读流量分摊到从节点。
  2. 可能遇到问题:
    ·复制数据延迟
    ·读到过期数据
    ·从节点故障
    在这里插入图片描述
◆主从配置不一致
  1. 例如maxmemory不一致:丢失数据
  2. 例如数据结构优化参数(例如hash-max-ziplist-entries):内存不一致
◆ 规避全量复制
  1. 第一次全量复制
    第一次不可避免·小主节点、低峰
  2. 节点运行ID不匹配
    主节点重启(运行ID变化)
    故障转移,例如哨兵或集群
  3. 复制积压缓冲区不足
    网络中断,部分复制无法满足
    增大复制缓冲区配置rel_backlog_size,网络“增强"。
◆ 规避复制风暴
  1. 单主节点复制风暴:
    问题:主节点重启,多从节点复制,主节点压力较大
    解决:更换复制拓扑
    在这里插入图片描述
  2. 单机器复制风暴
    如右图:机器宕机后(假设该机器上均为主节点),则会大量全量复制
    解决办法:主节点分散多机器上
    在这里插入图片描述

第8章 Redis Sentinel

本章将一步步解析Redis Sentinel的相关概念、安装部署、配置、客户端路由、原理解析,最后分析了Redis Sentinel运维中的一些问题。

8-1 sentinel-目录

◆主从复制高可用?
◆架构说明
◆安装配置
◆客户端连接
◆实现原理
◆常见开发运维问题

8-2 主从复制高可用?

之前主从复制中存在的问题:

  1. 手动故障转移
  2. 写能力(只能写在一个节点上)和存储能力受限
    在这里插入图片描述
    之前一旦主节点挂掉 就需要手动或者使用脚本来进行故障转移,而转移的过程中涉及到许多问题。普通开发人员难以实现,而redis sentinel 则提供了这样一些功能来帮我们解决这些问题。

8-3 redis sentinel架构

实现了类似于 监控节点是否有问题,完美的迁移流程,以及如何通知客户端
在这里插入图片描述
故障转移
在这里插入图片描述
可以使用 同一redis sentinel 来监控多个redis master
在这里插入图片描述

8-4 redis sentinel安装与配置

  1. 配置开启主从节点
  2. 配置开启sentinel监控主节点。(sentinel是特殊的redis)
  3. 实际应该多机器
  4. 详细配置节点

8-5 redis sentinel安装演示-1

在这里插入图片描述

8-6 redis sentinel安装演示-2

8-7 java客户端

8-8 python客户端

8-9 实现原理-1-故障转移演练

8-10 实现原理-2.故障转移演练(客户端)

8-11 实现原理-3.故障演练(日志分析)

以上几个部分对应 :
Redis笔记(三)实验部分:Redis Sentinel的配置与安装&Java客户端连接 Redis Sentinel&故障转移演练

8-12 三个定时任务

  1. 每10秒每个sentinel对master和slave执行info
    ·发现slave节点
    ·确认主从关系
    在这里插入图片描述
  2. 每2秒每个sentinel通过master节点的channel交换信息(pub/sub)
    ·通过_sentinel__:hello频道交互
    ·交互对节点的“看法”和自身信息
    在这里插入图片描述
  3. 每1秒每个sentinel对其他sentinel和redis执行ping
    ·心跳检测,失败判定依据

在这里插入图片描述

8-13 主观下线和客观下线

sentinel monitor  <masterName> <ip> <port> <quorum>
sentinel monitor myMaster 127.0.0.1 6379 2
sentinel down-after-milliseconds <masterName> <timeout>
sentinel down-after-milliseconds mymaster 30000

·主观下线:每个sentinel节点对Redis节点失败的“偏见"

·客观下线:所有sentinel节点对Redis节点失败“达成共识"(超过
quorum个统一)
sentinel is-master-down-by-addr

8-14 领导者选举

·原因:只有一个sentinel节点完成故障转移

·选举:通过sentinel is-master-down-by-addr命令都希望成为领导者

  1. 每个做主观下线的Sentinel节点向其他Sentinel节点发送命令,要求将它设置为领导者。
  2. 收到命令的Sentinel节点如果没有同意通过其他Sentinel节点发送的命令,那么将同意该请求,否则拒绝
  3. 如果该Sentinel节点发现自己的票数已经超过Sentinel集合半数且超过quorum,那么它将成为领导者。
  4. 如果此过程有多个Sentinel节点成为了领导者,那么将等待一段时间重新进行选举。
    在这里插入图片描述

8-15 故障转移(sentinel领导者节点完成)

  1. 从slave节点中选出一个“合适的"节点作为新的master节点
  2. 对上面的slave节点执行slaveof no one命令让其成为master节点。
  3. 向剩余的slave节点发送命令,让它们成为新master节点的slave节点,复制规则和parallel-syncs参数有关。
  4. 更新对原来master节点配置为slave,并保持着对其“关注",当其恢复后命令它去复制新的master节点。

选择“合适的"slave节点

  1. 选择slave-priority(slave节点优先级)最高的slave节点,如果存在则返回,不存在则继续。
  2. 选择复制偏移量最大的slave节点(复制的最完整),如果存在则返回,不存在则继续。
  3. 选择runld最小的slave节点。

8-16 常见开发运维问题-目录

◆节点运维◆高可用读写分离

8-17 节点运维

节点下线
机器下线:例如过保等情况
机器性能不足导致下线:例如CPU、内存、硬盘、网络等
节点自身故障导致下线:例如服务不稳定等

◆主节点
使用命令手动下线:
在这里插入图片描述

◆从节点:临时下线还是永久下线,例如是否做一些清理工作。
但是要考虑读写分离的情况。

◆Sentinel节点:同上。

节点上线
◆主节点:sentinel failover进行替换。

◆从节点:slaveof即可,sentinel节点可以感知。

◆sentinel节点:参考其他sentinel节点启动即可。

8-18 高可用读写分离

在这里插入图片描述
◆+switch-master:切换主节点(从节点晋升主节点)
◆+convert-to-slave:切换从节点(原主节点降为从节点)
◆+sdown:主观下线。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值