[Redis]：进阶(二)·分布式缓存

摘要

摘要：Redis持久化；Redis哨兵；Redis主从集群；Redis分片集群；Redis插槽

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分片集群

6 master主节点复制为什么要用RDB为什么不用AOF？

答：理解错误，先是RDB，后是AOF，也就是说是RDB跟AOF结合使用

7 Redis插槽

7.1 Redis插槽是什么

Redis插槽：在Redis中一个Redis键值空间被分成16384个插槽，每个插槽可以存储一个键值对，每个Redis集群节点负责处理部分插槽，所有节点一起负责整个Redis键值空间。用来解决数据分片和负载均衡问题。

7.2 Redis插槽作用

① 数据分片：利用插槽将Redis键值空间划分为多部分，在不同节点存储不同数九，避免数据全部存储在单节点导致节点压力过大。
② 负载均衡：不同节点处理不同插槽，保证每个节点的负载均衡。
③ 处理节点故障：若一个节点出现故障，其它节点可以负责处理该节点上负责的插槽，保障系统的高可用性。
④ 扩容缩容：Redis集群可方便进行扩容和缩容，只需将插槽映射到新节点。

7.3 Redis插槽解决的问题

• ① 数据分片问题：将数据按照指定规则分散到多个节点上，以达到提高性能、增加可靠性和利于扩展的目的，数据分片可以避免单节点处理所有数据的问题，因而降低单节点压力，数据分片可分为水平分片和垂直分片。
• ② 负载均衡问题：在分布式系统中，将负载平均分配到多个节点以提高系统的性能和可靠性，通过将请求分配到多节点上，因此避免单节点负载过高，保证整个分布式系统负载均衡，使得让系统吞吐量达到最大值。
• ③ 节点扩容问题：节点扩容是将新节点加入到分布式系统中，以提高系统性能和可靠性，其具体有两方面，一方面，动态增加服务器数量以处理更多请求，另一方面，增加存储容量以容纳更多数据。
• ④ 节点缩容问题：节点缩容是将无用节点从分布式系统中移除，以降低系统运行成本。