文章目录
1 单机的Redis存在四大问题
1.1 数据丢失问题
| 解决方案 | 实现Redis数据持久化 |
|---|
持久化：由于Redis缓存存储在内存中，而内存不存储数据（内存读写快），磁盘存储数据（IO交互多，读写慢），我们需要将Redis存储在内存中数据持久化存储到磁盘中。
1.2 故障恢复问题
| 解决方案 | 利用Redis哨兵，实现健康检测和自动恢复 |
|---|
1.3 并发能力问题
| 解决方案 | 搭建主从集群，实现读写分离 |
|---|
1.4 存储能力问题
| 解决方案 | 搭建分片集群。利用插槽机制实现动态扩容 |
|---|
2 数据丢失问题：Redis持久化解决RDB与AOF
2.1 RDB持久化
RDB（Redis Database Backup file）（Redis数据备份文件）：也称Redis数据快照。把内存中的数据记录到磁盘中。
当Redis实例故障重启，从磁盘读取快照文件（RDB文件），恢复数据。默认保存在当前运行目录。
2.1.1 执行时机
| 执行时机 | 解释 | 测试 |
|---|---|---|
| 执行save命令 | save命令会使主进程执行RDB，过程中其它命令都会被阻塞。只有在数据迁移时可能用到此命令 |
 |
| 执行bgsave命令 | 此命令可以异步执行RDB ,执行后开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。 |
 |
| 停机时 | Redis停机时执行一次save命令，实现RDB持久化。 |  |
| 触发RDB条件 | Redis内部有触发RDB机制，在redis.conf文件中修改 |   |
2.1.2 触发RDB条件及其他配置
Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：
# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1
save 300 10
save 60 10000
RDB的其它配置也可以在redis.conf文件中设置，格式如下：
# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes
# RDB文件名称
dbfilename dump.rdb
# 文件保存的路径目录
dir ./
2.1.3 RDB原理
RDB原理：首先，bgsave开始时fork主进程得到子进程，子进程共享主进程的存数据。其次，完成fork后读取内存数据并写入 RDB 文件。
fork采用copy-on-write技术：
- 主进程执行读操作时，访问共享内存；
- 主进程执行写操作时，拷贝一份数据，执行写操作。
2.1.4 RDB方式bgsave的基本流程
首先，fork主进程得到一进程，共享内存空间，其次，子进程读取内存数据并写入新的RDB文件，最后，用新RDB文件替换旧的RDB文件。
2.1.5 RDB的缺点
- RDB执行间隔时间长（因为其要
保存一时刻redis缓存的所有快照），两次RDB之间写入数据有丢失风险- fork子进程、压缩、写出RDB文件都比较耗时
2.2 AOF持久化
2.2.1 AOF原理
AOF(Append Only File)（追加文件）：Redis处理的每个写命令都要记录在AOF文件（命令日志文件）。
2.2.2 AOF配置
2.2.2.1 AOF默认关闭，修改redis.conf配置文件开启AOF
# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"
2.2.3 AOF命令记录频率三种策略
# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no
2.2.4 AOF文件重写
2.2.4.1 为什么进行重写：
因为AOF方式是记录命令的，因此会比RDB方式产生的文件大的多。**
2.2.4.2 重写的思路：
例如，对同一key的多此操作，只有最后一次才有意义，我们要做的就是减少此类操作中产生的垃圾命令。
2.2.4.3 实现：
执行
bgrewriteaof命令，让AOF文件执行重写功能，用最少命令达到相同效果。
2.2.4.4 Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：
# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb
2.3 RDB与AOF对比
3 并发能力问题：Redis主从
3.1 为什么要搭建Redis主从架构
单节点Redis并发能力有上限，如需提高并发能力，需搭建主从集群，实现读写分离。
3.1 搭建主从架构
3.2 主从数据同步原理
3.2.1 全量同步
主从数据同步原理：首先，主从第一次建立连接时，执行全量同步（将RDB文件通过网络传输给slave）
3.2.2 问题：master如何得知salve是第一次来连接呢？以及master如何判定此salve是自己的从节点？
答：salve做数据同步，首先，salve向master发送
自己原有的replid和offset，当master发现slave发送来的replid与自己不一致，说明这是全新slave需要做全量同步，然后，master会将自己的replid和offset发送给slave，slave保存这些信息。以后slave的replid就与master一致,也判定此salve是自己的从节点。即：master判断某节点是否为第一次同步的:依据是
比较replid是否相同。
| 名词 | 解释 |
|---|---|
| Replication Id (replid)（数据集标记） | id一致说明是同一数据集。每一个master都有唯一replid，slave会继承master节点replid |
| offset (偏移量) | 随repl_baklog中数据增多而增大。slave完成同步时记录当前同步的offset。如slave的offset小于master的offset，说明slave数据落后于master，需要更新。 |
3.2.3 增量同步
4 故障恢复问题：Redis哨兵
5 存储能力问题：Redis分片集群
master主节点复制为什么要用RDB为什么不用AOF？
答：理解错误，先是RDB，后是AOF，也就是说是RDB跟AOF结合使用