Redis 分布式缓存

分布式缓存

单点 Redis 的问题及解决

• 数据丢失：实现Redis数据持久化
• 并发能力：搭建主从集群，实现读写分离
• 存储能力：搭建分片集群，利用插槽机制实现动态扩容
• 故障恢复能力：利用哨兵机制，实现健康检测和自动恢复

RDB

RDB全称Redis Database Backup file （Redis数据备份文件），也被叫做Redis数据快照，简单来说就是把内存中的所有数据都记录到磁盘上，当Redis实时故障重启后，从磁盘读取快照文件，恢复数据

save #由Redis主进程来执行RDB，会阻塞所有命令

bgsave #开启子进程执行RDB，避免主进程收到影响，推荐

RDB默认是开启的，内部有触发机制，可以在redis.conf文件中找到，RDB文件也支持压缩；Redis关闭时，也会触发一次RDB

RDB方式bgsave的基本流程

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

RDB会在什么时候执行？save 60 1000的含义？

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

RDB的缺点

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

AOF

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

AOF默认是关闭的，AOF的命令记录频率也可以通过修改redis.conf文件修改

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always

# 写命令执行完先放到AOF缓冲区，然后表示每隔1s将缓冲区数据写入到AOF文件，是默认方案
appendfsync everysec

# 写入命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写到磁盘
appendfsync no

• 因为AOF记录的是每次写的命令。AOF文件会比RDB文件大，而且AOF中会记录对同一个key的多次写操作，但是只有最后一次的才有意义，通过执行bgreWriteaop命令，可以让AOF文件执行重写功能，用最少得命令达到相同的效果

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

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

• AOF和RDB同时开启，会以AOF优先；在实际的开发中往往结合两者使用

Redis主从

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

主从数据同步原理

第一次是全量同步

全量同步的流程

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

如果slave重启后，执行增量同步

哨兵（Sentinel）

Redis提供哨兵（Sentinel）机制来实现主从集群的自动恢复

• 监控：哨兵会不断监控master和slave的健康状况
• 故障自动恢复：当master故障时，Sentinel哨兵会将其中一个slave提升为master，当老master恢复后，还是以新的master为主
• 通知：哨兵充当Redis客户端发现来源，当集群发生故障转移时，会将最新的消息推送给Redis的客户端

哨兵基于心跳监测机制，每个1s向集群的每一个实例发送ping命令：

• 主观下线：如果某个哨兵节点发现某实例为在规定时间内响应，则认为该实例主观下线
• 客观下线：若超过指定数量（quorum）的哨兵都认为该实例主观下线，则该实例客观下线，类似投票机制

选举新的master

• 首先会判断slave节点与master节点断开时间的长短，如果超过指定值，则会排除在外
• 然后根据slave节点的slave-priority，越小优先级越高
• slave一样，则判断slave节点的offset值。越大说明数据越新，优先级越高
• 最后判断slave节点的运行id大小，越小优先级越高

故障转移

• Sentinel哨兵给备选的slave发送命令，让该节点称为新的master
• 哨兵给所有的其它slave发送命令，让这些节点成为新master的slave节点，开始从master同步数据
• 最后，哨兵将故障节点，也就是老的master标记为slave从节点

Redis分片集群

主从和哨兵解决了高可用、高并发读的问题，但依然有两个问题没有解决：

• 海量数据存储问题
• 高并发写的问题

使用分片集群可以解决以上问题

• 集群中有多个master，每个master保存不同的数据
• 每个master都可以有多个slave节点
• master之间通过ping监测彼此健康状态
• 客户端请求可以访问集群中的任一个节点，最终都会被转发到正确的节点上

散列插槽

1. Redis会把每个master节点映射到0~16383共16384个插槽（Hash slot）上
2. 数据key不是与节点绑定，而是与插槽绑定，Redis会根据key的有效部分计算插槽值，分为两种情况：
   • key中包含"{}“，且”{}“中至少包含一个字符，”{}"中的部分是有效部分，这就实现了控制不同的key在同一插槽上
   • 可以中不包含"{}"，整个可以都是有效部分
   • 计算方式是利用CRC16算法得到一个Hash值，然后对16384取余，得到的就是slot值