常见的持久化开发运维问题 & 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
8-14 领导者选举
·原因:只有一个sentinel节点完成故障转移
·选举:通过sentinel is-master-down-by-addr命令都希望成为领导者
- 每个做主观下线的Sentinel节点向其他Sentinel节点发送命令,要求将它设置为领导者。
- 收到命令的Sentinel节点如果没有同意通过其他Sentinel节点发送的命令,那么将同意该请求,否则拒绝
- 如果该Sentinel节点发现自己的票数已经超过Sentinel集合半数且超过quorum,那么它将成为领导者。
- 如果此过程有多个Sentinel节点成为了领导者,那么将等待一段时间重新进行选举。
8-15 故障转移(sentinel领导者节点完成)
- 从slave节点中选出一个“合适的"节点作为新的master节点
- 对上面的slave节点执行slaveof no one命令让其成为master节点。
- 向剩余的slave节点发送命令,让它们成为新master节点的slave节点,复制规则和parallel-syncs参数有关。
- 更新对原来master节点配置为slave,并保持着对其“关注",当其恢复后命令它去复制新的master节点。
选择“合适的"slave节点
- 选择slave-priority(slave节点优先级)最高的slave节点,如果存在则返回,不存在则继续。
- 选择复制偏移量最大的slave节点(复制的最完整),如果存在则返回,不存在则继续。
- 选择runld最小的slave节点。
8-16 常见开发运维问题-目录
◆节点运维◆高可用读写分离
8-17 节点运维
节点下线
机器下线:例如过保等情况
机器性能不足导致下线:例如CPU、内存、硬盘、网络等
节点自身故障导致下线:例如服务不稳定等
◆主节点
使用命令手动下线:
◆从节点:临时下线还是永久下线,例如是否做一些清理工作。
但是要考虑读写分离的情况。
◆Sentinel节点:同上。
节点上线
◆主节点:sentinel failover进行替换。
◆从节点:slaveof即可,sentinel节点可以感知。
◆sentinel节点:参考其他sentinel节点启动即可。
8-18 高可用读写分离
◆+switch-master:切换主节点(从节点晋升主节点)
◆+convert-to-slave:切换从节点(原主节点降为从节点)
◆+sdown:主观下线。