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

常见的持久化开发运维问题 & 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

2. 通过info Persistence

127.0.0.1:6379>info persistence

3. 直接查看是否紧张

第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：主观下线。