Redis笔记（三）常见的持久化开发运维问题 & Redis复制的原理与优化 & Redis Sentinel_aof和rdb文件写入,可以结合iostat,iotop分析。-优快云博客

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

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

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

在这里插入图片描述

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

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

6-1 常见问题目录

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

6-2 fork

同步操作
与内存量息息相关：内存越大，耗时越长（与机器类型有关）
info:latest_fork usec #查询上一次持久化所消耗的时间

改善fork

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

6-3 子进程开销和优化

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

硬盘优化

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

6-4 AOF阻塞

在这里插入图片描述

AOF阻塞定位

通过日志

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

通过info Persistence

127.0.0.1:6379>info persistence

直接查看是否紧张

在这里插入图片描述

第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最后在进行数据写入
在这里插入图片描述
全量复制开销

bgsave时间
RDB文件网络传输时间
从节点清空数据时间
从节点加载RDB的时间
可能的AOF重写时间

部分复制

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

7-5 故障处理

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

slave 宕掉

在这里插入图片描述

master 宕掉

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

7-6 主从复制常见问题

◆读写分离

读写分离：读流量分摊到从节点。
可能遇到问题：
·复制数据延迟
·读到过期数据
·从节点故障

◆主从配置不一致

例如maxmemory不一致：丢失数据
例如数据结构优化参数（例如hash-max-ziplist-entries）：内存不一致

◆ 规避全量复制

第一次全量复制
第一次不可避免·小主节点、低峰
节点运行ID不匹配
主节点重启（运行ID变化）
故障转移，例如哨兵或集群
复制积压缓冲区不足
网络中断，部分复制无法满足
增大复制缓冲区配置rel_backlog_size，网络“增强"。

◆ 规避复制风暴

单主节点复制风暴：
问题：主节点重启，多从节点复制，主节点压力较大
解决：更换复制拓扑
单机器复制风暴
如右图：机器宕机后（假设该机器上均为主节点），则会大量全量复制
解决办法：主节点分散多机器上

第8章 Redis Sentinel

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

8-1 sentinel-目录

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

8-2 主从复制高可用？

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

手动故障转移
写能力（只能写在一个节点上）和存储能力受限

之前一旦主节点挂掉就需要手动或者使用脚本来进行故障转移，而转移的过程中涉及到许多问题。普通开发人员难以实现，而redis sentinel 则提供了这样一些功能来帮我们解决这些问题。

8-3 redis sentinel架构

实现了类似于监控节点是否有问题，完美的迁移流程，以及如何通知客户端
在这里插入图片描述
故障转移

可以使用同一redis sentinel 来监控多个redis master

8-4 redis sentinel安装与配置

配置开启主从节点
配置开启sentinel监控主节点。（sentinel是特殊的redis）
实际应该多机器
详细配置节点

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 三个定时任务

每10秒每个sentinel对master和slave执行info
·发现slave节点
·确认主从关系
每2秒每个sentinel通过master节点的channel交换信息（pub/sub）
·通过_sentinel__：hello频道交互
·交互对节点的“看法”和自身信息
每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