分布式缓存（redis）

最新推荐文章于 2024-07-18 16:23:00 发布

啵萝蜜多斩

最新推荐文章于 2024-07-18 16:23:00 发布

阅读量123

点赞数

分类专栏： redis 文章标签：缓存 redis 分布式

本文链接：https://blog.csdn.net/oybc666/article/details/128942774

版权

redis 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

文章详细介绍了Redis的两种持久化方案：RDB（数据快照）和AOF（追加文件），以及它们的优缺点和执行机制。此外，还讨论了Redis的主从架构和数据同步过程，包括全量同步和增量同步，以及哨兵系统在监控和故障恢复中的作用。最后，提到了缓存问题，如缓存穿透、缓存击穿和缓存雪崩，及其解决方案。

摘要由CSDN通过智能技术生成

Redis 持久化的方案

1、RDB 持久化

-- RDB ( Redis Database Backup file) redis 数据备份文件
也叫数据快照，即将缓存数据写入到磁盘，当 redis 重启后，会重新加载这些数据，存储数据的文件就是 RDB，存储在redis 的运行目录下

-- 执行时机
① 执行 save 命令（命令执行时，其他所有的命令都会阻塞，直到该命令执行完毕）
② 执行 bgsave 命令（ bg 是后台运行，不会影响其他命令，是开启了子线程做处理）
③ redis 停机时
④ 触发 RDB 条件时（机制保存在redis.conf 文件中）👇

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

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

# RDB文件名称
dbfilename dump.rdb  

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

-- RDB方式bgsave的基本流程？

①， fork主进程得到一个子进程，共享内存空间

②，子进程读取内存数据并写入新的RDB文件

③，用新RDB文件替换旧的RDB文件

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

①，默认是服务停止时

②，代表60秒内至少执行1000次修改则触发RDB

-- RDB的缺点？

①，RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险

②，fork子进程、压缩、写出RDB文件都比较耗时

2、AOF 持久化

AOF : Append Only File (追加文件) ，redis 处理的每一个写命令都会记录到 AOF 文件中，相当于一份操作日志
由于是记录操作，容易造成历史无意义操作浪费资源，所以需要做重写处理，
可以通过手动操作命令 bgrewriteaof 重写，也可以配置阈值自动重写

AOF 默认关闭，需要在 redis.conf 中配置开启

    # 是否开启AOF功能，默认是no

appendonly yes

    # AOF文件的名称

appendfilename "appendonly.aof"


# 表示每执行一次写命令，立即记录到AOF文件 
#（同步刷盘，可靠性高，几乎不丢失数据，性能影响大）

appendfsync always 

# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
# （每秒刷盘，性能始终，最多丢失1秒数据）

appendfsync everysec 

# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
# （操作系统控制，性能最好，可靠性较差，可能丢失大量数据）

appendfsync no

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

auto-aof-rewrite-percentage 100

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

auto-aof-rewrite-min-size 64mb

RDB 和 AOF 对比

Redis 集群（主从架构）

目的在于提高 redis 的并发能力，实现读写分离

数据同步

全量同步：对全部数据同步（master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。）
增量同步：同步master和slave存在差异的数据，一般是首次全量同步之后才用的方式（slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave ）
偏移量： offset ，指的是 slave 落后于 master 的数据，也是slave 即将要同步的数据

主从第一次建立连接时，会执行全量同步，将master节点的所有数据都拷贝给slave节点，
replid 是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid

什么时候执行全量同步？

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

什么时候执行增量同步？

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

同步流程：

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

主从同步优化

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

哨兵 Sentinel

作用：监控，哨兵会通过不断地 ping master 和 slave 是否正常运行
自动故障恢复，如果master 出现故障，哨兵会选择一个 slave 变成新的master，在此之后，如果旧的master恢复，旧的master会变成slave
通知，哨兵充当客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给redis客户端

主观下线：一个哨兵发现某个redis实例没及时响应

客观下线：多个哨兵（最好是一半）发现同一个实例下线

集群故障恢复原理

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

选出新的 master 之后，执行如下流程：

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

项目中配置哨兵集群
yml 中配置:

 spring:
  redis:
    sentinel:
      master: mymaster
      nodes:
        - 192.168.150.101:27001
        - 192.168.150.101:27002
        - 192.168.150.101:27003

可以在启动类中配置bean

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

ReadFrom.REPLICA_PREFERRED : 读写策略
其包括：