vault backup: 2026-08-08 19:01:04
This commit is contained in:
@@ -0,0 +1,143 @@
|
||||
---
|
||||
tags: [redis, rdb-aof, persistence, fork, snapshot]
|
||||
create time: 2026-08-08 18:43
|
||||
update time: 2026-08-08 18:43
|
||||
---
|
||||
|
||||
# RDB 与 AOF 持久化
|
||||
|
||||
## 概述
|
||||
|
||||
Redis 作为内存数据库，崩溃重启后需要可靠的数据恢复机制。RDB（快照）和 AOF（追加日志）是 Redis 提供的两种持久化方案，各有优劣。Redis 4.0 之后又引入了混合持久化（Hybrid Persistence），结合了两者之长。理解它们的机制和取舍，是在生产环境选型的基础。
|
||||
|
||||
## 核心原理
|
||||
|
||||
### RDB — 快照机制
|
||||
|
||||
RDB（Redis Database）在指定时间间隔内将内存中的数据集写入磁盘，生成一个压缩的二进制文件（dump.rdb）。
|
||||
|
||||
**fork 子进程快照流程：**
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Client as 客户端
|
||||
participant Master as Redis主进程
|
||||
participant Child as fork子进程
|
||||
participant Disk as 磁盘
|
||||
|
||||
Client->>Master: SAVE / BGSAVE
|
||||
Master->>Master: 执行 bgsave
|
||||
Master->>Master: fork 创建子进程
|
||||
Note over Master: 父进程继续处理请求
|
||||
Master->>Child: 子进程独占写内存
|
||||
Child->>Child: 遍历内存数据结构
|
||||
Child->>Child: 写入临时 RDB 文件
|
||||
Child->>Disk: mv 替换 dump.rdb
|
||||
Child-->>Master: SIGCHLD 通知完成
|
||||
```
|
||||
|
||||
关键细节：
|
||||
- **COW（Copy-On-Write）**：fork 时父子进程共享内存页，子进程读数据，父进程写数据。当某页被修改时操作系统复制该页给子进程使用。这意味着 RDB 过程中内存峰值 = 当前内存 + fork 瞬间的增量变化量。
|
||||
- **save vs bgsave**：`SAVE` 阻塞所有客户端等待完成（生产环境禁用）；`BGSAVE` 后台异步执行。
|
||||
- **自动触发**：通过 `save <seconds> <changes>` 配置自动触发（如 `save 900 1` 表示 900 秒内有至少 1 个 key 被修改则触发）。
|
||||
- **RDB 压缩**：RDB 文件本身是无损压缩的二进制格式，不同版本间不兼容（不能跨版本还原）。
|
||||
|
||||
> [!WARNING]
|
||||
> RDB 每次全量快照，两次快照之间的数据在崩溃时会丢失。不适合对数据完整性要求极高的场景。
|
||||
|
||||
### AOF — 追加日志
|
||||
|
||||
AOF（Append Only File）以日志形式记录每个写操作，重启时重放日志恢复数据。
|
||||
|
||||
**appendfsync 三种策略：**
|
||||
|
||||
| 策略 | fsync 频率 | 性能 | 数据安全性 |
|
||||
|------|-----------|------|----------|
|
||||
| always | 每条命令一次 | 最差（约等于MySQL innodb_flush_log_at_trx_commit=1） | 最高，零丢失 |
|
||||
| everysec（默认） | 每秒一次 | 良好（1ms 系统调用） | 丢 1 秒数据 |
|
||||
| no | OS 决定 | 最佳 | 完全取决于 OS 刷新节奏 |
|
||||
|
||||
**AOF 重写（Rewrite）原理：**
|
||||
|
||||
AOF 文件会随时间越来越大。重写不是简单地删除旧文件再写新内容，而是：
|
||||
|
||||
1. 父进程 fork 子进程
|
||||
2. 子进程遍历内存数据，将每个 key 用 `SET key value` 命令序列化（而非读取旧 AOF）
|
||||
3. 父进程同时将新写命令写入 `aof_rewrite_buffer`
|
||||
4. 子进程完成后将新数据和缓冲区合并写入临时文件
|
||||
5. 原子替换原 AOF 文件
|
||||
|
||||
> [!NOTE]
|
||||
> AOF 重写期间，旧 AOF 保持不变直到新文件准备好，保证不会丢失任何已确认的数据。重写后的 AOF 可能比原来的小很多（去除了已过期 key 的旧记录）。
|
||||
|
||||
### 混合持久化
|
||||
|
||||
Redis 4.0+ 引入的混合持久化 = RDB 全量快照 + AOF 增量日志：
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A[BGSTART] --> B[fork 子进程]
|
||||
B --> C["写 RDB 部分<br/>（全部内存快照）"]
|
||||
B --> D["父进程收集<br/>AOF 增量命令"]
|
||||
C --> E["合并为临时文件"]
|
||||
D --> E
|
||||
E --> F["原子替换 AOF 文件"]
|
||||
```
|
||||
|
||||
优势：
|
||||
- 启动速度远快于纯 AOF（RDB 部分只需加载一次全量快照）
|
||||
- 数据安全性接近 pure AOF everysec（RDB 部分保证了到 fork 时刻的完整状态）
|
||||
|
||||
### 选型对比
|
||||
|
||||
| 维度 | RDB | AOF（everysec） | 混合持久化 |
|
||||
|------|-----|----------------|----------|
|
||||
| 数据丢失风险 | 高（丢最近快照期间的数据） | 低（最多丢 1s） | 极低 |
|
||||
| 启动恢复速度 | 快（单个文件） | 慢（逐条重放） | 较快 |
|
||||
| 磁盘占用 | 小（压缩二进制） | 大（文本指令） | 中等 |
|
||||
| CPU 开销 | 高（定期全量拷贝） | 低（持续追加） | 中 |
|
||||
| 适用场景 | 容灾备份、可接受短暂丢数据 | 对数据一致性要求高 | 兼顾速度与安全的推荐方案 |
|
||||
|
||||
## 代码示例
|
||||
|
||||
Go 中使用 Redigo 触发和管理持久化：
|
||||
|
||||
```go
|
||||
conn, _ := redis.Dial("tcp", "localhost:6379")
|
||||
defer conn.Close()
|
||||
|
||||
// 手动触发 BGSAVE（生产环境通常交给监控定时触发）
|
||||
res, _ := redis.String(conn.Do("BGSAVE"))
|
||||
// res == "Background saving started"
|
||||
|
||||
// 查看上次 BGSAVE 的状态
|
||||
info, _ := redis.StringMap(conn.Do("INFO", "persistent"))
|
||||
fmt.Println(info["last_bgsave_status"]) // "ok" or "err"
|
||||
```
|
||||
|
||||
```bash
|
||||
# Redis CLI 检查 AOF 状态
|
||||
127.0.0.1:6379> CONFIG GET appendonly
|
||||
1) "appendonly"
|
||||
2) "yes" # yes=开启, no=关闭
|
||||
|
||||
# 动态开启 AOF 重写
|
||||
127.0.0.1:6379> CONFIG SET auto-aof-rewrite-percentage 100
|
||||
OK
|
||||
```
|
||||
|
||||
## 实践场景
|
||||
|
||||
1. **默认推荐**：开启混合持久化（`aof-use-rdb-preamble yes`），既保证数据安全又控制启动时间。大多数互联网公司的标准配置。
|
||||
|
||||
2. **冷备策略**：每天凌晨做一次 `SAVE`（或 `BGSAVE`），将 dump.rdb 上传到 OSS/S3。注意 `SAVE` 是阻塞命令，不要在高峰期执行。
|
||||
|
||||
3. **迁移场景**：从一个 Redis 集群迁到另一个，用 `BGSAVE` 拿到最新快照后复制文件到新实例，恢复速度远超 AOF 重放。
|
||||
|
||||
4. **大数据量陷阱**：当内存超过 10GB 时，fork 导致 COW 成本剧增。考虑增大 AOF 重写阈值或将业务拆分到多实例，避免单次 fork 过大的内存开销。
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[03.Redis/core/Redis 五大核心数据结构]]
|
||||
- [[03.Redis/core/集群与哨兵机制]]
|
||||
- [[03.Redis/strategies/多级缓存架构设计]]
|
||||
@@ -0,0 +1,148 @@
|
||||
---
|
||||
tags: [redis, data-structures, sds, quicklist, skiplist]
|
||||
create time: 2026-08-08 18:43
|
||||
update time: 2026-08-08 18:43
|
||||
---
|
||||
|
||||
# Redis 五大核心数据结构
|
||||
|
||||
## 概述
|
||||
|
||||
Redis 的性能基石在于其精心设计的底层数据结构。Redis 的每个值都有多种编码（encoding），会根据数据规模和内容自动切换，在内存占用和操作效率之间寻找最优解。理解这些编码的切换策略，是面试中的高频考点，也是性能调优的关键前提。
|
||||
|
||||
## 核心原理
|
||||
|
||||
### String — SDS（Simple Dynamic String）
|
||||
|
||||
Redis 的 String 类型不是直接用 C 字符串，而是用 SDS（Simple Dynamic String）结构。SDS 的定义如下：
|
||||
|
||||
```c
|
||||
struct sdshdr {
|
||||
int len; // buf 中已使用的字节数
|
||||
int free; // buf 中未使用的字节数
|
||||
unsigned char flags; // 低3位标记类型：SDS_TYPE_5/8/10/16/32
|
||||
char buf[]; // 可变长度字符数组，以 \0 结尾
|
||||
};
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> SDS 有 5 种格式（SDS_TYPE_5 到 SDS_TYPE_32），通过 `flags` 字段的低 3 位区分。SDS_TYPE_5 用于短字符串（len < 32），直接内嵌在 dictEntry 中而不分配独立对象。
|
||||
|
||||
**为什么不用 C 字符串？**
|
||||
|
||||
| 问题 | C 字符串 | SDS |
|
||||
|------|---------|-----|
|
||||
| O(N) 获取长度 | strlen 遍历计数 | len 字段 O(1) |
|
||||
| 缓冲区溢出风险 | strcpy/strcat 不安全 | 分配时检查空间 |
|
||||
| 修改需重新分配 | 每次可能 realloc | 惰性空间释放（free 保留） |
|
||||
| 二进制安全 | 遇 \0 截断 | 记录 len，可存任意二进制数据 |
|
||||
|
||||
**innative 优化**：从 Redis 7.0 开始，小字符串使用 SDS_TYPE_5 直接存储在 dictEntry 的键槽中，完全避免额外的堆分配，减少内存碎片和 malloc 开销。
|
||||
|
||||
### List — quicklist
|
||||
|
||||
Redis 3.2 之前用 ziplist + linkedlist 实现 List，3.2 之后统一为 **quicklist**。
|
||||
|
||||
quicklist 是一个双向链表，每个节点（quicklistNode）是一个 ziplist 或 listpack（Redis 7.0+）。通过 `list-max-ziplist-size` 控制每个节点的压缩列表大小：
|
||||
|
||||
| list-max-ziplist-size 值 | 含义 |
|
||||
|--------------------------|------|
|
||||
| 正数 N | 该节点最多 N 个元素 |
|
||||
| -1 | 每节点不限（仅受 memory 约束） |
|
||||
| -2 | 每节点 <= 8KB |
|
||||
| -3 | 每节点 <= 4KB |
|
||||
| -4 | 每节点 <= 2KB |
|
||||
| -5 | 每节点 <= 1KB（默认） |
|
||||
|
||||
```go
|
||||
// Go 伪代码示意 quicklist 的结构
|
||||
type quicklist struct {
|
||||
head *quicklistNode
|
||||
tail *quicklistNode
|
||||
count int64 // 总元素数
|
||||
zipsize int // list-max-ziplist-size 全局配置
|
||||
}
|
||||
|
||||
type quicklistNode struct {
|
||||
prev *quicklistNode
|
||||
next *quicklistNode
|
||||
ptr unsafe.Pointer // 指向 ziplist/listpack
|
||||
sz uint32 // 字节大小
|
||||
}
|
||||
```
|
||||
|
||||
### Hash — zipmap / hashtable 切换
|
||||
|
||||
Hash 有两种编码，根据数据和元素数量自动切换：
|
||||
|
||||
- **zipmap**（Redis 4.0 之前）→ 当元素数量 >= 512 且最大 value 长度 < 64 字节时使用 hashtable
|
||||
- **ziplist**（Redis 4.0 ~ 5.x）→ 元素数量 <= 512 且所有 value 长度 < 64 字节
|
||||
- **hashtable**（Redis 4.0+ 默认）→ 只要有一个 value > 64 字节 或 元素数 > 512 就切换到 hashtables
|
||||
|
||||
> [!WARNING]
|
||||
> Redis 4.0+ 废弃了 ziplist 作为 Hash 编码，默认始终使用 hashtable。这是因为 ziplist 插入删除的均摊代价在大数据量下反而更高。ziplist 编码目前仅在 ZSet 场景中保留。
|
||||
|
||||
### Set — intset → hashtable 切换
|
||||
|
||||
Set 编码切换逻辑非常直观：
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A["Set 创建"] --> B{"所有元素都是整数?"}
|
||||
B -->|是| C["intset 编码"]
|
||||
B -->|否| D["hashtable 编码"]
|
||||
C --> E{"新加入的元素仍是整数?"}
|
||||
E -->|是| F["继续 intset"]
|
||||
E -->|否| G["转换为 hashtable"]
|
||||
D --> H["维持 hashtable"]
|
||||
```
|
||||
|
||||
- **intset**：有序整数集合，紧凑排列在连续内存中。支持 int16_t、int32_t、int64_t 三种格式，升级时 realloc 整个结构（不可降级）。
|
||||
- **hashtable**：通用哈希表，任何类型的成员都能存储。
|
||||
|
||||
### ZSet — skiplist + ziplist / quicklist 切换
|
||||
|
||||
ZSet 是最复杂的结构，组合了两层编码：
|
||||
|
||||
- **ziplist**（Redis 5.0 之前）/ **quicklist**（Redis 5.0+）：当元素少且值小时用压缩列表存储
|
||||
- **skiplist + hashtable**：标准模式，跳表按 score 排序，hashtable 按 member 做 O(1) 查找
|
||||
|
||||
> [!TIP]
|
||||
> 面试常考：跳表的平均查找复杂度 O(log N)，最坏 O(N)；Redis 跳表通过限制随机层级上限（maxlevel=32）和控制概率 p=0.25，保证最坏情况也在可接受范围。跳表节点包含：score（分数）、member（成员）、back（后退指针）、forward（多层前进指针数组）。
|
||||
|
||||
## 代码示例
|
||||
|
||||
以下展示如何查看 Redis 对象的内部编码：
|
||||
|
||||
```bash
|
||||
# Redis CLI 中查看键的内部编码
|
||||
127.0.0.1:6379> OBJECT ENCODED mykey
|
||||
"ziplist" # 或 "skiplist", "hashtable", "intset"
|
||||
```
|
||||
|
||||
```go
|
||||
// Go 中使用 Redigo 库观察 Redis 行为
|
||||
import "github.com/gomodule/redigo/redis"
|
||||
|
||||
conn, _ := redis.Dial("tcp", "localhost:6379")
|
||||
defer conn.Close()
|
||||
|
||||
// HSET 少量数据 → ziplist/hashmap
|
||||
conn.Do("HSET", "user:1", "name", "alice", "age", "25")
|
||||
// 数据量大后自动切 hashtable —— 用户无感知
|
||||
```
|
||||
|
||||
## 实践场景
|
||||
|
||||
1. **Hash 内存优化**：对于一个用户有几十个字段的小 Hash，手动合并成单个 Key（如 `user:1:name`）不如用一个 Hash 结构 `user:1`，因为 ziplist 能省大量内存。
|
||||
|
||||
2. **ZSet 排行榜实现**：电商商品销量排名、社交媒体点赞排行等场景天然适合 ZSet。`ZREVRANGEBYSCORE` 可以高效取 Top-N。
|
||||
|
||||
3. **List 替代方案**：如果 List 只用两端操作（LPUSH + RPOP），本质上是个队列；但 quicklist 的中间节点插入在大数据量时会有 O(N) 成本，考虑用 Stream 替代。
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[03.Redis/core/RDB 与 AOF 持久化]]
|
||||
- [[03.Redis/core/集群与哨兵机制]]
|
||||
- [[03.Redis/strategies/多级缓存架构设计]]
|
||||
- [[03.Redis/strategies/缓存穿透击穿雪崩解决方案]]
|
||||
@@ -0,0 +1,207 @@
|
||||
---
|
||||
tags: [redis, cluster-sentinel, sharding, gossip, failover]
|
||||
create time: 2026-08-08 18:43
|
||||
update time: 2026-08-08 18:43
|
||||
---
|
||||
|
||||
# 集群与哨兵机制
|
||||
|
||||
## 概述
|
||||
|
||||
Redis 单实例架构天然面临内存上限和单点故障问题。Redis Cluster（原生分片集群）解决了水平扩展，Sentinel（哨兵）解决了高可用自动故障转移。理解它们的架构、通信协议和选举机制，是构建生产级 Redis 基础设施的前提。
|
||||
|
||||
## 核心原理
|
||||
|
||||
### Sentinel — 哨兵架构
|
||||
|
||||
哨兵不是对数据进行分片的，而是在主从复制的基础上增加自动化故障检测和恢复能力。
|
||||
|
||||
**哨兵节点组成：**
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph RedisCluster["Redis 主从集群"]
|
||||
M["Master<br/>192.168.1.10:6379"]
|
||||
S1["Slave1<br/>192.168.1.11:6379"]
|
||||
S2["Slave2<br/>192.168.1.12:6379"]
|
||||
end
|
||||
|
||||
subgraph Sentinels["哨兵集群"]
|
||||
SEN1["Sentinel-1<br/>192.168.1.10:26379"]
|
||||
SEN2["Sentinel-2<br/>192.168.1.11:26379"]
|
||||
SEN3["Sentinel-3<br/>192.168.1.12:26379"]
|
||||
end
|
||||
|
||||
subgraph Clients["客户端"]
|
||||
APP1["应用服务A"]
|
||||
APP2["应用服务B"]
|
||||
end
|
||||
|
||||
M -->|replication| S1
|
||||
M -->|replication| S2
|
||||
SEN1 -->|监控| M
|
||||
SEN2 -->|监控| M
|
||||
SEN3 -->|监控| M
|
||||
SEN1 <-->|Gossip通信| SEN2
|
||||
SEN2 <-->|Gossip通信| SEN3
|
||||
SEN3 <-->|Gossip通信| SEN1
|
||||
APP1 -->|连接| M
|
||||
APP2 -->|连接| M
|
||||
```
|
||||
|
||||
**四大职责：**
|
||||
|
||||
1. **监控（Monitoring）**：定期检查 Master、Slave 和其他 Sentinel 是否可达（通过 PING）。
|
||||
2. **提醒（Notification）**：当某个节点发现异常时，通知其他 Sentinel。
|
||||
3. **自动故障转移（Failover）**：当 master 被标记为客观下线（ODOWN）时，选择一个 slave 升为主节点。
|
||||
4. **配置提供者（Configuration Provider）**：客户端连接 sentinel 来获取当前 master 地址。
|
||||
|
||||
**故障转移步骤：**
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant S1 as Sentinel-1
|
||||
participant Quorum as Quorum(n/2+1)
|
||||
participant Master as 原Master
|
||||
participant Slave as Slave节点
|
||||
|
||||
S1->>Master: PING (超时判定主观下线)
|
||||
S1->>S1: 标记为 Subjectively Down (SDOWN)
|
||||
S1->>Quorum: 询问是否也认为 Master SDOWN
|
||||
Quorum-->>S1: n/2+1 确认
|
||||
S1->>S1: 标记为 Objectively Down (ODOWN)
|
||||
S1->>S1: 选举 leader Sentinel
|
||||
Note over S1: RAFT-like 选举<br/>先到先得
|
||||
S1->>Quorum: 投票选出 Failover Owner
|
||||
S1->>Slave: 选出最合适的 slave (复制偏移量最大)
|
||||
Slave->>Slave: SLAVEOF NO ONE
|
||||
Slave->>Slave: 提升为 Master
|
||||
S1->>其他 Slave: SLAVEOF new-master IP PORT
|
||||
S1->>Clients: 更新 master 地址
|
||||
```
|
||||
|
||||
**关键参数：**
|
||||
|
||||
| 参数 | 默认值 | 含义 |
|
||||
|------|-------|------|
|
||||
| down-after-milliseconds | 30000 | 主观下线的判断时间（ms） |
|
||||
| failover-timeout | 180000 | 故障转移超时（ms） |
|
||||
| parallel-syncs | 1 | 故障转移后同时同步的新 master 数量 |
|
||||
|
||||
> [!NOTE]
|
||||
> quorum = n/2 + 1 中的 n 是配置的 Sentinel 节点总数，不是存活节点数。如果配置了 3 个 Sentinel，需要至少 2 个认为 master SDOWN 才会触发 ODOWN。这意味着少数派宕机不影响多数派的故障检测。
|
||||
|
||||
### Redis Cluster — 槽位分配
|
||||
|
||||
Redis Cluster 是无中心架构，每个节点都知道完整的拓扑结构。数据分片基于 **哈希槽（hash slot）**。
|
||||
|
||||
**16384 个槽位：**
|
||||
|
||||
- Redis Cluster 将 16384 个 hash slot 分布在多个节点上
|
||||
- Key 的 slot 计算：`CRC16(key) % 16384`
|
||||
- 客户端可以通过 `ASK` 和 `MOVED` 重定向消息定位到正确节点
|
||||
|
||||
**槽位迁移流程（在线迁移）：**
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Admin as 管理员
|
||||
participant NodeA as Source Node
|
||||
participant NodeB as Target Node
|
||||
participant Client as 客户端
|
||||
|
||||
Admin->>NodeA: CLUSTER ADDSLOTS 0-5460
|
||||
NodeA->>NodeB: 开始迁移 slots
|
||||
Note over NodeA,NodeB: 阶段1: IMPORTING
|
||||
NodeA->>NodeA: setslot IMPORTING <slot> <target-id>
|
||||
NodeB->>NodeB: setslot MIGRATING <slot> <source-id>
|
||||
loop 逐个 key 迁移
|
||||
NodeA->>NodeB: MIGRATE host port key timeout
|
||||
Note over NodeA: client 查 key → ASK redirect →<br/>再查到目标 node
|
||||
end
|
||||
NodeA->>NodeA: setslot NODE <my-id> （迁移完成）
|
||||
Client->>NodeB: 直接查找 (no redirect needed)
|
||||
```
|
||||
|
||||
### Gossip 协议
|
||||
|
||||
哨兵之间使用简单的主子 Gossip 协议进行信息交换：
|
||||
|
||||
- **PUBLISH/SUBSCRIBE**：哨兵可以发布订阅频道获取全局事件
|
||||
- **HEARTBEAT**：每秒钟互相发送 PING，包含自身的版本号和当前 master 状态
|
||||
- **INFO 传播**：每个哨兵维护整个集群的视图，定期与其他哨兵同步
|
||||
- **领导选举**：基于 Raft 思想的简化版——先到先得，获得 quorum 票数成为 owner
|
||||
|
||||
> [!WARNING]
|
||||
> Gossip 协议存在最终一致性延迟。在哨兵刚刚选出新 leader 的瞬间，未收到通知的哨兵可能仍认为旧状态是正确的，此时如果再次发生故障转移请求可能出现混乱。实际生产中要合理设置 timeouts。
|
||||
|
||||
### CP vs AP 权衡
|
||||
|
||||
Redis Cluster 在设计上做出了明确的取舍：
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A["CAP 定理"] --> B{"一致性 or 可用性?"}
|
||||
B -->|Redis Cluster 选择| C["AP 倾向<br/>(可用性优先)"]
|
||||
B -->|对比方案| D["Redis Sentinel CP 倾向"]
|
||||
|
||||
C --> E["分片节点不可用时<br/>部分操作返回 -CLUSTERDOWN"]
|
||||
D --> F["单主从切换期间<br/>短暂不可用但最终一致"]
|
||||
|
||||
E --> G["适合：缓存/排行榜等可接受短暂不一致场景"]
|
||||
F --> H["适合：会话存储/限流计数等要求强一致场景"]
|
||||
```
|
||||
|
||||
| 维度 | Redis Sentinel | Redis Cluster |
|
||||
|------|---------------|---------------|
|
||||
| 一致性模型 | CP（主从切换期间短暂不可用但保证一致） | AP（分片后允许不同分区有不同视角） |
|
||||
| 数据分片 | 否（全量复制到每个从节点） | 是（16384 槽位分散） |
|
||||
| 多 DB 支持 | 支持（DB0 ~ DB15） | 不支持（仅 DB0） |
|
||||
| 扩容方式 | 手动迁移或重新搭建 | 在线增量迁移 |
|
||||
| 适用场景 | 中小规模、强一致性要求 | 大规模、水平扩展需求 |
|
||||
|
||||
## 代码示例
|
||||
|
||||
Go 中使用 Redigo 连接 Sentinel：
|
||||
|
||||
```go
|
||||
import "github.com/gomodule/redigo/redis"
|
||||
|
||||
sentinelAddrs := []string{"192.168.1.10:26379", "192.168.1.11:26379"}
|
||||
pool := &redis.Pool{
|
||||
MaxIdle: 10,
|
||||
DialContext: func(ctx context.Context) (conn redis.Conn, err error) {
|
||||
// 自动发现 master，无需硬编码地址
|
||||
conn, err = redis.DialSentinel(
|
||||
"mymaster", // sentinel 网络名
|
||||
sentinelAddrs, // sentinel 地址列表
|
||||
"", "", // username/password
|
||||
)
|
||||
return
|
||||
},
|
||||
}
|
||||
defer pool.Close()
|
||||
```
|
||||
|
||||
```bash
|
||||
# Sentinel CLI 查看当前 master 信息
|
||||
127.0.0.1:26379> SENTINEL get-master-addr-by-name mymaster
|
||||
1) "192.168.1.10"
|
||||
2) "6379" # 如果返回空数组，说明正在故障转移中
|
||||
```
|
||||
|
||||
## 实践场景
|
||||
|
||||
1. **Sentinel 部署最佳实践**：至少 3 个（奇数），跨机房部署避免单机房断电导致全部失联。quorum 设为 n/2 + 1。
|
||||
|
||||
2. **客户端感知的 Sentinel 连接**：Java 的 Jedis / Lettuce 和 Go 的 redigo 都内置了 Sentinel 发现逻辑，配置好 master name 即可自动路由。不要把 master IP 写死在配置里。
|
||||
|
||||
3. **Cluster 扩缩容**：新增节点时先 `CLUSTER MEET` 加入集群，再通过 `CLUSTER ADDSLOT` 分配槽位，最后用 `redis-cli --cluster rebalance` 自动均衡。整个过程业务零停机。
|
||||
|
||||
4. **脑裂风险**：当网络和物理隔离导致两个"主"共存时，会产生数据分裂。可通过 `min-replicas-to-write` 和 `min-replicas-max-lag` 降低风险。
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[03.Redis/core/Redis 五大核心数据结构]]
|
||||
- [[03.Redis/core/RDB 与 AOF 持久化]]
|
||||
- [[03.Redis/strategies/多级缓存架构设计]]
|
||||
Reference in New Issue
Block a user