Redis高级

分布式缓存

redis内存存储 服务重启数据会丢失
并发能力问题: 无法满足618这样的高并发问题
故障恢复问题:
存储能力问题: 单节点存储难以满足

redis持久化 RDB AOF

RDB

redis数据备份文件 也叫作 数据快照
默认保存在当前运行目录 .rdb文件

save 命令: 由主进程来执行RDB 会阻塞所有命令

bgsave 	: 重新来一条子进程去执行RDB
1
2
3

redis.conf 文件属性dir，默认配置是dir ./ 表示在哪启动server时候的时候，dump.rdb就在哪生成

主从集群 (实现读写分离)

集群搭建

一主两从
在同一个虚拟机中开始3个redis实例,模拟主从集群:

找个地方创建三个文件夹 分别为 7001 7002 7003
mkdir 7001 7002 7003
配置文件中开启默认的RDB模式,AOF保持关闭

# 开启RDB
# save ""
save 3600 1
save 300 100
save 60 10000

# 关闭AOF
appendonly no
1
2
3
4
5
6
7
8

然后把原本的配置文件拷贝到 7001 7002 7003 的文件夹中
cp 命令
然后修改这三个文件中的端口号 RDB文件的保存位置
修改每个实例的IP (避免混乱,直接绑定)
启动 (以配置文件启动)

当我们的配置文件中设置了每次连接需要密码的时候,接下来进行主从绑定的时候,会报错

连接不上,
MASTER aborted replication with an error: NOAUTH Authentication required.

因为master节点设置了密码，而在从节点的配置中，没有配置masterauth参数导致的。 进入配置文件

vi redis.conf
/masterauth		(进行搜索)
取消掉注释   加上master节点的连接密码	(主要是给从机配置)

参考:https://blog.csdn.net/hou_ge/article/details/104639396
1
2
3
4
5

启动两个从redis

# 连接 7002
redis-cli -p 7002
# 执行slaveof
slaveof 192.168.138.110 7001

# 连接 7003
redis-cli -p 7003
# 执行slaveof
slaveof 192.168.138.110 7001

# 最后启动主节点master7001
# 连接 7001
redis-cli -p 7001
# 查看状态
info replication
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

最后进行测试即可;
主节点设置值,从节点接收

主从数据同步的原理

当主从第一次建立连接的时候,会执行 全量同步,将master节点的所有数据拷贝给slave节点.

如何判断是否是第一次:

概念:
Replication Id		数据集的标记,简称replid
		id一致则说明是同一数据集,每一个master都有唯一的replid，slave则会继承
		master节点的replid

offset				偏移量
		slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的
		offset，说明slave数据落后于master，需要更新。

第一次连接的时候,slave会向master发送自己原本的replid 和 offset偏移量 ,master发信发送过来的与自己的不一致,
说明是一个新的slave,因此就需要做全量同步.
				如果一致,就是增量同步.
1
2
3
4
5
6
7
8
9
10
11
12

完整流程描述：

• slave节点请求增量同步
• master节点判断replid，发现不一致，拒绝增量同步
• master将完整内存数据生成RDB，发送RDB到slave
• slave清空本地数据，加载master的RDB
• master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave
• slave执行接收到的命令，保持与master之间的同步

repl_backlog原理

这个文件是一个固定大小的环形数组,当数据满了以后,会重新覆盖之前的文件内容
他会记录redis处理过的命令日志以及master当前的offset和已经拷贝过的slave的offset
.
.
master与slave直接偏移量的差距就是要增量的数据
.
.
当 他们之间的偏移量大过整个文件时(就是日志文件已经写完一轮又覆盖了slave的偏移量时) 就需要 全量同步了
(尚未备份的数据被覆盖)

主从同步优化

主从同步可以保证主从数据的一致性，非常重要。

- 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。
- Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
- 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
- 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力
1
2
3
4

主从从的架构图

redis 哨兵 (实现健康监测和自动恢复)

通过哨兵机制来实现主从集群的自动故障恢复

哨兵的作用如下：

• 监控：Sentinel 会不断检查您的master和slave是否按预期工作
• 自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主
• 通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端

监控原理

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

•主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例**主观下线**。

•客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例**客观下线**。quorum值最好超过Sentinel实例数量的一半。
1
2
3
4
5

故障恢复原理

一旦发现master故障，sentinel需要在salve中选择一个作为新的master，选择依据是这样的：

- 首先会判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds * 10）则会排除该slave节点
- 然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举
- 如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高
- 最后是判断slave节点的运行id大小，越小优先级越高。

1
2
3
4
5
6
7

搭建分片集群 (插槽机制实现动态扩容)