持久化、主从、分片、哨兵

最新推荐文章于 2024-07-11 21:41:59 发布

Li清水

最新推荐文章于 2024-07-11 21:41:59 发布

阅读量768

点赞数 13

分类专栏： Redis 文章标签： bootstrap 数据库前端

本文链接：https://blog.csdn.net/m0_74031434/article/details/139896953

版权

Redis 专栏收录该内容

7 篇文章 1 订阅

订阅专栏

持久化

RDB（存数据）

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

快照文件称为RDB文件，默认是保存在当前运行目录。

使用场景

在进行大量读写操作修改数据后，若Redis服务宕机则数据丢失；但是采取RDB即修改一部分数据后进行持久化到磁盘可避免数据丢失。

bgsave

使用方法

在redis.conf文件中找到：

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

bgsave是在保存数据时新开线程不影响Redis读写；而save在保存数据时Redis其他工作都要停止，其一般在关闭Redis时执行。

原理

RDB的缺点：RDB执行间隔实践长，两次RDB之间写入数据有丢失的风险（最新数据可能丢失）；在使用方法设置RDB中，若设置间隔时间（900）太短则处理还没完就要执行下一个bgsave即保存不了数据。

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

原理

将每个命令完完全全保存到AOF文件中，当出现服务宕机时，可执行AOF文件恢复数据。

AOF的缺点：因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有。

bgrewriteaof

通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

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

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

AOF和RDB

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

主从集群

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

搭建

📎Redis集群.md

数据同步原理(slave宕机）

全量同步

master如何判断slave是不是第一次来同步数据？

slave请求数据同步时，必须向master声明自己的replication id和offset，master才可以判断到底需要同步哪些数据。

Replication Id：数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid

offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

增量同步

replication id和offset一定于master相同。

集群优化

总结

哨兵机制（master宕机）

机制

作用

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

• 监控：Sentinel会不断检测master和slave是否按预期工作。

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

• 通知：新的master形成后相应地址发生改变，因此Sentinel充当Redis客户端的服务发现来源，会将地址等信息推送给Redis客户端（RedisClient）。

监控

Sentinel每隔1秒向集群的每个实例发送ping命令：

• 主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。

• 客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过sentinel实例数量的一半。

自动故障恢复

选举新的master

通知

在Sentinel集群监管下的Redis主从集群，其节点会因为自动故障转移而发生变化，Redis的客户端必须感知这种变化，及时更新连接信息。

Spring的RedisTemplate底层利用lettuce实现节点的感知和自动切换。

如何实现故障转移

搭建哨兵集群

📎Redis集群.md

RedisTemplate的哨兵模式

1.依赖

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

2.配置

spring:
    redis:
        sentinel:
            master:mymaster #指定master名称
            nodes: #指定redis-sentinel集群信息
                - 192.168.150.101:27001
                - 192.168.150.101:27002
                - 192.168.150.101:27003

3.配置主从读写分离(启动类）

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