Redis从入门到高可用，分布式实践 三（Sentinel与高可用主从复制）

知识点

常见问题

fork（内存页的拷贝）

子进程开销和优化

Aof追加阻塞（刷盘策略）

AOF阻塞定位

Redis复制

为数据提供副本，扩展读性能
- 单机问题
- 机器故障（高可用）
- 容量瓶颈
- QPS瓶颈

configuration

主机：
conf：
守护进程
daemonize yes
pidfile /var/run/redis-6379.pid
logfile '6379.log'
关掉 save 300 1 等三个检测配置
dbfilename dump-6379.rdb
dir /opt/soft/data
从机：
slave-read-only yes
dbfilename dump-6380.rdb
slaveof 127.0.0.1 6379
分别启动
我们可以使用redis-cli info replication 来检查主从情况

run id

run id是一个唯一标识，重启之后消失
redis-cli info server | grep run
如果id发生变化，从就会把主的数据全部复制过来，也就是全量复制
偏移量如果相差过多，可能说明主从复制有问题

全量复制

• 开销过大（时间）
• bgsave
• RDB文件网络传输
• 从节点清空数据
• 从节点加载RDB
• 可能的AOF重写

部分复制

slave宕机和master宕机（how to automate?）

主从复制遇到的问题

高可用

规避全量复制

复制风暴

当主节点宕机重启之后，所有的从节点都要进行一次全量复制
当然，高可用（从当主）也可以解决这个问题

主从复制的问题

• 手动故障转移
• 写能力和存储能力受到限制
  

生命周期

Redis Sentine 架构

sentine对redis进行故障判断，故障转移，通知客户端
可以监控多套redis主从架构，通过master-name作为标识

安装配置

Redis主节点

Redis从节点

sentinel配置

1. 2表示两台sentinel对redis master 进行监控，故障发现
2. 30000毫秒如果无反应，则判断成功
3. 转移时间 failover-timeout

[root@localhost ~]# redis-server redis-conf
[root@localhost ~]# redis-cli -p 7000 ping
PONG
[root@localhost ~]# redis-server redis-7001-conf 
[root@localhost ~]# redis-server redis-7002-conf 
[root@localhost ~]# ps -ef | grep redis-server | grep 700
root      6646     1  0 11:51 ?        00:00:00 redis-server *:7000
root      6673     1  0 11:54 ?        00:00:00 redis-server *:7001
root      6678     1  0 11:54 ?        00:00:00 redis-server *:7002

[root@localhost ~]# redis-cli -p 7000 info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=7001,state=online,offset=85,lag=0
slave1:ip=127.0.0.1,port=7002,state=online,offset=85,lag=0
master_repl_offset:99
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:98

sentinel配置

redis-sentinel redis-sentinel-26379(配置文件)
redis-cli -p 26379

故障转移演练（客户端）

• 客户端高可用观察
• 服务端日志分析： 数据节点和sentinel节点
  
  
  

客户端高可用

客户端接入流程

• Sentinel地址集合
• masterName
• 不是代理模式（只获取一次masterName,如果master没有变化之前）

java

py

故障转移

三个定时任务

主观下线和客观下线

quorum 法定人数，判定是否客观下线，最好是奇数，sentinel个数%2+1

领导者选举

故障转移（sentinel领导者节点完成）

选择最好的slave节点

节点运维问题

• 节点上线和下线
• 主节点
• 从节点
• Sentinel节点

主节点下线
手动故障转移，忽略主观下线和客观下线和领导者选举，只有故障转移的过程 
sentinel failover masterName

sentinel上线

高可用读写分离

从节点的作用

sentinel不会对master进行故障转移，只会做一个下线的判断

客户端

对slave做一个资源池
自定义客户端，监控如下的可能的变化