本文主要是介绍持久化、主从 、分片、哨兵，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
持久化
RDB（存数据）
使用场景
bgsave
使用方法
原理
AOF（存命令）
使用方法
原理
bgrewriteaof
AOF和RDB
主从集群
搭建
数据同步原理(slave宕机）
全量同步
增量同步
集群优化
总结
哨兵机制（master宕机）
机制
监控
自动故障恢复
通知
搭建哨兵集群
RedisTemplate的哨兵模式
分片集群
搭建
持久化
RDB（存数据）
RDB全称Redis Database Backup file(Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。
快照文件称为RDB文件，默认是保存在当前运行目录。
使用场景
在进行大量读写操作修改数据后，若Redis服务宕机则数据丢失；但是采取RDB即修改一部分数据后进行持久化到磁盘可避免数据丢失。
bgsave
使用方法
在redis.conf文件中找到：
#900秒内，如果至少有1个key被修改，则执行bgsave即RDB，如果是save ""则表示禁用RDB
save 900 1bgsave是在保存数据时新开线程不影响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 64mbAOF和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:270033.配置主从读写分离(启动类）
@Bean
public LettuceClientConfigurationBuilderCustomizer configurationBuilderCustomizer(){return configBuilder -> configBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);
} 
分片集群
分片集群就是多个主从集群。
主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：
• 海量数据存储问题
• 高并发写的问题
使用分片集群可以解决上述问题，分片集群特征：
• 集群中有多个master，每个master保存不同数据
• 每个master都可以有多个slave节点
• master之间通过ping监测彼此健康状态
• 客户端请求可以访问集群任意节点，最终都会被转发到正确节点
搭建
📎Redis集群.md
高级篇-分布式缓存-14-Redis分片集群-散列插槽_哔哩哔哩_bilibili
这篇关于持久化、主从 、分片、哨兵的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
