Redis 高级篇（未完结1/3）

本文将开启redis的高级篇，这篇文章将记录高级篇的所有笔记，这是前三分之一

未完待续

目录

一、分布式缓存​编辑

1. redis持久化

1.1 RDB持久化

1.2 AOF持久化

1.3.RDB与AOF对比

2 redis主从集群

2.1搭建主从架构

2.2主从数据同步原理

2.3.主从同步优化

2.4.小结

3 redis哨兵

3.1.哨兵原理

         3.2搭建哨兵集群

3.3.RedisTemplate

                  4 redis分片集群

4.1.搭建分片集群

4.2散列插槽

​                  4.3.集群伸缩

4.4.故障转移

---

一、分布式缓存

数据丢失问题：Redis 是基于内存的数据库，若仅在内存中存储数据，一旦服务器断电、宕机 或出现其他故障，内存中的数据会全部丢失，导致业务数据的不可用。

并发能力问题：单节点 Redis 的并发处理能力有限，在高并发的读请求场景下，可能会出现性能瓶颈，无法满足业务需求。

存储能力问题：单节点 Redis 的存储容量受限于服务器的内存大小，当业务数据量不断增长，单节点的存储容量无法满足需求时，就需要扩展存储能力。

故障恢复问题：在主从集群中，如果主节点出现故障，需要手动进行故障转移，将从节点提升为主节点，这不仅效率低，还可能导致服务中断时间过长，影响业务的连续性。

1. redis持久化

1.1 RDB持久化

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

1.1.1执行时机

RDB持久化在四种情况下会执行：

• 执行save命令

• 执行bgsave命令

• Redis停机时

• 触发RDB条件时

1. save命令
   执行下面的命令，可以立即执行一次RDB：
   
   save命令会导致主进程执行RDB，这个过程中其它所有命令都会被阻塞。只有在数据迁移时可能用到。
    
2. bgsave命令
   下面的命令可以异步执行RDB：
   
   这个命令执行后会开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。
    
3. 停机时
   Redis停机时会执行一次save命令，实现RDB持久化
    

4. 触发RDB条件
   Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

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

   RDB的其它配置也可以在redis.conf文件中设置：
    

   # 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
   rdbcompression yes# RDB文件名称
   dbfilename dump.rdb  # 文件保存的路径目录
   dir ./ 

1.1.2RDB原理

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

fork采用的是copy-on-write技术：

• 当主进程执行读操作时，访问共享内存；

• 当主进程执行写操作时，则会拷贝一份数据，执行写操作。

BGSAVE 的目标是将当前内存中的数据快照写入到一个 RDB 文件中。这是一个非常耗时的磁盘 I/O 操作。

如果让主线程来做这件事，主线程在写磁盘期间将被完全阻塞，无法处理任何新的命令请求，这对于单线程的 Redis 来说是灾难性的。所以，Redis 的解决方案是：

1. 主进程（单线程） 调用 fork() 系统调用，创建一个子进程。

   • 注意：是子进程，不是子线程。这是两个不同的概念。

2. 这个子进程是父进程的一个完整副本。它会拥有与父进程完全相同的内存数据。

3. 接下来，子进程开始负责将这份内存数据写入到一个临时的 RDB 文件中。

4. 而父进程（主线程） 继续像往常一样处理客户端的命令请求。

“子进程在写数据的时候，主进程还在修改数据，那不会导致数据不一致吗？”

这就是 fork() 和操作系统的 写时复制 机制的精妙之处。

• 当 fork() 被调用时，子进程并不会立即复制父进程的全部内存。相反，它与父进程共享同一份内存页。

• 只有当父进程（或子进程）需要修改某个内存页的数据时，操作系统才会将被修改的那一页内存复制一份。这样，修改在各自的副本上进行，互不干扰。

这个过程保证了：

• 子进程看到的永远是 fork() 那一瞬间的数据快照。它就像给数据拍了一张定格照片，然后安心地把这张照片写入磁盘。无论之后数据如何变化，这张“照片”的内容是固定的。

• 主进程可以毫无阻塞地继续服务。它修改数据时，只会触发对应内存页的复制，对性能的影响降到最低。

1.2 AOF持久化

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件

1.2.1.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

1.2.2.AOF文件重写

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

如图，AOF原本有三个命令，但是`set num 123 和 set num 666`都是对num的操作，第二次会覆盖第一次的值，因此第一个命令记录下来没有意义。

所以重写命令后，AOF文件内容就是：`mset name jack num 666`

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

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

1.3.RDB与AOF对比

当我们说 Redis 是“单线程”时，我们通常指的是 处理客户端命令请求的核心网络 I/O 和键值数据操作 是由一个线程来完成的。

1.3.1线程和进程

我们先来打个比方，帮你建立直观感受：

• 进程：就像一个 独立的工厂。

  • 这个工厂有自己独立的场地、仓库、资金、员工。

  • 工厂A和工厂B之间是完全独立的，一个工厂着火了对另一个工厂没影响。

  • 它们之间想传递货物（通信），需要通过修路、用车运输（进程间通信，如管道、消息队列），比较麻烦。

• 线程：就像同一个工厂里的 不同生产线。

  • 它们共享同一个工厂的场地、同一个仓库、同一笔资金。

  • 生产线A和生产线B可以随时从仓库里拿原料，沟通非常方便（直接读写共享内存）。

  • 但如果它们同时要抢最后一份原料，就会出问题（需要“锁”来协调）。

  • 一条生产线着火了，可能把整个工厂都烧掉（一个线程崩溃，整个进程可能崩溃）。

---

技术上的区别

现在我们从技术角度来看看它们的区别：

特性	进程	线程
基本定义	资源分配的独立单位	CPU调度的基本单位
内存空间	拥有独立的虚拟内存空间（代码、数据、堆栈）	共享 其所属进程的虚拟内存空间
资源开销	创建、销毁、切换开销大	创建、销毁、切换开销小（被称为“轻量级进程”）
独立性	非常独立，一个进程崩溃通常不影响其他进程	不独立，一个线程崩溃可能导致整个进程崩溃
数据共享	共享数据复杂，需要进程间通信	共享数据简单方便（直接读写全局变量），但需要加锁同步
通信机制	管道、消息队列、共享内存、信号量等	直接读写进程的全局变量、堆内存等（需同步）

回到 Redis 的 BGSAVE 和“子进程”

现在你就能明白为什么 Redis 要用 子进程，而不是子线程了。

1. 为什么不用子线程？

如果 BGSAVE 用一个子线程来做：

• 共享内存：子线程和主线程共享同一片内存数据。

• 数据一致性难题：主线程在不断修改数据（比如 SET、DEL），而子线程在遍历内存写文件。这就像你在一边翻书，我同时在一边修改书的内容，你拍出来的“照片”（RDB文件）内容可能是混乱的、不一致的。

• 需要复杂的锁：为了保证快照的一致性，主线程在子线程工作期间可能需要对所有数据操作加锁，这会让 Redis 的高性能瞬间消失，完全违背了设计初衷。

• 稳定性风险：如果子线程在写 RDB 时发生致命错误（如内存访问越界），可能会导致整个 Redis 进程崩溃。

2. 为什么用子进程就完美？

Redis 使用 fork() 创建子进程，完美地解决了上述所有问题：

• 获得数据快照：通过 写时复制，子进程看到的就是 fork() 发生那一瞬间的内存数据。这是一个完美的、静止的“照片”。

• 主进程无阻塞：主进程可以继续自由地处理命令、修改数据。它修改时，会触发对应内存页的复制，这个开销远小于全程加锁。

• 天然的隔离性：子进程是一个独立的“工厂”。即使它在写 RDB 文件时发生严重错误而崩溃，也不会影响到主进程这个“工厂”。主进程会继续稳定地服务客户端。

1.3.2对比：

操作	执行者	原理
RDB (BGSAVE)	子进程	将内存快照直接序列化为二进制文件
AOF 日常写入	主线程	将命令追加到文件末尾
AOF 重写	子进程	基于内存快照生成最小命令集

为什么日常写入用主线程？

• 操作简单：只是命令追加

• 开销小：主要是内存和文件追加操作

• 实时性：保证命令立即记录

为什么重写要用子进程？

• 避免阻塞：重写需要遍历所有数据并生成新文件，耗时较长

• 数据一致性：通过 fork + 写时复制获得一致的数据快照

• 进程隔离：即使重写过程出错，也不会影响主进程服务

特性	RDB	AOF
持久化方式	定时生成数据快照	实时记录每个写命令
数据安全性	可能丢失最后一次快照后的所有数据	最多丢失1秒数据（默认配置）
恢复速度	快（直接加载二进制文件）	慢（需要重新执行所有命令）
文件大小	小（二进制压缩）	大（文本格式，累积命令）
性能影响	fork子进程时可能有短暂阻塞	持续写入，对性能影响更平滑
灾难恢复	快照可能不完整/已损坏	可通过redis-check-aof修复
配置复杂度	简单（设置保存间隔）	相对复杂（同步策略、重写）
系统资源占用	高，大量cpu和内存消耗	低，主要是磁盘io资源，但aof重写时会占用大量cpu内存资源
使用场景	可以容忍数分钟的数据丢失，追求更快的启动速度	对数据安全性要求高

RDB工作流程

text

主进程 → fork() → 子进程 → 将内存数据写入临时RDB文件 → 替换旧RDB文件↓
继续处理命令        （写时复制保证数据一致性）

触发条件：

• 自动：save 900 1 (15分钟内有至少1个键变化)

• 手动：SAVE（阻塞）或 BGSAVE（后台）

AOF工作流程

text

接收SET key value → 执行命令 → 追加"*3\r\n$3\r\nSET\r\n$3\r\nkey\r\n$5\r\nvalue\r\n"到AOF缓冲区↓
根据配置同步到磁盘（always/everysec/no）

同步策略：

• appendfsync always：每个命令都同步，最安全但最慢

• appendfsync everysec：每秒同步，平衡安全与性能（默认）

• appendfsync no：由操作系统决定，最快但最不安全

2 redis主从集群

2.1搭建主从架构

2.2主从数据同步原理

2.2.1.全量同步

主从第一次建立连接时，会执行全量同步，将master节点的所有数据都拷贝给slave节点，流程：

在 Redis 的主从同步中，Master 判断 Slave 是否为第一次连接，主要通过Slave 发送的 replication ID（复制 ID）和 offset（偏移量） 来实现。

Slave 首次连接时的标识
当 Slave 是第一次连接 Master 时，它没有保存任何来自该 Master 的复制信息，因此会在同步请求中发送：

• 一个特殊的 replication ID
• 简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
• offset
• 偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

Master 的判断逻辑
Master 收到 Slave 的连接请求后，会检查这两个参数：

• 若发现 Slave 发送的 replication ID 与自身当前的 replication ID 不匹配，或 offset 为-1，则判定该 Slave 是首次连接或需要重新全量同步。
• 此时 Master 会触发全量同步：生成 RDB 文件，发送给 Slave，同时记录后续的写命令（repl_backlog），待 Slave 加载完 RDB 后，再发送增量命令。

因此，master判断一个节点是否是第一次同步的依据，就是看replid是否一致。

完整流程描述：

• slave节点请求增量同步

• master节点判断replid，发现不一致，拒绝增量同步

• master将完整内存数据生成RDB，发送RDB到slave

• slave清空本地数据，加载master的RDB

• master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave

• slave执行接收到的命令，保持与master之间的同步

2.2.2.增量同步

全量同步需要先做RDB，然后将RDB文件通过网络传输个slave，成本太高了。因此除了第一次做全量同步，其它大多数时候slave与master都是做增量同步。

什么是增量同步？就是只更新slave与master存在差异的部分数据。如图：

那么master怎么知道slave与自己的数据差异在哪里呢?

2.2.3.repl_backlog原理

这个文件是一个固定大小的数组，只不过数组是环形，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。

• repl_baklog中会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset。（slave与master的offset之间的差异，就是salve需要增量拷贝的数据 ）
• 随着不断有数据写入，master的offset逐渐变大，slave也不断的拷贝，追赶master的offset。
• 直到数组被填满（如果有新的数据写入，就会覆盖数组中的旧数据。不过，旧的数据只要是绿色的，说明是已经被同步到slave的数据，即便被覆盖了也没什么影响。因为未同步的仅仅是红色部分）
• 但是，如果slave出现网络阻塞，导致master的offset远远超过了slave的offset
• 如果master继续写入新数据，其offset就会覆盖旧的数据，直到将slave现在的offset也覆盖。棕色框中的红色部分，就是尚未同步，但是却已经被覆盖的数据。此时如果slave恢复，需要同步，却发现自己的offset都没有了，无法完成增量同步了。只能做全量同步。

2.3.主从同步优化

主从同步可以保证主从数据的一致性，非常重要。

可以从以下几个方面来优化Redis主从就集群：

• 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。

• Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO

• 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步

• 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

主从从架构图：

2.4.小结

简述全量同步和增量同步区别？

• 全量同步：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主从节点都设置了密码，仅执行 slaveof 命令是不够的，还需要进行密码认证配置。

下面的表格整理了配置密码认证的关键点：

配置项	作用描述	所在节点
requirepass	设置本节点的客户端连接密码。	主节点和从节点均需设置
masterauth	设置从节点用于连接主节点的认证密码。	仅在从节点配置
slaveof	指定主节点的IP地址和端口号。	仅在从节点配置

补充认证配置细节

• 主节点密码：在主节点的配置文件（如 redis.conf）中，通过 requirepass 指令设置连接密码。

• 从节点认证：在从节点的配置文件（如 redis.conf）中，你需要同时设置两个参数：

  1. masterauth：其值必须与主节点 requirepass 的密码完全一致。这是从节点"告诉"主节点"我是谁"的凭证。

  2. slaveof：指定主节点的IP和端口。

 两种配置方法

你可以通过以下两种方式完成配置：

1. 修改配置文件（推荐，永久生效）
   分别编辑主从节点的 redis.conf 文件，按上表说明配置 requirepass 和 masterauth，配置完成后重启Redis服务生效。

2. 使用命令行（临时生效，重启后失效）
   在Redis服务器运行时，通过 redis-cli 输入命令配置。例如，在从节点上执行：

   bash

   # 在从节点实例中执行
   SLAVEOF <主节点IP> <端口>
   CONFIG SET masterauth <主节点密码>

   这种方式在服务重启后配置会丢失，通常用于临时测试，生产环境建议使用配置文件方式。

主从复制中的offset和repl_backlog关系

组件	作用	数量	说明
从节点offset	记录该从节点已复制的最新数据位置	每个从节点独立一个	相当于从节点的"读书进度"
主节点offset	记录主节点已写入的最新数据位置	主节点维护一个	相当于主节点的"写作进度"
repl_backlog	主节点的复制积压缓冲区	主节点维护一个，所有从节点共享	相当于"最近写作内容的备份"

特性维度	描述	所在节点角色
数据同步	从节点会同步主节点的全部数据。主从库之间采用的是读写分离的方式。写操作在主节点执行，然后同步到从节点。	主节点 (a) / 从节点 (b, c)
读操作 (GET)	读操作主库和从库都可以接收。	从节点 (b, c)
写操作 (SET)	写操作由主节点执行。	主节点 (a)

Redis的读写分离不是在redis.conf配置文件中直接设置的，而是在客户端/应用程序层面实现的。让我详细解释一下：

 Redis配置文件相关设置

首先，在redis.conf中确实有一些与主从复制相关的配置，但与读写分离策略无关：

bash

# 在从节点的redis.conf中
slaveof 192.168.1.100 6379    # 指定主节点
masterauth "your_password"     # 主节点密码
slave-read-only yes           # 从节点只读模式（默认yes）

注意：slave-read-only yes 只是保证从节点本身不接受写操作，但不会自动分配读请求。

3 redis哨兵

3.1.哨兵原理

3.1.1.集群结构和作用

3.1.2.集群监控原理
Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

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

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

3.1.3.集群故障恢复原理
一旦发现master故障，sentinel需要在salve中选择一个作为新的master，选择依据如下：

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

3.2搭建哨兵集群

3.3.RedisTemplate

引入依赖

在项目的pom文件中引入依赖：

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

配置Redis地址

然后在配置文件application.yml中指定redis的sentinel相关信息：

spring:redis:sentinel:master: mymasternodes:- 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);
}

这个bean中配置的就是读写策略，包括四种：

• MASTER：从主节点读取

• MASTER_PREFERRED：优先从master节点读取，master不可用才读取replica

• REPLICA：从slave（replica）节点读取

• REPLICA _PREFERRED：优先从slave（replica）节点读取，所有的slave都不可用才读取master

4 redis分片集群

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

• 海量数据存储问题

• 高并发写的问题

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

分片集群特征：

- 集群中有多个master，每个master保存不同数据

- 每个master都可以有多个slave节点

- master之间通过ping监测彼此健康状态

- 客户端请求可以访问集群任意节点，最终都会被转发到正确节点

主从复制 + 哨兵模式解决了 可用性 和 读扩展 的问题，但它们本质上还是一个 “单主” 架构。

• 主从复制：数据全量复制到多个从节点，实现了数据备份和读写分离（读操作可以分摊到从节点）。

• 哨兵模式：监控主节点，实现自动故障转移，当主节点宕机时能自动提升一个从节点为主节点，保证服务可用。

但正如你所说，它们有两个致命的瓶颈：

1. 海量数据存储问题：单个Redis实例能管理的内存是有限的（比如16G、32G），即使你的机器有1T内存，单个Redis进程也无法有效利用。数据量接近或超过单机内存时，性能会急剧下降或无法存储。

2. 高并发写的问题：因为只有一个主节点负责处理所有写操作，所以写的瓶颈就在这个主节点上。无论你增加多少个从节点，写的上限就是这一个主节点的能力。

---

为什么分片集群可以解决这两个问题？

分片集群（Cluster）的核心思想是 “分而治之” 。它将一个巨大的数据集拆分成多个小的数据片（Shard），并将这些数据片分布到多个不同的Redis主节点上进行存储。每个主节点只负责处理自己所拥有的那部分数据的读写请求。

下面我们详细解释它是如何解决这两个问题的：

1. 解决海量数据存储问题

• 机制：分片集群将整个数据空间划分为16384个哈希槽（Hash Slot）。这些槽是数据分配和管理的基本单位。当你启动一个集群时，你可以将任意数量的主节点加入集群，并将这16384个槽分配给这些主节点。例如，在一个三主节点的集群中，可能这样分配：

  • 节点A： 0 - 5460 槽

  • 节点B： 5461 - 10922 槽

  • 节点C： 10923 - 16383 槽

• 数据存储：当客户端要存储一个键值对时，集群会使用CRC16算法对键（Key）进行计算，得到一个结果，然后对这个结果取模16384，确定这个键属于哪个哈希槽。最终，这个键值对就会被存储到负责该哈希槽的Redis主节点上。

• 效果：通过这种方式，原本需要单机承载的1T数据，现在被均匀地分布到了3个（或更多）主节点上，每个节点只需要存储大约300G的数据。理论上，只要你增加主节点的数量，就可以存储无限大的数据，从而解决了海量数据存储问题。

2. 解决高并发写的问题

• 机制：在分片集群中，有多个主节点，每个主节点都可以独立地处理写操作。

• 请求路由：

  • 客户端可以直接连接任何一个集群节点。

  • 如果该节点拥有客户端请求的键所对应的哈希槽，它就直接处理命令。

  • 如果它没有（即请求的键不在它负责的槽范围内），它会返回一个“重定向”错误（MOVED），告诉客户端应该去连接哪个正确的节点。

  • 聪明的客户端（如redis-cli -c或各种语言的Redis客户端库）会自动处理这个重定向，对用户来说几乎是透明的。

• 效果：假设一个三主节点的集群，理论上它的写吞吐量是单主节点的三倍。因为三个写请求如果恰好指向三个不同的键，并且这些键分布在三个不同的主节点上，那么这三个写操作就可以完全并行地执行。通过水平增加主节点的数量，就可以线性地提升整个集群的写并发处理能力。

4.1.搭建分片集群

4.2散列插槽

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

key不是与节点绑定，而是与插槽绑定。redis会根据key的有效部分计算插槽值，分两种情况：

• key中包含"{}"，且"{}"中至少包含1个字符，"{}"中的部分是有效部分

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

例如：key是num，那么就根据num计算，如果是{itcast}num，则根据itcast计算。计算方式是利用CRC16算法得到一个hash值，然后对16384取余，得到的结果就是slot值。

如图，在7001这个节点执行set a 1时，对a做hash运算，对16384取余，得到的结果是15495，因此要存储到103节点。

到了7003后，执行get num时，对num做hash运算，对16384取余，得到的结果是2765，因此需要切换到7001节点

Redis如何判断某个key应该在哪个实例？

• 将16384个插槽分配到不同的实例

• 根据key的有效部分计算哈希值，对16384取余

• 余数作为插槽，寻找插槽所在实例即可

如何将同一类数据固定的保存在同一个Redis实例？

• 这一类数据使用相同的有效部分，例如key都以{typeId}为前缀（一个插槽里可以有多个实例）

4.3.集群伸缩

redis-cli --cluster提供了很多操作集群的命令，可以通过下面方式查看：

需求：向集群中添加一个新的master节点，并向其中存储 num = 10

• 启动一个新的redis实例，端口为7004

• 添加7004到之前的集群，并作为一个master节点

• 给7004节点分配插槽，使得num这个key可以存储到7004实例

这里需要两个新的功能：

• 添加一个节点到集群中

• 将部分插槽分配到新插槽

创建新的redis实例

创建一个文件夹：

mkdir 7004

拷贝配置文件：

cp redis.conf /7004

修改配置文件：

sed /s/6379/7004/g 7004/redis.conf

启动

redis-server 7004/redis.conf

添加新节点到redis

添加节点的语法如下：

执行命令：

redis-cli --cluster add-node  192.168.150.101:7004 192.168.150.101:7001

通过命令查看集群状态：

redis-cli -p 7001 cluster nodes

如图，7004加入了集群，并且默认是一个master节点：

但是，可以看到7004节点的插槽数量为0，因此没有任何数据可以存储到7004上

.转移插槽

我们要将num存储到7004节点，因此需要先看看num的插槽是多少：

如上图所示，num的插槽为2765.

我们可以将0~3000的插槽从7001转移到7004，命令格式如下：

具体命令如下：

建立连接：

询问要移动多少个插槽，我们计划是3000个：

新的问题来了：

那个node来接收这些插槽？？

显然是7004，那么7004节点的id是多少呢？

复制这个id，然后拷贝到刚才的控制台后：

这里询问，你的插槽是从哪里移动过来的？

• all：代表全部，也就是三个节点各转移一部分

• 具体的id：目标节点的id

• done：没有了

这里我们要从7001获取，因此填写7001的id：

填完后，点击done，这样插槽转移就准备好了：

确认要转移吗？输入yes：

然后，通过命令查看结果：

可以看到：

目的达成。

4.4.故障转移

集群初始状态是这样的：

其中7001、7002、7003都是master，我们计划让7002宕机。

4.4.1.自动故障转移

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

直接停止一个redis实例，例如7002：

redis-cli -p 7002 shutdown

1）首先是该实例与其它实例失去连接

2）然后是疑似宕机：

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

4）当7002再次启动，就会变为一个slave节点了：

4.4.2.手动故障转移

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

这种failover命令可以指定三种模式：

• 缺省：默认的流程，如图1~6歩

• force：省略了对offset的一致性校验

• takeover：直接执行第5歩，忽略数据一致性、忽略master状态和其它master的意见

4.5.RedisTemplate访问分片集群

RedisTemplate底层同样基于lettuce实现了分片集群的支持，而使用的步骤与哨兵模式基本一致：

1）引入redis的starter依赖

2）配置分片集群地址

3）配置读写分离

与哨兵模式相比，其中只有分片集群的配置方式略有差异，如下：

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