单点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检测彼此健康状态；
- 客户端请求可以访问集群任意节点，最终都会被转发到正确节点。
