分布式缓存

目录

 一、Redis持久化

1.1 RDB持久化

1.2 AOF持久化

 二、Redis主从

三、Redis哨兵

3.1 哨兵的作用和原理

3.1.1 哨兵作用：

3.1.2选举新的master

 3.1.3 如何实现故障转移

3.1.4 总结

3.2 搭建哨兵集群

3.3 RedisTemplate的哨兵模式

3.3.1 在pom文件中引入redis的starter依赖：

3.3.2然后在配置文件application.yml中指定sentinel相关信息：

3.3.3 配置主从读写分离

---

单点Redis的问题

 一、Redis持久化

1.1 RDB持久化

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

 Redis停机时会执行一次RDB。服务宕机时不会自动保存。

 Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB save 900 1  

save 300 10  

save 60 10000

 RDB的其它配置也可以在redis.conf文件中设置：

RDB方式bgsave的基本流程？

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

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

1. 默认是服务停止时。
2. 代表60秒内至少执行1000次修改则触发RDB

RDB的缺点？

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

1.2 AOF持久化

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在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 

配置项	刷盘时机	优点	缺点
Always	同步刷盘	可靠性高，几乎不丢数据	性能影响大
everysec	每秒刷盘	性能适中	最多丢失1秒数据
no	操作系统控制	性能最好	可靠性较差，可能丢失大量数据

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

 # AOF文件比上次文件 增长超过多少百分比则触发重写

auto-aof-rewrite-percentage 100

# AOF文件体积最小多大以上才触发重写

auto-aof-rewrite-min-size 64mb

	RDB	AOF
持久化方式	定时对整个内存做快照	记录每一次执行的命令
数据完整性	不完整，两次备份之间会丢失	相对完整，取决于刷盘策略
文件大小	会有压缩，文件体积小	记录命令，文件体积很大
宕机恢复速度	很快	慢
数据恢复优先级	低，因为数据完整性不如AOF	高，因为数据完整性更高
系统资源占用	高，大量CPU和内存消耗	低，主要是磁盘IO资源 但AOF重写时会占用大量CPU和内存资源
使用场景	可以容忍数分钟的数据丢失，追求更快的启动速度	对数据安全性要求较高常见

 二、Redis主从

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

可以从以下几个方面来优化Redis主从就集群：

1. 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。
2. Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
3. 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
4. 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

 

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

1. 全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。
2. 增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave

什么时候执行全量同步？

1. slave节点第一次连接master节点时
2. slave节点断开时间太久，repl_baklog中的offset已经被覆盖时

什么时候执行增量同步？

1. slave节点断开又恢复，并且在repl_baklog中能找到offset时

三、Redis哨兵

3.1 哨兵的作用和原理

 

3.1.1 哨兵作用：

1. 监控：Sentinel 会不断检查您的master和slave是否按预期工作
2. 自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主
3. 通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

1. 主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
2. 客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

3.1.2选举新的master

一旦发现master故障，sentinel需要在salve中选择一个作为新的master，选择依据是这样的：

1. 首先会判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds * 10）则会排除该slave节点
2. 然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举
3. 如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高
4. 最后是判断slave节点的运行id大小，越小优先级越高。

 3.1.3 如何实现故障转移

1. sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为master
2. sentinel给所有其它slave发送slaveof 192.168.150.101 7002 命令，让这些slave成为新master的从节点，开始从新的master上同步数据。
3. 最后，sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点

3.1.4 总结

Sentinel的三个作用是什么？

监控 故障转移 通知

Sentinel如何判断一个redis实例是否健康？

1. 每隔1秒发送一次ping命令，如果超过一定时间没有相向则认为是主观下线
2. 如果大多数sentinel都认为实例主观下线，则判定服务下线

故障转移步骤有哪些？

1. 首先选定一个slave作为新的master，执行slaveof no one
2. 然后让所有节点都执行slaveof 新master
3. 修改故障节点配置，添加slaveof 新master

 

3.2 搭建哨兵集群

3.3 RedisTemplate的哨兵模式

在Sentinel集群监管下的Redis主从集群，其节点会因为自动故障转移而发生变化，Redis的客户端必须感知这种变化，及时更新连接信息。Spring的RedisTemplate底层利用lettuce实现了节点的感知和自动切换。

3.3.1 在pom文件中引入redis的starter依赖：

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>

3.3.2然后在配置文件application.yml中指定sentinel相关信息：

spring:
  redis:
    sentinel:
      master: mymaster
      nodes:
        - 192.168.150.101.27001
        - 192.168.150.101.27002
        - 192.168.150.101.27003

3.3.3 配置主从读写分离

    @Bean
    public LettuceClientConfigurationBuilderCustomizer configurationBuilderCustomizer(){
        return configBuilder -> configBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);
    }

这里的ReadFrom是配置Redis的读取策略，是一个枚举，包括下面选择：

1. MASTER：从主节点读取
2. MASTER_PREFERRED：优先从master节点读取，master不可用才读取
3. replica REPLICA：从slave（replica）节点读取
4. REPLICA _PREFERRED：优先从slave（replica）节点读取，所有的slave都不可用才读取master

四、Redis分片集群

4.1分片集群结构

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

1. 海量数据存储问题
2. 高并发写的问题

使用分片集群可以解决上述问题，分片集群特征：

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

4.2 散列插槽

Redis会把每一个master节点映射到0~16383共16384个插槽（hash slot）上

 Redis如何判断某个key应该在哪个实例？

1. 将16384个插槽分配到不同的实例
2. 根据key的有效部分计算哈希值，对16384取余
3. 余数作为插槽，寻找插槽所在实例即可

如何将同一类数据固定的保存在同一个Redis实例？

这一类数据使用相同的有效部分，例如key都以{typeId}为前缀

 4.3 集群伸缩