分布式缓存（十四）

单点Redis的问题

数据丢失问题；实现Redis数据持久化

并发能力问题；搭建主从集群，实现读写分离；

存储能力问题；搭建分片集群，利用插槽机制实现动态扩容。

故障恢复问题；利用Redis哨兵，实现健康检测和自动恢复；

1 Redis持久化

1.1 RDB持久化

RDB全称Redis Database Backup fie（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。

快照文件称为RDB文件，默认是保存在当前运行目录。

命令：

1）save（不推荐此命令）：由redis主进程来执行RDB，会阻塞所有命令

2）bgsave：开启子进程执行RDB，避免主进程受到影响。

RDB方式bgsave的基本流程？

• fork主进程得到一个子进程，共享内存空间；
• 子进程读取内存数据并写入新的RDB文件；
• 用新RDB文件替换旧的RDB文件。

RDB会在什么时候执行？save 60 1000代表什么含义？

• 默认是服务停止时；
• 代表60秒内至少执行1000次修改则触发RDB；

RDB的缺点？

• RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险；
• fork子进程、压缩、写出RDB文件都比较耗时。

1.2 AOF持久化

AOF全称是Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename “appendonly.aof”

AOF的命令记录的频率也可以通过redis.conf文件来配：

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

配置项	刷盘时机	优点	缺点
Always	同步刷盘	可靠性高，几乎不丢数据	性能影响大
everysec	每秒刷盘	性能适中	最多丢失1秒数据
no	操作系统控制	性能最好	可靠性较差，可能丢失大量数据

bgrewriteaof：让AOF文件执行重写功能，用最少得命令达到相同效果。

RDB 和 AOF 的对比分析：

	RDB	AOF
持久化方式	定时对整个内存做快照	记录每一次执行的命令
数据完整性	不完整，两次备份之间会丢失	相对完整，取决于刷盘策略
文件大小	会有压缩，文件体积小	记录命令，文件体积大
宕机恢复速度	很快	慢
数据恢复优先级	低，因为数据完整性不如AOF	高，因为数据完整性更高
系统资源占用	高，大量CPU和内存损耗	低，主要是磁盘IO资源但AOF重写时会占用大量CPU和内存资源
使用场景	可以容忍数分钟的数据丢失，追求更快的启动速度	对数据安全性要求较高常见

2 Redis主存

全量同步的流程：

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

全量同步和增量同步的区别：

• 全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave；
• 增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave。

什么时候执行全量同步？

• slave节点第一次连接master节点时；
• slave节点断开时间太久，repl_baklog中的offset已经被覆盖时。

什么时候执行增量同步？

• slave节点断开又恢复，并且在repl_baklog中能找到offset时。

3 Redis哨兵

3.1 哨兵的作用和原理

Redis提供了哨兵机制来实现主从集群的自动故障恢复。

哨兵的结构和作用

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

3.2 服务状态监控

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

• 主观下线：如果某Sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线；
• 客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

故障转移步骤：

• 首先选定一个slave作为新的master，执行slaveof no one；
• 然后让所有节点都执行slaveof 新 master；
• 修改故障节点配置，添加slaveof 新master。

3.3 搭建哨兵集群

3.4 RedisTemplate的哨兵模式

4 Redis分片集群

4.1 分片集群结构

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：

• 海量数据存储问题；
• 高并发写的问题；

使用分片集群可以解决上述问题，分片集群特征：

• 集群中有多个master，每个master保存不同数据；
• 每个master都可以有多个slave节点；
• master之间通过ping检测彼此健康状态；
• 客户端请求可以访问集群任意节点，最终都会被转发到正确节点。

原文链接：【SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式，系统详解springcloud微服务技术栈课程|黑马程序员Java微服务-哔哩哔哩】 https://b23.tv/vv527Ac