Redis分布式缓存高级篇笔记 - 详细版

第一章：Redis持久化

1.1 RDB（Redis Database Backup）持久化详解

1.1.1 RDB基本概念

RDB的英文全称是Redis Database Backup File，也就是Redis的数据备份文件，也被称为数据快照。RDB的工作原理是将内存中的数据写入磁盘，形成快照文件。对于Redis来说，它的内存数据被备份写到磁盘上，这个磁盘中的数据就是一个备份，或者叫做快照。将来Redis一旦重启或发生故障，我们都可以从快照里去读取数据。

RDB方式比较适合在Redis运行的过程中去做持久化，尤其是当服务即将停机时进行备份。这种方案默认就已经开启了，它会在服务器停机那一刻就去触发一次save，完成一次持久化。

1.1.2 RDB工作原理

RDB的保存过程如下：

在Redis退出前，会执行一次RDB的保存操作
将当前内存中的数据保存为RDB文件
文件保存完成后，才正式退出Redis服务

RDB的文件叫快照文件，也叫RDB文件，默认保存在当前运行目录，也就是在哪个目录运行Redis，它就保存在哪里。RDB文件恢复数据的原理是：在Redis重启时，自动读取RDB文件并将数据加载到内存中。

1.1.3 RDB触发方式

RDB有多种触发方式：

手动触发方式：

SAVE命令：由Redis主进程执行，会阻塞Redis，使Redis无法处理其他请求
BGSAVE命令：在后台异步执行，由子进程完成RDB备份，主进程不受影响

自动触发方式：
在Redis配置文件中设置触发条件，如：

save 900 1：900秒内至少有1个key被修改，则执行BGSAVE
save 300 10：300秒内至少有10个key被修改，则执行BGSAVE
save 60 10000：60秒内至少有10000个key被修改，则执行BGSAVE

1.1.4 RDB配置详解

在Redis配置文件(redis.conf)中，可以对RDB进行详细配置：

文件名配置：

dbfilename dump.rdb：指定RDB文件的名称
dir ./: 指定RDB文件保存的目录

触发条件配置：

save 900 1：900秒内至少1次修改
save 300 10：300秒内至少10次修改
save 60 10000：60秒内至少10000次修改

压缩配置：

rdbcompression yes/no：是否对RDB文件进行压缩
- 压缩的优点：节省磁盘空间
- 压缩的缺点：消耗CPU资源
- 通常不推荐开启压缩，因为磁盘成本较低，而CPU资源更宝贵

1.1.5 RDB优缺点

优点：

文件较小，适合备份
恢复速度快
适合灾难恢复场景

缺点：

数据安全性相对较低，可能会丢失最后一次快照后的数据
在执行SAVE命令时会阻塞Redis服务
如果数据量很大，RDB的执行时间会较长

1.1.6 RDB适用场景

定期备份数据
灾难恢复
Redis服务停机前的数据保存
对数据丢失容忍度较高的场景

1.2 AOF（Append Only File）持久化详解

1.2.1 AOF基本概念

AOF的全称叫Append Only File，代表的是追加文件。AOF持久化的方式是把Redis接收到的所有写操作命令追加到一个文件当中，这个文件就叫做AOF文件。因为它是不断地记录新的命令，而不是像RDB那样每次都从头开始把整个内存都写一次，所以这种文件是逐渐累加的过程，因此叫追加文件。

AOF本质上是一个命令日志文件，记录的是Redis执行的写命令。例如当执行set number 123时，首先会把number 123记录到Redis的内存结构里，然后还会把这个命令写到AOF文件当中。AOF文件的格式包含了命令及其参数，例如set number 123，其中的$3表示命令中包含的字符长度。

当Redis出现故障需要恢复数据时，只需要读取AOF文件，把里面的命令从头开始一个一个再执行一遍，数据就能恢复到原始状态。

1.2.2 AOF配置

AOF方式默认是关闭的，需要手动开启。开启方式是修改Redis配置文件，在配置文件中有一个叫appendonly的配置项，默认值是no，需要把它改成yes来开启AOF方式。

AOF文件的名称通过appendfilename配置项指定，默认文件名是appendonly.aof。

1.2.3 AOF刷盘策略

AOF有三种不同的刷盘频率：

1. Always（同步刷盘）

每当Redis接收到一个命令时，立即把数据写到内存，同时把命令写入AOF文件
由Redis主进程完成，接收到命令后先操作内存，再写磁盘
数据安全性最高，基本上不会出现数据丢失
性能最差，因为每次都要同步刷盘

2. Everysec（每秒刷盘）

主进程接收到Redis命令时，不会立即写入磁盘，而是先处理内存数据
把命令放到AOF缓冲区，每隔一秒钟把缓冲区中的数据一次性写到AOF文件
性能比Always方式好很多，因为主进程只负责往缓冲区写，不负责往磁盘写
最多会丢失一秒钟内的所有操作
属于可靠性和性能之间的折中方案，是默认采用的方案

3. No（系统控制）

Redis主进程只负责处理内存数据，然后写到AOF缓冲区
至于往磁盘写入由操作系统控制
系统会定期把AOF写到磁盘，频率往往比较低
性能最好，但安全性最差
一般不推荐使用

三种方案对比：

Always：可靠性最好，性能最差
No：性能最好，可靠性最差
Everysec：性能适中，最多丢失一秒数据，是推荐方案

1.2.4 AOF文件重写

AOF文件会随着写操作的增多而不断增大，因为记录的是所有命令，即使是对同一个key的多次操作也会全部记录下来。例如对number执行set number 123、set name jack、set number 666，实际上只有最终的number 666和name jack有意义，前面的操作都是多余的。

为了解决AOF文件体积过大的问题，以及对同一个key多次操作只有最后一次有意义的问题，AOF提供了BGREWRITEAOF命令，可以对AOF文件做重写。

AOF重写的作用：

尽可能用最少的命令达到相同的效果
减少AOF文件的体积
例如把set number 123、set name jack、set number 666合并为mset name jack number 666

AOF重写是后台异步执行的，通过开启独立进程完成，不影响主进程处理请求。

AOF自动重写的触发条件：

auto-aof-rewrite-min-size：AOF文件大小超过指定值（如64MB）时触发重写
auto-aof-rewrite-percentage：AOF文件体积相比上次重写增加了指定百分比（如100%，即翻倍）时触发重写

1.2.5 AOF优缺点

优点：

数据安全性更高，丢失数据的概率更低
AOF文件可读性较好，记录的是命令
可以通过AOF重写优化文件大小

缺点：

AOF文件通常比RDB文件大很多
恢复数据的速度相对较慢
存在潜在的BUG风险（因为AOF是通过命令重放恢复数据）

1.2.6 AOF适用场景

对数据安全性要求较高的场景
需要尽可能减少数据丢失的场景
需要可读性较好的持久化文件的场景

第二章：Redis主从集群

2.1 主从集群概述

2.1.1 主从集群的作用

Redis主从集群主要作用包括：

数据冗余：通过主从复制实现数据的备份
读写分离：主节点负责写操作，从节点负责读操作，分担主节点压力
高可用性：当主节点出现故障时，可以手动或自动切换到从节点继续提供服务

2.1.2 主从集群结构

主节点（Master）：负责写操作和数据变更
从节点（Slave/Replica）：负责读操作，从主节点同步数据
数据从主节点流向从节点，实现单向复制

2.2 主从集群搭建

2.2.1 搭建准备工作

创建多个目录：为每个Redis实例创建独立的目录，便于管理，如7001、7002、7003
准备配置文件：每个实例都需要独立的配置文件，确保运行时不相互干扰
恢复原始配置：在搭建集群前，将配置文件恢复到原始状态，通常开启RDB模式，关闭AOF模式

2.2.2 配置文件修改

对每个实例的配置文件需要进行以下修改：

端口配置：将默认的6379端口修改为对应实例的端口（如7001、7002、7003）
工作目录：将数据保存目录修改为对应实例的目录
绑定IP：设置replicate-announce-ip指定实例的IP地址，确保集群内通信正常

使用sed命令可以批量修改配置文件：

# 批量修改端口和工作目录
sed -i 's/6379/7001/g' ./7001/redis.conf
sed -i 's/dir .\//dir \/tmp\/7001\//g' ./7001/redis.conf

# 添加绑定IP配置
sed -i '1a replica-announce-ip 127.0.0.1' ./7001/redis.conf

2.2.3 启动Redis实例

分别启动：在不同终端或使用后台进程启动各个Redis实例
指定配置文件：启动时指定对应的配置文件，如redis-server ./7001/redis.conf
验证启动：确认所有实例均已成功启动

2.2.4 配置主从关系

主从关系有两种配置方式：

临时配置方式（使用命令）：

连接到从节点：redis-cli -p 端口号
执行配置命令：slaveof 或 replicaof 主节点IP 主节点端口
特点：重启后失效

永久配置方式（修改配置文件）：

在从节点的配置文件中添加：slaveof 或 replicaof 主节点IP 主节点端口
特点：重启后仍然有效

Redis 5.0之前使用slaveof命令，5.0及以后推荐使用replicaof命令。

2.3 主从同步原理

2.3.1 同步过程

连接建立：从节点连接主节点
全量同步：从节点首次连接时，主节点会执行BGSAVE生成RDB文件，传输给从节点
命令传播：主节点将后续的写命令实时发送给从节点执行

2.3.2 同步类型

全量同步：从节点初次连接或断线重连时进行，同步全部数据
增量同步：基于repl_backlog_buffer实现，同步断线期间的命令

2.3.3 主从集群验证

通过执行info replication命令可以查看集群状态信息，确认主节点和从节点的关系及状态。

2.4 主从集群优缺点

2.4.1 优点

实现数据备份，提高数据安全性
支持读写分离，提高系统吞吐量
架构相对简单，易于理解和维护

2.4.2 缺点

故障时需要手动切换，无法自动恢复
主节点故障时写服务中断
存在数据延迟，从节点数据可能不是最新

第三章：Redis哨兵机制

3.1 哨兵机制概述

3.1.1 哨兵机制的作用背景

在主从集群中，如果从节点发生宕机，通常不用担心，因为从节点重启后可以从主节点完成数据同步。但如果宕机的是主节点，情况就复杂了。虽然如果做了主节点的数据持久化，重启后数据不会丢失，但问题在于：

主节点宕机期间，用户无法执行写操作
重启和数据恢复过程中，写服务仍然中断
集群的可用性大大降低

为了解决这个问题，需要一个机制来监控集群中的节点状态，当发现主节点宕机时，立即选择一个新的从节点作为主节点，实现自动故障切换，这就是Redis哨兵机制的作用。

3.1.2 哨兵的基本概念

Redis哨兵（Sentinel）是一个分布式系统，用于监控Redis主从集群的状态。哨兵本身也是一个集群，避免单点故障。哨兵的主要作用包括：

监控集群中每个节点的健康状态
当节点出现故障时自动进行故障恢复
向客户端通知节点地址变更

3.2 哨兵机制的作用

3.2.1 监控（Monitoring）

哨兵会持续监控集群中的所有节点，包括主节点和从节点，检查它们是否正常运行。哨兵会定期向每个节点发送PING命令，如果节点正常，会返回PONG响应。

3.2.2 故障恢复（Automatic Failover）

当哨兵检测到主节点故障时，会自动执行以下操作：

从现有的从节点中选择一个提升为新的主节点
通知其他从节点，让它们改为复制新的主节点
修改故障原主节点的配置，让它在恢复后成为新主节点的从节点

3.2.3 通知（Notification）

当主从切换发生时，哨兵会通知客户端节点地址发生了变更。客户端可以通过哨兵获取最新的主从节点地址信息，哨兵在此扮演了服务发现的角色。

3.3 哨兵工作机制

3.3.1 心跳机制

哨兵基于心跳机制来监测服务状态：

每隔一秒向集群中的每个实例发送PING命令
如果实例能响应PONG，证明它是正常的
如果超过一定时间没有响应，哨兵会认为该实例是主观下线

3.3.2 主观下线与客观下线

主观下线（Subjective Down）：单个哨兵认为某个实例下线
- 原因可能是网络阻塞导致超时未响应
- 单个哨兵的判断，不一定准确
客观下线（Objective Down）：多个哨兵共同认为某个实例下线
- 需要超过指定数量的哨兵都认为该实例主观下线
- 通过投票机制实现，通常是哨兵数量的一半以上
- 一旦判定为客观下线，就会触发故障转移

3.3.3 故障转移过程

当主节点被判定为客观下线后，哨兵会执行以下故障转移步骤：

选举新的主节点：
- 排除与原主节点断开时间过长的从节点（数据过旧）
- 按照以下优先级顺序选择新的主节点：
  - slave-priority值最小的从节点
  - 如果priority相同，则选择offset最大的从节点（数据最新）
  - 如果offset也相同，则选择runID最小的从节点
向选中的从节点发送SLAVEOF NO ONE命令：
- 让该从节点脱离原主节点，成为独立的主节点
- "NO ONE"表示不再从任何节点同步数据
通知其他从节点：
- 向其他从节点发送SLAVEOF命令，让它们复制新的主节点
- 广播新主节点的信息
处理原主节点：
- 修改原主节点的配置文件，将其标记为新主节点的从节点
- 当原主节点恢复后，会自动成为新主节点的从节点

3.4 哨兵配置要点

3.4.1 quorum配置

quorum参数定义了判断主节点客观下线所需的哨兵数量。通常配置为哨兵实例数量的一半加1，以确保决策的准确性。

3.4.2 down-after-milliseconds配置

该参数定义了哨兵认为节点主观下线所需的时间阈值，单位为毫秒。

3.4.3 parallel-syncs配置

该参数控制在故障转移后，同时向新主节点同步数据的从节点数量，避免对新主节点造成过大压力。

3.5 哨兵机制优缺点

3.5.1 优点

实现自动故障转移，提高系统可用性
提供服务发现功能，客户端可以获取最新节点信息
哨兵集群本身具有高可用性

3.5.2 缺点

配置相对复杂
在故障转移过程中可能存在短暂的服务不可用
需要额外的资源运行哨兵进程

第四章：Redis分片集群

4.1 分片集群概述

4.1.1 分片集群的产生背景

主从集群和哨兵机制虽然解决了高并发读和故障恢复问题，但仍存在以下局限性：

为提高主从同步性能，单机Redis内存不宜设置过高
内存占用过多会导致RDB持久化和全量同步时IO性能下降
单机内存受限（如10-20G）无法满足海量数据存储需求
高并发写操作仍受单主节点限制

分片集群正是为解决这些问题而设计的，能够应对海量数据存储和高并发读写的需求。

4.1.2 分片集群的特点

多主结构：集群中有多个主节点，每个主节点保存不同数据
数据分散：通过多个主节点分担数据存储，理论存储上限取决于主节点数量
并发提升：多个主节点可同时处理写操作，提升并发写能力
主从结合：每个主节点仍可配置从节点，兼具主从集群的读能力
自我监控：主节点间通过心跳互相监测，具备类似哨兵的功能
智能路由：客户端可访问集群中任意节点，请求会被自动路由到正确节点

4.2 分片集群搭建

4.2.1 搭建准备工作

创建多个目录：为每个Redis实例创建独立目录，如7001、7002、7003、8001、8002、8003
清理旧配置：删除之前的配置文件，避免干扰
准备配置文件：为每个实例创建集群模式的配置文件

4.2.2 集群配置文件关键参数

# 启用集群模式
cluster-enabled yes

# 集群配置文件（由Redis内部维护，只需指定位置）
cluster-config-file nodes-端口号.conf

# 集群节点超时时间
cluster-node-timeout 5000

# 数据目录
dir /tmp/端口号/

# 绑定IP地址
bind 0.0.0.0

# 后台运行
daemonize yes

# 声明节点IP
replica-announce-ip 127.0.0.1

# 关闭保护模式
protected-mode no

# 数据库数量
databases 1

# 日志文件
logfile /tmp/端口号/redis.log

4.2.3 启动集群节点

使用后台模式启动所有节点：

redis-server ./7001/redis.conf
redis-server ./7002/redis.conf
redis-server ./7003/redis.conf
redis-server ./8001/redis.conf
redis-server ./8002/redis.conf
redis-server ./8003/redis.conf

4.2.4 创建集群

使用Redis 5.0+内置的集群创建命令：

redis-cli --cluster create 
7001_ip:7001 7002_ip:7002 7003_ip:7003 
8001_ip:8001 8002_ip:8002 8003_ip:8003 
--cluster-replicas 1

参数说明：

--cluster-replicas 1：指定每个主节点的从节点数量为1
系统会自动将前3个节点作为主节点，后3个作为从节点

4.2.5 集群状态验证

使用以下命令查看集群状态：

redis-cli -p 7001 cluster nodes

4.3 散列插槽机制

4.3.1 插槽分配原理

插槽数量：Redis集群将整个数据空间划分为0-16383，共16384个插槽
分配方式：每个主节点分配一部分插槽，所有主节点的插槽集合覆盖整个范围
数据定位：根据key计算出插槽值，确定数据存储在哪个节点

4.3.2 插槽计算方法

确定有效部分：
- 如果key包含大括号{}且内部至少有一个字符，则{}内的内容为有效部分
- 否则整个key为有效部分
计算插槽值：
- 对有效部分使用CRC16算法计算哈希值
- 将哈希值对16384取模：CRC16(key) % 16384
- 结果即为插槽值，范围在0-16383之间

4.3.3 插槽的优势

数据绑定：数据与插槽绑定而非与节点绑定
灵活迁移：当节点故障或集群伸缩时，插槽可在节点间迁移
动态调整：支持集群的动态扩容和缩容

4.3.4 集群伸缩

扩容：添加新节点，将部分插槽从现有节点迁移到新节点
缩容：将待下线节点的插槽迁移到其他节点，再删除节点

4.3.5 插槽机制的验证与测试

在集群模式下访问Redis需要使用-c参数：

redis-cli -p 7001 -c

当执行操作时，如果当前节点不是目标节点，会返回MOVED重定向信息：

-> Redirected to slot [slot_number] located at [node_address]

通过这种方式可以验证插槽的分配和路由机制。

4.3.6 数据分布控制策略

通过合理设计key的格式，可以控制数据的分布：

统一类型数据集中存储：使用{type_id}:item_id格式，相同type_id的数据会存储在同一节点
减少跨节点查询：将相关联的数据放在同一节点，避免跨节点操作
避免热点问题：合理设计key，避免数据过度集中

4.3.7 插槽机制的优势

灵活性：支持动态的集群伸缩，数据跟随插槽迁移
负载均衡：通过插槽均匀分布，实现数据和请求的均衡分布
高可用性：插槽可在主从节点间迁移，保证数据的可用性
可预测性：通过key可以计算出数据所在节点，便于定位和管理

4.4 集群伸缩

4.4.1 添加节点

添加节点使用redis-cli的cluster add-node命令：

redis-cli --cluster add-node 
<new_node_ip>:<new_node_port> 
<existing_node_ip>:<existing_node_port>

参数说明：

<new_node_ip>:<new_node_port>：新节点的IP和端口
<existing_node_ip>:<existing_node_port>：集群中已存在节点的IP和端口

添加从节点时可使用额外参数：

--cluster-slave：指定新节点作为从节点
--cluster-master-id <master_id>：指定从节点对应的主节点ID

4.4.2 分配插槽

添加新主节点后，需要将部分插槽从现有节点迁移到新节点：

使用redis-cli --cluster reshard命令进行插槽重新分片
指定接收插槽的新节点ID
指定要迁移的插槽数量
选择源节点（可指定all平均分配或指定具体节点）

4.4.3 移除节点

移除节点前需要先将该节点上的插槽迁移到其他节点，然后使用cluster forget <node_id>命令从集群中移除节点。

4.5 故障转移

4.5.1 自动故障转移

当主节点宕机时，Redis集群会自动执行故障转移：

其他节点检测到主节点失联
将该节点标记为失败状态
选择对应的从节点提升为主节点
通知集群中其他节点更新节点状态
原主节点恢复后自动成为新主节点的从节点

4.5.2 手动故障转移

手动故障转移用于有计划的节点维护或升级，通过在从节点上执行CLUSTER FAILOVER命令实现：

默认模式：执行完整的故障转移流程，确保数据一致性
FORCE模式：跳过数据一致性校验，强制执行故障转移
TAKEOVER模式：强制接管，忽略数据一致性和其他节点意见

手动故障转移流程：

从节点向主节点发送替换请求
主节点拒绝新的客户端请求
主从节点校验数据偏移量(offset)是否一致
数据同步完成后执行角色切换
新主节点向集群广播角色变更信息

4.6 分片集群应用场景

4.6.1 海量数据存储

通过多主节点水平扩展存储容量
适用于大数据量的缓存或存储场景

4.6.2 高并发读写

多主节点并行处理读写请求
提升系统整体吞吐量

4.6.3 高可用需求

主从架构提供数据冗余
自动故障转移保证服务连续性

4.6.4 动态扩展需求

支持集群动态扩容和缩容
适应业务增长和变化

第五章：Java客户端访问分片集群

5.1 Spring Boot集成

5.1.1 依赖引入

在Spring Boot项目中访问Redis分片集群，需要引入Redis的starter依赖：

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

5.1.2 配置分片集群地址

与哨兵模式不同，分片集群需要配置集群中各节点的地址：

spring:
  redis:
    cluster:
      nodes:
        - 127.0.0.1:7001
        - 127.0.0.1:7002
        - 127.0.0.1:7003
        - 127.0.0.1:8001
        - 127.0.0.1:8002
        - 127.0.0.1:8003
    timeout: 1000ms
    lettuce:
      pool:
        max-active: 1024
        max-wait: 1000ms

5.1.3 读写分离配置

Redis分片集群天然支持读写分离：

写操作：由对应插槽的主节点处理
读操作：可在主节点或从节点处理，通过配置指定读取策略

5.2 客户端访问特点

5.2.1 智能路由

客户端可连接集群中任意节点
请求会自动路由到正确的节点
客户端维护集群拓扑结构，支持动态更新

5.2.2 插槽感知

客户端感知插槽分配情况
根据key计算插槽，直接访问目标节点
减少不必要的重定向

5.2.3 故障转移透明化

主从切换对客户端透明
客户端自动感知节点状态变化
无需应用程序干预

5.3 访问示例

5.3.1 基本操作

@Autowired
private RedisTemplate<String, Object> redisTemplate;

// 写操作会自动路由到对应插槽的主节点
redisTemplate.opsForValue().set("key", "value");

// 读操作可根据配置在主节点或从节点执行
Object value = redisTemplate.opsForValue().get("key");

5.3.2 注意事项

跨插槽操作（如MULTI/EXEC事务）受到限制
某些命令可能不支持或需要特殊处理
需要合理设计key，避免频繁跨节点操作

总结

Redis分布式缓存高级篇涵盖了多种高可用和高性能的架构方案：

持久化方案：RDB适合备份和灾难恢复，AOF提供更好的数据安全性，两者可结合使用
主从架构：实现数据冗余和读写分离，但需要手动故障转移
哨兵机制：提供自动故障转移和高可用保障
分片集群：解决海量数据存储和高并发访问问题，支持动态伸缩
客户端集成：通过Spring Boot等框架轻松集成各种Redis架构

根据业务需求选择合适的架构方案，或组合使用多种方案，可以构建出满足不同场景需求的Redis缓存架构。

4.4 集群客户端访问

4.4.1 集群模式访问

在集群模式下访问Redis需要添加-c参数：

redis-cli -p 7001 -c

4.4.2 请求路由机制

客户端可访问集群中任意节点
节点根据key计算插槽值，判断目标节点
如果当前节点不是目标节点，则返回MOVED重定向响应
客户端自动重定向到正确的节点

4.4.3 数据分布控制

通过合理设计key的格式，可以控制同一类数据存储在同一个节点：

使用大括号指定有效部分：{type_id}:item_id
相同类型的数据会被分配到同一节点
便于批量操作和减少跨节点查询

4.5 分片集群优缺点

4.5.1 优点

海量存储：通过多个主节点扩展存储容量
高并发：多主节点并行处理读写请求
高可用：主从结构和节点间互监提供高可用性
灵活扩展：支持动态扩容和缩容
自动路由：客户端透明访问，自动路由请求

4.5.2 缺点

复杂性高：配置和维护比单机或主从模式复杂
事务限制：跨插槽操作无法使用事务
数据倾斜：不当的key设计可能导致数据分布不均
运维难度：需要更多的运维知识和经验