Aron-Blog

Redis 多级缓存与JVM进程缓存

Fri, 31 Jul 2026 00:00:00 GMT

1. 为什么需要多级缓存#

1.1 传统缓存方案#

传统查询链路通常是：

flowchart LR A[客户端] --> B[Tomcat] B --> C{Redis 命中?} C -- 是 --> B C -- 否 --> D[(数据库)] D --> C B --> A

这种方案虽然已经通过 Redis 减少了数据库访问，但仍然存在两个突出问题：

所有动态请求都必须经过 Tomcat
当并发持续升高时，Tomcat 的线程、CPU、连接池等资源可能成为系统瓶颈。
Redis 未命中会把压力继续传给数据库
缓存过期、冷启动或热点 Key 失效时，大量请求可能同时访问数据库。

1.2 多级缓存方案#

多级缓存会充分利用请求链路中的各层存储能力：

flowchart LR A[浏览器缓存] --> B[反向代理 Nginx] B --> C[业务 Nginx 本地缓存] C -->|未命中| D[(Redis)] D -->|未命中| E[Tomcat] E --> F[JVM 进程缓存] F -->|未命中| G[(数据库)]

典型查询顺序如下：

浏览器访问静态资源时，优先读取浏览器缓存；
动态请求到达 Nginx 后，优先查询 Nginx 本地缓存；
Nginx 本地缓存未命中时，查询 Redis；
Redis 未命中时，请求 Tomcat；
Tomcat 优先查询 JVM 进程缓存；
JVM 进程缓存未命中时，最后查询数据库。

这样可以逐层拦截请求，减少对后端服务和数据库的访问。

1.3 各层缓存的职责#

缓存层级	典型内容	优点	主要限制
浏览器缓存	HTML、CSS、JS、图片等静态资源	距离用户最近，命中后不访问服务端	受浏览器缓存策略控制
Nginx 本地缓存	热点接口结果	延迟低，可在进入 Java 服务前返回	多节点之间需要处理数据一致性
Redis	跨实例共享的热点数据	容量较大、可共享、可持久化和高可用	存在网络和序列化开销
JVM 进程缓存	单个 Java 实例中的高频小数据	直接读取本机内存，速度快	容量有限、进程重启丢失、实例间不共享
数据库	最终业务数据	持久化、查询能力完整	承载高并发读的成本较高

在课程架构中，承担业务查询和缓存逻辑的 Nginx 已不只是反向代理服务器，而是一个可通过 OpenResty 与 Lua 编写业务逻辑的 Web 服务。因此通常会把它部署成集群，并在前面再设置专门的反向代理 Nginx。

2. JVM 进程缓存#

2.1 什么是进程缓存#

JVM 进程缓存是保存在当前 Java 进程堆内存中的数据。常见实现包括：

HashMap；
ConcurrentHashMap；
Guava Cache；
Caffeine。

与普通 Map 相比，专业缓存库通常还提供：

最大容量控制；
基于时间的过期；
自动加载；
并发访问控制；
驱逐策略；
命中率、加载耗时等统计；
移除监听、异步刷新等扩展能力。

2.2 进程缓存与 Redis 的区别#

对比维度	JVM 进程缓存	Redis 分布式缓存
数据位置	当前应用进程内存	独立 Redis 服务
访问成本	无网络开销，通常更快	有网络与序列化开销
数据共享	不同应用实例之间不共享	多个实例可以共享
容量	受 JVM 堆大小限制	可独立扩容，容量通常更大
可靠性	进程停止后数据丢失	可通过持久化、主从、集群提高可靠性
一致性	每个实例可能保存不同版本	集中存储，更容易统一管理
适用场景	数据量小、访问极频繁、允许短暂不一致	数据量较大、需要跨实例共享

二者不是互相替代的关系。常见做法是把 Caffeine 作为一级缓存（L1），把 Redis 作为二级缓存（L2）。

2.3 进程缓存的边界#

使用 JVM 进程缓存时要明确：

每个 Tomcat 实例都有自己的缓存副本；
请求被负载均衡到不同实例时，可能连续发生多次未命中；
实例扩容后，新实例的缓存是空的；
应用重启后，缓存会全部丢失；
数据更新后，需要考虑所有实例中旧值的失效问题；
缓存对象会占用 JVM 堆，容量失控可能增加 GC 压力，甚至导致 OOM。

因此，进程缓存适合保存“体积较小、访问频繁、可重新加载”的数据，不应充当可靠的最终数据源。

3. 初识 Caffeine#

3.1 Caffeine 的定位#

Caffeine 是 Java 平台上的高性能本地缓存库，提供手动缓存、同步加载缓存和异步缓存等模式。

Spring Framework 提供了对 Caffeine 的适配，可以通过 CaffeineCache、CaffeineCacheManager 或 Spring Cache 注解使用它。需要注意：Spring 的缓存模块是一层抽象，Caffeine 是它支持的具体缓存实现之一，不能简单理解为“Spring 内部默认缓存就是 Caffeine”。

官方资料：

项目依赖#

使用 Spring Boot 2.3.9.RELEASE 和 Java 8，并直接引入 Caffeine：

1
<dependency>
2
    <groupId>com.github.ben-manes.caffeine</groupId>
3
    <artifactId>caffeine</artifactId>
4
</dependency>

该工程继承 Spring Boot 父 POM，因此依赖没有单独声明版本。若脱离这个父 POM 使用，需要在自己的依赖管理中明确一个与当前 Java 版本兼容的 Caffeine 版本。

3.2 基本 API#

1
@Test
2
void testBasicOps() {
3
    // 1. 创建手动缓存。未配置过期或容量时，缓存可能持续增长。
4
    Cache<String, String> cache = Caffeine.newBuilder()
5
            .maximumSize(100)
6
            .build();
7

8
    // 2. 写入或覆盖
9
    cache.put("name", "Caffeine");
10

11
    // 3. 只查询缓存；未命中返回 null
12
    String value = cache.getIfPresent("name");
13

14
    // 4. 查询缓存；未命中时执行加载函数，并把非 null 结果写入缓存
15
    String loaded = cache.get("language", key -> {
16
        // 实际业务中可以在这里查询数据库或调用下一级缓存
17
        return "Java";
18
    });
19

20
    // 5. 删除单个 Key
21
    cache.invalidate("name");
22

23
    // 6. 清空缓存
24
    cache.invalidateAll();
25
}

展开收起

常用方法：

方法	作用
`getIfPresent(key)`	只查询缓存，未命中时返回 `null`
`get(key, mappingFunction)`	未命中时计算并写入，然后返回结果
`put(key, value)`	新增或覆盖缓存
`invalidate(key)`	使指定 Key 失效
`invalidateAll()`	使全部缓存失效
`estimatedSize()`	返回缓存条目数的估算值
`stats()`	获取命中率、加载耗时、驱逐次数等统计信息

同一个测试类的容量驱逐案例使用 Thread.sleep(10L) 等待维护任务，这会让测试依赖机器调度。需要稳定断言时，可在写入后调用 cache.cleanUp() 触发待执行的维护，再检查条目或统计信息。

3.3 为什么优先使用 `cache.get`#

不要把“先判断，再加载，再写入”拆成三个独立步骤：

1
// 不推荐：并发请求可能同时发现缓存未命中，然后重复查询数据库
2
Item item = cache.getIfPresent(id);
3
if (item == null) {
4
    item = itemService.getById(id);
5
    cache.put(id, item);
6
}
7
return item;

更推荐：

1
return cache.get(id, itemService::getById);

cache.get(key, mappingFunction) 会以原子方式完成“未命中时计算并写入”。同一个 JVM 内并发访问同一 Key 时，它能减少重复加载，缓解本机范围内的缓存击穿。

但它只能协调当前进程中的线程，不能阻止其他 Tomcat 实例同时回源。如果需要跨实例控制热点 Key 的并发回源，还需要 Redis 锁、逻辑过期、请求合并等分布式方案。

3.4 空值与异常#

加载函数可能查询不到数据，也可能抛出异常：

1
Item item = itemCache.get(id, key -> itemService.getById(key));

需要注意：

加载函数返回 null 时，不会形成一个正常的 Caffeine 缓存条目；
如果热点请求持续查询一个不存在的 ID，仍可能反复访问数据库，这就是缓存穿透；
加载函数抛出异常时，异常会向调用方传播，不应把系统错误当作正常数据缓存；
可以缓存一个明确的空对象或包装类型，并设置较短有效期，但不能直接把“数据不存在”和“查询失败”混为一谈。

例如：

1
record CacheValue<T>(boolean found, T data) {
2
    static <T> CacheValue<T> hit(T data) {
3
        return new CacheValue<>(true, data);
4
    }
5

6
    static <T> CacheValue<T> notFound() {
7
        return new CacheValue<>(false, null);
8
    }
9
}

4. Caffeine 的驱逐与过期策略#

缓存必须有边界，否则可能不断占用内存。

4.1 基于容量#

1
Cache<Long, Item> cache = Caffeine.newBuilder()
2
        .initialCapacity(100)
3
        .maximumSize(10_000)
4
        .build();

initialCapacity(100)：初始容量提示，用于减少早期扩容，不是最小容量，也不是上限；
maximumSize(10_000)：最多保留约 10,000 个条目；
达到上限后，Caffeine 会根据访问频率与近期访问情况选择条目驱逐；
maximumSize 限制的是条目数量，不是内存字节数。

如果不同条目的内存大小差异很大，可以考虑 maximumWeight 与 weigher：

1
Cache<Long, byte[]> cache = Caffeine.newBuilder()
2
        .maximumWeight(10 * 1024 * 1024)
3
        .weigher((Long key, byte[] value) -> value.length)
4
        .build();

这里的权重由业务定义，不等同于 JVM 对象的精确内存占用。

4.2 基于时间#

写入后过期#

1
Cache<Long, Item> cache = Caffeine.newBuilder()
2
        .expireAfterWrite(Duration.ofMinutes(10))
3
        .maximumSize(10_000)
4
        .build();

expireAfterWrite 从条目创建或最近一次值替换开始计时，适合“写入一段时间后数据可能变旧”的场景。

访问后过期#

1
Cache<Long, Item> cache = Caffeine.newBuilder()
2
        .expireAfterAccess(Duration.ofMinutes(10))
3
        .maximumSize(10_000)
4
        .build();

expireAfterAccess 从最近一次读或写开始计时，适合会话数据或长期不访问即可淘汰的数据。

两者区别：

策略	计时起点	适合场景
`expireAfterWrite`	创建或最近一次替换	控制数据的新鲜度
`expireAfterAccess`	最近一次读或写	清理长期不访问的数据

4.3 基于引用#

Caffeine 支持弱引用 Key、弱引用 Value 和软引用 Value，但这类策略依赖 GC，回收时间和容量都不够可预测。通常更推荐使用明确的 maximumSize 或 maximumWeight。

4.4 过期不等于立即删除#

默认情况下，条目到达过期时间后，不一定会在那个时间点被后台线程立即物理删除。清理通常在写操作、部分读操作或维护任务中完成。

因此应这样理解：

过期条目不会再作为有效命中返回；
estimatedSize() 在维护完成前可能仍包含等待清理的条目；
不要用缓存内部条目是否已物理删除，替代业务上的过期判断。

如果业务要求更及时地执行过期维护，可按所用 Java 与 Caffeine 版本评估 scheduler 配置。

4.5 刷新与过期的区别#

refreshAfterWrite 和 expireAfterWrite 语义不同：

过期：旧值失效，后续请求通常要等待新值加载；
刷新：条目达到刷新条件后，在被访问时异步加载新值，刷新期间仍可返回旧值。

刷新适合允许短时间旧数据、但希望降低重新加载等待时间的场景。它通常用于 LoadingCache，并需要谨慎设计加载线程池、失败回退和数据一致性。

5. 使用 Caffeine 实现商品进程缓存#

5.1 需求#

给商品服务增加两组 JVM 进程缓存：

根据 ID 查询商品，未命中时查询数据库；
根据 ID 查询库存，未命中时查询数据库；
初始容量为 100；
最大条目数为 10,000。

商品与库存应使用不同缓存，原因包括：

数据类型不同；
更新频率不同；
过期时间可能不同；
需要分别统计命中率和执行失效操作。

5.2 定义缓存 Bean#

1
@Configuration
2
public class CaffeineConfig {
3

4
    @Bean
5
    public Cache<Long, Item> itemCache() {
6
        return Caffeine.newBuilder()
7
                .initialCapacity(100)
8
                .maximumSize(10_000)
9
                .build();
10
    }
11

12
    @Bean
13
    public Cache<Long, ItemStock> stockCache() {
14
        return Caffeine.newBuilder()
15
                .initialCapacity(100)
16
                .maximumSize(10_000)
17
                .build();
18
    }
19
}

展开收起

上面是符合需求的最小实现。生产环境通常还应评估：

是否配置过期时间；
商品和库存是否采用不同有效期；
是否需要 recordStats()；
是否添加 removalListener；
最大条目数是否适合对象体积和 JVM 堆大小。

例如：

1
@Bean
2
public Cache<Long, Item> itemCache() {
3
    return Caffeine.newBuilder()
4
            .initialCapacity(100)
5
            .maximumSize(10_000)
6
            .expireAfterWrite(Duration.ofMinutes(10))
7
            .recordStats()
8
            .build();
9
}

5.3 在 Controller 中查询缓存#

1
@RestController
2
@RequestMapping("item")
3
public class ItemController {
4

5
    private final IItemService itemService;
6
    private final IItemStockService stockService;
7
    private final Cache<Long, Item> itemCache;
8
    private final Cache<Long, ItemStock> stockCache;
9

10
    public ItemController(
11
            IItemService itemService,
12
            IItemStockService stockService,
13
            Cache<Long, Item> itemCache,
14
            Cache<Long, ItemStock> stockCache) {
15
        this.itemService = itemService;
16
        this.stockService = stockService;
17
        this.itemCache = itemCache;
18
        this.stockCache = stockCache;
19
    }
20

21
    @GetMapping("/{id}")
22
    public Item findById(@PathVariable Long id) {
23
        return itemCache.get(id, key -> itemService.query()
24
                .ne("status", 3)
25
                .eq("id", key)
26
                .one());
27
    }
28

29
    @GetMapping("/stock/{id}")
30
    public ItemStock findStockById(@PathVariable Long id) {
31
        return stockCache.get(id, stockService::getById);
32
    }
33
}

展开收起

这里改用构造器注入，依赖关系更明确，也更方便测试。

5.4 查询流程#

flowchart TD A[收到商品查询请求] --> B{Caffeine 是否命中?} B -- 是 --> C[直接返回缓存值] B -- 否 --> D[执行加载函数] D --> E[查询数据库] E --> F{查询结果是否为 null?} F -- 否 --> G[写入 Caffeine] G --> H[返回商品] F -- 是 --> I[返回未找到]

第一次请求某个 ID 时：

Caffeine 未命中；
执行加载函数；
查询数据库；
将非空结果写入当前 JVM 的缓存；
返回结果。

后续请求命中同一 Tomcat 实例时，可以直接从内存返回。

5.5 Tomcat 集群中的命中率#

课程后续会启动两个 Tomcat 实例，例如 8081 和 8082。如果 OpenResty 对它们使用轮询：

1
第一次查询 /item/10001 → 8081，建立 8081 的本地缓存
2
第二次查询 /item/10001 → 8082，8082 仍需查询数据库
3
第三次查询 /item/10001 → 8081，命中

因此课程使用请求 URI 做哈希，让同一商品尽量落到同一实例：

1
upstream tomcat-cluster {
2
    hash $request_uri;
3
    server 192.168.150.1:8081;
4
    server 192.168.150.1:8082;
5
}
6

7
location /item {
8
    proxy_pass http://tomcat-cluster;
9
}

其目标是提高 JVM 进程缓存命中率：

flowchart LR A["/item/10001"] --> B["hash(request_uri)"] B --> C[Tomcat 8081] C --> D["8081 的 Caffeine"]

但需要区分两个问题：

固定路由解决的是命中率问题；
缓存同步解决的是数据一致性问题。

哈希路由不会让两个 JVM 共享缓存，也不会自动删除其他实例中的旧值。Tomcat 节点数量变化时，映射还可能重新分布，新节点仍会经历冷缓存。

6. 数据更新与缓存一致性#

只实现查询缓存还不完整。商品或库存发生修改时，旧缓存可能继续被读取。

6.1 常用处理策略#

策略	做法	特点
设置有效期	到期后自动失效，再次查询时重新加载	简单，但过期前可能读到旧值
更新缓存	数据库修改成功后写入新缓存值	时效性强，但并发和失败处理复杂
删除缓存	数据库修改成功后使缓存失效	实现简单，下次查询自然回源
事件通知	修改成功后发布事件，各实例删除或更新本地缓存	适合集群，但要处理消息丢失与重试

当前服务是单实例时，可以在数据库更新成功后删除对应 Key：

1
public void updateItem(Item item) {
2
    itemService.updateById(item);
3
    itemCache.invalidate(item.getId());
4
}

集群部署时，只删除当前实例的 Caffeine 缓存还不够。其他实例仍可能保留旧值，需要借助：

Redis Pub/Sub；
消息队列；
Canal 或数据库变更事件；
配置中心或专门的缓存失效通道；
较短 TTL 作为最终兜底。

6.2 商品与库存应区别对待#

库存更新通常比商品基本信息更频繁，对时效性要求也更高。因此可以考虑：

商品信息采用较长 TTL；
库存采用较短 TTL；
对库存变更主动发送失效通知；
对强一致性库存扣减，不把本地缓存值当作最终扣减依据。

6.3 Canal 同步实现#

采用 Canal 监听 MySQL binlog，再更新 Caffeine 与 Redis。核心逻辑如下：

1
@CanalTable("tb_item")
2
@Component
3
public class ItemHandler implements EntryHandler<Item> {
4

5
    @Autowired
6
    private RedisHandler redisHandler;
7
    @Autowired
8
    private Cache<Long, Item> itemCache;
9

10
    @Override
11
    public void insert(Item item) {
12
        itemCache.put(item.getId(), item);
13
        redisHandler.saveItem(item);
14
    }
15

16
    @Override
17
    public void update(Item before, Item after) {
18
        itemCache.put(after.getId(), after);
19
        redisHandler.saveItem(after);
20
    }
21

22
    @Override
23
    public void delete(Item item) {
24
        itemCache.invalidate(item.getId());
25
        redisHandler.deleteItemById(item.getId());
26
    }
27
}

展开收起

对应配置位于完成版 application.yml：

1
canal:
2
  destination: aron
3
  server: 192.168.150.101:11111

处理链路是：

flowchart LR A[(MySQL)] -->|binlog| B[Canal] B --> C[ItemHandler] C --> D[Caffeine itemCache] C --> E[(Redis)]

这种方案降低了业务写接口与缓存维护代码之间的耦合，但属于异步同步，数据库提交与缓存更新之间仍可能存在短暂时间窗。

7. 监控、测试与调优#

7.1 开启统计#

1
Cache<Long, Item> itemCache = Caffeine.newBuilder()
2
        .maximumSize(10_000)
3
        .recordStats()
4
        .build();
5

6
System.out.println(itemCache.stats().hitRate());
7
System.out.println(itemCache.stats().evictionCount());
8
System.out.println(itemCache.stats().averageLoadPenalty());

建议重点观察：

hitRate()：命中率；
missRate()：未命中率；
loadSuccessCount()：成功加载次数；
loadFailureCount()：加载失败次数；
averageLoadPenalty()：平均加载耗时；
evictionCount()：容量等原因导致的驱逐次数。

命中率不是越高越好。如果为了命中率缓存大量低价值对象，导致堆占用和 GC 压力上升，整体性能反而可能下降。

7.2 基本验证步骤#

启动商品服务；
打开数据库 SQL 日志；
第一次请求某商品 ID，确认执行了 SQL；
再次请求相同 ID，确认不再执行 SQL；
请求另一个 ID，确认会执行新的 SQL；
使指定 Key 失效后再次请求，确认重新查询数据库；
启动两个 Tomcat 实例，分别请求同一 ID，观察两个实例会各自建立缓存；
修改数据库数据，验证失效策略是否能避免长期读取旧值。

7.3 示例单元测试#

1
@Test
2
void shouldLoadOnlyOnceForSameKey() {
3
    AtomicInteger loadCount = new AtomicInteger();
4

5
    Cache<Long, String> cache = Caffeine.newBuilder()
6
            .maximumSize(100)
7
            .build();
8

9
    String first = cache.get(1L, key -> {
10
        loadCount.incrementAndGet();
11
        return "item-1";
12
    });
13

14
    String second = cache.get(1L, key -> {
15
        loadCount.incrementAndGet();
16
        return "item-1-new";
17
    });
18

19
    assertEquals("item-1", first);
20
    assertEquals("item-1", second);
21
    assertEquals(1, loadCount.get());
22
}

展开收起

测试时间过期时，优先使用 Caffeine 提供的可控时间源思路，而不是让测试线程真实等待数秒，这样测试会更快、更稳定。

8. 本章小结#

JVM 进程缓存的核心价值是利用本机内存降低延迟和下游访问压力。Caffeine 在普通 Map 的基础上补齐了容量控制、过期、并发加载、统计等能力，适合实现 Java 服务内部的一级缓存。

落地时应同时回答五个问题：

缓存什么：是否为高频、可重建、体积可控的数据？
如何加载：是否使用原子加载避免同一进程内重复回源？
保存多久：容量和过期策略如何设置？
如何更新：数据变化时怎样删除或刷新各实例缓存？
如何观测：命中率、加载失败、驱逐次数和 JVM 内存是否健康？

只有把读取、失效、一致性和监控一起设计，进程缓存才能稳定地成为多级缓存体系中的一层，而不是新的数据风险来源。

参考资料#

Redis Cluster 分片集群原理、部署与实践

Thu, 30 Jul 2026 00:00:00 GMT

讲义实验环境使用 Redis 6.2.4；本文同时说明 Redis 7.x/8.x 中仍适用的核心机制。具体命令和配置应以生产版本的官方文档为准。

1. 为什么需要 Redis Cluster#

普通主从复制和 Sentinel 可以解决：

master 故障后的自动切换。
通过 replica 扩展部分读取能力。
提供在线数据副本。

但它们仍然只有一个逻辑写 master，存在两个主要瓶颈：

容量瓶颈：所有数据必须能放入单个 master 的内存。
写入瓶颈：所有写请求仍由单个 master 处理。

Redis Cluster 将完整键空间拆分给多个 master：

不同 master 保存不同数据。
多个 master 可以并行处理读写请求。
每个 master 可以配置一个或多个 replica。
master 故障后，其 replica 可以自动提升。
增加 master 并迁移一部分槽位后，可以水平扩展容量和吞吐。

一句话概括：

Redis Cluster 通过固定的 16384 个 Hash Slot 对数据进行分片，并通过主从复制、Gossip 和多数派选举提供分片级高可用。

2. Sentinel 与 Redis Cluster 的区别#

对比项	Sentinel 主从架构	Redis Cluster
数据分布	所有 master/replica 保存同一份数据	不同 master 保存不同槽位的数据
写 master 数量	一个	多个
水平扩展写能力	不支持	支持
水平扩展容量	不支持	支持
自动故障转移	支持	支持
服务发现	Sentinel 提供当前 master 地址	Cluster 客户端维护槽位到节点映射
多 key 命令	单机语义	所有 key 通常必须属于同一槽位
数据库	支持多个逻辑 DB	只支持 DB 0
适用场景	单 master 容量和写吞吐足够	数据量或写吞吐需要多 master 分担

Redis Cluster 不是“多个互为主节点、每个节点都有全部数据”的多主复制系统。每个 master 只负责部分槽位。

3. 集群基本结构#

一个常见的六节点集群：

1
                    Redis Cluster
2

3
        Shard A          Shard B          Shard C
4
    ┌────────────┐   ┌────────────┐   ┌────────────┐
5
    │ Master A   │   │ Master B   │   │ Master C   │
6
    │ slots      │   │ slots      │   │ slots      │
7
    │ 0-5460     │   │ 5461-10922 │   │10923-16383 │
8
    └─────┬──────┘   └─────┬──────┘   └─────┬──────┘
9
          │复制              │复制              │复制
10
    ┌─────▼──────┐   ┌─────▼──────┐   ┌─────▼──────┐
11
    │ Replica A1 │   │ Replica B1 │   │ Replica C1 │
12
    └────────────┘   └────────────┘   └────────────┘
13

14
    所有节点通过 Cluster Bus 组成全连接拓扑，
15
    交换心跳、Gossip、槽位配置和故障转移消息。

展开收起

3.1 Shard 的含义#

一个逻辑分片通常由：

一个负责槽位和读写的 master。
零个、一个或多个保存该 master 数据副本的 replica。

1
Shard = Master + Replicas

replica 默认不负责该分片的业务写入。master 故障后，合格 replica 可以通过集群选举被提升。

3.2 最小与推荐节点数#

Redis 官方文档指出：

正常工作的最小集群需要至少 3 个 master。
生产通常至少使用 3 master + 3 replica。

三个 master 的原因：

故障确认和 replica 提升需要 master 多数派参与。
两个 master 无法形成稳健的多数派容错结构。

六节点也不是所有生产系统的固定答案。实际副本数还取决于：

可用区数量。
允许的故障范围。
数据恢复目标。
内存成本。
跨可用区网络质量。

3.3 故障域部署#

生产建议：

同一 shard 的 master 与 replica 不部署在同一宿主机。
replica 尽量位于不同机架或可用区。
不要把三个 master 全部放在同一故障域。
节点之间的客户端端口和 Cluster Bus 端口都必须互通。
客户端必须能访问集群通告出来的所有节点地址。

4. Hash Slot 数据分片模型#

Redis Cluster 不使用传统的一致性哈希环，而是把键空间划分为固定的 16384 个槽位：

1
slot 范围：0 ～ 16383
2
槽位总数：16384

每个槽位在同一时刻由一个 master 负责。

1
Key
2
 │
3
 ├─提取有效哈希内容
4
 │
5
 ├─CRC16
6
 │
7
 ├─对 16384 取模
8
 │
9
 ↓
10
Hash Slot
11
 │
12
 ↓
13
负责该槽位的 Master

基本计算公式：

1
slot = CRC16(key) mod 16384

也可以写成：

1
slot = CRC16(key) & 16383

4.1 Key 绑定的是槽位，不是物理节点#

需要理解：

key 经过哈希计算后属于某个 slot。
slot 当前归某个 master 管理。
扩缩容时迁移的是 slot 及其 key。
key 的 slot 通常不会变化，但 slot 的负责节点可以变化。

因此客户端维护的是：

1
slot → master 地址

而不是：

1
key → 永久固定节点

4.2 查看 key 的槽位#

1
CLUSTER KEYSLOT user:1001

示例：

1
CLUSTER KEYSLOT foo{order:1001}
2
CLUSTER KEYSLOT bar{order:1001}

两者使用相同 Hash Tag，返回相同 slot。

5. Hash Tag：让相关 key 落在同一槽位#

如果 key 中存在第一个有效的 {...} 结构，Redis 只对大括号中的非空内容计算哈希。

1
普通 key：
2
user:1001:name
3
有效哈希内容 = user:1001:name
4

5
Hash Tag key：
6
user:{1001}:name
7
user:{1001}:orders
8
有效哈希内容都为 1001

这两个 key 会落在同一槽位：

1
user:{1001}:profile
2
order:{1001}:recent

5.1 精确规则#

只有同时满足以下条件才使用 Hash Tag：

key 包含 {。
在该 { 右侧存在 }。
第一个匹配的 { 和其右侧第一个 } 之间至少有一个字符。

Key	实际参与哈希的内容
`user:1001`	整个 `user:1001`
`{user1001}.name`	`user1001`
`{user1001}.orders`	`user1001`
`foo{}{bar}`	整个 key，因为第一个 `{}` 为空
`foo{{bar}}zap`	`{bar`
`foo{bar}{zap}`	`bar`

5.2 Hash Tag 的用途#

Hash Tag 主要用于：

让多 key 命令中的所有 key 位于同一槽位。
让 Lua 脚本或事务涉及的 key 位于同一槽位。
将同一业务聚合的相关数据放入同一个 shard。

示例：

1
MSET order:{1001}:status paid order:{1001}:amount 99
2
MGET order:{1001}:status order:{1001}:amount

5.3 Hash Tag 的风险#

Hash Tag 不是越多越好。设计不当会产生热点：

1
所有商品 key 都使用 {product}
2
                 ↓
3
所有商品落入同一个 slot
4
                 ↓
5
一个 master 承担绝大多数流量和内存

建议：

Tag 颗粒度使用租户 ID、用户 ID、订单 ID 等业务聚合标识。
不要让所有业务 key 共享同一个 Tag。
在保证多 key 原子操作的同时保持槽位分布均衡。
监控 hot key、big key 和各 master 的内存、QPS 差异。

6. 多 Key 命令与 CROSSSLOT#

Redis Cluster 的服务器端多 key 操作通常要求所有 key 属于同一槽位。

错误示例：

1
MGET user:1 user:2

如果两个 key 不在同一槽位，可能返回：

1
CROSSSLOT Keys in request don't hash to the same slot

使用 Hash Tag：

1
MGET {user}:1 {user}:2

两个 key 对 {user} 哈希，可以在同一槽位执行。

6.1 受影响的操作#

需要特别检查：

MGET、MSET
集合的交、并、差运算
RENAME、RENAMENX
事务 MULTI/EXEC
Lua 脚本和 Redis Functions
涉及多个 key 的阻塞命令
pipeline 中要求服务端原子或同节点执行的业务

有些客户端会把部分跨槽操作拆成多次单 key 请求并在客户端合并结果，但这会改变：

原子性。
网络开销。
错误语义。
返回时延。

不能因为客户端“能够执行”就假定它仍等同于单机上的一个原子命令。

6.2 Lua 脚本和事务#

脚本或事务所访问的 key 应：

在调用时显式声明。
全部属于同一槽位。
不要在脚本内部动态拼接并访问未知跨槽 key。

典型分布式锁的锁 key、状态 key 和 fencing token 如需同一脚本操作，应使用相同 Hash Tag。

7. 节点通信与 Cluster Bus#

Redis Cluster 节点之间不通过普通客户端协议完成所有集群协作，而是使用专门的二进制 Cluster Bus。

默认情况下：

1
客户端端口：6379
2
Cluster Bus：16379，即客户端端口 + 10000

如果节点客户端端口为 7001：

1
客户端端口：7001
2
Cluster Bus：17001

也可以通过配置显式指定 Bus 端口：

1
cluster-port 17001

7.1 Cluster Bus 用途#

节点握手和自动发现。
PING/PONG 心跳。
Gossip 故障信息传播。
槽位映射和配置纪元传播。
master 故障确认。
replica 选举与提升。
Pub/Sub 和其他集群内部消息。

7.2 全连接拓扑#

集群节点之间维持全连接关系：

1
N 个节点中，每个节点维护到其他节点的连接。

业务客户端不应直接使用 Cluster Bus 协议；客户端只连接普通 Redis 数据端口。

7.3 防火墙要求#

每个节点至少需要：

客户端数据端口对客户端和集群节点开放。
Cluster Bus 端口对其他集群节点开放。

如果只开放数据端口、不开放 Bus 端口：

单节点可能仍能被 redis-cli 连接。
但节点无法正常交换集群消息。
故障检测、槽位传播和故障转移会异常。

Cluster Bus 端口不应暴露到不可信公网。

8. 节点标识、拓扑与配置纪元#

8.1 Node ID#

每个 Cluster 节点都有持久化 Node ID，例如：

1
07c37dfeb235213a872192d90877d0cd55635b91

Node ID：

在节点首次启动时生成。
存储在集群配置文件中。
节点地址改变时通常仍保持不变。
用于复制关系、槽位归属和集群命令。

8.2 nodes.conf#

配置示例：

1
cluster-config-file nodes-7001.conf

该文件由 Redis 自动维护，保存：

Node ID。
已知节点。
master/replica 关系。
槽位归属。
配置纪元。
故障和迁槽状态。

注意：

不应手工编辑 nodes.conf。
每个 Redis 进程必须使用独立文件。
文件所在目录必须可写。
同一主机多个实例不能共用一个 nodes.conf。
删除或错误复制该文件可能改变节点身份并破坏拓扑。

8.3 configEpoch#

configEpoch 是槽位配置的逻辑版本：

故障转移会生成新的、递增且唯一的配置纪元。
如果多个节点声称拥有同一槽位，较新的配置纪元优先。
网络分区恢复后，旧节点会接受更新的槽位配置。

9. 请求路由：MOVED 与 ASK#

讲义中“访问任意节点，最终会被转发到正确节点”的说法需要更精确地理解：

Redis Cluster 节点通常不会像代理一样替客户端转发业务请求，而是返回重定向错误；Cluster 客户端根据错误重新连接正确节点。

9.1 MOVED：永久槽位归属重定向#

客户端向错误节点发送：

1
GET order:1001

节点可能返回：

1
-MOVED 3999 192.168.150.102:7002

含义：

key 属于 slot 3999。
slot 3999 当前由 192.168.150.102:7002 负责。
客户端应向该节点重新发送命令。
客户端应更新本地槽位映射。

1
Client ──GET key──→ Node A
2
Client ←─MOVED──── Node A
3
Client ──GET key──→ Node B
4
Client ←─value──── Node B

9.2 ASK：迁槽期间的一次性重定向#

槽位正在从 A 迁移到 B 时，部分 key 已在 B，部分仍在 A。

源节点可能返回：

1
-ASK 3999 192.168.150.102:7002

客户端应：

只把当前这一次命令发送到 B。
先向 B 发送 ASKING。
再发送原命令。
不要立即永久修改本地 slot 映射。

1
Client ──GET key──→ Node A
2
Client ←──ASK───── Node A
3
Client ──ASKING──→ Node B
4
Client ──GET key──→ Node B
5
Client ←─value──── Node B

9.3 MOVED 与 ASK 对比#

对比项	MOVED	ASK
含义	槽位已归另一个节点负责	槽位正在迁移，本次命令临时去目标节点
是否更新客户端槽位表	是，通常刷新完整拓扑	否
是否先发送 `ASKING`	否	是
常见时机	正常路由错误、故障转移后	在线 reshard 期间

9.4 redis-cli 的 `-c`#

普通连接：

Terminal window

1
redis-cli -p 7001

收到 MOVED 后只会显示错误。

Cluster 跟随重定向模式：

Terminal window

1
redis-cli -c -p 7001

-c 会帮助命令行客户端处理重定向。生产应用仍应使用真正支持 Redis Cluster 的客户端。

10. Cluster 客户端应如何工作#

Cluster 客户端通常维护：

1
16384 个槽位 → 当前 master 地址

启动流程：

连接任意一个可用的 seed 节点。
获取当前 shard 和槽位映射。
根据 key 在客户端计算 slot。
直接把命令发送到负责该 slot 的节点。
收到 MOVED 时刷新槽位映射。
收到 ASK 时完成一次性重定向。
节点故障或拓扑变化后重新建立连接。

较新客户端和运维工具应优先使用：

1
CLUSTER SHARDS

CLUSTER SLOTS 已被标记为弃用，但为了兼容旧客户端仍广泛存在。

10.1 Seed 节点#

客户端配置中的节点列表是启动入口，不是静态完整拓扑。

建议：

配置多个位于不同故障域的 seed 节点。
不必在所有客户端中列出每一个节点，但不能只依赖一个节点。
客户端发现的节点地址必须从客户端网络可达。
故障转移和扩容后允许客户端刷新拓扑。

11. 核心配置#

实验节点的基本配置：

1
port 7001
2

3
cluster-enabled yes
4
cluster-config-file nodes-7001.conf
5
cluster-node-timeout 5000
6

7
dir /var/lib/redis/7001
8

9
appendonly yes
10
appendfsync everysec

11.1 配置项说明#

配置项	作用	注意事项
`cluster-enabled yes`	开启 Cluster 模式	每个集群节点都要配置
`cluster-config-file`	Redis 自动维护的集群状态文件	每个实例必须独立且可写
`cluster-node-timeout`	节点不可达和故障处理的基础超时	应明显大于正常网络 RTT
`cluster-port`	显式指定 Cluster Bus 端口	不指定时通常为数据端口 + 10000
`cluster-require-full-coverage`	是否要求所有槽位都可用时集群才接受请求	默认倾向完整覆盖
`cluster-replica-validity-factor`	控制断链过久的 replica 是否仍可自动提升	设为 0 会放宽新鲜度限制
`cluster-migration-barrier`	replica 自动迁移后原 master 至少保留的健康副本数	常见默认值为 1
`cluster-replica-no-failover`	禁止该 replica 自动参与故障转移	灾备拓扑中可能使用

11.2 不要照搬实验安全配置#

讲义实验中使用：

1
bind 0.0.0.0
2
protected-mode no

这只适合隔离实验环境。生产应：

绑定明确的内网地址。
保持保护机制。
配置 ACL 和强密码。
使用防火墙限制客户端端口。
Cluster Bus 只允许集群节点访问。
跨不可信网络时启用 TLS。

12. NAT、容器与地址通告#

Redis Cluster 客户端会根据节点通告的地址直连所有 master。容器内部地址或 NAT 后错误地址会导致：

客户端能连接 seed，但无法连接其他节点。
不断收到 MOVED 后连接失败。
节点之间 Cluster Bus 无法建立连接。

常见配置：

1
cluster-announce-ip 192.168.150.101
2
cluster-announce-port 7001
3
cluster-announce-bus-port 17001

每个节点都应通告：

其他集群节点可访问的地址。
业务客户端可访问的地址。
与端口映射一致的数据端口和 Bus 端口。

讲义中的 replica-announce-ip 主要属于复制地址通告；Redis Cluster 的客户端和 Bus 地址应重点检查 cluster-announce-* 配置。

13. 创建一个六节点集群#

实验拓扑：

节点	初始角色	说明
`192.168.150.101:7001`	master	Shard A
`192.168.150.101:7002`	master	Shard B
`192.168.150.101:7003`	master	Shard C
`192.168.150.101:8001`	replica	复制某个 master
`192.168.150.101:8002`	replica	复制某个 master
`192.168.150.101:8003`	replica	复制某个 master

创建前要求：

所有节点为空。
所有节点已开启 Cluster 模式。
节点之间的数据端口和 Bus 端口互通。
使用独立工作目录和 nodes.conf。
节点的通告地址正确。

Redis 5.0 及以后：

Terminal window

1
redis-cli --cluster create \
2
  192.168.150.101:7001 \
3
  192.168.150.101:7002 \
4
  192.168.150.101:7003 \
5
  192.168.150.101:8001 \
6
  192.168.150.101:8002 \
7
  192.168.150.101:8003 \
8
  --cluster-replicas 1

--cluster-replicas 1 表示希望每个 master 配置一个 replica。

创建后检查：

Terminal window

1
redis-cli -p 7001 CLUSTER INFO
2
redis-cli -p 7001 CLUSTER NODES
3
redis-cli -p 7001 CLUSTER SHARDS
4
redis-cli --cluster check 192.168.150.101:7001

健康集群应满足：

cluster_state:ok。
0～16383 所有槽位均已分配。
三个 master 分别持有槽位。
每个 master 至少有预期 replica。
所有节点的 link-state 正常。

14. 查看集群状态#

14.1 CLUSTER INFO#

1
CLUSTER INFO

常见字段：

字段	含义
`cluster_state`	当前节点看到的集群总体状态
`cluster_slots_assigned`	已分配槽位数
`cluster_slots_ok`	正常槽位数
`cluster_slots_pfail`	关联 PFAIL 节点的槽位数
`cluster_slots_fail`	关联 FAIL 节点的槽位数
`cluster_known_nodes`	当前已知节点数
`cluster_size`	至少负责一个槽位的 master 数
`cluster_current_epoch`	当前集群配置纪元
`cluster_my_epoch`	当前节点的配置纪元
`cluster_stats_messages_*`	Cluster Bus 消息统计

14.2 CLUSTER NODES#

1
CLUSTER NODES

每行包含：

1
node-id endpoint flags master-id ping-sent pong-recv config-epoch link-state slots

常见 flags：

flag	含义
`myself`	当前查询节点
`master`	master
`slave`	协议兼容字段，表示 replica
`fail?`	PFAIL，当前节点怀疑其故障
`fail`	FAIL，故障已被足够 master 确认
`handshake`	正在进行节点握手
`noaddr`	地址未知
`nofailover`	replica 不参与自动提升

14.3 CLUSTER SHARDS#

1
CLUSTER SHARDS

用于查看：

shard 的槽位范围。
master 节点。
replica 节点。
节点 endpoint、角色和健康状态。

它比手工解析 CLUSTER NODES 更适合新客户端获取拓扑。

15. 在线扩容：添加 master 并迁移槽位#

新 master 加入集群后默认没有槽位，因此也不会承载普通 key。

15.1 添加空节点#

Terminal window

1
redis-cli --cluster add-node \
2
  192.168.150.101:7004 \
3
  192.168.150.101:7001

参数含义：

第一个地址是新节点。
第二个地址是集群中任意一个可达的已有节点。

检查：

Terminal window

1
redis-cli -p 7001 CLUSTER NODES

此时 7004 通常是：

1
master，0 slots

15.2 迁移槽位#

交互式 reshard：

Terminal window

1
redis-cli --cluster reshard 192.168.150.101:7001

需要指定：

迁移多少个槽位。
接收槽位的新 master Node ID。
从哪些源 master 迁移。

也可以在自动化中提供对应 --cluster-* 参数，但生产迁移前应先在目标版本的 redis-cli --cluster help 中确认语法。

15.3 槽位迁移的内部状态#

假设 slot 2765 从 A 迁移到 B：

1
1. B 将 2765 标记为 IMPORTING，来源 A
2
2. A 将 2765 标记为 MIGRATING，目标 B
3
3. 从 A 获取该槽位中的 key
4
4. 使用 MIGRATE 将 key 原子地移动到 B
5
5. B 成为 2765 的正式 owner
6
6. A 和其他 master 更新 slot 2765 的归属

底层涉及：

1
CLUSTER SETSLOT 2765 IMPORTING <source-node-id>
2
CLUSTER SETSLOT 2765 MIGRATING <target-node-id>
3
CLUSTER GETKEYSINSLOT 2765 100
4
MIGRATE ...
5
CLUSTER SETSLOT 2765 NODE <target-node-id>

通常应使用 redis-cli --cluster reshard，避免人工执行底层命令时顺序错误。

15.4 迁移期间的请求行为#

源节点 A：

key 仍在 A：直接处理。
key 已经迁走或新 key 不在 A：返回 ASK 到 B。

目标节点 B：

收到普通请求但尚未正式拥有槽位：通常返回 MOVED。
收到 ASKING 后的请求：允许处理该导入槽位的当前命令。

15.5 迁槽风险#

big key 会延长单次迁移阻塞和网络传输时间。
热点槽位迁移时重定向和延迟可能增加。
多 key 命令在相关槽位迁移时可能返回 TRYAGAIN。
源和目标节点的内存峰值需要预留。
客户端必须正确支持 ASK。
迁移中断可能留下 MIGRATING/IMPORTING 状态。

迁移前应治理 big key，并在低峰期分批执行。

16. 添加 replica#

添加新的 replica：

Terminal window

1
redis-cli --cluster add-node \
2
  192.168.150.101:8004 \
3
  192.168.150.101:7001 \
4
  --cluster-slave

如果要指定复制某个 master：

Terminal window

1
redis-cli --cluster add-node \
2
  192.168.150.101:8004 \
3
  192.168.150.101:7001 \
4
  --cluster-slave \
5
  --cluster-master-id <master-node-id>

也可以先把节点作为空 master 加入，再在新节点执行：

1
CLUSTER REPLICATE <master-node-id>

添加后确认：

1
CLUSTER NODES
2
CLUSTER REPLICAS <master-node-id>
3
INFO REPLICATION

17. 缩容与删除节点#

17.1 删除 replica#

Terminal window

1
redis-cli --cluster del-node \
2
  192.168.150.101:7001 \
3
  <replica-node-id>

17.2 删除 master#

master 必须先清空其槽位：

将该 master 的所有槽位 reshard 到其他 master。
确认它不再负责任何 slot。
确认业务客户端拓扑已经刷新。
再执行 del-node。

Terminal window

1
redis-cli --cluster del-node \
2
  192.168.150.101:7001 \
3
  <empty-master-node-id>

不能直接删除仍持有槽位的 master。

17.3 删除不可达故障节点#

故障节点不可连接时，普通 del-node 可能失败。可以根据实际版本和场景对每个节点执行：

1
CLUSTER FORGET <node-id>

或使用：

Terminal window

1
redis-cli --cluster call \
2
  192.168.150.101:7001 \
3
  CLUSTER FORGET <node-id>

执行前必须确认：

故障节点不会带着旧配置重新加入。
其槽位已经由新 master 正式接管。
集群中所有节点最终都忘记了该 Node ID。

18. 负载均衡与 Rebalance#

增加 master 后只“加入节点”不会自动平均迁移全部槽位。

可使用：

Terminal window

1
redis-cli --cluster rebalance 192.168.150.101:7001

Rebalance 的目标通常是按节点权重重新分配槽位数量。

但槽位数量均衡不等于负载均衡：

1
每个 Master 槽位数相同
2
≠
3
每个 Master 的 key 数、内存、QPS 和网络流量相同

原因：

不同 slot 的 key 数量不同。
key 大小差异巨大。
某些 key 或 Tag 是热点。
不同数据结构的 CPU 成本不同。

真正的均衡应同时观察：

槽位数。
key 数。
内存使用量。
QPS。
CPU。
网络带宽。
命令延迟。
hot key 和 big key。

19. 自动故障检测：PFAIL 与 FAIL#

Redis Cluster 不依赖 Sentinel。所有 Cluster 节点通过 Cluster Bus 自行完成故障检测。

19.1 PFAIL#

PFAIL 表示 Possible Failure：

某个节点根据自己的本地观察，认为另一个节点超过 cluster-node-timeout 没有正常响应。

1
单个节点的本地主观判断 → PFAIL

master 和 replica 都可以把其他节点标记为 PFAIL。

19.2 FAIL#

PFAIL 不足以触发 replica 提升。故障报告通过 Gossip 传播，当足够多的 master 在有效时间窗口内确认目标不可达时，目标进入 FAIL。

1
多数 master 的有效故障报告 → FAIL

19.3 与 Sentinel 的类比#

Sentinel	Redis Cluster
SDOWN	PFAIL
ODOWN	FAIL
Sentinel 多数派授权	master 多数派参与 replica 选举

二者概念相似，但协议、角色和实现并不相同。

20. 自动故障转移#

假设 Master B 故障，它负责一部分槽位并拥有 Replica B1。

1
Master B 失联
2
    │
3
    ↓
4
部分节点标记 PFAIL
5
    │
6
    ↓
7
多数 master 确认 FAIL
8
    │
9
    ↓
10
Replica B1 发起选举
11
    │
12
    ↓
13
获得 master 多数派授权
14
    │
15
    ↓
16
B1 提升为新 Master
17
    │
18
    ↓
19
新 configEpoch 和槽位归属传播

展开收起

20.1 replica 参与提升的基本条件#

它的 master 已处于 FAIL。
原 master 负责至少一个槽位。
replica 与 master 断链没有久到超过允许的新鲜度范围。
replica 未被配置为禁止故障转移。
它能联系到足够 master 并获得选票。

20.2 数据更新程度与选举延迟#

同一 master 的多个 replica 会根据复制进度形成不同的选举延迟：

offset 越新，通常越早尝试选举。
offset 较旧，延迟更长。
最终只有一个 replica 获得多数 master 授权。

这与 Sentinel 中按 replica-priority → offset → run ID 选择候选节点的流程不同。

20.3 configEpoch 的作用#

新 master 获得新的配置纪元并广播：

自己现在负责原 master 的槽位。
其他节点采用更新的槽位配置。
旧 master 恢复后不能用旧配置夺回槽位。

21. 集群何时不可用#

默认安全取向下，常见不可用条件包括：

大多数 master 不可达，集群处于少数派分区。
某个 master 和它的所有可提升 replica 同时不可用。
存在未覆盖槽位，并要求 full coverage。
节点之间 Cluster Bus 被阻断。
槽位配置冲突或迁移状态异常。

21.1 cluster-require-full-coverage#

1
cluster-require-full-coverage yes

当任意槽位没有可用 owner 时，集群倾向停止接受查询，避免向客户端呈现不完整键空间。

设置为 no 时，仍有 owner 的槽位可以继续服务，但应用会得到“部分 key 可用、部分 key 不可用”的状态。

取舍：

配置	优点	风险
`yes`	语义明确，不返回不完整键空间	单个 shard 丢失可能使整个集群不可用
`no`	健康 shard 可继续服务	应用必须能处理部分可用和跨槽操作失败

不能只为了“高可用”就盲目改为 no，应根据业务是否能接受部分数据不可用来决定。

22. 手动故障转移#

在准备提升的 replica 上执行：

1
CLUSTER FAILOVER

适合：

滚动升级。
主机维护。
主动切换主从。
将业务平滑迁离某个 master。

22.1 默认模式#

1
CLUSTER FAILOVER

简化流程：

replica 请求 master 暂停处理客户端写入。
master 把当前复制 offset 告诉 replica。
replica 等待自己追平该 offset。
replica 向其他 master 请求故障转移授权和新配置纪元。
replica 提升为 master 并广播配置。
原 master 接受新配置并成为 replica。

默认模式最重视数据一致性，适合计划内切换。

22.2 FORCE#

1
CLUSTER FAILOVER FORCE

不与原 master 协调。
适用于原 master 无法访问，但集群仍可形成故障转移授权的情况。
仍需要 Cluster 的多数派授权。
可能丢失 replica 尚未收到的写入。

22.3 TAKEOVER#

1
CLUSTER FAILOVER TAKEOVER

跳过与原 master 的协调。
还绕过正常的集群多数派授权。
可能违反正常配置纪元和“最后一次故障转移获胜”的安全原则。
只应在明确理解网络分区和数据冲突风险时使用。

对比：

模式	原 master 协调	offset 追平	多数派授权	风险
默认	是	是	是	最低
`FORCE`	否	不保证	是	可能丢数据
`TAKEOVER`	否	不保证	否	最高，可能造成冲突

命令返回 OK 只表示故障转移已被调度，不等于已经成功。之后必须检查：

1
ROLE
2
INFO REPLICATION
3
CLUSTER NODES
4
CLUSTER SHARDS

23. Replica Migration#

Redis Cluster 可以把 replica 从“副本过多的 master”迁移给“没有健康副本的 master”，提高后续故障的可恢复性。

示例：

1
Master A：0 个 Replica
2
Master B：1 个 Replica
3
Master C：2 个 Replica
4

5
在满足迁移屏障条件时，
6
Master C 的一个 Replica 可自动改为复制 Master A。

24. 数据一致性与丢失窗口#

Redis Cluster 的 shard 内仍使用异步主从复制。

可能丢数据的基本场景：

1
Client ──写入──→ Master
2
Client ←─OK──── Master
3
                   │
4
                   │ 尚未复制到 Replica
5
                   × Master 故障
6

7
Replica 被提升，但缺少刚才的写入。

24.1 少数派分区中的旧 master#

如果客户端仍能访问处于少数派网络中的旧 master，它可能在一段时间内接受写入。多数派一侧完成故障转移后，旧 master 恢复连接并采用新配置，少数派期间的独有写入可能丢失。

可以在所有可能成为 master 的节点配置：

1
min-replicas-to-write 1
2
min-replicas-max-lag 10

以限制无法连接足够 replica 的 master 继续写入的时间窗口。

代价是 replica 或网络异常时 master 可能拒绝写入。

24.2 WAIT#

关键写入可以评估：

1
SET order:{1001}:status paid
2
WAIT 1 1000

WAIT 能提高写入已经到达 replica 的概率，但不能：

将 Redis 变成强一致数据库。
保证写入已经按要求落盘。
替代 RDB、AOF 和独立备份。
消除网络分区中的全部数据丢失风险。

25. 持久化与备份#

每个 master 只保存一部分数据，因此每个 shard 都必须有独立的数据保护。

建议所有可能成为 master 的节点启用合适的持久化，例如：

1
appendonly yes
2
appendfsync everysec

并根据 RPO/RTO 配置 RDB 和集群外备份。

25.1 Cluster 不等于备份#

误删 key 会通过复制传播给 replica。
程序错误可以同时污染所有 shard。
FLUSHALL、错误脚本或错误迁槽会影响整个集群。
多节点在线副本无法替代历史版本备份。

备份恢复必须考虑：

每个 shard 的备份时间点。
槽位映射和 Node ID。
恢复到新集群还是原集群。
跨 shard 数据的一致时间点。
恢复后的重新分片和客户端切换。

26. Spring Boot 与 RedisTemplate#

Spring Boot 3.x：

1
spring:
2
  data:
3
    redis:
4
      username: app-user
5
      password: app-password
6
      cluster:
7
        nodes:
8
          - 192.168.150.101:7001
9
          - 192.168.150.102:7002
10
          - 192.168.150.103:7003
11
        max-redirects: 5
12
      connect-timeout: 2s
13
      timeout: 2s

较早 Spring Boot 版本常使用：

1
spring:
2
  redis:
3
    cluster:
4
      nodes:
5
        - 192.168.150.101:7001
6
        - 192.168.150.101:7002
7
        - 192.168.150.101:7003

具体属性以前端项目实际 Spring Boot 版本为准。

26.1 Seed 节点不必列出全部节点#

cluster.nodes 用于启动拓扑发现。客户端连接成功后会获取完整槽位和节点信息。

但建议至少配置多个不同故障域的可用入口。

26.2 Topology Refresh#

Lettuce 客户端应具备拓扑刷新能力：

启动时加载拓扑。
收到 MOVED 时刷新。
在故障转移和伸缩后更新连接。
可根据客户端版本配置周期刷新或自适应刷新。

具体属性名称和默认值随 Spring Boot / Lettuce 版本变化，应以项目依赖版本文档为准。

26.3 Replica 读取#

Lettuce 支持把部分读取路由到 replica，但要注意：

主从复制异步，可能读到旧数据。
写后立即读、锁、余额、库存等强时效业务应读 master。
Cluster 的副本读取需要客户端支持并正确发送只读连接语义。
replica 故障或提升后客户端必须刷新拓扑。

26.4 RedisTemplate 的集群操作#

1
ClusterOperations<String, Object> clusterOps =
2
        redisTemplate.opsForCluster();

集群级操作与普通 key 操作不同：

普通 key 命令由客户端按槽位路由。
查看所有节点、在指定节点执行命令等需要 Cluster API。
对单个节点执行 KEYS 只能看到该节点负责的数据。
Spring Data Redis 的聚合集群操作可能向多个 master 并行发送命令，成本远高于单机命令。

27. 命令和功能限制#

27.1 只支持 DB 0#

Redis Cluster 不支持多个逻辑数据库：

1
SELECT 1

不可用于 Cluster。

业务隔离应使用：

key 前缀。
不同集群。
不同 Redis 实例或托管数据库。
ACL 权限。

27.2 KEYS 与 SCAN#

在某个节点执行：

1
KEYS *

只能看到该节点当前保存的 key，不等于整个集群。

全集群扫描需要：

获取所有 master。
分别对每个 master 使用 SCAN。
聚合结果并处理拓扑变化。

生产中不要使用 KEYS * 扫描大型节点。

Redis 8.0 起，某些明确包含单槽 Hash Tag 的 glob pattern 可以只扫描对应槽位，但仍需以客户端和服务端实际版本行为为准。

27.3 Keyspace Notification#

keyspace notification 是节点本地事件，不会自动汇总整个 Cluster。监听随机单节点会漏掉其他 shard 的事件。

需要全集群事件时：

在所有 master 上建立订阅。
处理故障转移和拓扑刷新。
或使用更适合可靠事件传递的 Stream / 消息队列方案。

27.4 Pub/Sub#

传统 Pub/Sub 和分片 Pub/Sub 的传播范围及路由不同。高规模 Cluster 应根据 Redis 版本评估 Sharded Pub/Sub：

1
SSUBSCRIBE channel
2
SPUBLISH channel message

不要把普通 Pub/Sub 当作可靠消息队列。

28. 常用运维命令#

集群状态#

1
CLUSTER INFO
2
CLUSTER NODES
3
CLUSTER SHARDS
4
CLUSTER LINKS
5
CLUSTER MYID

槽位与 key#

1
CLUSTER KEYSLOT <key>
2
CLUSTER COUNTKEYSINSLOT <slot>
3
CLUSTER GETKEYSINSLOT <slot> <count>

节点与复制#

1
CLUSTER REPLICAS <master-node-id>
2
CLUSTER REPLICATE <master-node-id>
3
ROLE
4
INFO REPLICATION

redis-cli 集群管理#

Terminal window

1
redis-cli --cluster help
2
redis-cli --cluster check <host:port>
3
redis-cli --cluster info <host:port>
4
redis-cli --cluster add-node <new> <existing>
5
redis-cli --cluster del-node <existing> <node-id>
6
redis-cli --cluster reshard <host:port>
7
redis-cli --cluster rebalance <host:port>
8
redis-cli --cluster fix <host:port>

--cluster fix 可能修改槽位状态和数据位置，执行前必须：

备份。
明确故障原因。
保存 CLUSTER NODES、CLUSTER INFO 和日志。
在可控窗口操作。

29. 常见故障排查#

现象	常见原因	排查方向
`MOVED` 被直接返回给应用	客户端不支持 Cluster 或未开启重定向	使用 Cluster-aware 客户端；命令行加 `-c`
`CROSSSLOT`	多个 key 不在同一 slot	用 `CLUSTER KEYSLOT` 检查，设计 Hash Tag
`CLUSTERDOWN Hash slot not served`	槽位无 owner 或关联节点故障	`CLUSTER INFO`、`CLUSTER NODES`、迁槽状态
`CLUSTERDOWN The cluster is down`	丢失多数 master、全覆盖失败或 Bus 异常	检查 master 多数派、槽位覆盖和 Bus 端口
`TRYAGAIN`	迁槽中的多 key 请求部分 key 已移动	等待迁移完成并重试
客户端能连 seed 但其他命令失败	节点通告了客户端不可达地址	检查 `cluster-announce-*`、NAT 和 DNS
节点都能连接但不能组成集群	Bus 端口被拦截或 Node ID/配置冲突	检查 Bus、防火墙和 `nodes.conf`
新 master 加入后没有流量	新节点没有 slot	执行 reshard/rebalance
无法删除 master	master 仍持有槽位或 key	先迁空所有 slot
master 故障但 replica 未提升	无多数派、replica 过旧或被禁止 failover	查看 flags、复制状态、有效性配置
故障转移后客户端仍连接旧节点	拓扑刷新未生效	检查 `MOVED` 处理和 topology refresh
各节点内存严重不均	槽位 key 分布不均、big key 或 Hash Tag 热点	比较 key/内存/QPS，不只看 slot 数
迁槽速度很慢	big key、网络慢、目标内存压力	检查 key 大小、延迟和资源峰值
节点重启后变成陌生节点	`nodes.conf` 丢失或复用了错误文件	恢复正确集群配置文件，检查 Node ID

参考资料#

Redis Sentinel（哨兵）原理、部署与实践

Thu, 30 Jul 2026 00:00:00 GMT

1. Sentinel 解决什么问题#

Redis 主从复制可以提供数据副本，但单纯的主从复制不能自动处理 master 故障：

客户端通常只向 master 写入。
master 宕机后，replica 不会仅凭普通主从配置自动成为 master。
运维人员需要判断故障、选择 replica、提升节点并通知客户端。
整个过程如果依靠人工处理，恢复时间长且容易配置错误。

Redis Sentinel 在主从复制之上增加高可用能力，主要提供四项功能：

功能	说明
监控 Monitoring	持续检查 master、replica 和其他 Sentinel 是否可达
通知 Notification	通过日志、Pub/Sub 事件或脚本报告实例状态变化
自动故障转移 Automatic failover	master 故障后选择一个合适的 replica，将其提升为新 master
配置提供 Configuration provider	向客户端提供当前 master 的地址，实现服务发现

一句话概括：

主从复制负责复制数据，Sentinel 负责监控主从拓扑并在 master 故障时完成自动切换。

Sentinel 本身：

不保存业务数据。
不代理业务读写流量。
不能代替 RDB、AOF 和独立备份。
不提供数据分片。
不能把异步主从复制变成强一致复制。

2. Sentinel、主从复制、持久化与 Cluster 的区别#

能力	主要目标	是否自动切换 master	是否分片	是否保证零丢失
RDB/AOF	单节点重启后的数据恢复	否	否	取决于持久化策略，仍需备份
主从复制	在线数据副本、读扩展	否	否	否，默认异步复制
Sentinel	非分片主从架构的高可用	是	否	否
Redis Cluster	分片、扩容和分片级高可用	是	是	否，仍存在异步复制窗口

适合 Sentinel 的场景：

数据量可以由单个 master 承载。
需要一个写主节点和若干只读副本。
需要 master 故障后的自动切换。
客户端支持 Sentinel 服务发现。

不适合仅使用 Sentinel 的场景：

数据量或写吞吐已经超过单个 master 的容量。
需要多个节点共同承担读流量和写流量。
需要跨分片水平扩容。

这些场景通常应考虑 Redis Cluster 或托管 Redis 服务。

3. 推荐架构#

生产环境通常至少部署：

1 个 master。
2 个或更多 replica。
3 个或更多 Sentinel，数量一般使用奇数。
支持 Sentinel 的客户端。

1
                        业务写入
2
                           │
3
                           ↓
4
                  ┌────────────────┐
5
                  │ Redis Master M │
6
                  └───────┬────────┘
7
                          │ 异步复制
8
                 ┌────────┴────────┐
9
                 ↓                 ↓
10
        ┌────────────────┐ ┌────────────────┐
11
        │ Redis Replica 1│ │ Redis Replica 2│
12
        └────────────────┘ └────────────────┘
13

14
        ┌────────────┐ ┌────────────┐ ┌────────────┐
15
        │ Sentinel S1│ │ Sentinel S2│ │ Sentinel S3│
16
        └────────────┘ └────────────┘ └────────────┘
17
               \             |             /
18
                \──监控所有 Redis 节点────/
19

20
客户端：
21
1. 连接多个 Sentinel 地址。
22
2. 询问逻辑主节点 mymaster 当前对应的 IP 和端口。
23
3. 连接返回的 master 执行业务写入。
24
4. 故障转移后重新发现并连接新 master。

展开收起

3.1 为什么至少部署三个 Sentinel#

Sentinel 是分布式系统。多个 Sentinel 共同判断故障，可以降低单点故障和误判风险。

两个 Sentinel 并不是稳健部署：

若一台机器同时运行 master 和 Sentinel，机器故障后只剩一个 Sentinel。
执行故障转移需要 Sentinel 多数派授权。
两个 Sentinel 的多数派是两个，剩余一个 Sentinel 无法授权切换。

三个 Sentinel 的多数派是两个，只要仍有两个 Sentinel 互相通信，就有机会完成故障转移。

3.2 Sentinel 应放在不同故障域#

把三个 Sentinel 全部运行在同一台主机，只适合本地实验，不能消除单点故障。

生产建议：

分散在不同物理机、虚拟机或可用区。
不共用同一个电源、宿主机和网络故障点。
Sentinel 的网络视角尽量接近业务客户端。
Sentinel 与 Redis 数据节点之间、Sentinel 彼此之间都要能双向通信。

4. Sentinel 如何发现拓扑#

每个 Sentinel 初始只需要配置要监控的 master：

1
sentinel monitor mymaster 192.168.150.101 7001 2

不需要在每个 sentinel.conf 中手动列出所有 replica 和其他 Sentinel。

4.1 发现 replica#

Sentinel 定期向 master 获取复制信息，从 master 报告的拓扑中发现 replica，并继续监控这些 replica。

因此必须保证：

replica 已正确执行 replicaof。
master 能报告 replica 的可访问地址。
Sentinel 能访问 replica 对外通告的 IP 和端口。

4.2 发现其他 Sentinel#

监控同一 master 的 Sentinel 会通过 Redis 实例的 Pub/Sub 频道交换 hello 消息：

1
__sentinel__:hello

hello 消息包含 Sentinel 的地址、端口、运行 ID 和已知 master 配置版本等信息。

这使 Sentinel 能够：

自动发现监控同一 master 的其他 Sentinel。
交换主节点配置和版本信息。
在故障时询问其他 Sentinel 对 master 状态的判断。

4.3 自动改写配置#

Sentinel 会把发现的拓扑、运行 ID、配置纪元和故障转移结果写回 sentinel.conf。

因此：

启动 Sentinel 必须提供配置文件。
Sentinel 对配置文件所在路径必须具有写权限。
不应把 sentinel.conf 挂载为只读文件。
配置管理系统不应持续用旧模板覆盖 Sentinel 自动写入的运行状态。
可以用 SENTINEL FLUSHCONFIG 强制写回当前状态。

5. 健康监控：PING、SDOWN 与 ODOWN#

Sentinel 会周期性向 master、replica 和其他 Sentinel 发送命令并检查响应。

5.1 主观下线 SDOWN#

SDOWN 是 Subjectively Down，表示：

某一个 Sentinel 根据自己的观察，认为目标实例不可达。

配置：

1
sentinel down-after-milliseconds mymaster 5000

如果某 Sentinel 在完整的 down-after-milliseconds 时间内没有收到可接受的 PING 响应，就会把目标标记为 SDOWN。

可接受的 PING 响应包括：

+PONG
-LOADING
-MASTERDOWN

SDOWN 是单个 Sentinel 的本地判断，可能由以下问题引发：

Redis 进程真的宕机。
Sentinel 到 Redis 的网络中断。
Redis 阻塞或负载过高，无法及时响应。
DNS、NAT、防火墙或路由配置错误。

单个 Sentinel 的 SDOWN 不足以触发自动故障转移。

5.2 客观下线 ODOWN#

ODOWN 是 Objectively Down，表示：

至少达到配置的 quorum 数量的 Sentinel 都认为 master 已经下线。

Sentinel 之间会使用内部询问命令交换对 master 的判断。当达到 quorum 后，master 从 SDOWN 进入 ODOWN。

需要注意：

ODOWN 只针对 master。
replica 和其他 Sentinel 只会被标记为 SDOWN，不会进入 ODOWN。
replica 处于 SDOWN 时不会被选为新 master。

5.3 状态变化流程#

1
Redis 正常
2
   │
3
   │ 某 Sentinel 在 down-after-milliseconds 内
4
   │ 没有收到有效响应
5
   ↓
6
该 Sentinel 判定 SDOWN
7
   │
8
   │ 询问其他 Sentinel
9
   │ 达到 quorum 个 Sentinel 同意
10
   ↓
11
Master 被判定 ODOWN
12
   │
13
   │ 获得多数派授权并选出故障转移领导者
14
   ↓
15
开始自动故障转移

展开收起

6. quorum 与多数派：最容易混淆的概念#

配置示例：

1
sentinel monitor mymaster 192.168.150.101 7001 2

最后一个参数 2 是 quorum。

6.1 quorum 的作用#

quorum 表示：

至少多少个 Sentinel 同意 master 不可达，才能将 master 标记为 ODOWN。

它用于故障检测，不是 replica 竞选新 master 的票数。

6.2 多数派的作用#

进入 ODOWN 后，还需要选出一个负责本次故障转移的 Sentinel 领导者。真正执行故障转移必须获得 Sentinel 多数派授权。

1
Sentinel 总数 N
2
多数派 = floor(N / 2) + 1

Sentinel 总数	多数派
3	2
5	3
7	4

执行故障转移需要同时满足：

达到 quorum，master 被判定为 ODOWN。
某 Sentinel 获得执行故障转移所需的多数派授权；如果 quorum 高于多数派，还必须满足更高的 quorum。

6.3 五个 Sentinel、quorum 为 2 的例子#

1
Sentinel 总数：5
2
quorum：2
3
多数派：3

只要 2 个 Sentinel 认为 master 下线，就可触发 ODOWN。
但实际执行故障转移时，领导者仍至少需要 3 个 Sentinel 的授权。
如果只有 2 个 Sentinel 能相互通信，可能判定 ODOWN，但不能真正完成自动切换。

6.4 quorum 如何选择#

三个 Sentinel 常用：

1
sentinel monitor mymaster 192.168.150.101 7001 2

建议原则：

通常使用奇数个 Sentinel。
三个 Sentinel 常将 quorum 设为 2。
quorum 越小，故障检测越敏感，也越容易受局部网络问题影响。
quorum 越大，误切换概率较低，但自动切换所需的可达 Sentinel 更多。
上线前应运行 SENTINEL CKQUORUM 检查 quorum 和多数派条件。

7. Sentinel 领导者选举#

ODOWN 只说明多个 Sentinel 同意 master 下线。为了避免多个 Sentinel 同时发起相互冲突的切换，每次故障转移还要选出一个领导者。

简化过程：

Sentinel 发现 master 进入 ODOWN。
发起一次新的故障转移尝试，并为本次尝试使用新的配置纪元。
向其他 Sentinel 请求授权。
每个 Sentinel 在一个配置纪元中只会投出符合协议的一票。
获得所需授权的 Sentinel 成为本次故障转移领导者。
只有该领导者负责选择 replica 和执行切换。

配置纪元可以理解为 Sentinel 配置的递增版本号：

每次有效故障转移都拥有唯一的配置纪元。
其他 Sentinel 收到更新的配置后采用较新的版本。
网络恢复后，不同分区中的 Sentinel 最终会收敛到最新逻辑配置。

8. 如何选择新的 master#

领导者会从可用 replica 中选择一个提升为新 master。

选择前先排除不合格 replica，例如：

已被 Sentinel 判定 SDOWN。
长时间与原 master 断开。
replica-priority 配置为 0。
状态异常或当前不适合提升。

8.1 断线时间筛选#

如果 replica 与 master 断开的时间超过以下范围，会被认为不可靠：

1
(down-after-milliseconds × 10)
2
+ 当前 master 已处于 SDOWN 的持续时间

讲义中常简写成 down-after-milliseconds × 10，完整判断还包含 master 已处于 SDOWN 的时间。

8.2 候选 replica 排序规则#

合格候选者按照以下顺序比较：

replica-priority：数值越小，优先级越高。
复制 offset：越大说明接收的数据通常越新，优先级越高。
run ID：前两项相同则选择字典序更小的 run ID，用于得到确定性结果。

比较项	优先规则	目的
与 master 的断线时间	过长直接排除	避免提升严重落后的副本
`replica-priority`	数值越小越优先	人工控制提升偏好
复制 offset	越大越优先	尽量选择数据更新的副本
run ID	字典序更小优先	在其他条件相同时稳定决策

8.3 replica-priority#

Redis 节点配置：

1
replica-priority 100

特殊值：

1
replica-priority 0

表示该 replica 永远不被 Sentinel 提升为 master，但它仍会继续作为 replica 接收数据，并可在故障转移后改为复制新的 master。

常见使用场景：

专门承担备份任务、性能较差的 replica 设置为 0。
同机房副本优先级设为 10。
异地灾备副本优先级设为 100。

如果一个节点未来可能从 master 变为 replica，建议所有 Redis 实例都配置符合其故障域定位的 replica-priority。

9. 自动故障转移完整流程#

假设原拓扑：

1
Master M1
2
├── Replica R1
3
└── Replica R2

完整流程如下：

一个或多个 Sentinel 发现 M1 无法正常响应，分别将其标记为 SDOWN。
达到 quorum 后，M1 被标记为 ODOWN。
Sentinel 通过投票选出本次故障转移的领导者。
领导者筛选合格 replica。
按优先级、复制 offset 和 run ID 选择 R1。
领导者向 R1 发送：
```
1
REPLICAOF NO ONE
```
Sentinel 通过 INFO 观察到 R1 已成为 master。
Sentinel 发布新的主节点配置，其他 Sentinel 和客户端开始获知 R1 的地址。
Sentinel 向 R2 发送：
```
1
REPLICAOF <R1-IP> <R1-PORT>
```
R2 开始复制新 master R1。
原 master M1 恢复后，Sentinel 将其改为 R1 的 replica。

角色变化：

1
故障前：
2

3
M1：Master
4
R1：Replica of M1
5
R2：Replica of M1
6

7
M1 故障后：
8

9
M1：不可用
10
R1：New Master
11
R2：Replica of R1
12

13
M1 恢复后：
14

15
R1：Master
16
R2：Replica of R1
17
M1：Replica of R1

展开收起

注意：

原 master 恢复并不自动夺回 master 身份。
Sentinel 会持续把最新逻辑配置施加到恢复或重新连通的节点。
故障转移成功的关键点是候选 replica 已收到 REPLICAOF NO ONE，且 Sentinel 从 INFO 中确认它已经切换为 master。

10. Sentinel 核心配置#

10.1 最小配置示例#

1
port 26379
2
bind 0.0.0.0
3
protected-mode yes
4

5
dir "/var/lib/redis-sentinel"
6

7
sentinel monitor mymaster 192.168.150.101 7001 2
8
sentinel down-after-milliseconds mymaster 5000
9
sentinel failover-timeout mymaster 180000
10
sentinel parallel-syncs mymaster 1

10.2 配置项说明#

配置项	含义	调整影响
`port`	Sentinel 监听端口，默认 26379	每个实例必须可被其他 Sentinel 和客户端访问
`dir`	工作目录	必须可写
`sentinel monitor`	逻辑 master 名称、初始地址和 quorum	master 名称必须与客户端配置一致
`down-after-milliseconds`	判定 SDOWN 所需的连续无有效响应时间	太小容易误判，太大则恢复较慢
`failover-timeout`	控制故障转移超时、重试与部分重配置节奏	不是简单的“宕机检测时间”
`parallel-syncs`	故障转移后允许同时改为复制新 master 的 replica 数量	数值越大恢复快，但同步压力和同时不可读副本数可能增加

10.3 parallel-syncs#

1
sentinel parallel-syncs mymaster 1

设置为 1：

每次只让一个 replica 与新 master 重新同步。
减少多个 replica 同时加载全量数据造成的服务影响。
整体完成时间可能更长。

设置为较大值：

可以更快完成所有 replica 的重新配置。
可能同时触发多个复制同步，增加 CPU、内存、磁盘和网络压力。
如果 replica 在同步加载数据时暂时不可读，可用读副本数量会同时减少。

10.4 failover-timeout#

failover-timeout 参与多种故障转移内部时间控制，包括：

一次故障转移尝试的时间边界。
失败后再次尝试故障转移的间隔。
replica 改为复制新 master 时的重配置节奏。

不应把它误解为 master 多久没有响应后才判定故障；后者由 down-after-milliseconds 控制。

11. 示例：三节点 Sentinel 实验环境#

讲义中的实验结构：

Sentinel	IP	端口	工作目录
S1	192.168.150.101	27001	`/tmp/s1`
S2	192.168.150.101	27002	`/tmp/s2`
S3	192.168.150.101	27003	`/tmp/s3`

S1：

1
port 27001
2
sentinel announce-ip 192.168.150.101
3
sentinel monitor mymaster 192.168.150.101 7001 2
4
sentinel down-after-milliseconds mymaster 5000
5
sentinel failover-timeout mymaster 60000
6
sentinel parallel-syncs mymaster 1
7
dir "/tmp/s1"

S2、S3 分别使用不同端口和目录：

1
S2：port 27002，dir "/tmp/s2"
2
S3：port 27003，dir "/tmp/s3"

启动方式一：

Terminal window

1
redis-sentinel /tmp/s1/sentinel.conf
2
redis-sentinel /tmp/s2/sentinel.conf
3
redis-sentinel /tmp/s3/sentinel.conf

启动方式二：

Terminal window

1
redis-server /tmp/s1/sentinel.conf --sentinel

说明：

同一台机器运行三个 Sentinel 只能验证功能。
生产环境必须将 Sentinel 分散到独立故障域。
启动前应确保端口、防火墙、配置文件写权限和数据节点认证正确。

12. 认证与安全#

Sentinel 环境包含三类连接：

Sentinel 连接 Redis master 和 replica。
Sentinel 连接其他 Sentinel。
业务客户端连接 Sentinel，并连接 Redis 数据节点。

三类连接的认证不能混为一谈。

12.1 Redis 数据节点要求密码#

密码模式：

1
sentinel auth-pass mymaster redis-data-password

ACL 模式：

1
sentinel auth-user mymaster sentinel-monitor
2
sentinel auth-pass mymaster redis-data-password

这个凭证供 Sentinel 访问 mymaster 对应的 master 和 replica。该组 Redis 数据节点应使用兼容的认证配置。

replica 自己连接 master 时也需要配置：

1
masteruser replication-user
2
masterauth replication-password

12.2 保护 Sentinel 自身#

Sentinel 本身也暴露 Redis 协议端口，不能直接暴露到不可信网络。

密码模式：

1
requirepass "sentinel-password"

使用密码模式时，各 Sentinel 通常要使用相同密码，以便彼此认证。还要确认客户端库支持连接 Sentinel 时发送认证信息。

ACL 模式可以分别配置：

1
sentinel sentinel-user sentinel-admin
2
sentinel sentinel-pass sentinel-admin-password

这组凭证用于 Sentinel 之间的连接。业务客户端访问 Sentinel 时也应使用权限受限的专用用户。

12.3 安全建议#

使用 ACL 创建最小权限用户，避免业务客户端使用默认超级用户。
Sentinel 端口只允许应用服务器、运维网络和其他 Sentinel 访问。
Redis 数据端口只允许应用、Sentinel 和复制节点访问。
跨主机或跨可用区连接考虑启用 TLS。
密码不要直接硬编码在代码仓库和公开配置模板中。
定期轮换凭证，并验证所有 Sentinel、replica 和客户端均已同步更新。

13. NAT、Docker、主机名与地址通告#

Sentinel 自动发现依赖节点通告的 IP 和端口。容器端口映射或 NAT 可能导致节点通告内部地址，使其他 Sentinel 或客户端无法访问。

13.1 Sentinel 地址通告#

1
sentinel announce-ip 192.168.150.101
2
sentinel announce-port 27001

每个 Sentinel 都应通告其他 Sentinel 和客户端实际可达的地址。

13.2 Redis replica 地址通告#

1
replica-announce-ip 192.168.150.102
2
replica-announce-port 7002

否则 master 报告给 Sentinel 的 replica 地址可能是容器内部地址。

13.3 使用主机名#

较新 Redis 版本可以配置 Sentinel 解析和通告主机名：

1
sentinel resolve-hostnames yes
2
sentinel announce-hostnames yes

注意：

DNS 必须稳定且解析迅速。
应统一使用主机名或统一使用 IP，避免混用。
部分旧客户端可能只接受 IP 地址。
TLS 证书校验依赖主机名时，通告主机名通常更合适。

14. 客户端如何接入 Sentinel#

Sentinel 不代理业务命令。客户端必须显式支持 Sentinel。

典型写连接流程：

1
客户端启动
2
   │
3
   ├─连接任意可用 Sentinel
4
   │
5
   ├─执行 SENTINEL GET-MASTER-ADDR-BY-NAME mymaster
6
   │
7
   ├─获得当前 master 地址
8
   │
9
   ├─连接 master 并验证其角色
10
   │
11
   └─连接断开或发生切换后，再次进行服务发现

客户端配置应包含：

逻辑 master 名称，例如 mymaster。
多个 Sentinel 地址，而不是只配置一个。
Sentinel 的认证信息。
Redis 数据节点的认证信息。
连接、命令和重连超时。
拓扑切换后的重试与连接池更新策略。

不要：

在业务代码中永久写死原 master 的 IP。
只配置一个 Sentinel 地址。
把 Sentinel 地址当成 Redis 数据地址直接执行 GET、SET。
在非幂等写入上进行无边界自动重试。

14.1 常用服务发现命令#

1
SENTINEL GET-MASTER-ADDR-BY-NAME mymaster

返回当前 master 的 IP 和端口。

1
SENTINEL REPLICAS mymaster

查看 Sentinel 已知的 replica。

1
SENTINEL SENTINELS mymaster

查看 Sentinel 已知的其他 Sentinel。

15. Spring Boot 与 RedisTemplate#

Spring Boot 3.x 使用 spring.data.redis 配置前缀：

1
spring:
2
  data:
3
    redis:
4
      username: app-user
5
      password: app-password
6
      sentinel:
7
        master: mymaster
8
        nodes:
9
          - 192.168.150.101:27001
10
          - 192.168.150.102:27002
11
          - 192.168.150.103:27003
12
        username: sentinel-client
13
        password: sentinel-client-password
14
      connect-timeout: 2s
15
      timeout: 2s

展开收起

较早的 Spring Boot 版本常使用：

1
spring:
2
  redis:
3
    sentinel:
4
      master: mymaster
5
      nodes:
6
        - 192.168.150.101:27001
7
        - 192.168.150.102:27002
8
        - 192.168.150.103:27003

具体前缀和认证属性应以项目实际 Spring Boot / Spring Data Redis 版本为准。

15.1 Lettuce 读策略#

现代 Spring Boot 可使用属性控制 Lettuce 读来源，具体可用值取决于当前版本：

1
spring:
2
  data:
3
    redis:
4
      lettuce:
5
        read-from: replica-preferred

也可以通过代码定制：

1
@Bean
2
LettuceClientConfigurationBuilderCustomizer redisReadFromCustomizer() {
3
    return builder -> builder.readFrom(ReadFrom.REPLICA_PREFERRED);
4
}

常见策略含义：

策略	读取位置	特点
`MASTER`	只读 master	一致性相对更好，读压力集中
`MASTER_PREFERRED`	优先 master	master 不可用时尝试 replica
`REPLICA`	只读 replica	可能读到旧数据，副本不可用时可能失败
`REPLICA_PREFERRED`	优先 replica	适合允许短暂陈旧读的业务

主从复制是异步的。即使写入 master 已返回成功，立即从 replica 读取也可能读取不到新值。

以下场景通常应从 master 读取：

写后立即读。
分布式锁状态判断。
库存、余额、订单状态等强时效数据。
依赖最新数据进行后续写入的逻辑。

16. Sentinel 与数据一致性#

16.1 为什么故障转移仍可能丢数据#

Redis 主从复制默认异步：

1
客户端 ──写入──→ 旧 Master
2
客户端 ←─OK──── 旧 Master
3
                    │
4
                    │ 写命令尚未复制到 Replica
5
                    × 旧 Master 故障
6

7
Replica 被提升为新 Master，但缺少刚才的写入。

因此 Sentinel 可以缩短故障恢复时间，但不能保证已确认写入一定保留。

16.2 网络分区与旧 master#

网络分区时可能出现：

旧 master 与多数 Sentinel、replica 失联。
多数派一侧把 replica 提升为新 master。
旧 master 所在分区仍可能被部分旧客户端访问并接受写入。
网络恢复后，旧 master 被改为新 master 的 replica。
旧 master 分区期间独有的写入会被新主线覆盖。

16.3 限制旧 master 的孤立写入#

在所有可能成为 master 的 Redis 节点配置：

1
min-replicas-to-write 1
2
min-replicas-max-lag 10

含义：

master 至少要有 1 个延迟不超过要求的 replica。
如果在 10 秒内无法获得足够 replica 的进度确认，master 停止接受写入。

作用：

缩短网络分区中旧 master 继续产生孤立写入的时间窗口。
降低故障恢复后被覆盖的数据量。

代价：

replica 故障或网络抖动时，master 可能拒绝写入。
系统可用性下降。
仍然不是严格同步复制，也不是绝对零丢失保证。

16.4 关键写入使用 WAIT#

1
SET order:1001 paid
2
WAIT 1 1000

表示最多等待 1000 毫秒，希望至少一个 replica 确认已接收到当前连接之前的写入。

应用必须检查 WAIT 的返回值。WAIT 可以提高写入到达 replica 的概率，但：

不能把 Redis 变为强一致系统。
不等于写入已按业务要求持久化到磁盘。
不能替代 AOF、RDB 和独立备份。
不能消除客户端重试造成的重复写风险。

17. Sentinel 与持久化#

Sentinel 依赖 replica 提升为新 master，因此所有可能被提升的节点都应有适当的持久化配置。

建议：

1
appendonly yes
2
appendfsync everysec

并根据恢复目标配置 RDB 快照和独立备份。

17.1 危险组合#

以下组合风险极高：

1
Master 关闭 RDB
2
+ Master 关闭 AOF
3
+ 进程崩溃后自动重启

可能过程：

master 崩溃。
进程管理器迅速把它自动重启。
因无持久化文件，master 以空数据集启动。
Sentinel 可能尚未完成故障转移。
replica 继续把空 master 当作复制源。
空数据集被同步给 replica，整个复制组的数据一起丢失。

因此：

不要把 Sentinel 当作持久化和备份。
master 关闭持久化时，不应允许它在故障后未经控制地空数据自动重启。
所有可能成为 master 的节点都应具备符合业务 RPO 的恢复能力。
备份应放在复制组之外，防止误删命令和逻辑错误同步到所有副本。

18. 常用运维命令#

连接 Sentinel：

Terminal window

1
redis-cli -h 192.168.150.101 -p 27001

若需要认证：

Terminal window

1
redis-cli -h 192.168.150.101 -p 27001 --user sentinel-client --pass 'password'

18.1 查询状态#

1
PING
2
INFO sentinel
3
ROLE
4
SENTINEL MASTERS
5
SENTINEL MASTER mymaster
6
SENTINEL REPLICAS mymaster
7
SENTINEL SENTINELS mymaster
8
SENTINEL GET-MASTER-ADDR-BY-NAME mymaster
9
SENTINEL CKQUORUM mymaster

18.2 动态配置#

修改 master 专属配置：

1
SENTINEL SET mymaster down-after-milliseconds 10000
2
SENTINEL SET mymaster parallel-syncs 1

修改 Sentinel 全局配置：

1
SENTINEL CONFIG GET *
2
SENTINEL CONFIG SET resolve-hostnames yes

动态修改应在所有 Sentinel 上保持一致。只修改一个 Sentinel，不会自动把该项运行时配置传播给所有 Sentinel。

18.3 手动触发故障转移#

1
SENTINEL FAILOVER mymaster

该命令会强制 Sentinel 为指定 master 发起故障转移，不需要先把 master 判定为 ODOWN。

使用前必须确认：

存在健康且复制进度合适的 replica。
客户端具备重连能力。
监控和回滚方案已经准备。
不会与正在进行的自动故障转移冲突。

18.4 订阅事件#

1
PSUBSCRIBE *

常见 Sentinel 日志和 Pub/Sub 事件：

事件	含义
`+sdown`	实例进入主观下线
`-sdown`	实例退出主观下线
`+odown`	master 进入客观下线
`-odown`	master 退出客观下线
`+try-failover`	开始尝试故障转移
`+elected-leader`	当前 Sentinel 当选故障转移领导者
`+selected-slave`	已选中待提升 replica
`+failover-state-send-slaveof-noone`	正在提升 replica
`+slave-reconf-sent`	已发送重新复制新 master 的命令
`+slave-reconf-done`	replica 已完成对新 master 的同步
`+switch-master`	master 地址已经切换
`+failover-end`	故障转移结束
`+tilt` / `-tilt`	进入或退出 TILT 保护模式

19. 故障排查表#

现象	常见原因	排查方向
master 已宕机但未自动切换	未达到 quorum 或多数派；无合格 replica	`SENTINEL CKQUORUM`、`SENTINEL REPLICAS`、Sentinel 日志
只有 SDOWN，没有 ODOWN	其他 Sentinel 不同意或彼此无法通信	检查 Sentinel 数量、端口、防火墙、认证
达到 ODOWN 但不切换	无法获得多数派授权	检查 Sentinel 网络分区和已知 Sentinel 数量
日志出现 `no-good-slave`	replica 断线过久、SDOWN、优先级为 0 或状态异常	检查 `INFO replication` 和 `replica-priority`
新 master 已产生但客户端仍报错	客户端不支持 Sentinel、只配置一个 Sentinel 或连接池未刷新	检查客户端服务发现和重连日志
Sentinel 无法启动	未提供配置文件或文件不可写	检查启动参数、目录和文件权限
Sentinel 发现错误 IP	Docker/NAT/主机名通告错误	配置 announce IP/port 和 replica announce
Sentinel 无法认证 Redis	`auth-user`/`auth-pass` 错误或 ACL 权限不足	分别检查数据节点和 Sentinel 的认证
故障转移后多个 replica 同时卡顿	`parallel-syncs` 过大或触发全量同步	调低并发同步，检查 backlog 与资源
读到旧数据	从 replica 读取且复制存在延迟	强时效读走 master，监控复制延迟
旧 master 恢复后变成 replica	Sentinel 的正常行为	确认新拓扑，不要手工抢回角色
发生切换但丢失最近写入	异步复制窗口	评估 `WAIT`、min-replicas、持久化和业务补偿

参考资料#

Redis 持久化：RDB、AOF 与混合持久化

Tue, 28 Jul 2026 00:00:00 GMT

适用范围：Redis Open Source 7.x/8.x。旧版本的 AOF 文件结构与 Redis 7+ 存在明显差异。

1. 先理解持久化要解决什么#

Redis 的主要数据在内存中。持久化用于把可恢复的数据写入磁盘，以便进程重启、机器故障或数据迁移后恢复。

设计持久化方案前先明确两个指标：

RPO（Recovery Point Objective）：最多允许丢失多长时间的数据。
RTO（Recovery Time Objective）：故障后允许多长时间恢复服务。

Redis 提供四种常见选择：

不持久化：适合可完全重建的纯缓存。
只使用 RDB：周期性保存数据快照。
只使用 AOF：持续记录写命令。
同时使用 RDB 与 AOF：兼顾备份、恢复速度和较小的数据丢失窗口。

持久化不等于备份，也不等于高可用。误执行 FLUSHALL、磁盘损坏或整机丢失都可能同时影响在线数据和本地持久化文件，因此仍需要异机备份、复制、哨兵或集群以及恢复演练。

2. RDB：某一时刻的数据集快照#

RDB 把当前内存数据保存为紧凑的二进制快照，默认文件名通常为 dump.rdb。

2.1 执行方式#

SAVE#

Terminal window

1
SAVE

由 Redis 主线程同步执行。
生成快照期间会阻塞其他请求。
在线生产实例通常不应主动使用。

BGSAVE#

Terminal window

1
BGSAVE

Redis 先 fork 子进程。
子进程在后台生成 RDB。
父进程继续处理客户端请求。
新快照完成后通过原子替换取代旧 RDB 文件。

两种命令对比：

命令	执行进程	是否阻塞客户端请求	典型用途
`SAVE`	Redis 主线程	是	极少使用，通常仅限特殊维护场景
`BGSAVE`	`fork` 出的子进程	`fork` 阶段可能短暂停顿，写文件期间不持续阻塞	生产环境生成 RDB 的常用方式

自动快照规则#

1
# 示例：60 秒内至少发生 1000 次数据变更，则触发后台快照
2
save 60 1000
3

4
# 禁用自动快照
5
save ""

save N M 表示：在 N 秒内至少发生 M 次会改变数据集的操作后，触发一次后台保存。

不要依赖“Redis 正常停机一定会保存 RDB”这一假设。停机参数、当前持久化配置和进程退出方式都会影响结果，恢复能力必须通过实际配置和演练验证。

2.2 核心配置#

1
# RDB 所在目录
2
dir /var/lib/redis
3

4
# RDB 文件名
5
dbfilename dump.rdb
6

7
# 是否压缩 RDB
8
rdbcompression yes
9

10
# 是否写入并检查校验和
11
rdbchecksum yes
12

13
# 最近一次后台保存失败后是否拒绝继续写入
14
stop-writes-on-bgsave-error yes

不应简单地认为“磁盘便宜，所以一定关闭压缩”。是否压缩需要结合 CPU、磁盘吞吐、快照耗时和文件大小进行压测。

2.3 BGSAVE 与 Copy-on-Write#

执行 BGSAVE 时：

父进程执行 fork，创建子进程。
父子进程最初共享相同的物理内存页。
子进程读取快照时刻的数据并写入临时 RDB。
父进程继续处理请求。
父进程修改某个共享页时，操作系统复制该页，这就是 Copy-on-Write。
子进程完成写入后，Redis 原子替换旧 RDB。

需要注意的开销：

大数据集会增加 fork 和页表复制时间，造成短暂停顿。
快照期间写入越多，COW 复制的内存页越多，峰值内存越高。
快照写盘可能与业务 I/O、AOF 重写或主从全量同步争抢资源。
内存不足时可能发生 OOM，不能只按 used_memory 配置机器容量。

2.4 RDB 的优缺点#

优点：

文件紧凑，适合归档和异地备份。
大数据集下，启动恢复通常快于回放 AOF。
生成完成的 RDB 文件不会被继续修改，便于复制。
对正常请求的持续写盘影响较小。

缺点：

RPO 取决于快照间隔，故障时可能丢失最近数分钟数据。
fork、COW 和磁盘写入可能造成延迟和内存放大。
快照只能表示某个时间点，不能反映之后的增量写入。

3. AOF：记录写命令并在启动时回放#

AOF（Append Only File）记录所有会改变数据集的写命令。Redis 重启时按顺序回放这些命令，重新构造内存状态。

3.1 写入路径#

一次写命令大致经过：

1
客户端写命令
2
    ↓
3
Redis 执行命令并修改内存
4
    ↓
5
AOF 缓冲区
6
    ↓ write
7
操作系统页缓存
8
    ↓ fsync
9
稳定存储

write 成功不代表数据已经进入稳定存储；真正的耐久性主要由 fsync 策略决定。

3.2 基础配置#

1
appendonly yes
2
appendfilename "appendonly.aof"
3

4
# Redis 7+ 的多文件 AOF 目录
5
appenddirname "appendonlydir"
6

7
# AOF 重写时允许 base 文件采用 RDB 前导
8
aof-use-rdb-preamble yes

3.3 appendfsync 三种策略#

1
# 每批写命令都执行 fsync
2
appendfsync always
3

4
# 大约每秒执行一次 fsync，常用且推荐的折中方案
5
appendfsync everysec
6

7
# 不主动执行 fsync，由操作系统决定刷盘时间
8
appendfsync no

策略	刷盘方式	典型数据丢失窗口	性能与适用场景
`always`	每批写命令执行 `fsync`	极低	耐久性最强，但写延迟和吞吐压力最大
`everysec`	后台线程约每秒 `fsync`	通常约 1 秒	性能与安全性的常用平衡
`no`	交给操作系统	不确定	性能优先，故障时可能丢失更多数据

“always 完全不丢数据”也不是绝对保证。磁盘控制器缓存、虚拟化存储、文件系统和硬件故障仍可能影响最终耐久性。

3.4 AOF 重写#

AOF 会不断增长。例如某个计数器执行 100 次 INCR，恢复当前状态可能并不需要保留全部 100 条历史命令。

手工重写：

Terminal window

1
BGREWRITEAOF

自动重写阈值：

1
# 当前 AOF 相比上次重写后的基准大小增长 100%
2
auto-aof-rewrite-percentage 100
3

4
# 文件达到该大小后才考虑自动重写
5
auto-aof-rewrite-min-size 64mb

重写不是在原 AOF 上删除命令，而是根据当前内存状态生成一套能够恢复相同数据集的最小表示。新文件准备完成前，旧 AOF 仍保持有效。

例如，原 AOF 中依次存在：

1
SET num 123
2
SET name jack
3
SET num 666

最终有效状态只有 name=jack、num=666。重写后可以用更短的等价命令表示：

1
MSET name jack num 666

重写前	状态影响	重写时是否需要保留
`SET num 123`	后续被 `SET num 666` 覆盖	不需要
`SET name jack`	决定最终的 `name`	需要以等价形式保留
`SET num 666`	决定最终的 `num`	需要以等价形式保留

Redis 会避免同时执行高开销的 RDB 后台保存和 AOF 重写。若 BGSAVE 正在执行，BGREWRITEAOF 可能进入排队状态。

3.5 Redis 7+ 的多文件 AOF#

Redis 7.0 起，AOF 不再只是一个不断追加的单文件，而是由以下部分组成：

base AOF：最多一个，表示最近一次重写时的数据基线；可以是 AOF 格式，也可以是 RDB 格式。
incremental AOF：一个或多个，记录 base 生成之后的增量写入。
manifest：记录当前有效的 base 和 incremental 文件组合。

这些文件存放在 appenddirname 指定的目录中。重写时，父进程会继续向新的增量文件写入；重写完成后通过原子替换 manifest 切换到新文件集合。

因此，Redis 7+ 备份 AOF 时不能只复制某一个 appendonly.aof 文件，而要复制整个 AOF 目录，并避免在重写过程中取得不一致的文件组合。

3.6 AOF 的优缺点#

优点：

使用 everysec 时，通常最多丢失约 1 秒数据。
追加写为主，日志尾部截断时可进行恢复。
可自动后台重写，控制文件膨胀。
命令日志相对容易理解和审计。

缺点：

文件通常比等价 RDB 更大。
持续写入和 fsync 会增加磁盘压力。
重写仍需要 fork，存在 COW 和额外 I/O 开销。
大 AOF 启动时需要回放，恢复速度通常慢于 RDB。

4. 混合持久化与恢复优先级#

4.1 同时开启 RDB 和 AOF#

同时开启两种持久化时：

RDB 可用于周期性快照、归档和较快恢复。
AOF 用于缩小故障时的数据丢失窗口。
Redis 重启时会优先使用 AOF 恢复数据，因为 AOF 通常更完整。

4.2 AOF 的 RDB 前导#

1
aof-use-rdb-preamble yes

开启后，AOF 重写生成的 base 部分可使用 RDB 格式，后续增量仍以 AOF 命令日志记录：

1
RDB 格式的 base + incremental AOF + manifest

收益：

base 更紧凑。
重写速度和启动加载速度通常更好。
增量 AOF 继续提供较小的数据丢失窗口。

需要区分：

RDB + AOF：同时开启两套持久化机制。
RDB 前导 AOF：AOF 重写后的 base 使用 RDB 格式，是 AOF 的内部文件结构。

5. RDB 与 AOF 对比#

维度	RDB	AOF
记录方式	某个时间点的数据集快照	会改变数据集的写命令
典型 RPO	取决于快照间隔，通常为分钟级	`everysec` 通常约 1 秒
启动恢复	通常更快	需要加载 base 并回放增量日志
文件体积	紧凑，适合归档	通常更大
正常运行开销	周期性 `fork` 和集中写盘	持续追加、`fsync` 和周期重写
主要风险	快照间隔丢数据、fork/COW 峰值	磁盘延迟、文件膨胀、重写和回放时间
备份方式	复制完整 RDB 文件	Redis 7+ 复制整个 `appenddirname`
典型用途	快照备份、灾难恢复、快速重启	较强耐久性、缩小数据丢失窗口

6. 生产环境选型建议#

6.1 纯缓存，可从数据库重建#

可以关闭持久化，降低 I/O 和 fork 影响。
若希望重启后快速预热，可保留低频 RDB。
必须确认缓存重建不会压垮下游数据库。

6.2 可以容忍数分钟数据丢失#

可只使用 RDB。
设置与业务 RPO 对齐的快照规则。
定期把 RDB 复制到异机或对象存储。

6.3 数据较重要，希望最多丢失约 1 秒#

开启 AOF。
通常选择 appendfsync everysec。
保留周期性 RDB，便于归档、恢复和应对 AOF 故障。

6.4 极强耐久性要求#

可以评估 appendfsync always，但必须压测写延迟和吞吐。
结合主从复制、高可用、可靠存储和异地备份。
如果业务要求严格事务耐久性，需要评估 Redis 是否适合作为唯一事实数据源。

7. 监控与故障处理#

7.1 查看持久化状态#

Terminal window

1
redis-cli INFO persistence

重点关注：

RDB：

rdb_bgsave_in_progress
rdb_last_bgsave_status
rdb_last_bgsave_time_sec
rdb_last_cow_size
rdb_changes_since_last_save

AOF：

aof_enabled
aof_rewrite_in_progress
aof_rewrite_scheduled
aof_last_bgrewrite_status
aof_last_write_status
aof_current_size
aof_base_size
aof_pending_bio_fsync
aof_delayed_fsync
aof_last_cow_size

还应同时监控：

latest_fork_usec
磁盘使用率、写延迟、I/O 等待
Redis 主进程 RSS 与可用内存
持久化文件更新时间
备份任务成功率和恢复演练结果

7.2 AOF 尾部截断或损坏#

处理原则：先停止写入并复制原文件，再尝试修复。

Terminal window

1
# 先检查
2
redis-check-aof <aof-file-or-manifest>
3

4
# 确认可接受丢弃损坏部分后再修复
5
redis-check-aof --fix <aof-file-or-manifest>

如果是中间区域损坏，修复工具可能丢弃损坏位置之后的内容，因此不能不做备份就直接使用 --fix。

RDB 可使用：

Terminal window

1
redis-check-rdb dump.rdb

7.3 在线开启 AOF#

在已有 RDB 数据的运行实例上切换为 AOF 时，不要只修改配置文件后直接重启。可按以下思路操作：

Terminal window

1
redis-cli CONFIG SET appendonly yes
2
redis-cli INFO persistence
3
redis-cli CONFIG REWRITE

等待 AOF 重写完成，并确认：

aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_bgrewrite_status:ok
AOF 持续增长且重启后 key 数量符合预期

CONFIG SET 只修改运行时配置；若不修改配置文件或执行 CONFIG REWRITE，重启后可能恢复旧配置。

参考资料#

Redis 主从复制与持久化

Tue, 28 Jul 2026 00:00:00 GMT

适用范围：Redis Open Source 7.x/8.x。文中优先使用 master（主节点）和 replica（副本节点）；部分配置项与 INFO 字段为了兼容旧版本，仍保留 slave 字样。

1. 主从复制解决什么问题#

Redis 主从复制让一个或多个 replica 持续复制 master 的数据，主要用于：

扩展读取能力，实现读写分离。
保留数据的冗余副本。
为 Sentinel 或 Redis Cluster 的故障转移提供可提升的节点。
支持滚动升级、数据迁移和只读分析。

典型结构：

1
                 写请求
2
                   ↓
3
客户端 ───────→ Master
4
                   │
5
          异步复制命令流
6
              ┌────┴────┐
7
              ↓         ↓
8
          Replica 1  Replica 2
9
              ↑         ↑
10
           读请求      读请求

需要明确：

Redis 默认使用异步复制。
master 完成内存写入后通常就可以向客户端返回，不会等待所有 replica。
replica 可能暂时落后，读取到旧数据。
复制、持久化、备份和高可用解决的是不同问题，不能互相替代。

能力	主要解决的问题	不能保证什么
主从复制	在线冗余、读扩展、故障转移的数据来源	不保证零数据丢失，不是历史备份
RDB/AOF	单节点重启后的本地数据恢复	不自动完成故障转移
Sentinel	监控和自动主从切换	异步复制下仍可能丢失已确认写入
独立备份	误删、文件损坏和灾难恢复	不提供实时读扩展

2. 基础搭建与配置#

2.1 把节点配置为 replica#

配置文件：

1
replicaof 192.168.10.10 6379

运行时命令：

Terminal window

1
REPLICAOF 192.168.10.10 6379

取消复制关系并把当前节点提升为独立 master：

Terminal window

1
REPLICAOF NO ONE

2.2 认证配置#

如果 master 需要认证，replica 必须配置连接 master 所需的凭证：

1
masterauth your-password

使用 ACL 时，还需要为复制连接配置具有相应权限的用户。生产环境应同时保护 master 和 replica，避免 replica 成为绕过认证的数据入口。

2.3 replica 的读写行为#

1
# 默认开启，只允许客户端读取 replica
2
replica-read-only yes
3

4
# 与 master 断开或正在同步时，是否允许返回可能过期的数据
5
replica-serve-stale-data yes

即使把 replica-read-only 改为 no，也不代表 Redis 变成多主系统：

replica 上的本地写入不会反向复制给 master。
重新同步时，本地写入可能被 master 的数据覆盖。
普通主从架构应坚持所有业务写入只进入当前 master。

3. 正常复制链路#

master 与 replica 已完成同步且连接正常时，流程如下：

客户端向 master 发出写命令。
master 修改自己的内存数据。
master 把产生相同数据效果的命令写入复制流。
replica 接收并执行复制流中的命令。
replica 周期性向 master 上报自己已经处理到的复制偏移量。

复制流不仅包含显式客户端写命令，还包含：

key 过期产生的数据变更。
内存淘汰产生的数据变更。
其他会改变数据集的操作。

master 可以同时连接多个 replica。replica 也可以作为其他 replica 的上游，形成级联复制：

1
Master
2
  │
3
  ├── Replica A
4
  │       ├── Sub-replica A1
5
  │       └── Sub-replica A2
6
  │
7
  └── Replica B

级联复制可以减少 master 直接服务大量副本的压力，但会增加复制延迟、拓扑复杂度和故障排查成本。

4. 复制的三个核心标识#

4.1 Replication ID#

Replication ID（复制 ID，通常称 replid）标识一段特定的数据历史。

master 拥有自己的复制 ID。
replica 同步后会记住 master 的复制 ID。
复制 ID 与 offset 组合起来，才能唯一描述某个数据历史中的位置。

Redis 还维护第二复制 ID：

master_replid：当前复制历史。
master_replid2：上一段复制历史。
second_repl_offset：旧历史可以继续部分同步的边界。

第二复制 ID 主要用于故障转移后，让原 master 的其他 replica 仍有机会与新 master 进行部分同步。

4.2 Replication Offset#

复制偏移量表示复制流已经生成或处理到的位置。

master 的 offset 随复制流增加。
replica 保存自己已处理的 offset。
两者差值可以近似反映副本落后程度。

不能只比较 offset 而忽略复制 ID。不同复制历史中的相同 offset 没有可比性。

4.3 Replication Backlog#

Replication backlog 是 master 内存中的固定容量环形缓冲区，保存最近一段复制命令流。

它不是磁盘文件，正确配置名为：

1
repl-backlog-size 256mb

环形结构的特点：

新复制数据持续写入 backlog。
缓冲区写满后，从头覆盖最旧的数据。
replica 短暂断线后，可以根据 offset 获取缺失部分。
如果需要的旧数据已被覆盖，就不能部分同步，只能全量同步。

文字示例：

1
backlog 保存的 offset 范围：10001 ～ 20000
2
master 当前 offset：       20000
3
replica 已处理 offset：    17500
4

5
结果：17501 ～ 20000 仍在 backlog 中，可以部分同步。

如果 replica 的 offset 是 8000，而 backlog 最早只保留到 10001，则缺失的 8001～10000 已经被覆盖，只能全量同步。

5. PSYNC：决定部分同步还是全量同步#

新版本 Redis 使用 PSYNC 协议进行复制协商。SYNC 是不支持部分同步的旧协议，只为兼容保留。

replica 建立连接时，会向 master 提供自己记住的复制 ID 和 offset。master 根据以下条件判断：

1
复制 ID 是否属于当前或仍可识别的旧历史？
2
                    │
3
          ┌─────────┴─────────┐
4
          │是                 │否
5
          ↓                   ↓
6
缺失 offset 是否仍在 backlog？  全量同步
7
          │
8
    ┌─────┴─────┐
9
    │是         │否
10
    ↓           ↓
11
部分同步       全量同步

判断结果	同步方式
复制 ID 可识别，缺失数据仍在 backlog	部分同步
第一次连接，没有有效复制 ID 和 offset	全量同步
复制 ID 不属于当前或可兼容历史	全量同步
replica 断开太久，需要的 offset 已被覆盖	全量同步
master 的历史发生无法兼容的变化	全量同步

6. 全量同步流程#

全量同步适用于首次连接或无法部分同步的情况。

6.1 磁盘式全量同步#

完整时序：

replica 发送 PSYNC，请求继续原来的复制历史。
master 判断不能部分同步，回复进行全量同步。
master 启动后台保存，生成代表当前数据集的 RDB。
生成 RDB 的同时，master 把新的写命令放入复制缓冲区。
master 把 RDB 传输给 replica。
replica 接收 RDB，清理旧数据并加载新数据集。
master 把生成 RDB 期间积累的命令继续发送给 replica。
replica 执行这些命令，追赶到 master 当前 offset。
后续进入持续命令流复制。

1
Master                                   Replica
2
  │                                         │
3
  │ ←──── PSYNC replid offset ───────────── │
4
  │                                         │
5
  │ ───── FULLRESYNC new-replid offset ───→ │
6
  │                                         │
7
  │ 生成 RDB，同时缓存新写入                 │
8
  │ ─────────── RDB 数据流 ───────────────→ │
9
  │                                         │ 清空旧数据并加载 RDB
10
  │ ───── RDB 期间积累的命令流 ───────────→ │
11
  │ ───────── 持续复制命令流 ─────────────→ │

6.2 无盘复制#

1
repl-diskless-sync yes
2

3
# 等待一小段时间，让多个同时到来的 replica 共用一次同步
4
repl-diskless-sync-delay 5

无盘复制时，master 的子进程直接通过网络套接字把 RDB 数据流发送给 replica，而不先在 master 磁盘生成 RDB 文件。

优点：

避免 master 上的 RDB 磁盘写入。
适合磁盘较慢而网络较快的环境。
多个同时请求同步的 replica 可以共享一次 RDB 生成过程。

代价：

仍然需要 fork，仍存在 COW 内存开销。
会占用大量网络带宽。
网络慢或 replica 多时，子进程存活时间可能更长。
需要结合 repl-diskless-load 等配置评估 replica 的加载策略。

6.3 全量同步的主要成本#

阶段	master 成本	replica 成本
`fork`	短暂停顿、页表复制	无
RDB 生成	CPU、COW 内存、磁盘或网络	接收数据
RDB 传输	网络带宽、输出缓冲区	网络和临时存储
数据加载	继续缓存增量命令	清空旧数据、加载 RDB，可能暂停服务
追赶增量	发送积累命令	执行大量命令、增加 CPU

因此应尽量避免多个大 replica 频繁触发全量同步。

7. 部分同步流程#

部分同步用于 replica 短暂断线且缺失命令仍在 backlog 中的情况。

流程：

replica 重连并提交复制 ID 与上次处理的 offset。
master 确认复制历史兼容。
master 确认缺失部分仍在 backlog。
master 从 offset+1 开始发送缺失命令。
replica 执行缺失命令并追赶 master。
双方恢复持续复制。

对比项	全量同步	部分同步
传输内容	完整 RDB + 同步期间增量命令	backlog 中缺失的命令
网络开销	大	小
master 开销	通常需要 `fork` 和生成 RDB	读取内存 backlog
replica 行为	替换完整数据集	在现有数据上补齐命令
触发场景	首次连接或历史缺失	短暂断线且历史仍保留

8. 如何设置 repl-backlog-size#

backlog 太小会让短暂网络故障频繁退化成全量同步；太大则持续占用 master 内存。

可按下面的思路估算：

1
backlog 大小
2
≈ 峰值复制流量（字节/秒）
3
× 希望容忍的最长断线时间（秒）
4
× 安全系数

示例：

1
峰值写入复制流量：20 MB/s
2
希望容忍断线：    5 分钟 = 300 秒
3
安全系数：        1.5
4

5
建议 backlog ≈ 20 × 300 × 1.5 = 9000 MB

实际设置前还要考虑：

Redis 命令编码后的复制流量可能与业务数据量不同。
过期、淘汰、批量命令也会进入复制流。
网络抖动时间不一定等于故障修复时间。
backlog 由同一 master 的 replica 共享，不需要按 replica 数量简单相乘。
必须确认机器有足够内存。

配置与观察：

1
repl-backlog-size 1gb
2
repl-backlog-ttl 3600

Terminal window

1
redis-cli INFO replication

关注：

repl_backlog_active
repl_backlog_size
repl_backlog_first_byte_offset
repl_backlog_histlen
master_repl_offset
replica 的复制 offset

9. 主从复制与 RDB/AOF 的关系#

9.1 全量同步会使用 RDB#

即使业务持久化配置中关闭了周期性 RDB，传统磁盘式全量复制仍可能生成 RDB 文件。

磁盘式复制：master 后台生成 RDB，再发送给 replica。
无盘复制：生成 RDB 格式的数据流并直接发送，不在 master 磁盘保留该文件。

所以“关闭 RDB 持久化”不等于“主从复制永远不会产生 RDB 相关开销”。

9.2 复制不能替代持久化#

复制的目标是让 replica 尽量成为 master 的当前副本。如果 master 变成空数据集，空数据也可能被复制出去。

危险场景：

master 关闭 RDB 和 AOF。
master 进程崩溃后被进程管理器自动重启。
因为没有持久化，master 以空数据集启动。
replica 重新连接并把空 master 当作正确数据源。
replica 的原有数据被清空，整个复制组的数据一起丢失。

因此 Redis 官方建议：

使用复制时，在 master 和 replica 上开启适合业务的持久化。
如果 master 确实关闭持久化，不要让它在崩溃后未经人工确认就自动以空数据集重启。
Sentinel 场景尤其要避免“无持久化 master + 自动重启”的组合。

9.3 replica 是否需要持久化#

通常建议 replica 也配置持久化，原因包括：

replica 重启后可先从本地恢复，减少完全从 master 获取数据的风险。
某个 replica 可能在故障转移后成为新 master。
可把备份、RDB 归档等磁盘任务放到专用 replica，降低 master 压力。

但要注意：

replica 的持久化文件同样会反映复制来的删除和误操作。
replica 本地持久化仍不是独立、版本化的备份。
Redis 官方文档指出，replica 平滑停机时写入的 RDB 可以保存部分同步所需元数据；仅通过 AOF 重启的 replica 不能依靠 AOF 完成相同的部分同步恢复。

9.4 AOF 与复制流不是同一个概念#

AOF	主从复制流
写入本机磁盘，用于本节点重启恢复	通过网络发送给 replica
耐久性由 `appendfsync` 决定	延迟由网络和 replica 处理速度决定
重写用于控制文件体积	backlog 用于短暂断线后的部分同步
本机恢复时加载 AOF	replica 通过 RDB 和复制命令追赶 master

10. 故障转移为什么仍可能丢数据#

Redis 主从复制默认是异步的。下面的写入可能已经被 master 确认，但还没到达 replica：

1
客户端 ── SET order:1 paid ──→ Master
2
客户端 ←──────── OK ───────── Master
3
                                  │
4
                                  │ 尚未复制完成
5
                                  × Master 故障
6
                                  │
7
Replica 被提升为新 Master，但没有这条写入

因此：

Sentinel 能自动切换 master，但不能把异步复制变成零丢失复制。
网络分区时，旧 master 可能仍短暂接受写入。
故障恢复后，旧 master 会被配置为新 master 的 replica，其分叉数据会被新历史覆盖。
replica 越落后，故障转移可能丢失的数据越多。

10.1 使用 min-replicas 限制风险#

1
min-replicas-to-write 1
2
min-replicas-max-lag 10

含义：

至少需要 1 个 replica 满足最大延迟要求。
如果 master 在规定时间内没有收到足够 replica 的进度确认，则停止接受写入。

作用：

限制 master 与 replica 长时间失联时继续产生大量孤立写入。
缩小网络分区期间的数据分叉窗口。

代价：

replica 不满足条件时，master 会拒绝写入，可用性下降。
这仍不是严格同步复制，也不能保证绝对零丢失。

10.2 使用 WAIT 提高关键写入安全性#

1
SET order:1 paid
2
WAIT 1 1000

WAIT 1 1000 表示最多等待 1000 毫秒，希望至少 1 个 replica 确认已经接收到当前连接此前的写入。

应用必须检查返回值：

1
返回 1：至少一个 replica 已确认相应复制位置
2
返回 0：超时前没有 replica 满足条件

注意：

WAIT 提高写入已到达 replica 的概率，但不会把 Redis 变成强一致 CP 系统。
replica 确认复制 offset 不一定等于写入已经按目标策略落到磁盘。
WAIT 不能替代 AOF、RDB、备份或正确的故障转移设计。
执行 WAIT 后若业务从另一个落后 replica 读取，仍可能读到旧值；读路由也必须设计。

11. 读写分离的一致性问题#

读 replica 可以扩展吞吐量，但要接受最终一致性。

常见问题：

问题	表现	处理思路
读到旧值	写 master 后立即读 replica，结果尚未同步	关键读回 master；按业务使用 `WAIT`；客户端做短期粘滞路由
主从切换后的旧连接	客户端仍向旧 master 写入	使用支持 Sentinel/Cluster 的客户端，及时刷新拓扑
replica 正在全量加载	暂停响应或返回旧数据	配置并评估 stale-data 行为；健康检查剔除同步中节点
复制延迟扩大	replica CPU、网络或磁盘不足	监控 offset 差值、链路状态和处理能力
过期时间看似不一致	replica 复制和过期处理存在时序差	以 master 为权威，避免依赖 replica 做强一致判断

不适合直接读 replica 的场景：

写后立即读取。
库存扣减后的可售数量判断。
分布式锁状态确认。
支付、订单状态等不能容忍短暂旧值的业务。

12. 主从复制优化#

12.1 控制单节点数据量#

单节点数据集越大：

全量同步的 RDB 越大。
fork、COW、网络传输和加载时间越长。
replica 追赶期间积累的命令越多。
故障恢复 RTO 越长。

应通过合理分片、内存上限和容量规划控制单节点规模。

12.2 合理增大 backlog#

backlog 应覆盖常见网络抖动和滚动重启时间，避免短暂断线退化为全量同步。

不要盲目设置：

太小：频繁全量同步。
太大：浪费 master 内存。
应基于峰值复制流量和最长断线时间计算。

12.3 评估无盘复制#

磁盘慢、网络快时可考虑：

1
repl-diskless-sync yes
2
repl-diskless-sync-delay 5

但仍需压测网络、COW 内存和多个 replica 同步时的表现。

12.4 限制直接 replica 数量#

大量 replica 同时直接连接 master 会增加：

网络输出。
每个 replica 的客户端输出缓冲区。
心跳和状态维护。
故障时的同步风暴。

可以采用级联复制降低 master 压力，但要评估多一跳延迟和级联上游故障的影响。

12.5 避免同步风暴#

分批重启 replica。
配合 repl-diskless-sync-delay 合并相近的同步请求。
不让大量 replica 在同一时间失联和重连。
监控全量同步次数与网络出口带宽。
Sentinel 中合理配置并行同步数量，避免故障转移后所有 replica 同时加载。

13. 监控与排障#

13.1 查看复制状态#

Terminal window

1
redis-cli INFO replication
2
redis-cli ROLE

master 侧重点：

role
connected_slaves：为兼容保留的旧字段名，表示已连接 replica 数。
master_replid
master_replid2
master_repl_offset
second_repl_offset
repl_backlog_active
repl_backlog_size
repl_backlog_first_byte_offset
repl_backlog_histlen

replica 侧重点：

master_host
master_port
master_link_status
master_last_io_seconds_ago
master_sync_in_progress
slave_repl_offset：兼容旧协议保留的字段名。
slave_read_repl_offset
master_link_down_since_seconds

还应结合：

Terminal window

1
redis-cli INFO persistence
2
redis-cli INFO memory
3
redis-cli INFO stats
4
redis-cli LATENCY DOCTOR

13.2 常见故障判断表#

现象	可能原因	检查与处理
`master_link_status:down`	网络、认证、TLS、超时或 master 不可达	检查网络、日志、`masterauth`、ACL 和 TLS
频繁全量同步	backlog 太小、断线太久、复制历史变化	查看 backlog 范围和同步日志，调整容量
replica 长时间追不上	写入过快、CPU 不足、网络慢	比较 offset、CPU、带宽和命令执行速度
master 内存突增	RDB/COW、输出缓冲区或 backlog 较大	查看 COW、客户端缓冲和 backlog 配置
master 延迟抖动	`fork`、磁盘 I/O、网络发送压力	查看 `latest_fork_usec`、延迟监控和磁盘
replica 全量同步时不可用	正在清空并加载 RDB	调整健康检查、同步策略和读流量摘除
master 重启后所有数据消失	未开启持久化却自动重启	立即停止复制扩散，恢复备份，修正启动策略
故障转移后少量数据丢失	异步复制尚未到达被提升 replica	评估 `WAIT`、min-replicas、持久化和业务补偿

14. 生产配置示例#

以下仅作为思路示例，不能直接替代压测和容量规划。

Master#

1
# 持久化
2
appendonly yes
3
appendfsync everysec
4
save 3600 1
5

6
# 部分同步窗口
7
repl-backlog-size 1gb
8
repl-backlog-ttl 3600
9

10
# 全量同步
11
repl-diskless-sync yes
12
repl-diskless-sync-delay 5
13

14
# 限制失去副本后的孤立写入
15
min-replicas-to-write 1
16
min-replicas-max-lag 10

展开收起

Replica#

1
replicaof 192.168.10.10 6379
2
masterauth your-password
3

4
replica-read-only yes
5
replica-serve-stale-data yes
6

7
# 作为可能被提升的新 master，通常也应具备持久化能力
8
appendonly yes
9
appendfsync everysec

部署时还要补充：

ACL 或密码配置。
TLS 复制链路。
主机地址通告与 NAT 环境配置。
Sentinel 或 Cluster 故障转移。
跨可用区延迟与带宽评估。
备份、告警和恢复演练。

参考资料#

Redis BitMap

Mon, 27 Jul 2026 00:00:00 GMT

适用范围：Redis Open Source 2.2+。文中会特别标注 Redis 7.0 和 8.2 引入的新语法。

1. Bitmap 是什么#

Bitmap（位图）使用一个二进制位表示一个对象的某种布尔状态：

1：是、存在、已发生；
0：否、不存在、未发生。

例如，可以让 offset 等于用户 ID：

1
offset:  0 1 2 3 4 5 6 7 ...
2
状态:    0 1 0 0 1 0 1 0 ...
3
含义:      ↑     ↑   ↑
4
          用户1  用户4 用户6 活跃

常见用途：

用户签到；
日活、周活和留存统计；
是否在线、是否完成任务；
权限或功能开关；
标签人群交集、并集和差集；
大量小整数计数器（使用 BITFIELD）。

2. Bitmap 不是独立数据类型#

Redis Bitmap 底层是二进制安全的 String。Bitmap 只是 Redis 提供的一组按位操作：

1
SETBIT bitmap:key 10 1
2
TYPE bitmap:key

1
string

所以 Bitmap key 也可以使用部分 String 命令，例如：

1
STRLEN bitmap:key       # String 占用的字节数
2
GETRANGE bitmap:key 0 9 # 读取前 10 个字节
3
EXPIRE bitmap:key 86400 # 设置整个 Bitmap key 的 TTL
4
DEL bitmap:key

直接 GET 得到的是二进制字节流，不一定是可读文本。

3. bit、byte 与 offset#

3.1 基本换算#

1
1 byte = 8 bit

Redis 的 offset 从 0 开始：

第 1 个字节保存 offset 0～7；
第 2 个字节保存 offset 8～15；
第 n 个 bit 所在字节是 floor(offset / 8)。

一个字节内按“从最高有效位到最低有效位”编号：

1
字节内容： 1 0 1 0 0 0 0 1
2
offset：   0 1 2 3 4 5 6 7

因此：

1
SETBIT demo 0 1

会把第一个字节的最高位设置为 1，而不是最低位。

3.2 最大容量#

String 的最大长度是 512 MiB，因此单个 Bitmap 最多可以寻址：

1
512 MiB × 8 = 2^32 bit

offset 的有效范围是：

1
0 ～ 2^32 - 1

也就是最多约 42.95 亿个位。

3.3 内存估算#

如果最大 offset 为 m，数据部分至少需要：

1
floor(m / 8) + 1 字节

常见规模：

最大编号规模	位图数据大小（约）
100 万	122 KiB
1,000 万	1.19 MiB
1 亿	11.92 MiB
10 亿	119.21 MiB
`2^32` 个 bit	512 MiB

这些数字不包含 Redis 对象、key、内存分配器等额外开销。

Bitmap 并不是稀疏压缩结构。即使只执行：

1
SETBIT users 1000000000 1

Redis 也必须分配能够覆盖 offset 10 亿的连续 String，约占 119 MiB。对很短的 key 突然设置极远 offset，扩容和补零还可能阻塞 Redis 主线程。

4. 适合与不适合的场景#

4.1 适合#

对象可以映射为较连续、较紧凑的非负整数；
每个对象只需表示 0/1；
经常需要计数、交集、并集或差集；
不要求直接从 Bitmap 中列出完整业务对象。

4.2 不适合#

ID 极度稀疏，例如只有少量用户但 ID 接近十亿；
需要保存名称、时间、次数等附加信息；
经常需要遍历并返回所有成员；
单个对象不只是布尔状态；
需要给每个 bit 单独设置 TTL。

Bitmap 的 TTL 是 key 级别的，不能给单独一个 bit 设置过期时间。

5. 命令总览#

命令	作用	版本	时间复杂度
`SETBIT`	设置指定 offset 的值	2.2+	`O(1)`，扩容除外
`GETBIT`	获取指定 offset 的值	2.2+	`O(1)`
`BITCOUNT`	统计值为 1 的 bit 数	2.6+	`O(N)`
`BITOP`	多个 String/Bitmap 做位运算并保存结果	2.6+	`O(N)`
`BITPOS`	查找第一个 0 或 1 的位置	2.8.7+	`O(N)`
`BITFIELD`	原子读写、自增不同宽度的整数	3.2+	每个子命令 `O(1)`
`BITFIELD_RO`	只读地获取 bitfield 整数	6.0+	每个子命令 `O(1)`

其中 N 与扫描或参与运算的字节数有关。

6. 命令详解#

6.1 SETBIT：设置 bit#

1
SETBIT key offset value

offset 从 0 开始；
value 只能是 0 或 1；
key 不存在时自动创建；
超出当前长度时自动扩容，中间部分补 0；
返回 修改前的 bit 值，不是修改后的值。

示例：

1
SETBIT active:2026-07-27 1001 1

第一次返回：

1
(integer) 0

重复执行返回：

1
(integer) 1

因此返回值可以用来判断“这是不是用户当天第一次活跃”，但业务端仍需考虑事件、网络重试和整体流程的幂等性。

清除状态：

1
SETBIT active:2026-07-27 1001 0

6.2 GETBIT：读取 bit#

1
GETBIT key offset

示例：

1
GETBIT active:2026-07-27 1001

返回 0 或 1。key 不存在或 offset 超过当前 String 长度时返回 0。

6.3 BITCOUNT：统计 1 的数量#

1
BITCOUNT key [start end [BYTE | BIT]]

统计整个 Bitmap：

1
BITCOUNT active:2026-07-27

如果“一名用户对应一个 offset”，结果就是当天去重活跃用户数。

范围查询默认按 byte，而且 start、end 都包含在内：

1
BITCOUNT key 0 0

表示统计第 1 个字节（offset 0～7），不是只统计 bit 0。

Redis 7.0+ 可以显式按 bit 范围统计：

1
BITCOUNT key 0 0 BIT

这才表示只统计 bit 0。BYTE 是默认模式。范围索引可以为负数，-1 表示最后一个 byte 或 bit，取决于指定的模式。

6.4 BITOP：位运算#

当前语法：

1
BITOP operation destination source [source ...]

经典操作：

操作	含义
`AND`	交集：所有源 Bitmap 都为 1
`OR`	并集：至少一个源 Bitmap 为 1
`XOR`	异或：常用于两个 Bitmap 状态不同的成员
`NOT`	取反；只能有一个源 key

Redis 8.2 新增：

操作	含义
`DIFF dest X Y...`	在 X 中但不在任何 Y 中
`DIFF1 dest X Y...`	在任一 Y 中但不在 X 中
`ANDOR dest X Y...`	在 X 中，并且至少在一个 Y 中
`ONE dest X...`	只在一个源 Bitmap 中出现

示例——连续两天都活跃：

1
BITOP AND active:{app}:both \
2
  active:{app}:2026-07-26 \
3
  active:{app}:2026-07-27
4

5
BITCOUNT active:{app}:both

示例——两天内至少活跃一次：

1
BITOP OR active:{app}:union \
2
  active:{app}:2026-07-26 \
3
  active:{app}:2026-07-27
4

5
BITCOUNT active:{app}:union

Redis 8.2+ 查询“昨天活跃、今天未活跃”：

1
BITOP DIFF active:{app}:lost \
2
  active:{app}:2026-07-26 \
3
  active:{app}:2026-07-27
4

5
BITCOUNT active:{app}:lost

需要注意：

运算结果总会写入 destination；
返回值是目标 String 的字节长度，不是 1 的数量；
要统计结果，继续使用 BITCOUNT destination；
较短或不存在的源 key 会按 0 补齐到最长源 key 的长度；
BITOP 是 O(N)，大 Bitmap 运算可能阻塞；
Redis 8.2 以前只有 AND、OR、XOR、NOT。

在 Redis Cluster 中，源 key 和目标 key 应位于同一个 slot。上例通过共同的 hash tag {app} 达到这一点。

6.5 BITPOS：寻找第一个 0 或 1#

1
BITPOS key bit [start [end [BYTE | BIT]]]

示例：

1
BITPOS active:2026-07-27 1

返回第一个值为 1 的绝对 bit offset。

默认情况下，start 和 end 是 byte 范围；Redis 7.0+ 可使用 BIT：

1
BITPOS key 0 100 199 BIT

在 bit 100～199 中寻找第一个 0，但返回值仍是从整个 Bitmap offset 0 开始计算的绝对位置。

特殊返回语义：

查找 1，但 key 为空或全为 0：返回 -1；
不限定完整范围地查找 0 时，Redis 会把 String 右侧视作有无限个 0，因此全为 1 的三字节 String 会返回 24；
如果同时明确给出 start 和 end，而该范围内没有目标 bit，则返回 -1。

6.6 BITFIELD：把位数组当小整数数组#

1
BITFIELD key
2
  [GET encoding offset |
3
   [OVERFLOW WRAP|SAT|FAIL]
4
   <SET encoding offset value |
5
    INCRBY encoding offset increment> ...]

BITFIELD 不只是操作单个 0/1，它可以将一段连续 bit 解释为整数。

编码格式：

uN：N 位无符号整数，支持到 u63；
iN：N 位有符号整数，支持到 i64；
例如 u8 的范围是 0～255，i8 的范围是 -128～127。

三种主要操作：

GET：读取整数；
SET：写入整数，返回旧值；
INCRBY：原子增减，返回新值。

普通 offset 表示 bit offset：

1
BITFIELD stats SET u8 0 100 SET u8 8 20

带 # 的 offset 表示“第几个同宽整数”，Redis 会自动乘以字段宽度：

1
BITFIELD stats SET u8 #0 100 SET u8 #1 20
2
BITFIELD stats GET u8 #0 GET u8 #1

这两组写法等价。

溢出策略：

策略	行为
`WRAP`	默认，环绕；例如 `u8` 的 255 加 1 变为 0
`SAT`	饱和，超过范围后停在最大值或最小值
`FAIL`	不修改，并为该子操作返回 `nil/null`

示例：

1
BITFIELD counters \
2
  SET u8 #0 254 \
3
  OVERFLOW SAT INCRBY u8 #0 10 \
4
  GET u8 #0

对应返回值依次是：

一条 BITFIELD 可以包含多个子操作，它们会按顺序原子执行，返回数组与子操作一一对应。

6.7 BITFIELD_RO：只读查询#

1
BITFIELD_RO key GET encoding offset [GET encoding offset ...]

它只允许 GET，不能使用 SET、INCRBY 或 OVERFLOW，适合明确的只读访问和只读副本。

示例：

1
BITFIELD_RO stats GET u8 #0 GET u8 #1

7. 完整案例一：用户签到#

设计：

1
key    = signin:{userId}:2026-07
2
offset = 当月日期 - 1
3
value  = 是否签到

例如用户 1001 在 7 月 1、2、5、27 日签到：

1
SETBIT signin:{1001}:2026-07 0 1
2
SETBIT signin:{1001}:2026-07 1 1
3
SETBIT signin:{1001}:2026-07 4 1
4
SETBIT signin:{1001}:2026-07 26 1

查询 7 月 27 日是否签到：

1
GETBIT signin:{1001}:2026-07 26

统计本月签到天数：

1
BITCOUNT signin:{1001}:2026-07

结果：

1
(integer) 4

Bitmap 能高效回答“是否签到”和“签到多少天”，但签到的具体时间、设备、奖励流水仍应保存在数据库、Hash、Stream 等其他结构中。

8. 完整案例二：活跃用户与留存#

设计：

1
key    = active:{app}:yyyy-MM-dd
2
offset = 紧凑的用户数字 ID
3
value  = 当天是否活跃

记录活跃：

1
SETBIT active:{app}:2026-07-27 1001 1
2
SETBIT active:{app}:2026-07-27 1002 1
3
SETBIT active:{app}:2026-07-27 2000 1

日活：

1
BITCOUNT active:{app}:2026-07-27

两日都活跃：

1
BITOP AND active:{app}:retained \
2
  active:{app}:2026-07-20 \
3
  active:{app}:2026-07-27
4

5
BITCOUNT active:{app}:retained

如果“7 月 20 日活跃用户”正是所定义的初始 cohort，上述交集数可作为 7 日回访人数。留存率应在业务端计算：

1
7 日留存率 = 7 月 20 日与 7 月 27 日交集人数 ÷ 7 月 20 日 cohort 人数

真实留存通常还要限定“新增用户 cohort”等业务条件，不能把任意两个日活 Bitmap 的交集都直接称为标准留存。

9. Bitmap、Set、HyperLogLog、Bloom Filter 的选择#

结构	成员判断	精确计数	集合运算	能否枚举成员	主要特点
Bitmap	精确	精确	很快	不方便	适合紧凑整数 ID 和布尔状态
Set	精确	精确	支持	支持	适合稀疏 ID，单成员开销较大
HyperLogLog	不支持	近似基数	不直接支持交集	不支持	固定小内存，适合只求 UV
Bloom Filter	概率判断	不用于精确人数	不作为普通集合运算	不支持	可能假阳性，适合快速过滤不存在项

选择建议：

ID 连续、需要交并集：Bitmap；
ID 稀疏、需要列出成员：Set；
只关心近似 UV：HyperLogLog；
只需要低内存的“可能存在/一定不存在”判断：Bloom Filter。

10. 官方资料#

Redis GEO

Mon, 27 Jul 2026 00:00:00 GMT

适用范围：Redis Open Source 3.2+；新项目优先采用 Redis 6.2 引入的 GEOSEARCH 和 GEOSEARCHSTORE。

1. GEO 是什么#

Redis GEO（Geospatial，地理空间索引）用于保存“成员—经纬度”的对应关系，并完成：

坐标写入和更新；
查询成员坐标；
计算两个成员间的直线球面距离；
按圆形半径或矩形范围搜索附近成员；
按距离排序、限制数量或保存查询结果。

它适合“附近门店、车辆、骑手、充电桩、车站”等简单邻近搜索。它不是完整的 GIS：不支持道路距离、导航路径、行政区或任意多边形判断。

2. 底层数据结构与原理#

GEO 底层就是一个 Sorted Set（有序集合）：

member 是成员名，例如 北京站；
score 是经纬度经过 Geohash 思路编码得到的 52 位整数；
经纬度的二进制位交错排列，使空间上相近的点大概率拥有相近的 score；
范围搜索先按网格/包围盒筛选候选点，再计算实际球面距离并剔除范围外的点。

因此可以对 GEO key 使用部分 Sorted Set 命令：

1
TYPE geo:stations                 # zset
2
ZCARD geo:stations                # 成员数量
3
ZREM geo:stations 北京西站        # 删除成员；没有 GEODEL 命令

不要随意用 ZADD 修改 GEO 成员的 score，否则会破坏地理编码。需要修改坐标时重新执行 GEOADD。

3. 坐标规则#

GEOADD 的坐标顺序固定为：

1
经度 longitude（x）在前，纬度 latitude（y）在后

有效范围：

经度：-180 到 180；
纬度：-85.05112878 到 85.05112878。

纬度不能到达南北极，因为 Redis 采用的投影/编码范围不覆盖极区。

国内坐标系注意事项#

Redis 只存数字，不识别或转换坐标系。WGS‑84、GCJ‑02（高德/腾讯常见）和 BD‑09（百度常见）不可混用，否则会产生数百米甚至更大的偏移。写入、搜索中心和业务展示应统一使用同一种坐标系。

4. 常用命令总览#

命令	作用	版本与建议
`GEOADD`	添加或更新成员坐标	3.2+
`GEOPOS`	返回成员经纬度	3.2+
`GEODIST`	计算两个已存在成员的距离	3.2+
`GEOHASH`	返回成员的标准 Geohash 字符串	3.2+
`GEOSEARCH`	按圆形或矩形范围搜索	6.2+，推荐
`GEOSEARCHSTORE`	搜索并把结果保存为新 key	6.2+，推荐
`GEORADIUS`	以给定坐标为圆心搜索	6.2 起 deprecated
`GEORADIUSBYMEMBER`	以已有成员为圆心搜索	6.2 起 deprecated

“Deprecated”表示不建议新代码继续使用，并不等同于 Redis 6.2 立即删除了旧命令。迁移关系是：

1
GEORADIUS / GEORADIUSBYMEMBER
2
              ↓
3
GEOSEARCH（只返回）/ GEOSEARCHSTORE（保存结果）

5. 命令详解#

5.1 GEOADD：添加或更新位置#

1
GEOADD key [NX | XX] [CH] longitude latitude member [longitude latitude member ...]

默认：不存在则新增，存在则更新坐标；
NX：只新增，不更新已有成员；
XX：只更新已有成员，不新增；
CH：返回新增或坐标发生变化的成员数；不加时只统计新增数；
NX 与 XX 互斥。

单次可以批量写入多个成员：

1
GEOADD geo:stations \
2
  116.378248 39.865275 北京南站 \
3
  116.428030 39.903738 北京站 \
4
  116.322287 39.893729 北京西站

每个元素写入的时间复杂度为 O(log N)。

5.2 GEOPOS：查询坐标#

1
GEOPOS key member [member ...]

示例：

1
GEOPOS geo:stations 北京站 北京西站 不存在的站

返回顺序仍是“经度、纬度”；不存在的成员返回 nil/null。由于坐标会先编码成 52 位值，再解码返回，所以结果可能与写入值存在很小差异。

5.3 GEODIST：计算两个成员的距离#

1
GEODIST key member1 member2 [M | KM | FT | MI]

单位：

M：米，默认；
KM：千米；
MI：英里；
FT：英尺。

示例：

1
GEODIST geo:stations 北京西站 北京站 KM

结果约为：

1
9.0915 km

如果任一成员不存在，返回 nil/null。GEODIST 只能接受已经存入同一个 GEO key 的成员，不能直接传两个临时坐标。

Redis 使用 Haversine 公式，并把地球视为球体；极端情况下误差可能达到约 0.5%，因此不适合测绘、计费等高精度场景。这里得到的是球面直线距离，不是驾车或步行路线距离。

5.4 GEOHASH：查询 Geohash 字符串#

1
GEOHASH key member [member ...]

返回 11 个字符的标准 Geohash。可以从右侧截短以降低精度、扩大表示区域。

注意：

前缀相同通常说明位置相近；
位置相近不保证前缀一定相同，尤其在网格边界两侧；
GEO 内部使用的是 52 位整数变体，GEOHASH 返回的是便于外部使用的标准字符串。

5.5 GEOSEARCH：推荐的范围查询#

1
GEOSEARCH key
2
  <FROMMEMBER member | FROMLONLAT longitude latitude>
3
  <BYRADIUS radius M|KM|FT|MI | BYBOX width height M|KM|FT|MI>
4
  [ASC | DESC]
5
  [COUNT count [ANY]]
6
  [WITHCOORD] [WITHDIST] [WITHHASH]

搜索中心二选一：

FROMMEMBER member：以已有成员为中心；
FROMLONLAT longitude latitude：以临时坐标为中心。

搜索形状二选一：

BYRADIUS：圆形范围；
BYBOX：以中心为中心点、宽度和高度给定的轴对齐矩形。

常用选项：

ASC：从近到远；
DESC：从远到近；
COUNT n：最多返回 n 条；
COUNT n ANY：找到足够数量就尽早停止，可能更快，但不保证拿到真正最近的 n 条；
WITHDIST：附带到中心的距离；
WITHCOORD：附带坐标；
WITHHASH：附带内部 52 位 Geohash 值，通常只用于调试。

5.6 GEOSEARCHSTORE：保存搜索结果#

1
GEOSEARCHSTORE destination source
2
  <FROMMEMBER member | FROMLONLAT longitude latitude>
3
  <BYRADIUS radius M|KM|FT|MI | BYBOX width height M|KM|FT|MI>
4
  [ASC | DESC]
5
  [COUNT count [ANY]]
6
  [STOREDIST]

不加 STOREDIST：目标 Sorted Set 的 score 仍是地理编码，可继续做 GEO 查询；
加 STOREDIST：目标 Sorted Set 的 score 是到中心的距离，适合再用 ZRANGE ... WITHSCORES 排名，但目标 key 不再是可直接查询的地理索引；
命令返回写入目标 key 的元素数量；
如果目标 key 已存在，会被结果集替换。

示例：

1
GEOSEARCHSTORE geo:nearby:distance geo:stations \
2
  FROMLONLAT 116.397904 39.909005 \
3
  BYRADIUS 10 KM ASC STOREDIST
4

5
ZRANGE geo:nearby:distance 0 -1 WITHSCORES

在 Redis Cluster 中，这是一个涉及源 key 和目标 key 的多 key 命令。可用相同 hash tag 让它们落到同一 slot，例如：

1
geo:{beijing}:stations
2
geo:{beijing}:nearby

6. 性能与工程建议#

6.1 复杂度#

GEOADD：每个成员 O(log N)；
GEODIST：O(1)；
GEOPOS、GEOHASH：每个成员 O(1)；
GEOSEARCH / GEOSEARCHSTORE：官方标注为 O(N + log M)，其中 N 是形状外接网格范围内的候选元素数，M 是索引总元素数。

查询成本取决于范围内的候选密度，而不只是最终返回数量。超大半径、热点区域和无上限返回都可能带来较高延迟。

6.2 建议#

按城市、区域或业务类型拆分 key，避免一个 GEO key 无限制膨胀；
查询时尽量设置合理半径和 COUNT；
只追求低延迟且能接受近似结果时，考虑 COUNT n ANY；
成员只保存稳定 ID，例如 station:123，名称、地址等详情放在 Hash/JSON；
GEO key 和详情 key 分开设置容量治理与 TTL；过期是 key 级别，不能直接只给某个 GEO member 设置 TTL；
动态对象离线时用 ZREM 移除，或另外维护心跳时间并定期清理；
道路距离、路径规划、复杂多边形、跨坐标系转换应交给地图/GIS 服务；
如果还要按名称、标签、价格等条件联合过滤，可考虑 Redis Search 的 GEO/GEOSHAPE 能力，而不是只用基础 GEO 命令。

7. 官方资料#

Redis HyperLogLog

Mon, 27 Jul 2026 00:00:00 GMT

适用范围：Redis Open Source 2.8.9+。

1. 从 PV、UV 和基数说起#

1.1 PV#

PV（Page View）通常表示页面浏览量或事件发生次数。一次访问记一次，同一用户访问 10 次通常产生 10 个 PV。

PV 不需要去重，可以直接使用计数器：

1
INCR metrics:{shop}:pv:2026-07-27

1.2 UV#

UV（Unique Visitor）表示某个统计窗口内去重后的访问者数量。同一个用户在一天内访问多次，在日 UV 中只算一次。

1
访问事件：A A B C A B
2
PV：6
3
UV：3

严格来说，UV 不一定等于“自然人数”。它取决于业务选择的身份标识：

登录用户 ID；
Cookie ID；
设备 ID；
经过隐私评审的匿名标识；
IP 地址与其他特征的组合。

标识不稳定会把同一个人算成多人；多人共用一个标识又会被算成一人。因此定义 UV 时，必须同时说明身份标识和时间窗口。

1.3 基数#

基数（Cardinality）是集合中不重复元素的数量：

1
集合 {A, A, B, C, C} 的基数 = 3

HyperLogLog（简称 HLL）解决的正是“大规模数据的近似基数统计”问题。

2. HyperLogLog 是什么#

HyperLogLog 是一种概率数据结构：

输入可以不断重复；
不保存完整元素集合；
只维护一份很小的统计摘要；
最终返回去重数量的近似值；
内存基本不随已观察元素数量线性增长。

Redis 的实现：

最坏情况下约使用 12 KB 数据空间；
标准误差约为 0.81%；
最多可估计约 2^64 个不同元素；
核心命令是 PFADD、PFCOUNT、PFMERGE。

它适合流量趋势、独立访客、独立搜索词、独立设备、独立视频观众等“允许近似”的大规模统计。

3. 为什么不用普通 Set#

使用 Set 可以得到精确 UV：

1
SADD uv:exact user:1 user:2 user:3
2
SCARD uv:exact

但 Set 必须保存每一个唯一成员，内存复杂度为 O(N)。随着访问者数量增长，成员数据、哈希表节点和分配器开销都会持续增加。

HLL 不保存成员本身，只保存统计摘要。无论观察几万、几百万还是更多不同元素，密集表示的数据部分都约为 12 KB。代价是：

结果不是精确值；
无法取回成员；
无法判断某个成员是否存在；
无法删除某一个已加入元素。

4. 核心原理#

HyperLogLog 利用了这样一个概率现象：

在均匀随机的二进制序列中，连续出现很多个前导 0 很少见；观察到的最大前导 0 数越大，通常意味着观察过的不同元素越多。

简化流程：

对输入元素做均匀哈希，得到固定长度的二进制值；
用哈希值的一部分选择一个寄存器；
用剩余部分计算“第一个 1 出现前有多少个 0”；
该寄存器只保留它见过的最大值；
综合所有寄存器，通过调和平均和偏差修正估计基数。

Redis 使用：

1
16384 个寄存器 × 每个寄存器 6 bit = 98304 bit = 12288 byte

再加上 16 字节头部等内部信息。

同一个元素经过相同哈希后总会定位到同一寄存器、得到相同观测值，因此重复加入不会不断增加估算值。

4.1 为什么需要很多寄存器#

只记录一个“最大前导 0 数”波动太大。HLL 将输入分散到大量寄存器中，再综合所有观测值，使估计更稳定。

标准误差可近似理解为：

1
1.04 / sqrt(m)

当 m = 16384 时：

1
1.04 / sqrt(16384) ≈ 0.8125%

4.2 0.81% 不是最大误差保证#

Redis 文档中的 0.81% 是 标准误差，不是“每次结果与真实值的误差一定小于 0.81%”。

例如真实基数为 100 万时，0.81% 对应的标准误差量级约为 8100，但某一次估算的偏差可能更大或更小。若业务要求计费、结算、配额、审计等严格精确结果，应使用精确数据结构或数据库统计。

5. Redis 中的存储表示#

Redis HLL 在内部编码为 String：

1
PFADD hll:demo a b c
2
TYPE hll:demo

1
string

HLL 有两种内部表示：

稀疏表示：初期大量寄存器为 0，使用游程编码，内存可显著低于 12 KB；
密集表示：数据增多后自动转换，使用 16384 个 6-bit 寄存器，数据部分为 12288 字节。

它可以用 GET 序列化、用 SET 恢复，但不应使用普通 String 命令随意修改其中的字节，否则会破坏 HLL 编码或得到无意义结果。

6. 命令总览#

命令	作用	时间复杂度	返回值
`PFADD`	将一个或多个元素加入 HLL	每个元素 `O(1)`	寄存器是否发生变化
`PFCOUNT`	返回一个 HLL或多个 HLL 并集的估计基数	单 key 平均 `O(1)`；多 key 为 `O(N)`	估计基数
`PFMERGE`	将多个 HLL 的并集保存到目标 key	合并 N 个 HLL 为 `O(N)`，常数较高	`OK`

PFDEBUG、PFSELFTEST 是内部调试/测试命令，带有危险或管理属性，不属于普通业务 API。

7. 命令详解#

7.1 PFADD：加入观测元素#

1
PFADD key [element [element ...]]

添加单个用户：

1
PFADD metrics:{shop}:uv:2026-07-27 user:1001

批量添加：

1
PFADD metrics:{shop}:uv:2026-07-27 \
2
  user:1001 user:1002 user:1003

返回值：

1：至少一个内部寄存器发生变化；
0：没有寄存器发生变化。

需要特别注意：

1
PFADD 返回 1 ≠ 一定加入了一个从未出现的新元素
2
PFADD 返回 0 ≠ 这个元素一定曾经出现过

原因是 HLL 不保存成员集合。不同元素可能对现有寄存器状态没有进一步贡献。因此不能用 PFADD 的返回值实现精确的“首次访问”“用户是否存在”判断。

同一个元素重复执行 PFADD 对最终摘要是幂等的，适合处理可能重试的事件。

不传元素也是合法的：

1
PFADD hll:empty

key 不存在时会创建一个空 HLL；存在时不做实际修改。

7.2 PFCOUNT：估计基数#

单 key：

1
PFCOUNT metrics:{shop}:uv:2026-07-27

返回该日的估计 UV。key 不存在时返回 0。

多 key：

1
PFCOUNT \
2
  metrics:{shop}:uv:2026-07-21 \
3
  metrics:{shop}:uv:2026-07-22 \
4
  metrics:{shop}:uv:2026-07-23

返回三个 HLL 并集的估计基数。重复出现在多天中的同一用户只近似计算一次。

因此：

1
周 UV ≠ 每日 UV 直接相加

每日 UV 相加会重复计算跨天访问者，周 UV 应通过多 key PFCOUNT 或 PFMERGE 后再统计。

性能区别：

单 key PFCOUNT 会使用内部缓存，平均开销很小；
多 key PFCOUNT 会临时合并所有 HLL，不能复用并集缓存，调用频繁时成本明显更高。

一个较少见但重要的内部细节是：PFCOUNT 可能更新 HLL 头部中的基数缓存。因此从底层实现看，它可能修改最后几个缓存字节，即使业务语义上它是读取统计值。

7.3 PFMERGE：合并并保存#

1
PFMERGE destination [source [source ...]]

示例：

1
PFMERGE metrics:{shop}:uv:2026-W31 \
2
  metrics:{shop}:uv:2026-07-27 \
3
  metrics:{shop}:uv:2026-07-28 \
4
  metrics:{shop}:uv:2026-07-29
5

6
PFCOUNT metrics:{shop}:uv:2026-W31

PFMERGE 保存的是可继续合并和计数的 HLL 摘要，不是普通整数。

合并的底层含义可以简化为：对每个寄存器取所有源 HLL 中的最大值。因此 HLL 合并具有：

可交换性；
可结合性；
幂等性。

这让它适合分片统计后汇总。

目标 key 的累积语义#

如果 destination 已存在，Redis 会把 destination 本身也当作一个源 HLL：

1
PFMERGE total old-part
2
PFMERGE total new-part

第二次结果包含原有 total 与 new-part 的并集，而不是单纯用 new-part 覆盖。

如果要从头重新计算某个固定名称的汇总 key，需要先明确删除旧目标，或者更稳妥地写入一个新的版本化 key，再切换引用：

1
metrics:{shop}:uv:2026-W31:v2

8. 完整案例：同时统计 PV 和 UV#

假设用户 1001 当天访问三次，用户 1002 访问两次。

每次访问都增加 PV：

1
INCR metrics:{shop}:pv:2026-07-27

每次访问也将稳定用户标识加入 HLL：

1
PFADD metrics:{shop}:uv:2026-07-27 user:1001
2
PFADD metrics:{shop}:uv:2026-07-27 user:1001
3
PFADD metrics:{shop}:uv:2026-07-27 user:1001
4
PFADD metrics:{shop}:uv:2026-07-27 user:1002
5
PFADD metrics:{shop}:uv:2026-07-27 user:1002

查询：

1
GET metrics:{shop}:pv:2026-07-27
2
PFCOUNT metrics:{shop}:uv:2026-07-27

小样本中通常会得到类似：

1
PV = 5
2
UV ≈ 2

PV 是精确计数，UV 是近似基数。不要使用 HLL 统计 PV，因为 HLL 会自动弱化重复元素的贡献。

9. 日 UV、周 UV、月 UV#

9.1 每天一个 HLL#

1
metrics:{shop}:uv:2026-07-27
2
metrics:{shop}:uv:2026-07-28
3
metrics:{shop}:uv:2026-07-29

这样可以：

独立查询每天 UV；
灵活合并周/月 UV；
按保留周期设置 TTL；
避免永久 HLL 无法删除历史元素的问题。

9.2 临时查询周 UV#

1
PFCOUNT \
2
  metrics:{shop}:uv:2026-07-27 \
3
  metrics:{shop}:uv:2026-07-28 \
4
  metrics:{shop}:uv:2026-07-29 \
5
  metrics:{shop}:uv:2026-07-30 \
6
  metrics:{shop}:uv:2026-07-31

适合低频临时查询。

9.3 预聚合周 UV#

1
PFMERGE metrics:{shop}:uv:2026-W31 \
2
  metrics:{shop}:uv:2026-07-27 \
3
  metrics:{shop}:uv:2026-07-28 \
4
  metrics:{shop}:uv:2026-07-29 \
5
  metrics:{shop}:uv:2026-07-30 \
6
  metrics:{shop}:uv:2026-07-31
7

8
PFCOUNT metrics:{shop}:uv:2026-W31

适合频繁查询报表。汇总 key 可设置比日 key 更长的 TTL。

9.4 时间窗口必须统一#

业务应明确：

使用 UTC 还是业务时区；
按事件发生时间还是服务器接收时间；
日界线如何定义；
迟到事件如何补录；
夏令时地区如何处理。

否则同一事件可能被放入不同日期的 HLL，导致跨系统统计不一致。

10. HLL 能做什么、不能做什么#

10.1 能做#

近似统计去重数量；
合并多个统计窗口或分片的并集；
用固定小内存持续接收大量重复事件；
序列化摘要并在其他 Redis 实例恢复。

10.2 不能做#

判断用户 1001 是否访问过；
列出所有访问用户；
返回某个用户出现次数；
删除单个用户的贡献；
精确计算基数；
直接计算交集、差集；
替代审计明细或原始事件存储。

如果必须支持成员查询、删除、枚举或精确集合运算，应使用 Set、Bitmap、数据库或其他合适结构。

11. 交集与留存为什么要谨慎#

数学上可以用容斥关系估算两个集合的交集：

1
|A ∩ B| ≈ PFCOUNT(A) + PFCOUNT(B) - PFCOUNT(A, B)

但三次 HLL 估计都有误差，做减法时误差会叠加。如果真实交集远小于 A、B 的规模，相对误差可能非常大，甚至可能出现不合理结果。

因此：

HLL 很适合估计并集 UV；
不适合要求稳定精度的留存、交集、流失用户统计；
精确或小交集场景优先使用 Bitmap、Set 或离线明细计算。

12. HLL、Set、Bitmap、Bloom Filter 的选择#

结构	主要问题	结果	成员查询	枚举/删除	集合运算	内存特点
HyperLogLog	有多少个不同元素	近似	不支持	不支持	主要支持并集合并	最高约 12 KB
Set	有哪些不同元素	精确	支持	支持	交并差集	随成员数增长
Bitmap	哪些紧凑整数 ID 为真	精确	支持	可清 bit	快速交并差	取决于最大 offset
Bloom Filter	某元素是否可能存在	概率	支持概率判断	通常不能枚举	不是普通集合统计	小内存，可能假阳性

快速选择：

只要近似 UV，数据量很大：HLL；
要精确人数并保留成员：Set；
用户 ID 紧凑且需要精确交并集：Bitmap；
只要快速判断“可能存在/一定不存在”：Bloom Filter。s

13. 官方资料#

Redis实战：Redisson 分布式锁与 Stream 消息队列

Fri, 17 Jul 2026 00:00:00 GMT

本文整理两个常见的 Redis 实战场景：使用 Redisson 实现分布式锁，以及使用 Redis Stream 构建支持消息持久化、阻塞读取、消费者组和消息确认的消息队列。

一、Redisson 分布式锁#

Redisson 是 Redis 的 Java 客户端之一。它在 Redis 命令之上封装了分布式锁、集合、信号量等常用组件，可以减少手动编写锁续期和解锁脚本的工作。

1. 引入依赖#

1
<dependency>
2
    <groupId>org.redisson</groupId>
3
    <artifactId>redisson</artifactId>
4
    <version>3.13.6</version>
5
</dependency>

2. 配置 Redisson 客户端#

1
@Configuration
2
public class RedissonConfig {
3

4
    @Bean
5
    public RedissonClient redissonClient() {
6
        // 配置
7
        Config config = new Config();
8
        config.useSingleServer().setAddress("redis://10.211.55.3:6379").setPassword("123123");
9
        // 创建RedissonClient对象
10
        return Redisson.create(config);
11
    }
12
}

3. 在业务中使用锁#

这段代码以用户 ID 作为锁粒度，保证同一用户的下单请求串行执行。不同用户使用不同的锁，因此仍然可以并发下单。

1
    @Resource
2
    private RedissonClient redissonClient;
3

4

5
        Long userId = UserHolder.getUser().getId();
6
        // 创建锁对象
7
        // SimpleRedisLock lock = new SimpleRedisLock("order" + userId, stringRedisTemplate);
8
        RLock lock = redissonClient.getLock("lock:order:" + userId);
9
        // 获取锁
10
        boolean isLock = lock.tryLock();
11
        //  判断是否获取锁成功
12
        if(!isLock){
13
            // 获取锁失败，返回错误或重试
14
            return Result.fail("不允许重复下单");
15
        }
16
        try{
17
            // 获取代理对象(事物)
18
            IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
19
            return proxy.createVoucherOrder(voucherId);
20
        } finally {
21
            // 释放锁
22
            lock.unlock();
23
        }

展开收起

4. 使用分布式锁时需要注意什么#

tryLock() 会立即尝试获取锁，失败后直接返回；需要等待时可以使用带等待时间的重载方法。
未显式指定租约时间时，Redisson 的看门狗机制会在持锁线程仍然存活时自动续期。
解锁必须放在 finally 中，避免业务异常导致锁无法释放。
只有锁的持有线程才能解锁。复杂流程中可在解锁前使用 lock.isHeldByCurrentThread() 检查。
分布式锁不能替代数据库约束。防止重复下单时，数据库唯一索引仍是最后一道保障。
通过 AopContext.currentProxy() 获取代理对象，需要启用代理暴露；否则可能抛出异常。也可以通过拆分 Service 避免同类内部调用导致事务失效。

二、Redis Stream 基础#

Redis Stream 是 Redis 5.0 引入的数据类型，适合保存按时间追加的事件。一个 Stream 可以理解为一条只向尾部追加的日志，每条消息称为一个 Entry。

Stream 的基本结构如下：

1
Stream key
2
  ├── 1720000000000-0  name=jack  age=21
3
  ├── 1720000000100-0  name=rose  age=20
4
  └── 1720000000100-1  name=tom   age=22

每条 Entry 包含两部分：

唯一消息 ID，例如 1720000000000-0。
一个或多个 field value 键值对。

消息 ID 的格式是 毫秒时间戳-序列号。同一毫秒内产生多条消息时，序列号会递增。通常使用 * 让 Redis 自动生成 ID。

三、使用 XADD 发送消息#

1. 基本语法#

1
XADD key [NOMKSTREAM] [MAXLEN | MINID [= | ~] threshold [LIMIT count]]
2
     * | ID field value [field value ...]

常用参数：

key：Stream 的名称。
NOMKSTREAM：Stream 不存在时不自动创建；默认会自动创建。
MAXLEN：限制 Stream 的最大长度，避免消息无限堆积。
MINID：删除小于指定 ID 的旧消息。
~：近似裁剪，通常比精确裁剪 = 的性能更好。
*：让 Redis 自动生成消息 ID。
field value：消息内容，可以包含多个键值对。

2. 添加一条消息#

1
XADD users * name jack age 21

返回值是新消息的 ID：

1
"1644805700523-0"

3. 限制队列长度#

1
XADD users MAXLEN ~ 10000 * name jack age 21

该命令在添加消息的同时，把 Stream 大致控制在 10000 条以内。~ 是近似裁剪，实际长度可能略大于阈值。

常用的查看命令：

1
XLEN users
2
XRANGE users - + COUNT 10
3
XREVRANGE users + - COUNT 10
4
XINFO STREAM users

四、使用 XREAD 读取消息#

XREAD 直接读取 Stream，不使用消费者组。它适合单消费者读取，或者多个消费者都需要接收同一份消息的广播式场景。

1. 基本语法#

1
XREAD [COUNT count] [BLOCK milliseconds] STREAMS key [key ...] ID [ID ...]

阻塞 1 秒，等待 users 中的新消息：

1
XREAD COUNT 1 BLOCK 1000 STREAMS users $

如果 1 秒内没有新消息，命令返回 nil。BLOCK 0 表示一直阻塞，直到有消息到达。

2. 起始 ID 的含义#

0-0：从最早的消息开始读取。
某个具体 ID：读取 ID 大于它的消息，适合接着上一次的位置继续读取。
$：只等待执行命令之后到达的新消息。

3. 为什么循环使用 `$` 可能漏读#

如果每次循环都执行下面的命令：

1
XREAD COUNT 1 BLOCK 2000 STREAMS users $

那么 $ 每次都会重新代表“当前 Stream 的最后一条消息”。消费者处理上一条消息期间，如果又有多条消息到达，下次读取会从新的队尾开始等待，这些已经到达的消息可能被跳过。

更稳妥的做法是保存最后一次成功读取的消息 ID，并在下一次读取时传入该 ID：

1
lastId = 0-0
2

3
循环：
4
  messages = XREAD COUNT 10 BLOCK 2000 STREAMS users lastId
5
  依次处理 messages
6
  lastId = 本批最后一条消息的 ID

如果进程重启后仍要从原位置继续，还需要把 lastId 持久化。Redis 本身不会为普通 XREAD 保存消费者进度。

4. XREAD 的特点#

支持按 ID 回溯历史消息。
支持阻塞读取。
多个客户端可以读取同一条消息，彼此之间不会自动分流。
Redis 不记录每个读取者的确认状态。
使用方式不当会跳过消息，因此不适合直接承担需要可靠消费的复杂业务。

五、消费者组 Consumer Group#

消费者组将多个消费者组织成一个组，共同消费同一个 Stream。它主要解决三个问题：消息分流、消费进度记录和消息确认。

1. 消息分流#

同一消费者组中的多个消费者会竞争组内的新消息。一条新消息通常只交给组内的一个消费者处理，从而提高整体吞吐量。

不同消费者组之间互不影响。同一条消息可以分别被多个消费者组各消费一次。

2. 消费进度#

消费者组维护最后投递位置，用于记录哪些新消息已经投递给该组。消费者宕机重启后，消费者组可以继续从组的进度读取新消息。

3. Pending Entries List#

消费者读取消息后，如果没有使用 NOACK，该消息会进入 Pending Entries List，简称 PEL。PEL 记录消息 ID、所属消费者、空闲时间和投递次数。

业务处理成功后，需要执行 XACK 确认消息。确认成功后，消息才会从 PEL 中移除。注意，XACK 只会修改消费者组的确认状态，不会删除 Stream 中的原始消息。

六、管理消费者组#

1. 创建消费者组#

1
XGROUP CREATE key groupName ID [MKSTREAM]

示例：

1
XGROUP CREATE users user-group 0-0 MKSTREAM

参数说明：

key：Stream 名称。
groupName：消费者组名称。
ID：消费者组的起始位置。
0-0：从 Stream 中现有的第一条消息开始消费。
$：忽略当前已有消息，只消费创建消费者组之后的新消息。
MKSTREAM：Stream 不存在时自动创建一个空 Stream。

2. 其他管理命令#

1
# 删除消费者组
2
XGROUP DESTROY users user-group
3

4
# 手动创建消费者
5
XGROUP CREATECONSUMER users user-group consumer-1
6

7
# 删除消费者
8
XGROUP DELCONSUMER users user-group consumer-1
9

10
# 查看消费者组和消费者信息
11
XINFO GROUPS users
12
XINFO CONSUMERS users user-group

消费者通常不必手动创建。第一次执行 XREADGROUP 时，如果消费者名称不存在，Redis 会自动创建该消费者。

删除消费者前必须先处理其 Pending 消息。直接执行 XGROUP DELCONSUMER 会删除该消费者对应的 Pending 记录，未确认消息将无法再通过原 PEL 恢复。

七、使用 XREADGROUP 消费消息#

1. 基本语法#

1
XREADGROUP GROUP group consumer
2
  [COUNT count]
3
  [BLOCK milliseconds]
4
  [NOACK]
5
  STREAMS key [key ...] ID [ID ...]

读取新消息：

1
XREADGROUP GROUP user-group consumer-1 COUNT 10 BLOCK 2000 STREAMS users >

参数说明：

group：消费者组名称。
consumer：当前消费者名称；不存在时会自动创建。
COUNT：本次最多返回的消息数量。
BLOCK：没有消息时的最长等待时间，单位为毫秒。
STREAMS：后面依次提供 Stream 名称和对应的起始 ID。
>：读取从未投递给当前消费者组的新消息。

2. `>` 和具体 ID 的区别#

使用 > 时，读取尚未投递给消费者组的新消息。
使用 0 或 0-0 等具体 ID 时，读取已经分配给当前消费者、但尚未确认的 Pending 消息。
具体 ID 不会直接读取其他消费者名下的 Pending 消息。接管其他消费者的消息需要使用 XCLAIM 或 XAUTOCLAIM。

3. 谨慎使用 NOACK#

NOACK 表示消息被读取后不进入 PEL。它更接近“无需确认”，而不是业务成功后的“自动确认”。如果消费者读取后立刻宕机，消息不会留在 PEL 中供后续重试。

对订单、支付、库存等可靠性要求高的业务，不建议使用 NOACK。

八、消息确认与异常恢复#

1. 确认消息#

业务处理成功后执行：

1
XACK users user-group 1644805700523-0

推荐顺序是：

1
读取消息 -> 执行业务 -> 业务成功提交 -> XACK

如果业务处理失败，不要确认消息，让它继续保留在 PEL 中，等待重试或被其他消费者接管。

2. 查看 Pending 消息#

1
XPENDING users user-group
2
XPENDING users user-group - + 10
3
XPENDING users user-group - + 10 consumer-1

第一条命令查看 PEL 摘要，后两条命令查看 Pending 消息明细。

3. 接管长时间未处理的消息#

Redis 6.2 及以上可以使用 XAUTOCLAIM：

1
XAUTOCLAIM users user-group consumer-2 60000 0-0 COUNT 10

这表示由 consumer-2 接管空闲时间至少达到 60000 毫秒的 Pending 消息。较早版本可以先用 XPENDING 找到消息 ID，再使用 XCLAIM 接管。

4. 推荐的可靠消费流程#

1
1. 使用 XREADGROUP ... STREAMS users > 阻塞读取新消息
2
2. 执行业务逻辑
3
3. 业务成功后执行 XACK
4
4. 业务失败时保留 Pending 状态，并记录失败原因
5
5. 定时扫描空闲时间过长的 Pending 消息
6
6. 使用 XAUTOCLAIM 或 XCLAIM 接管并重试
7
7. 超过最大重试次数后写入自定义死信 Stream，并人工或定时处理

消费者组配合 PEL 和 ACK 可以实现至少一次投递，但不能天然实现严格的恰好一次。消费者可能在“业务已成功、ACK 尚未发送”时宕机，恢复后同一条消息会再次处理，因此业务必须具备幂等性。

常见幂等方案：

使用消息 ID 作为幂等键，并记录已处理消息。
利用数据库唯一索引阻止重复写入。
使用业务单号检查当前状态，只允许合法的状态迁移。
把业务写入和消费记录放在同一个数据库事务中。

九、XREAD 与 XREADGROUP 对比#

对比项	`XREAD`	`XREADGROUP`
消费模式	多个读取者可以重复读取同一消息	组内消费者竞争新消息
消费进度	客户端自行保存最后 ID	Redis 保存消费者组投递进度
消息确认	不支持	支持 `XACK`
Pending 记录	不支持	支持 PEL
故障恢复	需要应用自行实现	可通过 `XPENDING`、`XCLAIM`、`XAUTOCLAIM` 恢复
适用场景	简单读取、广播、历史查询	任务分发、并行消费、可靠消息处理

不能简单地认为 XREADGROUP “绝对不会漏消息”。可靠性仍取决于是否正确使用 ACK、是否恢复 Pending 消息、是否误用 NOACK、是否过早裁剪 Stream，以及业务是否具备幂等性。

十、List、Pub/Sub 与 Stream 对比#

能力	List	Pub/Sub	Stream
消息持久化	支持	不支持	支持
阻塞读取	支持	支持订阅等待	支持
多消费者分流	支持，但需自行设计	不适用，订阅者各收一份	消费者组原生支持
消息确认	无原生 ACK	不支持	支持
消息回溯	不方便	不支持	按 ID 支持
消费进度	应用自行维护	不维护	消费者组维护
典型场景	简单任务队列	实时通知、允许丢失的广播	可靠任务队列、事件流

选择建议：

只需要非常简单的先进先出任务队列，可以考虑 List。
只关心在线订阅者，并且允许离线期间丢消息，可以使用 Pub/Sub。
需要持久化、回溯、消费者组、确认和故障恢复时，优先考虑 Stream。

十一、生产实践建议#

使用 MAXLEN ~ 或定期 XTRIM 控制 Stream 长度，防止内存无限增长。
每个消费者实例使用唯一且稳定的消费者名称，便于观察和故障接管。
使用 BLOCK 阻塞读取，避免无消息时高频轮询消耗 CPU。
业务成功后再执行 XACK，不要把“读取成功”当成“处理成功”。
定时监控 PEL 数量、消息空闲时间、投递次数和消费者状态。
对重复消费做好幂等处理，这是至少一次投递模型中的必要设计。
设计最大重试次数和死信 Stream，避免异常消息永久占用重试资源。
裁剪或删除消息前确认消费组的处理进度。过早清理可能导致 PEL 中只剩消息 ID，而消息正文已经不存在。

总结#

Redisson 分布式锁解决的是多个应用实例之间的并发互斥问题，Redis Stream 解决的是消息的持久化、分发与消费进度管理问题。二者可以组合使用，但职责不同：锁用于保护临界区，Stream 用于解耦生产者和消费者。

学习 Redis Stream 时，需要重点掌握以下关系：

1
XADD        负责生产消息
2
XREAD       负责不带消费者组的读取
3
XGROUP      负责创建和管理消费者组
4
XREADGROUP  负责组内分流和消费
5
XPENDING    负责查看未确认消息
6
XACK        负责确认处理完成
7
XCLAIM / XAUTOCLAIM 负责接管超时未完成的消息

Redis全局唯一ID

Sat, 11 Jul 2026 00:00:00 GMT

全局ID生成器#

订单表使用数据库自增ID存在一些问题：

ID的规律性太明显，容易暴露业务数据量
分库分表后，不同表可能生成重复ID
受单表数据量和单库写入能力的限制

全局ID生成器，是一种在分布式系统下用来生成全局唯一ID的工具，一般要满足下列特性：

唯一性
高可用
高性能
递增性
安全性

为了增加ID的安全性，不直接使用Redis自增的数值，而是拼接时间戳等其它信息。

ID的组成#

64位long类型表示：

符号位：1 bit，固定为0
时间戳：31 bit，以秒为单位，大约可以使用68年
序列号：32 bit，使用Redis自增值生成

1
0 | 31位时间戳 | 32位序列号

生成公式：

1
return timestamp << COUNT_BITS | count;

使用相对时间戳而不是完整时间戳，可以减少时间戳占用的位数。

Redis自增策略#

Redis Key按照“业务类型+日期”划分：

1
icr:order:2026:07:09
2
icr:order:2026:07:10

这样可以让不同业务使用不同计数器，并且能够按天统计订单量。

Redis的INCR命令是原子操作，多线程并发执行时不会生成重复序号。

代码中的计数器实际上是按天递增，因此同一个Key在一天内不能超过2^32 - 1。

RedisIdWorker.java#

1
@Component
2
public class RedisIdWorker {
3

4
    // 开始时间戳
5
    private static final long BEGIN_TIMESTAMP = 1783555200L;
6
    // 序列号的位数
7
    private static final int COUNT_BITS = 32;
8

9
    private StringRedisTemplate stringRedisTemplate;
10

11
    public RedisIdWorker(StringRedisTemplate stringRedisTemplate) {
12
        this.stringRedisTemplate = stringRedisTemplate;
13
    }
14

15
    public long nextId(String keyPrefix) {
16
        // 1.生成时间戳
17
        LocalDateTime now = LocalDateTime.now();
18
        long nowSecond = now.toEpochSecond(ZoneOffset.UTC);
19
        long timestamp  = nowSecond - BEGIN_TIMESTAMP;
20
        // 2.生成序列号
21
        // 2.1获取当前日期，精确到日
22
        String date = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));
23
        long count = stringRedisTemplate.opsForValue().increment("icr:" + keyPrefix + ":" + date);
24
        // 3.拼接并返回
25
        return timestamp << COUNT_BITS | count;
26
    }
27
    public static void main(String[] args) {
28
        LocalDateTime time = LocalDateTime.of(2026, 7, 9, 0, 0, 0);
29
        long second = time.toEpochSecond(ZoneOffset.UTC);
30
        System.out.println(second);
31
    }
32
}

展开收起

HmDianPingApplicationTests.java#

1
@Resource
2
private RedisIdWorker redisIdWorker;
3

4
private ExecutorService es = Executors.newFixedThreadPool(500);
5

6
@Test
7
void testIDWorker() throws InterruptedException {
8
    CountDownLatch latch = new CountDownLatch(300);
9

10
    Runnable task = () -> {
11
        try {
12
            for (int i = 0; i < 100; i++) {
13
                long id = redisIdWorker.nextId("order");
14
                System.out.println("id= " + id);
15
            }
16
        } finally {
17
            latch.countDown();
18
        }
19
    };
20

21
    long begin = System.currentTimeMillis();
22

23
    for (int i = 0; i < 300; i++) {
24
        es.submit(task);
25
    }
26

27
    latch.await();
28

29
    long end = System.currentTimeMillis();
30

31
    System.out.println("time = " + (end - begin));
32

33
    es.shutdown();
34
}

展开收起

全局ID常见实现还有：

UUID
数据库自增
Redis自增
Snowflake雪花算法

优惠券添加#

数据库使用两张表保存优惠券信息：

tb_voucher保存优惠券基本信息，例如优惠金额、使用规则、折扣信息和店铺ID。

tb_seckill_voucher保存秒杀库存、秒杀开始时间和秒杀结束时间。只有秒杀优惠券才需要保存这些信息。

VoucherController.java#

1
@RestController
2
@RequestMapping("/voucher")
3
public class VoucherController {
4

5
    @Resource
6
    private IVoucherService voucherService;
7

8
    /**
9
     * 新增秒杀券
10
     * @param voucher 优惠券信息，包含秒杀信息
11
     * @return 优惠券id
12
     */
13
    @PostMapping("seckill")
14
    public Result addSeckillVoucher(@RequestBody Voucher voucher) {
15
        voucherService.addSeckillVoucher(voucher);
16
        return Result.ok(voucher.getId());
17
    }
18
}

展开收起

VoucherOrderServiceImpl.java#

1
@Override
2
@Transactional
3
public Result seckillVoucher(Long voucherId) {
4
    // 1.查询优惠卷
5
    SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
6
    // 2.判断秒杀是否开始
7
    if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {
8
        // 尚未开始
9
        return Result.fail("秒杀尚未开始:");
10
    }
11
    // 3.判断秒杀时候已经结束
12
    if (voucher.getEndTime().isBefore(LocalDateTime.now())) {
13
        return Result.fail("秒杀已经结束:");
14
    }
15
    // 4.判断库存是否充足
16
    if (voucher.getStock()<1) {
17
        // 库存不足
18
        return Result.fail("库存不足");
19
    }
20
    // 5.扣减库存
21
    boolean success = seckillVoucherService.update()
22
            .setSql("stock = stock - 1")
23
            .eq("voucher_id", voucherId)
24
            .update();
25
    if(!success) {
26
        // 扣减失败
27
        return Result.fail("库存不足");
28
    }
29
    // 6.创建订单
30
    VoucherOrder voucherOrder = new VoucherOrder();
31
    // 6.1 订单id
32
    long orderId = redisIdWorker.nextId("order");
33
    voucherOrder.setId(orderId);
34
    // 6.2 用户id
35
    Long userId = UserHolder.getUser().getId();
36
    voucherOrder.setUserId(userId);
37
    // 6.3 代金劵id
38
    voucherOrder.setVoucherId(voucherId);
39
    save(voucherOrder);
40
    // 7 返回订单
41
    return Result.ok(orderId);
42
}

展开收起

商品超卖#

原因是查询库存、判断库存和扣减库存不是一个不可分割的原子操作。

悲观锁#

悲观锁认为线程安全问题一定会发生，因此操作共享数据前先获取锁，使线程串行执行。

常见实现：

synchronized
Lock
数据库排他锁

优点是实现简单、安全性直观；缺点是线程需要等待，并发性能相对较低。

乐观锁#

乐观锁不直接加锁，而是在更新数据时判断数据是否已经被其他线程修改。

常见方式：

版本号法
CAS法
使用库存本身作为判断条件

版本号法：

1
UPDATE tb_seckill_voucher
2
SET stock = stock - 1,
3
    version = version + 1
4
WHERE voucher_id = ?
5
  AND version = ?;

秒杀库存只需要保证库存不小于0，可以使用stock > 0作为更新条件：

VoucherOrderServiceImpl.java#

1
// 5.扣减库存
2
boolean success = seckillVoucherService.update()
3
        .setSql("stock = stock - 1")
4
        .eq("voucher_id", voucherId).gt("stock",0)
5
        .update();
6
if(!success) {
7
    // 扣减失败
8
    return Result.fail("库存不足");
9
}

一人一单#

需求：同一个用户只能购买同一种优惠券一次。

单机环境加锁#

VoucherOrderServiceImpl.java#

1
Long userId = UserHolder.getUser().getId();
2
synchronized(userId.toString().intern()) {
3
    // 获取代理对象(事物)
4
    IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
5
    return proxy.createVoucherOrder(voucherId);
6
}

锁对象使用用户ID，能够使同一用户的请求互斥，同时允许不同用户并发下单。

创建订单#

VoucherOrderServiceImpl.java#

1
@Transactional
2
public Result createVoucherOrder(Long voucherId) {
3
    // 一人一单
4
    Long userId = UserHolder.getUser().getId();
5
    // 查询订单
6
    int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
7
    // 判断是否存在
8
    if (count > 0) {
9
        // 用户已经购买过了
10
        return Result.fail("用户已经购买一次");
11
    }
12

13
    // 5.扣减库存
14
    boolean success = seckillVoucherService.update()
15
            .setSql("stock = stock - 1") // set stock = stock - 1
16
            .eq("voucher_id", voucherId).gt("stock",0) // where id = ? and stock = ?
17
            .update();
18
    if(!success) {
19
        // 扣减失败
20
        return Result.fail("库存不足");
21
    }
22

23
    // 6.创建订单
24
    VoucherOrder voucherOrder = new VoucherOrder();
25
    // 6.1 订单id
26
    long orderId = redisIdWorker.nextId("order");
27
    voucherOrder.setId(orderId);
28
    // 6.2 用户id
29
    voucherOrder.setUserId(userId);
30
    // 6.3 代金劵id
31
    voucherOrder.setVoucherId(voucherId);
32
    save(voucherOrder);
33
    // 7 返回订单
34
    return Result.ok(orderId);
35
}

展开收起

HmDianPingApplication.java#

1
// 启动类
2
@EnableAspectJAutoProxy(exposeProxy = true)
3
@MapperScan("com.hmdp.mapper")
4
@SpringBootApplication
5
public class HmDianPingApplication {
6

7
    public static void main(String[] args) {
8
        SpringApplication.run(HmDianPingApplication.class, args);
9
    }
10
}

xml#

1
<dependency>
2
    <groupId>org.aspectj</groupId>
3
    <artifactId>aspectjweaver</artifactId>
4
</dependency>

数据库唯一索引兜底#

即使业务代码已经加锁，也建议在数据库中增加唯一索引：

1
ALTER TABLE tb_voucher_order
2
ADD CONSTRAINT uk_user_voucher
3
UNIQUE (user_id, voucher_id);

唯一索引是“一人一单”的最后一道防线，可以防止程序异常、锁失效或重复消息造成重复订单。

集群环境中的锁失效问题#

集群环境下，请求可能分别进入JVM1和JVM2。每个JVM都有自己的锁监视器，因此两个线程都可能获得各自JVM中的锁。

synchronized只能保证单个JVM内部互斥，不能解决集群环境中的并发问题。

Redis分布式锁

Sat, 11 Jul 2026 00:00:00 GMT

分布式锁#

分布式锁是满足分布式系统或集群模式下多进程可见并且互斥的锁。

基本要求：

互斥性
多进程可见
安全性
高可用
高性能
防止死锁

常见实现：

实现方式	核心机制	特点
MySQL	唯一索引、行锁或排他锁	实现方便，性能通常低于Redis
Redis	SET NX EX	性能高，需要处理过期和误删问题
ZooKeeper	临时节点、顺序节点	一致性较强，连接断开后临时节点自动删除

基于Redis实现分布式锁#

ILock.lua#

1
public interface ILock {
2

3
    /**
4
     * 尝试获取锁
5
     * @param timeoutSec 锁持有的超时时间，过期后自动释放
6
     * @return true代表获取锁成功，false代表获取锁失败
7
     */
8
    boolean tryLock(long timeoutSec);
9

10
    /**
11
     * 释放锁
12
     */
13
    void unlock();
14
}

SimpleRedisLock.java#

1
public class SimpleRedisLock implements ILock {
2

3
    private String name;
4
    private StringRedisTemplate stringRedisTemplate;
5

6
    public SimpleRedisLock(String name, StringRedisTemplate stringRedisTemplate){
7
        this.name = name;
8
        this.stringRedisTemplate = stringRedisTemplate;
9
    }
10
    private static final String KEY_PREFIX="lock";
11

12
    @Override
13
    public boolean tryLock(long timeoutSec) {
14
        // 获取线程标识
15
        long threadId = Thread.currentThread().getId();
16
        // 获取锁
17
        Boolean success = stringRedisTemplate.opsForValue().
18
                setIfAbsent(KEY_PREFIX + name, threadId + "", timeoutSec, TimeUnit.SECONDS);
19
        return Boolean.TRUE.equals(success);
20
    }
21

22
    @Override
23
    public void unlock() {
24
        // 释放锁
25
        stringRedisTemplate.delete(KEY_PREFIX + name);
26
    }
27
}

展开收起

setIfAbsent同时传入过期时间时，底层相当于一个原子的Redis命令：

1
SET lock thread1 NX EX 10

NX保证只有Key不存在时才能获取锁
EX设置过期时间，避免服务宕机后产生死锁

VoucherOrderServiceImpl.java#

1
Long userId = UserHolder.getUser().getId();
2
// 创建锁对象
3
SimpleRedisLock lock = new SimpleRedisLock("order" + userId, stringRedisTemplate);
4
// 获取锁
5
boolean isLock = lock.tryLock(1200);
6
//  判断是否获取锁成功
7
if(!isLock){
8
    // 获取锁失败，返回错误或重试
9
    return Result.fail("不允许重复下单");
10
}
11
try{
12
    // 获取代理对象(事物)
13
    IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
14
    return proxy.createVoucherOrder(voucherId);
15
} finally {
16
    // 释放锁
17
    lock.unlock();
18
}

展开收起

Redis分布式锁误删问题#

1
线程1获取锁成功
2
线程1执行时间过长，锁自动过期
3
线程2获取到同一把锁
4
线程1执行完成，直接执行DEL
5
线程1错误地删除了线程2的锁
6
线程3也可以获取锁并进入业务

锁中需要保存锁持有者的唯一标识：

1
UUID + 线程ID

UUID用于区分不同JVM，线程ID用于区分同一个JVM中的不同线程。

改进Redis的分布锁#

1
private static final String ID_PREFIX= UUID.randomUUID().toString(true)+"-";
2

3
// 获取线程标识
4
String threadId = ID_PREFIX+Thread.currentThread().getId();
5
// 获取锁
6
Boolean success = stringRedisTemplate.opsForValue().
7
        setIfAbsent(KEY_PREFIX + name, threadId, timeoutSec, TimeUnit.SECONDS);

UUID.randomUUID().toString(true)是Hutool UUID的写法。如果使用JDK的java.util.UUID，应写为：

1
UUID.randomUUID().toString()

SimpleRedisLock.java#

1
@Override
2
public void unlock() {
3
    // 获取线程标识
4
    String  threadId= ID_PREFIX+Thread.currentThread().getId();
5
    // 获取锁中的标识
6
    String id = stringRedisTemplate.opsForValue().get(KEY_PREFIX + name);
7
    // 判断标识是否一致
8
    if(threadId.equals(id)){
9
        // 释放锁
10
        stringRedisTemplate.delete(KEY_PREFIX + name);
11
    }
12
}

Redis分布式锁原子性问题#

上面的GET和DEL是两个独立操作，仍然可能出现：

1
线程1执行GET，确认锁属于自己
2
线程1发生阻塞
3
锁到期自动删除
4
线程2获取锁
5
线程1恢复执行DEL
6
线程1删除了线程2的锁

因此“判断锁标识”和“删除锁”必须作为一个原子操作执行。

Redis的Lua脚本#

Redis可以在一个Lua脚本中编写多条Redis命令。Redis会将整个脚本作为一个整体执行，脚本执行期间不会插入其他命令。

基本语法：

1
redis.call('命令名称', 'key', '其它参数')

示例：

1
redis.call('set', 'name', 'jack')

执行多条命令：

1
redis.call('set', 'name', 'jack')
2
local name = redis.call('get', 'name')
3
return name

EVAL命令#

1
EVAL script numkeys key [key ...] arg [arg ...]

固定参数：

1
EVAL "return redis.call('set', 'name', 'jack')" 0

动态参数：

1
EVAL "return redis.call('set', KEYS[1], ARGV[1])" 1 name Rose

参数对应关系：

1
1       脚本需要一个Key
2
name    放入KEYS[1]
3
Rose    放入ARGV[1]

Lua数组从1开始，因此使用KEYS[1]和ARGV[1]。

使用Lua脚本释放锁#

unLock.lua#

1
--- 比较线程标识与锁中的标识是否一致
2
if(redis.call('get',KEYS[1]) == ARGV[1]) then
3
    --- 释放锁 del key
4
    return redis.call('del',KEYS[1])
5
end
6
return 0

脚本将读取标识、比较标识和删除锁放在同一次执行中，保证操作的原子性。

Spring调用Lua脚本#

SimpleRedisLock.java#

1
private static final DefaultRedisScript<Long> UNLOCK_SCRIPT;
2
static {
3
    UNLOCK_SCRIPT = new DefaultRedisScript<>();
4
    UNLOCK_SCRIPT.setLocation(new ClassPathResource("unLock.lua"));
5
    UNLOCK_SCRIPT.setResultType(Long.class);
6
}
7

8
@Override
9
public void unlock() {
10
    // 调用lua脚本
11
    stringRedisTemplate.execute(
12
            UNLOCK_SCRIPT,
13
            Collections.singletonList(KEY_PREFIX+name),
14
            ID_PREFIX+Thread.currentThread().getId()
15
    );
16
}

展开收起

Linux软件安装、服务管理、环境变量与压缩解压

Thu, 09 Jul 2026 00:00:00 GMT

软件安装方式概览#

Linux 软件安装常见方式有三类：

方式	常见系统	特点
`rpm`	CentOS、RHEL、openEuler 等	安装本地 `.rpm` 包，依赖需要额外处理
`yum` / `dnf`	CentOS、RHEL、Fedora 等	自动处理依赖，适合在线安装
`apt`	Ubuntu、Debian 等	自动处理依赖，Ubuntu 最常用

入门阶段建议优先掌握 yum 和 apt，因为它们会自动处理大部分依赖问题。

rpm：本地软件包管理#

安装 rpm 包：

Terminal window

1
rpm -ivh 软件包名.rpm

升级 rpm 包：

Terminal window

1
rpm -Uvh 软件包名.rpm

查询软件是否安装：

Terminal window

1
rpm -q 软件包名

查询所有已安装软件包：

Terminal window

1
rpm -qa

查询软件包详细信息：

Terminal window

1
rpm -qi 软件包名

查询软件安装了哪些文件：

Terminal window

1
rpm -ql 软件包名

查询某个文件属于哪个 rpm 包：

Terminal window

1
rpm -qf /usr/bin/vim

rpm 的缺点是依赖处理不够方便。比如安装 A 包时，如果它依赖 B、C 包，就需要手动补齐依赖。

yum：CentOS 常用软件管理#

安装软件：

Terminal window

1
yum install 软件名
2
yum install -y 软件名

-y 表示自动确认。

卸载软件：

Terminal window

1
yum remove 软件名

搜索软件：

Terminal window

1
yum search 关键字

查看软件信息：

Terminal window

1
yum info 软件名

列出可安装和已安装软件：

Terminal window

1
yum list

检查可更新软件：

Terminal window

1
yum check-update

更新全部软件：

Terminal window

1
yum update

清理缓存：

Terminal window

1
yum clean all

配置本地 yum 源时，常见步骤是挂载光盘并配置 repo 文件：

Terminal window

1
mount /dev/sr0 /mnt
2
vi /etc/yum.repos.d/local.repo

示例内容：

1
[local]
2
name=centos7
3
baseurl=file:///mnt
4
gpgcheck=0

查看 yum 源：

Terminal window

1
yum repolist

apt：Ubuntu 常用软件管理#

Ubuntu 和 Debian 系统常用 apt。

更新软件源缓存：

Terminal window

1
sudo apt update

安装软件：

Terminal window

1
sudo apt install 软件名

卸载软件：

Terminal window

1
sudo apt remove 软件名

搜索软件：

Terminal window

1
apt search 关键字

升级系统已安装软件：

Terminal window

1
sudo apt upgrade

无论是 yum 还是 apt，安装和卸载系统软件通常都需要 root 权限。

wget：命令行下载文件#

wget 是非交互式下载工具，适合在服务器上下载文件。

Terminal window

1
wget URL

后台下载：

Terminal window

1
wget -b URL

后台下载日志默认写入当前目录的 wget-log，可以查看进度：

Terminal window

1
tail -f wget-log

下载并指定保存文件名：

Terminal window

1
wget -O CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo

systemctl：系统服务管理#

systemctl 用来管理系统服务，比如 nginx、mysql、sshd、ntpd。

Terminal window

1
systemctl start 服务名
2
systemctl stop 服务名
3
systemctl restart 服务名
4
systemctl status 服务名
5
systemctl enable 服务名
6
systemctl disable 服务名

含义：

命令	作用
`start`	启动服务
`stop`	停止服务
`restart`	重启服务
`status`	查看服务状态
`enable`	设置开机自启
`disable`	关闭开机自启

示例：

Terminal window

1
systemctl status sshd
2
systemctl restart nginx
3
systemctl enable nginx

排查服务问题时，通常先看状态，再看日志：

Terminal window

1
systemctl status nginx
2
journalctl -u nginx

软链接：ln -s#

软链接类似快捷方式。

Terminal window

1
ln -s 源文件或目录 链接位置

示例：

Terminal window

1
ln -s /usr/local/nginx/sbin/nginx /usr/bin/nginx

这样就可以直接执行 nginx，不用每次输入完整路径。

查看软链接：

Terminal window

1
ls -l

软链接前面通常会显示 -> 指向原路径。

日期、时区和时间同步#

查看当前时间：

Terminal window

1
date

格式化输出：

Terminal window

1
date "+%Y-%m-%d"
2
date "+%Y-%m-%d %H:%M:%S"

常见格式：

格式	含义
`%Y`	四位年份
`%y`	两位年份
`%m`	月
`%d`	日
`%H`	小时
`%M`	分钟
`%S`	秒
`%s`	Unix 时间戳

修改时区可以使用：

Terminal window

1
timedatectl set-timezone Asia/Shanghai

安装 NTP：

Terminal window

1
yum install -y ntp

启动 NTP 服务：

Terminal window

1
systemctl start ntpd
2
systemctl enable ntpd

手动校准时间：

Terminal window

1
ntpdate -u ntp.aliyun.com

环境变量和 PATH#

查看全部环境变量：

Terminal window

1
env

查看某个变量：

Terminal window

1
echo $PATH

临时设置变量：

Terminal window

1
export APP_HOME=/opt/app

临时变量只在当前终端有效。想永久生效，可以写入：

用户级配置：~/.bashrc
全局配置：/etc/profile

PATH 记录了系统查找可执行命令的路径。比如把自定义脚本目录加入 PATH：

Terminal window

1
export PATH=$PATH:/opt/scripts

如果变量名后面要紧跟其他字符，建议使用 ${}：

Terminal window

1
echo ${PATH}ABC

压缩和解压#

使用 tar 打包压缩：

Terminal window

1
tar -zcvf archive.tar.gz file1 dir1

常用选项：

选项	作用
`-z`	使用 gzip
`-c`	创建归档
`-v`	显示过程
`-f`	指定文件名
`-t`	查看归档内容
`-x`	解包
`-C`	指定解压目录

查看压缩包内容：

Terminal window

1
tar -tf archive.tar.gz

解压：

Terminal window

1
tar -zxvf archive.tar.gz
2
tar -zxvf archive.tar.gz -C /opt

使用 zip 压缩：

Terminal window

1
zip file.zip a.txt
2
zip -r project.zip project

使用 unzip 解压：

Terminal window

1
unzip file.zip
2
unzip file.zip -d /opt/project

本篇命令速查#

命令	作用
`rpm -ivh 包名.rpm`	安装 rpm 包
`yum install -y 软件`	CentOS 安装软件
`apt install 软件`	Ubuntu 安装软件
`wget URL`	下载文件
`systemctl status 服务`	查看服务状态
`systemctl enable 服务`	设置服务开机自启
`ln -s 源链接`	创建软链接
`date "+%Y-%m-%d"`	格式化时间
`env`	查看环境变量
`echo $PATH`	查看 PATH
`tar -zcvf`	打包压缩
`tar -zxvf`	解压
`zip -r`	zip 压缩目录
`unzip -d`	解压 zip 到指定目录

Linux网络、进程与系统资源排查常用命令

Thu, 09 Jul 2026 00:00:00 GMT

IP 地址基础#

IPv4 地址通常是类似下面这样的格式：

1
192.168.1.10

每一段的范围是 0 到 255。

几个特殊地址需要记住：

地址	含义
`127.0.0.1`	本机回环地址，只代表当前机器
`localhost`	通常解析到 `127.0.0.1`
`0.0.0.0`	在服务监听中常表示监听所有网卡

例如服务监听 127.0.0.1:8080，通常只能本机访问；监听 0.0.0.0:8080，其他机器才可能通过服务器 IP 访问。

查看 IP 地址#

老系统常用：

Terminal window

1
ifconfig

如果提示命令不存在，可以安装 net-tools，或者使用更现代的命令：

Terminal window

1
ip addr

简写：

Terminal window

1
ip a

查看默认路由：

Terminal window

1
ip route

主机名#

查看主机名：

Terminal window

1
hostname

设置主机名：

Terminal window

1
hostnamectl set-hostname 新主机名

主机名常用于区分多台服务器，比如：

1
web-01
2
web-02
3
db-01

测试网络连通：ping#

ping 用于测试网络是否连通。

Terminal window

1
ping 目标地址

限制次数：

Terminal window

1
ping -c 4 baidu.com
2
ping -c 4 192.168.1.1

如果 IP 能 ping 通，域名不能 ping 通，可能是 DNS 问题。如果都不通，可能是网络、网关、防火墙或目标机器问题。

下载和接口测试：curl#

curl 常用于测试 HTTP 接口。

Terminal window

1
curl http://127.0.0.1:8080

查看响应头：

Terminal window

1
curl -I https://example.com

发送 POST 请求：

Terminal window

1
curl -X POST http://127.0.0.1:8080/api

排查 Web 服务时，常见顺序是：

systemctl status 服务名
netstat 或 ss 查看端口是否监听
curl 127.0.0.1:端口 测试本机访问
从其他机器访问服务器 IP 和端口

查看端口占用：netstat 和 ss#

老系统常用 netstat：

Terminal window

1
netstat -anp | grep 端口

例如：

Terminal window

1
netstat -anp | grep 8080

现代系统更推荐 ss：

Terminal window

1
ss -lntp
2
ss -lntp | grep 8080

常见选项含义：

选项	含义
`-l`	只看监听端口
`-n`	不解析服务名，直接显示数字端口
`-t`	TCP
`-u`	UDP
`-p`	显示进程信息

如果端口没有监听，说明服务可能没启动或启动失败。如果端口已经被其他进程占用，新服务可能无法启动。

查看进程：ps#

查看全部进程：

Terminal window

1
ps -ef

配合 grep 过滤：

Terminal window

1
ps -ef | grep nginx
2
ps -ef | grep java

常见字段：

字段	含义
`UID`	进程所属用户
`PID`	进程 ID
`PPID`	父进程 ID
`CMD`	启动命令

查看某个进程的详细状态：

Terminal window

1
ps -p PID -f

结束进程：kill#

结束进程：

Terminal window

1
kill PID

强制结束：

Terminal window

1
kill -9 PID

建议优先使用普通 kill，让进程有机会正常退出。kill -9 是强制终止，可能导致临时文件、锁文件或数据状态来不及清理。

实时查看系统状态：top#

top 可以实时查看系统运行状态。

Terminal window

1
top

重点关注：

指标	说明
load average	系统负载
CPU 使用率	用户态、系统态、空闲比例
Mem	内存使用情况
Swap	交换分区使用情况
PID	进程 ID
%CPU	进程 CPU 占用
%MEM	进程内存占用

常用快捷键：

按键	作用
`P`	按 CPU 占用排序
`M`	按内存占用排序
`q`	退出

如果某个进程 CPU 或内存异常高，可以记录 PID，再结合日志继续排查。

查看磁盘占用：df 和 du#

查看磁盘分区使用情况：

Terminal window

1
df -h

-h 表示用人类易读的单位显示。

查看目录大小：

Terminal window

1
du -sh 目录

Terminal window

1
du -sh *

磁盘满了时，常见排查路径：

Terminal window

1
df -h
2
cd /var
3
du -sh *
4
cd /var/log
5
du -sh *

逐层定位哪个目录占用最大。

查看磁盘和 CPU IO：iostat#

iostat 可以查看 CPU 和磁盘 IO 情况，常用于排查磁盘读写压力。

Terminal window

1
iostat
2
iostat -x 1

如果系统没有该命令，CentOS 可安装：

Terminal window

1
yum install -y sysstat

查看网络统计：sar#

sar 也来自 sysstat 工具包，可以查看网络、CPU、内存等历史统计。

查看网络设备统计：

Terminal window

1
sar -n DEV 1

查看 TCP 统计：

Terminal window

1
sar -n TCP 1

sar 更偏系统性能分析，入门阶段先知道它能查看历史和实时统计即可。

固定 IP 配置思路#

在虚拟机或服务器中配置固定 IP，通常涉及两部分：

虚拟化平台或云平台的网络配置。
Linux 系统内部网卡配置。

CentOS 7 常见配置文件：

Terminal window

1
/etc/sysconfig/network-scripts/ifcfg-ens33

核心配置示例：

1
BOOTPROTO="static"
2
ONBOOT="yes"
3
IPADDR="192.168.88.131"
4
NETMASK="255.255.255.0"
5
GATEWAY="192.168.88.2"
6
DNS1="192.168.88.2"

配置后通常需要重启网络服务或重启机器。不同发行版网络配置方式差异较大，实际操作前要确认系统版本。

常见排查套路#

服务访问不了时：

Terminal window

1
systemctl status 服务名
2
ps -ef | grep 服务关键字
3
ss -lntp | grep 端口
4
curl http://127.0.0.1:端口
5
ping 目标IP

机器变慢时：

Terminal window

1
top
2
df -h
3
free -h
4
iostat -x 1

日志异常时：

Terminal window

1
tail -f app.log
2
grep -n "ERROR" app.log

本篇命令速查#

命令	作用
`ip addr`	查看 IP 地址
`hostname`	查看主机名
`hostnamectl set-hostname`	设置主机名
`ping -c 4 地址`	测试连通性
`curl URL`	测试 HTTP 请求
`netstat -anp`	查看网络连接和端口
`ss -lntp`	查看监听端口
`ps -ef`	查看进程
`kill PID`	结束进程
`top`	实时查看系统状态
`df -h`	查看磁盘分区占用
`du -sh *`	查看目录大小
`iostat -x 1`	查看磁盘 IO
`sar -n DEV 1`	查看网络统计

Linux用户、用户组、权限与 sudo 管理

Thu, 09 Jul 2026 00:00:00 GMT

用户和用户组的关系#

Linux 中每个用户都有一个 UID，每个用户组都有一个 GID。

用户可以属于：

一个主组，也叫基本组。
多个附加组。

查看用户身份信息：

Terminal window

1
id 用户名

查看当前用户：

Terminal window

1
whoami

查看系统用户信息：

Terminal window

1
getent passwd

查看系统用户组信息：

Terminal window

1
getent group

创建用户：useradd#

创建用户：

Terminal window

1
useradd 用户名

常用选项：

选项	作用
`-c`	指定描述信息
`-u`	指定 UID
`-d`	指定用户家目录
`-m`	创建家目录
`-g`	指定主组
`-G`	指定附加组
`-M`	不创建家目录
`-s`	指定登录 Shell

示例：

Terminal window

1
useradd -m -d /home/testuser -s /bin/bash testuser

创建用户后设置密码：

Terminal window

1
passwd testuser

管理密码状态：passwd 和 chage#

修改用户密码：

Terminal window

1
passwd 用户名

查看密码过期信息：

Terminal window

1
chage -l 用户名

强制用户下次登录修改密码：

Terminal window

1
chage -d 0 用户名

锁定用户密码：

Terminal window

1
passwd -l 用户名

解锁用户密码：

Terminal window

1
passwd -u 用户名

删除用户：userdel#

删除用户：

Terminal window

1
userdel 用户名

删除用户并删除家目录：

Terminal window

1
userdel -r 用户名

删除用户是高风险操作，尤其是带 -r 时会删除家目录。执行前建议确认该用户是否仍有业务文件或运行中的进程。

修改用户：usermod#

usermod 用来修改已有用户。

常用选项：

选项	作用
`-c`	修改描述信息
`-u`	修改 UID
`-d`	修改家目录
`-m`	移动家目录内容到新位置
`-g`	修改主组
`-G`	修改附加组
`-aG`	追加附加组，常用
`-s`	修改登录 Shell
`-e`	设置账号过期时间
`-l`	修改账号名称
`-L`	锁定用户
`-U`	解锁用户

把用户加入附加组：

Terminal window

1
usermod -aG docker testuser

这里推荐使用 -aG，表示追加附加组。如果只用 -G，可能会覆盖用户原有附加组。

用户组管理#

创建用户组：

Terminal window

1
groupadd 组名

指定 GID：

Terminal window

1
groupadd -g 1001 dev

删除用户组：

Terminal window

1
groupdel 组名

把用户加入组：

Terminal window

1
gpasswd -a 用户名 组名

从组中移除用户：

Terminal window

1
gpasswd -d 用户名 组名

查看某个组：

Terminal window

1
getent group 组名

文件权限怎么看#

使用 ls -l 查看文件权限：

Terminal window

1
ls -l file.txt

示例：

1
-rw-r--r-- 1 aron dev 1024 Jul 9 10:00 file.txt

第一段 -rw-r--r-- 表示权限：

1
-   rw-   r--   r--
2
类型 所有者 所属组 其他人

文件类型常见含义：

标记	含义
`-`	普通文件
`d`	目录
`l`	软链接

权限含义：

权限	对文件	对目录
`r`	读取文件内容	列出目录内容
`w`	修改文件内容	在目录中创建、删除、改名
`x`	执行文件	进入目录

目录的 x 权限很重要。没有 x，即使有 r，也可能无法进入目录。

chmod：修改权限#

符号方式：

Terminal window

1
chmod u+x script.sh
2
chmod g-w file.txt
3
chmod o+r file.txt
4
chmod a+r file.txt

含义：

符号	含义
`u`	所有者
`g`	所属组
`o`	其他人
`a`	所有人
`+`	增加权限
`-`	删除权限
`=`	设置为指定权限

数字方式：

权限	数值
`r`	4
`w`	2
`x`	1

常见权限：

Terminal window

1
chmod 755 script.sh
2
chmod 644 file.txt
3
chmod 700 private-dir

解释：

权限	含义
`755`	所有者可读写执行，组和其他人可读执行
`644`	所有者可读写，组和其他人只读
`700`	只有所有者可读写执行

递归修改目录及其内容：

Terminal window

1
chmod -R 755 目录

递归操作要谨慎，不建议随意对系统目录执行 chmod -R。

chown：修改所有者和所属组#

修改文件所有者：

Terminal window

1
chown 用户 文件

修改所有者和所属组：

Terminal window

1
chown 用户:用户组 文件

递归修改目录：

Terminal window

1
chown -R 用户:用户组 目录

示例：

Terminal window

1
chown -R nginx:nginx /var/www/html

特殊权限：SGID 和粘滞位#

SGID 常用于共享目录。对目录设置 SGID 后，用户在该目录中新建的文件会继承目录的所属组。

Terminal window

1
chmod g+s 目录

适合多人协作目录，例如：

Terminal window

1
chmod g+s /data/project

粘滞位常用于公共可写目录。即使用户对目录有写权限，也不能删除其他用户的文件。

Terminal window

1
chmod o+t 目录

取消粘滞位：

Terminal window

1
chmod o-t 目录

典型例子是 /tmp 目录。

ACL：更细粒度的权限控制#

传统权限只能控制所有者、所属组、其他人。ACL 可以针对指定用户或指定组设置额外权限。

给用户设置 ACL：

Terminal window

1
setfacl -m u:用户名:权限 文件或目录

给用户组设置 ACL：

Terminal window

1
setfacl -m g:组名:权限 文件或目录

删除某个 ACL：

Terminal window

1
setfacl -x u:用户名 文件或目录
2
setfacl -x g:组名 文件或目录

删除全部 ACL：

Terminal window

1
setfacl -b 文件或目录

查看 ACL：

Terminal window

1
getfacl 文件或目录

示例：

Terminal window

1
setfacl -m u:alice:rw file.txt
2
getfacl file.txt

su 和 sudo#

su 用于切换用户：

Terminal window

1
su - 用户名

切换到 root：

Terminal window

1
su -

- 表示同时切换用户环境，更接近完整登录该用户。

sudo 用于以管理员权限执行单条命令：

Terminal window

1
sudo systemctl restart nginx

配置 sudo 权限建议使用：

Terminal window

1
visudo

示例：

1
testuser ALL=(ALL) NOPASSWD: ALL

这表示 testuser 可以免密执行所有 sudo 命令。生产环境中不建议随意给 NOPASSWD: ALL，应按最小权限原则授权。

权限排查思路#

遇到权限不足时，可以按这个顺序排查：

当前用户是谁：whoami
当前用户属于哪些组：id
文件或目录权限是什么：ls -l
上级目录是否有执行权限：逐级检查目录权限
是否存在 ACL：getfacl
是否需要 sudo 或切换用户

例如：

Terminal window

1
whoami
2
id
3
ls -ld /data
4
ls -ld /data/project
5
ls -l /data/project/app.log
6
getfacl /data/project/app.log

很多权限问题并不是文件本身没权限，而是上级目录缺少 x 权限。

本篇命令速查#

命令	作用
`id 用户名`	查看用户 UID、GID 和所属组
`whoami`	查看当前用户
`getent passwd`	查看系统用户
`getent group`	查看系统用户组
`useradd 用户`	创建用户
`passwd 用户`	设置用户密码
`userdel -r 用户`	删除用户及家目录
`usermod -aG 组用户`	追加附加组
`groupadd 组`	创建用户组
`gpasswd -a 用户组`	添加用户到组
`ls -l`	查看权限
`chmod 755 文件`	修改权限
`chown 用户:组文件`	修改所有者和所属组
`setfacl -m`	设置 ACL
`getfacl`	查看 ACL
`su - 用户`	切换用户
`sudo 命令`	以管理员权限执行命令

Linux目录结构、路径与终端基本认知

Wed, 08 Jul 2026 00:00:00 GMT

Linux 的目录结构#

Linux 只有一个顶级目录，也就是根目录 /。所有文件、目录、设备、配置都挂在这棵目录树下面。

常见目录可以先这样理解：

目录	作用
`/`	根目录，Linux 文件系统的起点
`/home`	普通用户的家目录所在位置
`/root`	root 用户的家目录
`/etc`	系统和软件配置文件
`/var`	日志、缓存、运行时数据等经常变化的文件
`/usr`	用户级软件、命令、库文件
`/bin`、`/sbin`	常用系统命令
`/tmp`	临时文件目录

例如：

Terminal window

1
/home/user/a.txt

表示从根目录 / 开始，依次进入 home 目录、user 目录，最后找到 a.txt 文件。

HOME 目录#

每个用户在 Linux 中通常都有自己的专属工作目录，也叫 HOME 目录。

普通用户的 HOME 目录通常是 /home/用户名
root 用户的 HOME 目录是 /root
终端刚登录后，默认通常会进入当前用户的 HOME 目录

可以使用 pwd 查看当前位置：

Terminal window

1
pwd

如果当前登录用户是 aron，输出可能是：

Terminal window

1
/home/aron

绝对路径和相对路径#

路径是 Linux 中非常重要的概念。它分为绝对路径和相对路径。

绝对路径从根目录 / 开始描述位置：

Terminal window

1
/home/aron/test/a.txt

不管你当前在哪个目录，这个路径指向的位置都固定不变。

相对路径不以 / 开头，它以当前所在目录作为起点：

Terminal window

1
test/a.txt

如果当前目录是 /home/aron，那么 test/a.txt 实际指向：

Terminal window

1
/home/aron/test/a.txt

特殊路径符#

Linux 中有几个很常见的特殊路径符。

符号	含义	示例
`.`	当前目录	`./a.txt`
`..`	上一级目录	`cd ..`
`../..`	上两级目录	`cd ../..`
`~`	当前用户 HOME 目录	`cd ~`

例如，回到用户 HOME 目录：

Terminal window

1
cd ~

进入上一级目录：

Terminal window

1
cd ..

执行当前目录下的脚本：

Terminal window

1
./start.sh

这里的 ./ 表示“当前目录下”。

隐藏文件和隐藏目录#

Linux 中，以 . 开头的文件或目录默认是隐藏的，例如：

Terminal window

1
.bashrc
2
.ssh
3
.vimrc

普通 ls 看不到隐藏文件，需要加 -a：

Terminal window

1
ls -a

很多用户配置、软件配置、SSH 密钥都会放在隐藏文件或隐藏目录里，所以排查环境变量、登录配置、密钥问题时经常会用到 ls -a。

查看命令帮助#

查看简要帮助：

Terminal window

1
命令 --help

例如：

Terminal window

1
ls --help

查看详细手册：

Terminal window

1
man 命令

例如：

Terminal window

1
man ls

在 man 手册中按 q 可以退出。

本篇命令速查#

命令	作用
`pwd`	查看当前工作目录
`cd 目录`	切换目录
`cd ~`	回到当前用户 HOME 目录
`cd ..`	回到上一级目录
`ls -a`	查看包含隐藏文件在内的目录内容
`命令 --help`	查看命令简要帮助
`man 命令`	查看命令详细手册

Linux文件与目录操作

Wed, 08 Jul 2026 00:00:00 GMT

查看目录内容：ls#

Terminal window

1
ls [选项] [目录]

Terminal window

1
ls

常用选项：

选项	作用
`-l`	以长格式显示详细信息
`-h`	配合 `-l`，用更易读的方式显示文件大小
`-a`	显示隐藏文件
`-d`	只显示目录本身，不展开目录内容
`-t`	按修改时间排序

常见组合：

Terminal window

1
ls -lh
2
ls -la
3
ls -ld /etc
4
ls -lt

其中 ls -lh 很常用，可以看到权限、所属用户、所属组、大小、修改时间等信息。

查看当前位置：pwd#

pwd 用来显示当前工作目录。

Terminal window

1
pwd

切换目录：cd#

cd 用来切换工作目录。

Terminal window

1
cd [目标目录]

常用写法：

Terminal window

1
cd /etc
2
cd ~
3
cd ..
4
cd ../logs
5
cd

不带参数的 cd 默认回到当前用户的 HOME 目录。

创建目录：mkdir#

mkdir 用来创建目录。

Terminal window

1
mkdir 目录名

例如：

Terminal window

1
mkdir test

如果要一次性创建多级目录，使用 -p：

Terminal window

1
mkdir -p project/logs/nginx

如果不加 -p，上级目录不存在时会报错。

有些 Shell 支持用大括号批量创建目录：

Terminal window

1
mkdir -p project/{bin,conf,logs,data}

这会创建：

Terminal window

1
project/bin
2
project/conf
3
project/logs
4
project/data

创建空文件：touch#

touch 常用于创建空文件，也可以更新文件的修改时间。

Terminal window

1
touch 文件名

例如：

Terminal window

1
touch app.log
2
touch README.md

如果文件不存在，会创建空文件；如果文件已经存在，会更新它的时间戳。

复制文件和目录：cp#

cp 用来复制文件或目录。

Terminal window

1
cp [选项] 源 目标

复制文件：

Terminal window

1
cp a.txt b.txt

复制文件到目录：

Terminal window

1
cp a.txt test/

复制目录需要加 -r：

Terminal window

1
cp -r test test2

常用选项：

选项	作用
`-r`	递归复制目录及其内容
`-f`	强制覆盖
`-p`	保留源文件属性

实际工作中，如果复制配置文件，常见做法是先备份：

Terminal window

1
cp nginx.conf nginx.conf.bak

再修改原文件，这样出问题时可以快速恢复。

移动和重命名：mv#

mv 既可以移动文件，也可以重命名文件。

Terminal window

1
mv 源 目标

重命名：

Terminal window

1
mv old.txt new.txt

移动到目录：

Terminal window

1
mv app.log logs/

移动并改名：

Terminal window

1
mv app.log logs/app-2026.log

常用选项：

选项	作用
`-i`	覆盖前询问
`-f`	强制覆盖
`-n`	不覆盖已存在文件
`-u`	源文件更新或目标不存在时才移动
`-b`	覆盖前创建备份

对重要文件执行 mv 时，可以用 -i 降低误覆盖风险：

Terminal window

1
mv -i config.yml config.yml.bak

删除文件和目录：rm#

rm 用来删除文件或目录。

Terminal window

1
rm [选项] 文件或目录

删除文件：

Terminal window

1
rm a.txt

删除目录需要加 -r：

Terminal window

1
rm -r test

常用选项：

选项	作用
`-r`	递归删除目录
`-f`	强制删除，不提示
`-i`	删除前逐个确认

rm 是高风险命令，尤其是 rm -rf。执行前建议先用 ls 确认目标：

Terminal window

1
ls test
2
rm -r test

本篇命令速查#

命令	作用
`ls -lh`	查看详细文件列表
`ls -a`	查看隐藏文件
`pwd`	查看当前位置
`cd 目录`	切换目录
`mkdir -p 目录`	创建多级目录
`touch 文件`	创建空文件
`cp 源目标`	复制文件
`cp -r 源目录目标目录`	复制目录
`mv 源目标`	移动或重命名
`rm 文件`	删除文件
`rm -r 目录`	删除目录

Linux文本处理基础

Wed, 08 Jul 2026 00:00:00 GMT

查看完整文件：cat#

cat 会把文件内容直接输出到终端。

Terminal window

1
cat 文件

常用选项：

选项	作用
`-n`	显示所有行行号
`-b`	只给非空行编号
`-s`	将连续空行压缩为一行

示例：

Terminal window

1
cat -n nginx.conf

cat 适合查看内容不长的文件。如果文件很大，建议使用 less、more、head 或 tail。

分页查看：more 和 less#

more 可以分页查看文件。

Terminal window

1
more 文件

常用操作：

按键	作用
空格	下一页
回车	下一行
`b`	上一页
`q`	退出

less 功能更强，也更常用：

Terminal window

1
less 文件

常用操作：

按键	作用
空格	下一页
`b`	上一页
`/关键字`	搜索关键字
`n`	下一个匹配
`N`	上一个匹配
`q`	退出

查看日志或配置文件时，less 比 cat 更稳，因为它不会一次性刷满终端。

查看文件开头和结尾：head、tail#

查看文件前几行：

Terminal window

1
head 文件
2
head -n 20 文件

查看文件最后几行：

Terminal window

1
tail 文件
2
tail -n 50 文件

持续跟踪文件变化：

Terminal window

1
tail -f app.log

tail -f 是看实时日志的常用命令。退出时按 Ctrl+C。

搜索文件内容：grep#

grep 用来按关键字过滤文本。

Terminal window

1
grep [选项] 关键字 文件

常用选项：

选项	作用
`-n`	显示匹配行号
`-v`	反向匹配，显示不包含关键字的行
`-i`	忽略大小写
`-r`	递归搜索目录

示例：

Terminal window

1
grep -n "error" app.log
2
grep -i "failed" app.log
3
grep -v "#" nginx.conf
4
grep -r "server_name" /etc/nginx

一些常用匹配：

Terminal window

1
grep "^root" /etc/passwd
2
grep "bash$" /etc/passwd
3
grep "^$" file.txt

含义分别是：匹配以 root 开头的行、匹配以 bash 结尾的行、匹配空行。

查找文件：find#

find 用来在目录中查找文件或目录。

Terminal window

1
find 路径 条件

按名称查找：

Terminal window

1
find /etc -name "*.conf"

按类型查找：

Terminal window

1
find /var/log -type f
2
find /home -type d

按大小查找：

Terminal window

1
find /var/log -type f -size +100M

常见类型：

类型	含义
`f`	普通文件
`d`	目录

find 的搜索范围越大，耗时越长。实际使用时最好先限定目录，比如从 /var/log、/etc、项目目录开始。

统计文本：wc#

wc 用来统计文件内容。

Terminal window

1
wc [选项] 文件

常用选项：

选项	作用
`-l`	统计行数
`-w`	统计单词数
`-c`	统计字节数
`-m`	统计字符数

示例：

Terminal window

1
wc -l app.log
2
wc -w article.md

配合管道可以统计搜索结果：

Terminal window

1
grep "ERROR" app.log | wc -l

这表示统计日志中包含 ERROR 的行数。

管道符：|#

管道符 | 的作用是把左边命令的输出，作为右边命令的输入。

Terminal window

1
命令1 | 命令2

示例：

Terminal window

1
cat app.log | grep "ERROR"
2
ps -ef | grep nginx
3
find /etc -name "*.conf" | wc -l

管道可以连续使用：

Terminal window

1
cat app.log | grep "ERROR" | grep "timeout"

这表示先找出包含 ERROR 的日志，再从结果中找出包含 timeout 的行。

输出和重定向：echo、>、>>#

echo 用来输出内容：

Terminal window

1
echo "hello linux"

使用 > 可以覆盖写入文件：

Terminal window

1
echo "hello" > a.txt

使用 >> 可以追加写入文件：

Terminal window

1
echo "world" >> a.txt

错误输出可以使用 2> 重定向：

Terminal window

1
ls /not-exist 2> error.log

注意：> 会覆盖文件原内容，写配置或日志时要确认是否真的需要覆盖。

反引号和命令替换#

被反引号包围的内容会作为命令执行：

Terminal window

1
echo `pwd`

输出当前工作目录。

现代 Shell 中更推荐使用 $()，可读性更好：

Terminal window

1
echo "$(pwd)"

例如创建带日期的备份文件：

Terminal window

1
cp app.log "app-$(date +%Y%m%d).log"

vim 编辑器入门#

vim 是 Linux 中非常常见的文本编辑器。它至少要理解三种模式：

模式	作用
命令模式	默认模式，用来移动、复制、删除
输入模式	输入文本
末行模式	保存、退出、替换、设置行号

从命令模式进入输入模式：

按键	作用
`i`	在光标前插入
`a`	在光标后插入
`o`	在下一行插入新行

命令模式常用操作：

按键	作用
`G`	跳到最后一行
`50gg`	跳到第 50 行
`10dd`	删除 10 行
`10yy`	复制 10 行
`p`	粘贴

末行模式常用操作：

1
:set nu
2
:set nonu
3
:w
4
:q
5
:wq
6
:q!

含义分别是显示行号、取消行号、保存、退出、保存并退出、强制退出不保存。

文本替换：

1
:s/old/new
2
:s/old/new/g
3
:%s/old/new/g

含义分别是替换当前行第一个匹配、替换当前行所有匹配、替换全文所有匹配。

本篇命令速查#

命令	作用
`cat -n 文件`	查看文件并显示行号
`less 文件`	分页查看文件
`head -n 20 文件`	查看前 20 行
`tail -n 50 文件`	查看最后 50 行
`tail -f 日志`	实时跟踪日志
`grep -n 关键字文件`	搜索关键字并显示行号
`find 路径 -name 名称`	按名称查找
`wc -l 文件`	统计行数
`命令1	命令2`
`echo 内容 > 文件`	覆盖写入
`echo 内容 >> 文件`	追加写入
`vim 文件`	编辑文件

Redis缓存和更新

Tue, 07 Jul 2026 00:00:00 GMT

缓存是数据交换的缓冲区，用来临时存储热点数据。相比数据库，缓存通常具备更高的读写性能。

常见缓存层级：

浏览器缓存
应用层缓存，例如 Tomcat、本地缓存
分布式缓存，例如 Redis
数据库缓存
操作系统缓存、CPU 缓存、磁盘缓存

缓存的主要作用：

降低后端数据库压力
提高读写效率
降低接口响应时间
提升系统吞吐量

缓存带来的成本：

数据一致性成本
代码维护成本
运维成本
缓存异常场景处理成本

添加 Redis 缓存#

常见的查询模型是 Cache Aside Pattern，也叫旁路缓存模式。

查询流程：

客户端提交查询请求。
服务端先根据 key 查询 Redis。
如果缓存命中，直接返回缓存数据。
如果缓存未命中，查询数据库。
如果数据库存在数据，将数据写入 Redis，并返回结果。
如果数据库不存在数据，返回错误或空结果。

示例：

1
public Result queryById(Long id) {
2
    String key = "cache:shop:" + id;
3

4
    String shopJson = stringRedisTemplate.opsForValue().get(key);
5
    if (StrUtil.isNotEmpty(shopJson)) {
6
        Shop shop = JSONUtil.toBean(shopJson, Shop.class);
7
        return Result.ok(shop);
8
    }
9

10
    Shop shop = getById(id);
11
    if (shop == null) {
12
        return Result.fail("商铺不存在");
13
    }
14

15
    stringRedisTemplate.opsForValue().set(
16
            key,
17
            JSONUtil.toJsonStr(shop),
18
            30L,
19
            TimeUnit.MINUTES
20
    );
21

22
    return Result.ok(shop);
23
}

展开收起

缓存更新策略#

常见缓存更新策略有三种。

策略	说明	一致性	维护成本
内存淘汰	依赖 Redis 内存淘汰机制，内存不足时自动淘汰部分数据	差	无
超时剔除	给缓存设置 TTL，到期后自动删除，下次查询时重新加载	一般	低
主动更新	修改数据库时，同时更新或删除缓存	好	高

业务选择建议：

低一致性需求：使用 Redis 自带的内存淘汰机制，例如店铺类型、排行榜等不敏感数据。
高一致性需求：使用主动更新，并结合超时剔除作为兜底方案，例如店铺详情、商品详情等核心数据。

主动更新模式#

主动更新有三种常见模式：

Cache Aside Pattern#

由业务代码维护缓存和数据库。

读操作：

先查缓存。
命中则直接返回。
未命中则查数据库。
数据库存在则写入缓存。
数据库不存在则返回空结果。

写操作：

先更新数据库。
再删除缓存。

这是业务系统中最常见的方案。

Read/Write Through Pattern#

缓存与数据库被整合成一个服务，调用者只访问这个服务，不直接感知缓存一致性问题。

优点是调用方简单，缺点是实现复杂，需要专门维护缓存服务。

Write Behind Caching Pattern#

调用者只操作缓存，由缓存异步把数据持久化到数据库，保证最终一致。

优点是写性能好，缺点是数据可靠性和一致性风险更高，常用于对一致性要求不强、写入压力很高的场景。

Cache Aside 的关键问题#

删除缓存还是更新缓存#

推荐删除缓存。

更新缓存的问题是：每次数据库更新后都要重新写缓存，如果该数据后续没有被读取，就产生了无效写操作。

删除缓存的好处是：缓存失效后，等下一次查询时再重新构建，避免无效写。

先操作数据库还是先操作缓存#

如何保证数据库和缓存同时成功或失败#

单体系统中，可以把数据库操作和缓存操作放在一个事务流程中。

分布式系统中，可以考虑：

TCC
可靠消息
Canal 监听 binlog
延迟双删
重试补偿机制

示例：

1
@Transactional
2
public Result update(Shop shop) {
3
    Long id = shop.getId();
4
    if (id == null) {
5
        return Result.fail("店铺id不能为空");
6
    }
7

8
    updateById(shop);
9

10
    stringRedisTemplate.delete("cache:shop:" + id);
11

12
    return Result.ok();
13
}

Redis缓存穿透，雪崩，击穿，工具封装

Tue, 07 Jul 2026 00:00:00 GMT

缓存穿透#

缓存穿透是指客户端请求的数据在缓存和数据库中都不存在，导致每次请求都会打到数据库。

典型场景：

恶意请求不存在的 id
随机请求大量非法 key
数据库中确实没有对应数据

解决方案：

方案	优点	缺点
缓存空对象	实现简单，维护方便	占用额外内存，可能造成短期不一致
布隆过滤器	内存占用低，不会产生大量空 key	实现复杂，存在误判，不支持天然删除

缓存空对象#

核心逻辑：

查询 Redis。
如果 Redis 返回正常 JSON，说明缓存命中，直接返回。
如果 Redis 返回空字符串，说明之前查库不存在，直接返回不存在。
如果 Redis 返回 null，说明缓存未命中，查询数据库。
数据库不存在时，将空字符串写入 Redis，并设置较短 TTL。

1
public Shop queryWithPassThrough(Long id) {
2
    String key = "cache:shop:" + id;
3

4
    String shopJson = stringRedisTemplate.opsForValue().get(key);
5

6
    if (StrUtil.isNotEmpty(shopJson)) {
7
        return JSONUtil.toBean(shopJson, Shop.class);
8
    }
9

10
    if (shopJson != null) {
11
        return null;
12
    }
13

14
    Shop shop = getById(id);
15
    if (shop == null) {
16
        stringRedisTemplate.opsForValue().set(
17
                key,
18
                "",
19
                2L,
20
                TimeUnit.MINUTES
21
        );
22
        return null;
23
    }
24

25
    stringRedisTemplate.opsForValue().set(
26
            key,
27
            JSONUtil.toJsonStr(shop),
28
            30L,
29
            TimeUnit.MINUTES
30
    );
31

32
    return shop;
33
}

展开收起

注意：

空值缓存的 TTL 要短一些。
数据库新增该数据时，需要主动删除对应空值缓存。
空字符串和 null 的语义不同：空字符串表示缓存命中但业务数据不存在，null 表示缓存未命中。

布隆过滤器#

布隆过滤器可以在访问 Redis 前判断 key 是否可能存在。

流程：

请求进来后，先经过布隆过滤器。
如果布隆过滤器判断不存在，直接拒绝。
如果判断可能存在，再继续访问 Redis。
Redis 未命中时再查数据库并写缓存。

特点：

布隆过滤器判断不存在，一定不存在。
布隆过滤器判断存在，可能存在，也可能误判。
适合数据量大、非法请求多的场景。

缓存雪崩#

缓存雪崩是指同一时间大量缓存 key 同时失效，或者 Redis 服务宕机，导致大量请求直接访问数据库，数据库压力瞬间升高。

常见原因：

大量 key 设置了相同 TTL
Redis 宕机
缓存服务不可用
热点数据集中失效

解决方案：

给不同 key 的 TTL 添加随机值，避免同时过期。
搭建 Redis 主从、哨兵或集群，提高可用性。
给缓存业务添加限流、熔断、降级。
使用多级缓存，例如本地缓存 + Redis。
核心热点数据可以提前预热。

示例：

1
long ttl = 30L + RandomUtil.randomLong(1, 10);
2
stringRedisTemplate.opsForValue().set(
3
        key,
4
        JSONUtil.toJsonStr(shop),
5
        ttl,
6
        TimeUnit.MINUTES
7
);

缓存击穿#

缓存击穿也叫热点 key 问题。

它指的是某个被高并发访问的热点 key 突然失效，导致大量请求同时发现缓存未命中，并发查询数据库、重建缓存，给数据库造成瞬时冲击。

缓存击穿和缓存雪崩的区别：

缓存击穿：一个热点 key 失效。
缓存雪崩：大量 key 同时失效，或 Redis 整体不可用。

解决方案：

方案	优点	缺点
互斥锁	没有额外内存消耗，一致性较好，实现简单	线程需要等待，性能受影响，存在死锁风险
逻辑过期	线程无需等待，性能较好	不保证强一致性，有额外内存消耗，实现更复杂

互斥锁解决缓存击穿#

核心思想：

查询缓存。
命中则返回。
未命中时尝试获取互斥锁。
获取锁成功的线程查询数据库并重建缓存。
获取锁失败的线程休眠一小段时间后重试。
重建完成后释放锁。

1
public Shop queryWithMutex(Long id) {
2
    String key = "cache:shop:" + id;
3

4
    String shopJson = stringRedisTemplate.opsForValue().get(key);
5

6
    if (StrUtil.isNotEmpty(shopJson)) {
7
        return JSONUtil.toBean(shopJson, Shop.class);
8
    }
9

10
    if (shopJson != null) {
11
        return null;
12
    }
13

14
    String lockKey = "lock:shop:" + id;
15
    Shop shop = null;
16

17
    try {
18
        boolean isLock = tryLock(lockKey);
19
        if (!isLock) {
20
            Thread.sleep(50);
21
            return queryWithMutex(id);
22
        }
23

24
        shop = getById(id);
25
        if (shop == null) {
26
            stringRedisTemplate.opsForValue().set(
27
                    key,
28
                    "",
29
                    2L,
30
                    TimeUnit.MINUTES
31
            );
32
            return null;
33
        }
34

35
        stringRedisTemplate.opsForValue().set(
36
                key,
37
                JSONUtil.toJsonStr(shop),
38
                30L,
39
                TimeUnit.MINUTES
40
        );
41
    } catch (InterruptedException e) {
42
        Thread.currentThread().interrupt();
43
        throw new RuntimeException(e);
44
    } finally {
45
        unLock(lockKey);
46
    }
47

48
    return shop;
49
}
50

51
private boolean tryLock(String key) {
52
    Boolean flag = stringRedisTemplate.opsForValue()
53
            .setIfAbsent(key, "1", 10, TimeUnit.SECONDS);
54
    return BooleanUtil.isTrue(flag);
55
}
56

57
private void unLock(String key) {
58
    stringRedisTemplate.delete(key);
59
}

展开收起

注意：

加锁需要设置过期时间，避免业务异常导致锁永远不释放。
获取锁失败后应短暂休眠再重试，避免 CPU 空转。
释放锁最好校验锁标识，避免误删其他线程的锁。生产环境建议使用 Redisson。

逻辑过期解决缓存击穿#

逻辑过期不是依赖 Redis TTL 删除 key，而是在 value 中额外保存一个过期时间字段。

数据结构示例：

1
{
2
  "data": {
3
    "id": 1,
4
    "name": "Jack"
5
  },
6
  "expireTime": "2026-07-06T20:00:00"
7
}

核心思想：

热点数据提前写入 Redis，不设置 Redis TTL。
查询时先读取缓存。
如果逻辑时间未过期，直接返回。
如果逻辑时间已过期，尝试获取互斥锁。
获取锁成功，则开启独立线程异步重建缓存。
当前请求先返回旧数据。
获取锁失败，也直接返回旧数据。

适用场景：

热点数据
允许短暂返回旧数据
更关注可用性和响应速度，而不是强一致性

1
@Data
2
public class RedisData {
3
    private LocalDateTime expireTime;
4
    private Object data;
5
}

预热热点数据：

1
public void saveShop2Redis(Long id, Long expireSeconds) {
2
    Shop shop = getById(id);
3

4
    RedisData redisData = new RedisData();
5
    redisData.setData(shop);
6
    redisData.setExpireTime(LocalDateTime.now().plusSeconds(expireSeconds));
7

8
    stringRedisTemplate.opsForValue().set(
9
            "cache:shop:" + id,
10
            JSONUtil.toJsonStr(redisData)
11
    );
12
}

查询逻辑：

1
private static final ExecutorService CACHE_REBUILD_EXECUTOR =
2
        Executors.newFixedThreadPool(10);
3

4
public Shop queryWithLogicalExpire(Long id) {
5
    String key = "cache:shop:" + id;
6

7
    String shopJson = stringRedisTemplate.opsForValue().get(key);
8

9
    if (StrUtil.isEmpty(shopJson)) {
10
        return null;
11
    }
12

13
    RedisData redisData = JSONUtil.toBean(shopJson, RedisData.class);
14
    JSONObject data = (JSONObject) redisData.getData();
15
    Shop shop = JSONUtil.toBean(data, Shop.class);
16

17
    LocalDateTime expireTime = redisData.getExpireTime();
18
    if (expireTime.isAfter(LocalDateTime.now())) {
19
        return shop;
20
    }
21

22
    String lockKey = "lock:shop:" + id;
23
    boolean isLock = tryLock(lockKey);
24

25
    if (isLock) {
26
        CACHE_REBUILD_EXECUTOR.execute(() -> {
27
            try {
28
                saveShop2Redis(id, 30L);
29
            } finally {
30
                unLock(lockKey);
31
            }
32
        });
33
    }
34

35
    return shop;
36
}

展开收起

逻辑过期的特点：

不会因为热点 key 失效导致请求全部打到数据库。
请求线程不等待缓存重建，响应速度快。
可能短暂返回旧数据，因此不适合强一致性场景。

缓存工具封装#

可以基于 StringRedisTemplate 封装一个通用缓存工具类，统一处理：

普通缓存写入，并设置 TTL。
逻辑过期缓存写入。
缓存穿透查询。
逻辑过期查询。

1
@Component
2
@Slf4j
3
public class CacheClient {
4

5
    private final StringRedisTemplate stringRedisTemplate;
6

7
    private static final ExecutorService CACHE_REBUILD_EXECUTOR =
8
            Executors.newFixedThreadPool(10);
9

10
    public CacheClient(StringRedisTemplate stringRedisTemplate) {
11
        this.stringRedisTemplate = stringRedisTemplate;
12
    }
13

14
    public void set(String key, Object value, Long time, TimeUnit timeUnit) {
15
        stringRedisTemplate.opsForValue().set(
16
                key,
17
                JSONUtil.toJsonStr(value),
18
                time,
19
                timeUnit
20
        );
21
    }
22

23
    public void setWithLogicalExpire(
24
            String key,
25
            Object value,
26
            Long time,
27
            TimeUnit timeUnit
28
    ) {
29
        RedisData redisData = new RedisData();
30
        redisData.setData(value);
31
        redisData.setExpireTime(LocalDateTime.now().plusSeconds(timeUnit.toSeconds(time)));
32

33
        stringRedisTemplate.opsForValue().set(
34
                key,
35
                JSONUtil.toJsonStr(redisData)
36
        );
37
    }
38

39
    public <R, ID> R queryWithPassThrough(
40
            String keyPrefix,
41
            ID id,
42
            Class<R> type,
43
            Function<ID, R> dbFallback,
44
            Long time,
45
            TimeUnit timeUnit
46
    ) {
47
        String key = keyPrefix + id;
48

49
        String json = stringRedisTemplate.opsForValue().get(key);
50

51
        if (StrUtil.isNotEmpty(json)) {
52
            return JSONUtil.toBean(json, type);
53
        }
54

55
        if (json != null) {
56
            return null;
57
        }
58

59
        R r = dbFallback.apply(id);
60

61
        if (r == null) {
62
            stringRedisTemplate.opsForValue().set(
63
                    key,
64
                    "",
65
                    2L,
66
                    TimeUnit.MINUTES
67
            );
68
            return null;
69
        }
70

71
        this.set(key, r, time, timeUnit);
72

73
        return r;
74
    }
75

76
    public <R, ID> R queryWithLogicalExpire(
77
            String keyPrefix,
78
            ID id,
79
            Class<R> type,
80
            Function<ID, R> dbFallback,
81
            Long time,
82
            TimeUnit timeUnit
83
    ) {
84
        String key = keyPrefix + id;
85

86
        String json = stringRedisTemplate.opsForValue().get(key);
87

88
        if (StrUtil.isEmpty(json)) {
89
            return null;
90
        }
91

92
        RedisData redisData = JSONUtil.toBean(json, RedisData.class);
93
        R r = JSONUtil.toBean((JSONObject) redisData.getData(), type);
94

95
        LocalDateTime expireTime = redisData.getExpireTime();
96
        if (expireTime.isAfter(LocalDateTime.now())) {
97
            return r;
98
        }
99

100
        String lockKey = "lock:" + key;
101
        boolean isLock = tryLock(lockKey);
102

103
        if (isLock) {
104
            CACHE_REBUILD_EXECUTOR.execute(() -> {
105
                try {
106
                    R freshData = dbFallback.apply(id);
107
                    this.setWithLogicalExpire(key, freshData, time, timeUnit);
108
                } finally {
109
                    unLock(lockKey);
110
                }
111
            });
112
        }
113

114
        return r;
115
    }
116

117
    private boolean tryLock(String key) {
118
        Boolean flag = stringRedisTemplate.opsForValue()
119
                .setIfAbsent(key, "1", 10, TimeUnit.SECONDS);
120
        return BooleanUtil.isTrue(flag);
121
    }
122

123
    private void unLock(String key) {
124
        stringRedisTemplate.delete(key);
125
    }
126
}

展开收起

业务调用示例#

1
@Override
2
public Result queryById(Long id) {
3
    Shop shop = cacheClient.queryWithLogicalExpire(
4
            RedisConstants.CACHE_SHOP_KEY,
5
            id,
6
            Shop.class,
7
            this::getById,
8
            RedisConstants.CACHE_SHOP_TTL,
9
            TimeUnit.MINUTES
10
    );
11

12
    if (shop == null) {
13
        return Result.fail("店铺不存在");
14
    }
15

16
    return Result.ok(shop);
17
}

展开收起

测试预热逻辑过期缓存：

1
@SpringBootTest
2
class HmDianPingApplicationTests {
3

4
    @Resource
5
    private ShopServiceImpl shopService;
6

7
    @Resource
8
    private CacheClient cacheClient;
9

10
    @Test
11
    void testSaveShop() {
12
        Shop shop = shopService.getById(1L);
13
        cacheClient.setWithLogicalExpire(
14
                RedisConstants.CACHE_SHOP_KEY + 1L,
15
                shop,
16
                10L,
17
                TimeUnit.SECONDS
18
        );
19
    }
20
}

展开收起

Redis相关介绍和命令

Mon, 06 Jul 2026 00:00:00 GMT

一认识 NoSQL#

1. SQL与NoSQL对比

对比项	SQL	NoSQL
数据结构	结构化 Structured	非结构化
数据关联	关联的 Relational	无关联的
查询方式	SQL 查询	非 SQL
事务特性	ACID	BASE
存储方式	磁盘	内存
扩展性	垂直扩展	水平扩展
使用场景	数据结构固定；对数据安全性、一致性要求较高	数据结构不固定；对一致性、安全性要求不高；对性能要求高

2. NoSQL 类型

键值类型：Redis
文档类型：MongoDB
列类型：HBase
Graph 图类型：Neo4j

二认识 Redis#

1. 定义 Redis 远程字典服务器基于内存的键值型 NoSQL 数据库

2. 常用于：

缓存
登录验证码
Session 共享
排行榜
计数器
分布式锁
消息队列
热点数据存储

3. Redis特征

键值 key-value 类型
- Redis 以 key-value 的形式存储数据。
- value 支持多种数据结构，功能丰富。
单线程
- Redis 主要命令执行是单线程的。
- 每个命令具备原子性。
低延迟、速度快
- Redis 基于内存操作。
- 使用 IO 多路复用。
- 编码设计良好，所以读写速度快。
支持数据持久化
- Redis 虽然主要基于内存，但可以把数据保存到磁盘。
- 防止服务器重启后数据全部丢失。
支持主从集群、分片集群
- 可以通过主从复制提高读能力和可用性。
- 可以通过分片集群提升容量和并发能力。
支持多语言客户端
- Java、Python、PHP、Go、Node.js 等语言都可以连接 Redis。

4. Redis 常见数据类型

数据类型	说明	常见用途
String	字符串类型，最基础类型	缓存、验证码、计数器
Hash	哈希类型，类似 Java 中的 Map	存储对象信息
List	列表类型，有序可重复	消息队列、任务列表
Set	集合类型，无序不重复	去重、共同好友
ZSet	有序集合，带分数排序	排行榜、积分排名

5. Redis 和 MySQL 的区别

对比项	Redis	MySQL
数据库类型	NoSQL 数据库	关系型数据库
数据结构	key-value	表结构
存储位置	主要在内存	主要在磁盘
查询方式	Redis 命令	SQL 语句
速度	快	相对较慢
事务特性	较弱	支持 ACID
常见用途	缓存、高并发读写	持久化业务数据

6. Redis 的持久化方式
Redis 支持把内存中的数据保存到磁盘，常见方式有：

RDB
- 定时生成数据快照。
- 优点：恢复速度快，文件小。
- 缺点：可能丢失最近一段时间的数据。
AOF
- 记录每一次写操作命令。
- 优点：数据更安全。
- 缺点：文件可能较大，恢复速度相对慢。

三 Redis配置内容#

1. 网络与后台运行配置

1
# 监听的地址，默认是127.0.0.1，会导致只能在本地访问
2
# 修改为0.0.0.0则可以在任意IP访问，生产环境不要设置为0.0.0.0
3
bind 0.0.0.0
4

5
# 守护进程，修改为yes后即可后台运行
6
daemonize yes
7

8
# 密码，设置后访问Redis必须输入密码
9
requirepass 123321

2. 端口、目录、数据库、内存和日志配置

1
# 监听的端口,Redis 默认端口号是6379
2
port 6379
3

4
# 工作目录，默认是当前目录，也就是运行redis-server时的命令
5
# 日志、持久化等文件会保存在这个目录
6
dir .
7

8
# 数据库数量，设置为1，代表只使用1个库
9
# 默认有16个库，编号0~15
10
databases 1
11

12
# 设置redis能够使用的最大内存
13
maxmemory 512mb
14

15
# 日志文件，默认为空，不记录日志，可以指定日志文件名
16
logfile "redis.log"

展开收起

四 Redis相关命令#

1. 通用命令

命令	作用
keys *	查看所有 key
keys user:*	按规则查看 key
scan 0	渐进式扫描 key
exists key	判断 key 是否存在
del key	删除 key
type key	查看 key 类型
expire key 秒数	设置过期时间
ttl key	查看剩余过期时间
persist key	取消过期时间
rename oldkey newkey	修改 key 名称
randomkey	随机返回一个 key
select 0	切换数据库
flushdb	清空当前数据库
flushall	清空所有数据库

2. String类型

介绍

内容	示例
普通字符串	name = zhangsan
数字	age = 18
JSON 字符串	user = {“name”:“zhangsan”,“age”:18}
验证码	code = 123456
token	token = xxxxxx

命令

命令	作用
set key value	设置值
get key	获取值
mset key1 value1 key2 value2	设置多个值
mget key1 key2	获取多个值
incr key	自增 1
decr key	自减 1
incrby key 数字	增加指定整数
decrby key 数字	减少指定整数
incrbyfloat key 数字	增加小数
setex key 秒 value	设置值并指定秒级过期时间
setnx key value	key 不存在时才设置
append key value	追加字符串
strlen key	获取字符串长度
getrange key start end	截取字符串
setrange key offset value	修改指定位置内容
getset key value	获取旧值并设置新值

场景

场景	示例
缓存数据	set user:1 “张三”
验证码	setex code:1001 60 123456
计数器	incr article:readcount:1
登录 token	setex token:user:1 3600 abc123
分布式锁	set lock 1 nx ex 10

3. Hash类型

介绍

key	field	value
user:1	name	zhangsan
user:1	age	18
user:1	gender	male

命令

命令	作用
hset key field value	设置字段值
hget key field	获取字段值
hmget key field1 field2	获取多个字段值
hgetall key	获取所有字段和值
hdel key field	删除字段
hexists key field	判断字段是否存在
hkeys key	获取所有字段名
hvals key	获取所有字段值
hlen key	获取字段数量
hincrby key field 数字	字段整数自增
hincrbyfloat key field 数字	字段小数自增
hsetnx key field value	字段不存在时才设置

场景

场景	示例
用户信息	user:1
商品信息	product:1001
购物车	cart:user:1
订单信息	order:1001
店铺信息	shop:1

4. List类型

介绍

特点	说明
有序	按插入顺序保存
可重复	相同元素可以出现多次
可从两端操作	可以从左边或右边插入、删除
底层类似双端队列	适合做队列、栈

命令

命令	作用
lpush key value	从左侧添加元素
rpush key value	从右侧添加元素
lrange key start stop	查看指定范围元素
lindex key index	根据下标获取元素
llen key	获取列表长度
lpop key	从左侧弹出元素
rpop key	从右侧弹出元素
lrem key count value	删除指定元素
lset key index value	根据下标修改元素
ltrim key start stop	截取列表
linsert key before/after 元素新元素	在指定元素前后插入
blpop key timeout	阻塞式左侧弹出
brpop key timeout	阻塞式右侧弹出

场景

场景	说明
消息队列	一边插入，一边取出
任务队列	保存待处理任务
最新评论	保存最新几条评论
浏览记录	保存用户浏览顺序
栈结构	后进先出
队列结构	先进先出

5. Set类型

介绍

特点	说明
无序	元素没有固定顺序
不重复	相同元素只能保存一次
支持集合运算	可以求交集、并集、差集

命令

命令	作用
sadd key member	添加元素
smembers key	查看所有元素
sismember key member	判断元素是否存在
scard key	获取集合元素数量
srem key member	删除指定元素
spop key	随机删除并返回元素
srandmember key	随机返回元素，不删除
smove source destination member	移动元素
sinter key1 key2	求交集
sunion key1 key2	求并集
sdiff key1 key2	求差集
sinterstore result key1 key2	保存交集结果
sunionstore result key1 key2	保存并集结果
sdiffstore result key1 key2	保存差集结果

场景

场景	说明	示例
去重	利用 Set 不重复特点	用户签到、访问 IP
共同好友	使用交集	sinter user:1 user:2
共同关注	使用交集	两个用户都关注了谁
推荐好友	使用差集	A 关注但 B 未关注
标签系统	保存用户标签	user:1
抽奖	随机获取元素	srandmember users 1
点赞	保存点赞用户 ID	article:1

6. ZSet/SortedSet

介绍

特点	说明
元素不重复	member 不能重复
每个元素有分数	每个 member 都有一个 score
按分数排序	Redis 根据 score 进行排序
适合排行榜	比如积分榜、热度榜、成绩排名

命令

命令	作用
zadd key score member	添加元素
zrange key start stop	按分数从小到大查询
zrevrange key start stop	按分数从大到小查询
zrange key start stop withscores	查询时带分数
zscore key member	获取元素分数
zrank key member	获取从小到大排名
zrevrank key member	获取从大到小排名
zrangebyscore key min max	按分数范围查询
zrevrangebyscore key max min	按分数范围倒序查询
zrem key member	删除元素
zincrby key increment member	增加元素分数
zcard key	获取元素总数
zcount key min max	获取分数范围内元素数量
zremrangebyrank key start stop	按排名范围删除
zremrangebyscore key min max	按分数范围删除

场景

场景	说明
排行榜	按分数排名
成绩排名	按成绩高低排序
热度榜	按点赞数、浏览量排序
积分榜	按用户积分排序
延迟队列	score 可以存时间戳
商品销量榜	按销量排序

五 Key 的层级结构#

Redis 中常用 : 来分隔 key 的层级。
格式一般是：项目名:业务名: id:字段名

Key 层级结构示例
假设有一个用户模块，可以这样设计：

1
user:1:name
2
user:1:age
3
user:1:gender
4
user:2:name
5
user:2:age
6
user:2:gender

查看所有用户相关 key。

1
keys user:*

查看用户 1 的所有信息。

1
keys user:1:*

常见业务场景写法

场景	Key 示例	类型
用户对象	user:1	Hash
商品对象	product:1001	Hash
验证码	login:code:手机号	String
登录 token	login:token:user:1	String
购物车	cart:user:1	Hash
商品库存	stock:product:1001	String
文章点赞数	article:1001	String
排行榜	rank	ZSet
用户关注列表	follow:user:1	Set

Aron-Blog

Redis 多级缓存与JVM进程缓存

1. 为什么需要多级缓存#

1.1 传统缓存方案#

1.2 多级缓存方案#

1.3 各层缓存的职责#

2. JVM 进程缓存#

2.1 什么是进程缓存#

2.2 进程缓存与 Redis 的区别#

2.3 进程缓存的边界#

3. 初识 Caffeine#

3.1 Caffeine 的定位#

项目依赖#

3.2 基本 API#

3.3 为什么优先使用 cache.get#

3.4 空值与异常#

4. Caffeine 的驱逐与过期策略#

4.1 基于容量#

4.2 基于时间#

写入后过期#

访问后过期#

4.3 基于引用#

4.4 过期不等于立即删除#

4.5 刷新与过期的区别#

5. 使用 Caffeine 实现商品进程缓存#

5.1 需求#

5.2 定义缓存 Bean#

5.3 在 Controller 中查询缓存#

5.4 查询流程#

5.5 Tomcat 集群中的命中率#

6. 数据更新与缓存一致性#

6.1 常用处理策略#

6.2 商品与库存应区别对待#

6.3 Canal 同步实现#

7. 监控、测试与调优#

7.1 开启统计#

7.2 基本验证步骤#

7.3 示例单元测试#

8. 本章小结#

参考资料#

Redis Cluster 分片集群原理、部署与实践

1. 为什么需要 Redis Cluster#

2. Sentinel 与 Redis Cluster 的区别#

3. 集群基本结构#

3.1 Shard 的含义#

3.2 最小与推荐节点数#

3.3 故障域部署#

4. Hash Slot 数据分片模型#

4.1 Key 绑定的是槽位，不是物理节点#

4.2 查看 key 的槽位#

5. Hash Tag：让相关 key 落在同一槽位#

5.1 精确规则#

5.2 Hash Tag 的用途#

5.3 Hash Tag 的风险#

6. 多 Key 命令与 CROSSSLOT#

6.1 受影响的操作#

6.2 Lua 脚本和事务#

7. 节点通信与 Cluster Bus#

7.1 Cluster Bus 用途#

7.2 全连接拓扑#

7.3 防火墙要求#

8. 节点标识、拓扑与配置纪元#

8.1 Node ID#

8.2 nodes.conf#

8.3 configEpoch#

9. 请求路由：MOVED 与 ASK#

9.1 MOVED：永久槽位归属重定向#

9.2 ASK：迁槽期间的一次性重定向#

9.3 MOVED 与 ASK 对比#

9.4 redis-cli 的 -c#

10. Cluster 客户端应如何工作#

10.1 Seed 节点#

11. 核心配置#

11.1 配置项说明#

11.2 不要照搬实验安全配置#

12. NAT、容器与地址通告#

13. 创建一个六节点集群#

14. 查看集群状态#

14.1 CLUSTER INFO#

14.2 CLUSTER NODES#

3.3 为什么优先使用 `cache.get`#

9.4 redis-cli 的 `-c`#