Redis集群-分布式缓存
基于Redis集群解决单机Redis存在的问题
单机的Redis存在四大问题：
1.Redis持久化
1.1RDB持久化
RDB全称Redis Database Backup file(Redis数据备份文件) 也被叫做Redis数据快照
简单来说就是把内存中的所有数据都记录到磁盘中
当Redis实例故障重启后 从磁盘读取快照文件 恢复数据 快照文件称为RDB文件 默认是保存在当前运行目录
1.1.1执行时机
RDB持久化在四种情况下会执行：
- 执行save命令
- 执行bgsave命令
- Redis停机时
- 触发RDB条件时
1）save命令
save命令会导致主进程执行RDB 这个过程中其它所有命令都会被阻塞 只有在数据迁移时可能用到
2）bgsave命令
bgsave命令执行后会开启独立进程完成RDB 主进程可以持续处理用户请求 不受影响
3）停机时
Redis停机时会执行一次save命令 实现RDB持久化
4）触发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 ./
1.1.2RDB底层原理
bgsave开始时会fork主进程得到子进程 子进程共享主进程的内存数据 完成fork后读取内存数据并写入 RDB 文件
fork采用的是copy-on-write技术：
- 当主进程执行读操作时 访问共享内存
- 当主进程执行写操作时 则会拷贝一份数据 执行写操作
1.1.3.小结
RDB方式bgsave的基本流程
- fork主进程得到一个子进程 共享内存空间
- 子进程读取内存数据并写入新的RDB文件
- 用新RDB文件替换旧的RDB文件
RDB执行时机默认是服务停止时 save 60 1000代表含义为：60秒内至少执行1000次修改则触发RDB
RDB缺点
- RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
- fork子进程、压缩、写出RDB文件都比较耗时
1.2AOF持久化
1.2.1AOF原理
AOF全称为Append Only File(追加文件) Redis处理的每一个写命令都会记录在AOF文件 可以看做是命令日志文件
1.2.2AOF配置
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
三种策略对比：
1.2.3AOF文件重写
因为是记录命令 AOF文件会比RDB文件大的多 而且AOF会记录对同一个key的多次写操作
但只有最后一次写操作才有意义 通过执行bgrewriteaof命令 可以让AOF文件执行重写功能 用最少的命令达到相同效果
AOF原本有三个命令 但是set num 123 和 set num 666都是对num的操作
第二次会覆盖第一次的值 因此第一个命令记录下来没有意义
所以重写命令后，AOF文件内容就是：mset name jack num 666
Redis也会在触发阈值时自动去重写AOF文件 阈值也可以在redis.conf中配置：
# AOF文件比上次文件 增长超过多少百分比则触发重写 auto-aof-rewrite-percentage 100 # AOF文件体积最小多大以上才触发重写 auto-aof-rewrite-min-size 64mb
1.3RDB与AOF区别
RDB和AOF各有自己的优缺点 如果对数据安全性要求较高 在实际开发中往往会结合两者来使用
2.Redis主从
单节点Redis的并发能力是有上限的 要进一步提高Redis的并发能力 就需要搭建主从集群 实现读写分离
2.1搭建主从结构
在同一台虚拟机中开启3个redis实例 模拟主从集群 信息如下：
| IP | PORT | 角色 |
| 10.211.55.9 | 7001 | master |
| 10.211.55.9 | 7002 | slave |
| 10.211.55.9 | 7003 | slave |
2.2准备实例和对应的文件配置
在同一台虚拟机开启3个实例 必须准备三份不同的配置文件和目录 配置文件所在目录也就是工作目录
2.2.1创建目录
创建三个文件夹 名字分别叫7001、7002、7003：
# 进入/tmp目录 cd /tmp # 创建目录 mkdir 7001 7002 7003
2.2.2恢复原始配置
修改redis-6.2.4/redis.conf文件 将其中的持久化模式改为默认的RDB模式 AOF保持关闭状态
# 开启RDB # save "" save 3600 1 save 300 100 save 60 10000 # 关闭AOF appendonly no
2.2.3将配置文件拷贝到每个实例目录
将redis-6.2.4/redis.conf文件拷贝到三个目录中(在/tmp目录执行下列命令)：
# 方式一：逐个拷贝 cp redis-6.2.4/redis.conf 7001 cp redis-6.2.4/redis.conf 7002 cp redis-6.2.4/redis.conf 7003 # 方式二：管道组合命令，一键拷贝 echo 7001 7002 7003 | xargs -t -n 1 cp redis-6.2.4/redis.conf
2.2.4修改每个实例配置和端口
修改每个文件夹内的配置文件 将端口分别修改为7001、7002、7003 将rdb文件保存位置都修改为自己所在目录(在/tmp目录执行下列命令)：
sed -i -e 's/6379/7001/g' -e 's/dir .//dir /tmp/7001//g' 7001/redis.conf sed -i -e 's/6379/7002/g' -e 's/dir .//dir /tmp/7002//g' 7002/redis.conf sed -i -e 's/6379/7003/g' -e 's/dir .//dir /tmp/7003//g' 7003/redis.conf
2.2.5修改每个实例的声明IP
拟机本身有多个IP 为了避免将来混乱 需要在redis.conf文件中指定每一个实例的绑定ip信息
# 逐一执行 sed -i '1a replica-announce-ip 10.211.55.9' 7001/redis.conf sed -i '1a replica-announce-ip 10.211.55.9' 7002/redis.conf sed -i '1a replica-announce-ip 10.211.55.9' 7003/redis.conf # 或者一键修改 printf '%s\n' 7001 7002 7003 | xargs -I{} -t sed -i '1a replica-announce-ip 10.211.55.9' {}/redis.conf
2.2.6启动三个实例
# 第1个 redis-server 7001/redis.conf # 第2个 redis-server 7002/redis.conf # 第3个 redis-server 7003/redis.conf # 一键停止 printf '%s\n' 7001 7002 7003 | xargs -I{} -t redis-cli -p {} shutdown
2.2.7开启主从关系
要配置主从可以使用replicaof或者slaveof(5.0以前)命令
有临时和永久两种模式：
- 修改配置文件（永久生效）
- 在redis.conf中添加一行配置：
slaveof <masterip> <masterport>
- 使用redis-cli客户端连接到redis服务 执行slaveof命令(重启后失效)：
slaveof <masterip> <masterport>
注意：在5.0以后新增命令replicaof 与salveof效果一致
# 连接 7002 redis-cli -p 7002 # 执行slaveof slaveof 10.211.55.9 7001 # 连接 7003 redis-cli -p 7003 # 执行slaveof slaveof 10.211.55.9 7001 # 连接 7001 redis-cli -p 7001 # 查看状态 info replication
2.3主从数据同步原理
2.3.1全量同步
主从第一次建立连接时 会执行全量同步 将master节点的所有数据都拷贝给slave节点
master通过以下判断依据得知slave是否第一次进行连接：
- Replication Id：简称replid 是数据集的标记 id一致则说明是同一数据集
每一个master都有唯一的replid slave则会继承master节点的replid - offset：偏移量 随着记录在repl_baklog中的数据增多而逐渐增大
slave完成同步时也会记录当前同步的offset
如果slave的offset小于master的offset则说明slave数据落后于master 需要更新
master判断一个节点是否是第一次同步的依据 就是看replid是否一致
完整流程描述：
- slave节点请求增量同步
- master节点判断replid 发现不一致 拒绝增量同步
- master将完整内存数据生成RDB，发送RDB到slave
- slave清空本地数据 加载master的RDB
- master将RDB期间的命令记录在repl_baklog 并持续将log中的命令发送给slave
- slave执行接收到的命令 保持与master之间的同步
2.3.2增量同步
全量同步需要先做RDB 然后将RDB文件通过网络传输个slave 成本太高
因此除了第一次做全量同步 其它大多数时候slave与master都是做增量同步
增量同步就是只更新slave与master存在差异的部分数据
2.4主从同步优化
主从同步可以保证主从数据的一致性 可以从以下几个方面来优化Redis主从集群：
- 在master中配置repl-diskless-sync yes启用无磁盘复制 避免全量同步时的磁盘IO
- Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
- 适当提高repl_baklog的大小 发现slave宕机时尽快实现故障恢复 尽可能避免全量同步
- 限制一个master上的slave节点数量 如果实在是太多slave 则可以采用主-从-从链式结构 减少master压力
主从从架构图：
2.5总结
全量同步和增量同步区别
- 全量同步：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时
