Redis高级之分布式缓存

一、Redis持久化

1.1 RDB持久化

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

RDB持久化执行时机：

1. 执行save命令 主进程执行RDB，这个过程中其他命令都会被阻塞。只有在数据迁移时可能用到。
2. 执行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 

 redis的其他配置也可以在redis.conf文件中设置，如下图：

# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes

# RDB文件名称
dbfilename dump.rdb  

# 文件保存的路径目录
dir ./ 

 1.2 RDB原理

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入RDB文件。

fork采用了copy-on-write技术：

• 当主进程执行读操作时，访问共享内存。
• 当主进程执行写操作时，则会拷贝一份数据，执行写操作。

如下图：

 1.3 小结

a.RDB方式bgsave的基本流程?

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

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

• 默认是服务停止时
• 代表60s内至少执行10000次修改，才会触发RDB

c.RDB的缺点？

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

2.0 AOF持久化

AOF原理：

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

        如图：

        

 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

三种策略对比：

        

 Redis也会在触发阈值时自动重写AOF文件。阈值也可以在redis.conf中配置：

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb 

3.0 RDB与AOF对比

RDB和AOF各有优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

二、Redis 主从

1.搭建主从架构：

        单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。

示意图：

        

2.数据同步原理：

        主从第一次是全量同步：

        

有个值得思考的问题：

        master如何判断slave是不是第一次来同步数据？这里用到2个重要概念：

• Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid。
• offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。也就是说，slave（子节点）要做数据同步，必须向master声明自己的replication id和offset，master才可以判断到底需要同步哪些数据。

请看下面这种情况：

slave原本是一个master，有自己的replid和offset，当第一次变成slave，与master建立连接时，发送的replid和offset是自己的replid和offset。

master判断发现slave发送来的replid与自己的不一致，说明这是一个全新的slave，就知道要做全量同步了。

master会将自己的replid和offset都发送给这个slave，slave保存这些信息。以后slave的replid就与master一致了。

 结论：master判断一个slave节点是否是第一次来同步数据，就是看replid是否一致。

如图：

        

注意：repl_baklog大小有限，写满后会覆盖最早的数据。如果slave断开时间过久，导致尚未备份的数据被覆盖，则无法基于log做增量同步，只能再次全量同步。

完整流程：

1. slave节点请求增量同步
2. master节点判断replid，发现不一致，拒绝增量同步
3. master将完整内存数据生成RDB，发送RDB到slave
4. slave清空本地数据，加载master的RDB
5. master将RDB期间的命令记录在repl_baklog,并持续将log中的命令发送给slave
6. slave执行接受到的命令，保持与master之间的同步

3.增量同步

全量同步需要先做RDB，然后将RDB文件通过网络传输给slave，成本太高了。因此除了第一次做全量同步，其他大多数时候slave与master都是做增量同步。

何为增量同步？

        就是只更新slave与master存在差异的部分数据。

如图：

        

思考一个问题？

        master怎么知道slave与自己的数据差异在哪里呢？

        这里就要说到全量同步时的repl_baklog文件了。

        这个文件是一个固定大小的数组，只不过数组是环形，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被新数据覆盖了。

        repl_baklog中会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset ：

        如图：

        

        slave与master的offset之间的差异，就是salve需要增量拷贝的数据了。

        随着不断有数据写入，master的offset逐渐变大，slave也不断的拷贝，追赶master的offset：

        

         直到数组被填满：

        

 

        此时，如果有新的数据写入，就会覆盖数组中的旧数据。不过，旧的数据只要是绿色的，说明是已经被同步到slave的数据，即便被覆盖了也没什么影响。因为未同步的仅仅是红色部分。

        但是，如果slave出现网络阻塞，导致master的offset远远超过了slave的offset：

        

         如果master继续写入新数据，其offset就会覆盖旧的数据，直到将slave现在的offset也覆盖：

        

         棕色框中的红色部分，就是尚未同步，但是却已经被覆盖的数据。此时如果slave恢复，需要同步，却发现自己的offset都没有了，无法完成增量同步了。只能做全量同步。

 4.小结：

简述全量同步和增量同步区别？

• 全量同步：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时

待续...