分布式缓存-CSDN博客

[root@localhost ~]#redis-cli 127.0.0.1:6369>save   #由Redis主线程来执行RDB，会阻塞所有的命令 
127.0.0.1:6369>bgsave #由后台异步执行，开启子进程执行RDB，避免主进程收到影响
Background saving started

Reids停机时会执行一次RDB

测试

redis-server redis-6.2.4/redis.conf  
127.0.0.1:6379>redis-cli 
127.0.0.1:6379>set num 123 
127.0.0.1:6379>get num

默认在退出之前保存一次RDB

Redis内部由触发RDB的机制，可以在redis.conf文件中找到：

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

异步持久化：

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

RDB底层原理

RDB方式bgsave的基本流程：

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

RDB缺点

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

2.AOF持久化

全称为Append Only File(追加文件)

把Redis处理的每一个命令都记录到AOF文件，可以看作是日志文件

[root@localhost redis-6.2.4]redis-cli
127.0.0.1:6379>set num 123
OK

其中：$3表示输入字符的长度

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF

AOF的记录频率

# 表示每执行一次写命令，立即记录到AOF文件
appendsync alaways
#写命令执行完先放入AOF缓冲区，然后表示每隔一秒将缓冲区的数据写到AOF文件，也是默认方案
appendfsync everysec
#写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

因为将所有的命令都记录下来，会使AOF文件太大，因此，通过执行bgrewriteaof命令可以让AOF文件执行重写的功能，用最少的命令达到相同的效果。

用最少的命令达到相同的效果

RDB和AOF对比

二、Redis主从

搭建主从架构

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

开启主从关系

配置主从可以使用replicaof或者slaveof(5.0之前)命令

有临时和永久两种模式：

修改配置文件（永久生效）：
- 在redis.conf中添加一行配置：slaveof <masterip><masterport>
使用redis-cli客户端连接到redis服务，执行slaveof命令(重启后失效)：

slaveof <masterip> masterport

5.0之后新增命令replicaof，与salveof效果一致

注意：从节点只能读不能写，读写分离

假设有A、B两个Redis实例，如何让B作为A的slave节点？  
在B上执行`slaveof <Aip> Aport`

数据同步的原理

全量同步

主从第一次同步是全量同步：

1.master判断slave是不是第一次连接，是第一次全量同步(Full resync)，不是第一次，增量同步

2.如果是第一次建立连接，master把RDB文件(所有数据)发送给slave；但是由于(bgsave是异步执行的,在发送过程中master还会处理用户的请求，可能会有新的数据写入到redis但是又没有同步到RDB文件里面)RDB的间隔很大，可能在间隔期间执行了写操作，所以引入了repl_backlog文件来记录在生成和发送RDB文件的过程期间收到的新的命令。以此使slave完整的获取到master的数据。

3.RDB文件中的data+repl_baklog文件中的data就是master节点上的完整数据

master如何判断slave是不是第一次来同步数据？   
    Replication:数据集的标记，id一致则说明是同一数据集。每一个master都有一个唯一的id，slave会继承master节点的replid。   
    offset：偏移量，随着记录在repl_baklog中的数据增多而增大，slave完成同步时也会记录当前同步的offest，如果slave的offset小于master的offset,说明slave数据落后于master，需要更新。

这两个值用来判断是不是一个数据集和同步的进度。

完整的主从同步过程：

全量同步的过程：

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

增量同步

repl_baklog可以看作是一个循环数组

repl_backlog大小有上限，写满后会覆盖最早的数据，如果slave断开时间过久，导致数据被覆盖则无法实现增量同步，只能再次全量同步

优化主从集群

总结

全量同步和增量同步

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

三、Redis哨兵

为了解决master宕机的问题：因为如果slave宕机可以从master恢复数据，但是master宕机怎么同步？

解决方案：

实时监测,只要master宕机就立刻选择slave作为新master。挂掉的master恢复之后就当slave。

哨兵的作用

主从切换

监控：Sentinel会不断检查您的master和slave是否按照预期工作

自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主

通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis客户端

服务状态监控

哨兵是如何监测节点下线的？

Sentinel是基于心跳机制检测服务状态，每隔1秒就向集群发送ping命令：

主观下线：如果(单个)sentivle节点发现某实例未在规定实例内响应，则认为是主观下线

客观下线：如果超过指定数量的(多个)sentinel都认为该实例主管下线，则该实例客观下线。

选择新的master

首先判断slave与master节点断开时间长短，超过指定值（down-after-milliseconds）就排除

然后判断slave节点的slave-pripority值，越小优先级越高，如果是0永远不参加选举

如果slave-pripority一样，再看slave节点的offset（数据同步的进度），越大说明数据越新，优先级越高

最后看slave节点的运行id大小，越小优先级越高

实现故障转移

sentinel通知备选的slave节点（发送slaveof no one命令），让其成为新的master
sentinel再通知给所有的slave(发送slave of ip port命令)，让他们成为新master的从节点
最后将故障节点标记为slave，当故障节点恢复后自动成为新的master的slave节点

RedisTemplate的哨兵模式

四、Redis分片集群

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

海量数据存储问题

高并发写的问题

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

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

散列插槽

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

数据key不是和节点绑定，而是与插槽绑定。redis会根据key有效部分计算插槽值

1.key中包含{}，且{}中至少包含一个字符，{}中部分是有效部分

2.key中不包含{}，整个key都是有效部分

为什么要将数据与插槽绑定 因为redis的主节点是可能出现宕机的，或者增加删除主节点。如果数据绑定到节点，节点宕机或者被删除那数据也会跟着丢了，但是如果数据跟插槽绑定，当节点宕机时将这个节点对应的插槽转移到活着的节点，集群扩容时也可以将插槽进行转移，数据跟着插槽走永远都能找到数据的位置。

步骤：

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

如何将同一类的数据固定到同一个Redis实例中？

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

集群伸缩

添加一个节点到集群

查找命令

redis-cli --cluster help

添加节点的命令

add-node  new_host:new_port existing_host:existing_port
          --cluster-slave
          --cluster-id<arg>

难点：插槽分配

redis-cli --cluster reshard ip:port
How many slots do you want to move (from 1 to 16384)?   #想移动插槽的数量
What id the receiving node ID?                          #要接收的id
Source node #1:                                         #插槽从哪里作为数据源
Source node #1: done                                    #结束
Do you want to proceed with the proposed reshard plan(yes/no)?   #是否继续执行重新分片的计划？

故障转移

分片集群没有哨兵但是也具备故障转移的功能

查看集群节点实时状态：

[root@localhost redis]# watch redis-cli -p 7001 cluster nodes

当集群中有一个master宕机会发生什么呢？

1.首先是该实例与其他实例失去连接

2.然后是疑似宕机：

3.最后是确定下线，自动提升一个slave为新的master:

数据迁移

利用cluster failover命令可以手动让集群中某个master宕机，切换到执行cluster failover命令的这个slave节点，实现无感知的数据迁移。其流程如下：

手动的Failover支持三种不同模式：

缺省：默认的流程，如图1~6步
force：省略了对offset的一致性校验
takeover：直接执行第5步，忽略数据一致性、忽略master状态和其他master的意见

[root@localhost redis]# bin/redis-cli -p 7002
127.0.0.1:7002> cluster failover

RedisTemplate访问分片集群

1.引入redis的starter依赖

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

2.配置分片集群地址

spring:
  redis:
    cluster:
      nodes:
        - 192.168.31.181:7001
        - 192.168.31.181:7002
        - 192.168.31.181:7003
        - 192.168.31.181:8001
        - 192.168.31.181:8002
        - 192.168.31.181:8003

3.配置读写分离

    @Bean
    public LettuceClientConfigurationBuilderCustomizer configurationBuilderCustomizer(){
        return new LettuceClientConfigurationBuilderCustomizer(){
            public void customize(LettuceClientConfiguration.LettuceClientConfigurationBuilder clientConfigurationBuilder) {
                clientConfigurationBuilder.readFrom(ReadFrom.REPLICA);
            }
        };
    }