Redis 深度研究：从数据结构到生产实践的完整拆解

环境基线：Redis 8.0（社区版，AGPLv3）· Java 17 · Spring Boot 3.4.x · Spring Data Redis 3.4 · Lettuce 6.4 · Linux x86_64（生产建议 4C8G 起步）
全文示例统一使用上述版本，配置文件、命令与 Java 代码不混用 6.x / 7.x 的旧写法。涉及 7.x 行为的地方会单独标注。

Redis 是最容易被「用对了但没理解」的中间件。多数人第一次接触它，学的是 SET / GET / EXPIRE 三件套；真正出事故时，倒下的地方却往往是编码方式、淘汰策略、持久化 fsync 时机、集群 slot 归属这些没人教的部分。

这篇文章不做命令字典，而是沿着「一个 key 从写入到被淘汰」的完整生命周期，把 Redis 的内部机制、边界条件和工程约束逐个拆开，最后落到 Spring Boot 3.4 的可运行代码。

一、先看全景：Redis 到底是什么

1.1 常见误解与实际情况

1.2 组件全景

Redis 8.0 最值得关注的两个变化：

1. 原 Redis Stack 模块进入主发行包：JSON、Search（查询引擎）、TimeSeries、Bloom 不再需要单独装模块，docker run redis:8 即可用。
2. 新增 Vector Set 类型：VADD / VSIM / VCARD 等命令，把向量检索内置到键空间，适合做 RAG 的召回层。这是 8.0 与 7.x 最实质的能力差异。

二、数据结构与底层编码：决定性能的真正变量

2.1 逻辑类型与物理编码对照

Redis 对外只有 String / Hash / List / Set / ZSet / Stream / Bitmap / HyperLogLog / GEO / Vector Set 这些逻辑类型，但每个类型在内部有多种物理编码。OBJECT ENCODING key 是排查内存与延迟问题的第一把钥匙。

两条必须记住的规则：

• 阈值是「与」关系：Hash 只要有一个 field 的 value 超过 64 字节，整体立刻从 listpack 升级为 hashtable，而且不会降级。
• 升级是永久的：删除元素让长度回到阈值以下，编码也不会退回。想缩回只能重建 key（DUMP/RESTORE 或业务侧迁移）。

验证方式：

redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> HSET user:1 name "张三" age 28
127.0.0.1:6379> OBJECT ENCODING user:1
"listpack"
127.0.0.1:6379> HSET user:1 bio "<一段超过 64 字节的自我介绍……>"
127.0.0.1:6379> OBJECT ENCODING user:1
"hashtable"

2.2 SDS：String 为什么不是 C 字符串

Redis 自己实现了 SDS（Simple Dynamic String），结构大致为 len / alloc / flags / buf[]，带来三个直接收益：

embstr 与 raw 的区别在于：embstr 把 redisObject 与 SDS 一次性连续分配，适合短字符串；超过 44 字节后需要两次分配，改为 raw。

2.3 dict：哈希表的渐进式 rehash

Redis 的 dict 使用两张哈希表做渐进式 rehash：扩容时保留旧表，每次操作顺带迁移一个桶，把一次性 O(n) 的停顿摊到多次请求上。这也是 Redis 单线程还能保持低延迟的原因之一。

扩容触发条件与负载因子：

在 hashtable 编码下，Hash 与 Set 的每次读写都要经过 dict 查找，所以「小对象用 listpack、大对象用 hashtable」的分界点会直接反映在 P99 延迟上。

2.4 listpack / quicklist / skiplist

• listpack：紧凑的连续内存块，替代了旧的 ziplist（7.0 起全面替换），解决了 ziplist 的连锁更新问题。
• quicklist：List 的默认实现，本质是「双向链表 + 每节点一个 listpack」，兼顾插入效率与内存局部性。
• skiplist：ZSet 大对象编码，配合 dict 实现「按分数范围查」与「按成员查」两条路径都是 O(log n)。

实践结论：凡是「小集合」场景（配置项、对象字段、标签集合），把元素控制在上表阈值内，内存和延迟都会明显更好；一旦越过阈值，性能会呈台阶式变化，而不是线性渐变。

三、单线程模型与 I/O 多线程

3.1 为什么单线程还这么快

单线程的代价是一条慢命令会阻塞所有请求。KEYS *、FLUSHALL、大 key 的 DEL、SORT、复杂度 O(n) 的 Lua 脚本，都会让整实例停摆。这是 Redis 最重要的性能纪律。

3.2 6.0 之后的多线程边界

# redis.conf
io-threads 4
io-threads-do-reads yes

所以「Redis 6 变多线程了」并不意味着命令可以并行。命令层面的串行语义没有变，变的只是网络收发。

3.3 延迟敏感场景的配置建议

别把 io-threads 当成「加线程就变快」。它在高并发、小 value、多连接的场景收益最大；value 很大时收益有限，因为瓶颈在内存带宽与协议序列化。

四、持久化：RDB、AOF 与混合模式

4.1 三种方案对比

4.2 RDB 的关键参数

save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir /var/lib/redis
rdbcompression yes
rdbchecksum yes
stop-writes-on-bgsave-error yes

stop-writes-on-bgsave-error yes 是一个容易被忽略的保护：快照失败时拒绝写入，避免「以为有持久化、其实早就断了」。但它在磁盘满时会直接让实例只读，需要配合监控。

4.3 AOF：7.0 起是多文件结构

Redis 7.0 把单文件 AOF 改成多部分 AOF，目录结构如下：

/var/lib/redis/
└── appendonlydir/
    ├── appendonly.aof.1.base.rdb      # 基线（混合模式下是 RDB）
    ├── appendonly.aof.1.incr.aof      # 增量命令
    └── appendonly.aof.manifest        # 清单文件

对应配置：

appendonly yes
appendfilename "appendonly.aof"
appenddirname "appendonlydir"
aof-use-rdb-preamble yes
aof-timestamp-enabled yes

appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

appendfsync 的三种取值直接决定可靠性与吞吐：

7.0 之前的单文件 AOF 在 rewrite 期间可能产生「base 与 incr 混合」的重放歧义；多文件结构 + manifest 正是为解决这个问题。如果你的运维脚本还在按 appendonly.aof 单文件路径做备份，升级后必须改成备份 appendonlydir 整个目录。

4.4 fork 与内存放大

BGSAVE 与 AOF rewrite 都依赖 fork + COW（写时复制）。经验关系：

线上必须显式设置：

sysctl -w vm.overcommit_memory=1
echo 'never' > /sys/kernel/mm/transparent_hugepage/enabled

透明大页（THP）会让 fork 与 COW 的延迟抖动放大，Redis 官方长期建议关闭。

五、内存管理与淘汰策略

5.1 两层机制要分清

没有设置 maxmemory 时，淘汰策略永远不会触发，实例会一直吃到被 OOM Killer 干掉或触发 swap。这是 Redis 最常见的生产配置缺失。

5.2 八种淘汰策略

选型决策链：

1. 这个实例是否允许丢数据？不允许 → noeviction，并配置告警。
2. 是否全部 key 都可淘汰？是 → 在 allkeys-lru 与 allkeys-lfu 中二选一。
3. 只有部分 key 可淘汰 → 用 volatile-*，并确保可淘汰的 key 都设置了 TTL（否则候选集为空，行为退化为 noeviction）。

5.3 LRU 与 LFU 的真实实现

Redis 的 LRU 不是严格 LRU，而是采样近似：

maxmemory 4gb
maxmemory-policy allkeys-lru
maxmemory-samples 5

每次需要淘汰时随机采样 maxmemory-samples 个 key，挑最久未使用的淘汰。采样数越大越接近真实 LRU，CPU 开销也越高，5 是官方默认平衡点。

LFU 则维护一个 8 位的计数器（对数计数，lfu-log-factor 控制增长速度）与一个 16 位的衰减时间（lfu-decay-time 分钟）。LFU 更适合「热点长期稳定」的场景，LRU 更适合「访问模式随时间漂移」的场景。

5.4 内存碎片

mem_fragmentation_ratio = used_memory_rss / used_memory：

activedefrag yes
active-defrag-ignore-bytes 100mb
active-defrag-threshold-lower 10
active-defrag-threshold-upper 100
active-defrag-cycle-min 1
active-defrag-cycle-max 25

碎片治理的根因通常是「频繁增删不同大小的 value」与「大量过期 key 未及时释放」。前者靠对象复用与批量重建，后者靠 hz 与异步删除（lazyfree-lazy-expire yes、lazyfree-lazy-user-del yes）。

六、高可用与集群

6.1 三种部署形态

6.2 主从复制的关键参数

replicaof 10.0.0.11 6379
masterauth YourPassword
masteruser default

repl-backlog-size 64mb
repl-diskless-sync yes
repl-diskless-sync-delay 5
repl-diskless-load disabled

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

min-replicas-to-write 1 + min-replicas-max-lag 10 是防脑裂的核心配置：当没有健康副本、或副本延迟超过 10 秒时，主节点拒绝写入，避免旧主继续接受写请求造成数据分叉。

repl-backlog-size 决定「短暂断连后能否增量同步」。默认 1MB 在高写入场景下很容易被冲掉，导致全量同步（fork + 传输），进而引发雪崩式延迟。写入量大的实例建议 64MB 以上。

6.3 Cluster 的 slot 与重定向

Cluster 把键空间切成 16384 个 slot，slot = CRC16(key) mod 16384。

redis-cli --cluster create \
  10.0.0.1:6379 10.0.0.2:6379 10.0.0.3:6379 \
  10.0.0.4:6379 10.0.0.5:6379 10.0.0.6:6379 \
  --cluster-replicas 1

两种重定向必须区分：

把 ASK 当成 MOVED 处理、或反之，都会导致迁移期间的大量失败。成熟的客户端（Lettuce、Jedis）已经实现，自研客户端必须自己处理。

多 key 命令的约束：

# 同一个 slot（用 hash tag 强制同槽）
SET {order:1001}:amount 99
SET {order:1001}:status paid

# 跨 slot 会直接报错
MGET user:1 user:2
# (error) CROSSSLOT Keys in request don't hash to the same slot

所以 Cluster 下的批量操作要么用 hash tag 让相关 key 同槽（代价是热点集中），要么拆成多次单 key 请求 + pipeline，要么改用 RedisTemplate 的 executePipelined 逐 key 发送。

七、缓存三大问题与一致性

7.1 问题全景与解法

7.2 空值缓存与布隆过滤器的取舍

布隆过滤器适合「ID 空间可枚举」的场景（如商品 ID、用户 ID）；空值缓存适合「无效请求量可控」的场景。两者通常组合使用：布隆过滤挡第一层，空值缓存兜住假阳性。

7.3 Cache Aside 的正确顺序

为什么是「删除」而不是「更新」：两个并发写请求，若都去更新缓存，可能因执行顺序错乱导致缓存保留旧值；删除则让下一次读自然回源重建。

即便如此，仍有极小概率的不一致窗口（读请求在写请求删缓存之后、DB 更新之前读到旧值并回写）。常见兜底是延迟双删：

1. 删除缓存
2. 更新数据库
3. 延迟 500ms～1s 再删除一次缓存

延迟时间要大于「一次读请求的回源 + 回写」耗时，具体值需按业务压测确定，没有通用数字。

八、分布式锁：从 SET NX 到 Redisson

8.1 最小可用实现

# 加锁：原子地 SET NX + 过期时间，绝不要分成两条命令
SET lock:order:1001 "8f14e45f-ce" NX PX 30000

两个必须遵守的纪律：

1. SET key value NX PX ms 必须一条命令完成。先 SETNX 再 EXPIRE，中间进程崩溃就会产生永久锁。
2. value 必须是唯一标识（UUID / 请求 ID），释放时校验，避免误删别人的锁。

8.2 释放锁的 Lua 脚本

-- scripts/unlock.lua
if redis.call('GET', KEYS[1]) == ARGV[1] then
    return redis.call('DEL', KEYS[1])
else
    return 0
end

Redis 保证单条 Lua 脚本原子执行，因此「比较 + 删除」不会被打断。

8.3 三种实现对比

Redisson 看门狗机制：默认锁租约 30 秒，后台任务每 10 秒（租约的 1/3）续期一次，业务执行完主动 unlock 后停止续期。注意：只有「不显式指定 leaseTime」时看门狗才生效，一旦传入 leaseTime，Redisson 认为你自行管理超时，不再续期。

8.4 RedLock 的争议要点

RedLock 要求在 N 个独立 Redis 实例上多数派加锁成功才算成功。它的争议集中在：

• 依赖各实例的时钟速率假设，无法完全抵御进程暂停（GC 停顿、虚拟机迁移）。
• 运维成本高：需要维护 N 套互不相关的实例。
• 对绝大多数业务，单实例 + 合理超时 + 幂等设计已经足够。

结论：分布式锁的正确性最终应该由「幂等 + 唯一约束」兜底，而不是由锁本身保证。 锁是性能优化，不是正确性保证。

九、Spring Boot 3.4 集成实战

9.1 依赖

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

    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-pool2</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
</dependencies>

Spring Boot 3.x 的 Redis starter 默认使用 Lettuce（基于 Netty，连接共享、线程安全）。commons-pool2 只有启用连接池时才需要，但不引入它而配置了 lettuce.pool，配置会静默失效。

9.2 配置文件

单机：

spring:
  data:
    redis:
      host: 127.0.0.1
      port: 6379
      password: "YourStrong@Passw0rd"
      database: 0
      timeout: 2s
      connect-timeout: 2s
      lettuce:
        pool:
          max-active: 16
          max-idle: 8
          min-idle: 2
          max-wait: 1s
        shutdown-timeout: 200ms

Cluster：

spring:
  data:
    redis:
      password: "YourStrong@Passw0rd"
      timeout: 2s
      cluster:
        nodes:
          - 10.0.0.1:6379
          - 10.0.0.2:6379
          - 10.0.0.3:6379
        max-redirects: 3
      lettuce:
        cluster:
          refresh:
            adaptive: true
            period: 30s

adaptive: true 让 Lettuce 在收到 MOVED 后自动刷新拓扑，比固定周期刷新更及时。

9.3 序列化配置（最容易踩坑的一环）

package com.example.redis.config;

import com.fasterxml.jackson.annotation.JsonTypeInfo;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.jsontype.impl.LaissezFaireSubTypeValidator;
import com.fasterxml.jackson.datatype.jsr310.JavaTimeModule;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.StringRedisSerializer;

@Configuration
public class RedisConfig {

    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(factory);

        ObjectMapper mapper = new ObjectMapper();
        mapper.registerModule(new JavaTimeModule());
        mapper.activateDefaultTyping(
                LaissezFaireSubTypeValidator.instance,
                ObjectMapper.DefaultTyping.NON_FINAL,
                JsonTypeInfo.As.PROPERTY
        );

        StringRedisSerializer keySerializer = new StringRedisSerializer();
        GenericJackson2JsonRedisSerializer valueSerializer =
                new GenericJackson2JsonRedisSerializer(mapper);

        template.setKeySerializer(keySerializer);
        template.setHashKeySerializer(keySerializer);
        template.setValueSerializer(valueSerializer);
        template.setHashValueSerializer(valueSerializer);
        template.afterPropertiesSet();
        return template;
    }
}

关键点：

如果缓存内容可能来自外部或不可信来源，应改用 Jackson2JsonRedisSerializer<T> 绑定具体类型，或干脆只用 StringRedisTemplate 存 JSON 字符串，由业务层显式转换。

9.4 业务服务：缓存 + 防击穿

package com.example.redis.service;

import com.example.redis.config.RedisKeys;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;

import java.time.Duration;
import java.util.concurrent.ThreadLocalRandom;

@Service
public class ProductService {

    private final StringRedisTemplate redis;
    private final ProductRepository repository;

    public ProductService(StringRedisTemplate redis, ProductRepository repository) {
        this.redis = redis;
        this.repository = repository;
    }

    public Product getProduct(long id) {
        String key = RedisKeys.product(id);
        String cached = redis.opsForValue().get(key);
        if (cached != null) {
            return cached.isEmpty() ? null : JsonUtils.fromJson(cached, Product.class);
        }

        String lockKey = RedisKeys.productLock(id);
        Boolean locked = redis.opsForValue().setIfAbsent(lockKey, "1", Duration.ofSeconds(10));
        try {
            if (Boolean.TRUE.equals(locked)) {
                Product product = repository.findById(id).orElse(null);
                if (product == null) {
                    redis.opsForValue().set(key, "", randomTtl(60, 120));
                } else {
                    redis.opsForValue().set(key, JsonUtils.toJson(product), randomTtl(1800, 2400));
                }
                return product;
            }

            sleepQuietly(50);
            String retry = redis.opsForValue().get(key);
            if (retry != null) {
                return retry.isEmpty() ? null : JsonUtils.fromJson(retry, Product.class);
            }
            return repository.findById(id).orElse(null);
        } finally {
            if (Boolean.TRUE.equals(locked)) {
                redis.delete(lockKey);
            }
        }
    }

    private Duration randomTtl(int minSeconds, int maxSeconds) {
        int seconds = ThreadLocalRandom.current().nextInt(minSeconds, maxSeconds);
        return Duration.ofSeconds(seconds);
    }

    private void sleepQuietly(long millis) {
        try {
            Thread.sleep(millis);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

三个设计意图：

1. 空值缓存用空字符串而不是 null：opsForValue().get 对不存在的 key 返回 null，缓存空对象必须用可区分的非空值。
2. TTL 加随机抖动：避免同一批次 key 同时失效造成雪崩。
3. 互斥锁失败后短暂等待再重试读缓存：把并发重建降为一次，其余请求要么命中新缓存，要么直接回源一次。

9.5 分布式锁的正确写法（StringRedisTemplate + Lua）

package com.example.redis.lock;

import org.springframework.core.io.ClassPathResource;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.data.redis.core.script.DefaultRedisScript;
import org.springframework.data.redis.core.script.RedisScript;
import org.springframework.stereotype.Component;

import java.time.Duration;
import java.util.List;
import java.util.UUID;

@Component
public class RedisLock {

    private static final RedisScript<Long> UNLOCK_SCRIPT =
            new DefaultRedisScript<>(
                    "if redis.call('GET', KEYS[1]) == ARGV[1] then " +
                    "return redis.call('DEL', KEYS[1]) else return 0 end",
                    Long.class);

    private final StringRedisTemplate redis;

    public RedisLock(StringRedisTemplate redis) {
        this.redis = redis;
    }

    public String tryLock(String key, Duration ttl) {
        String token = UUID.randomUUID().toString();
        Boolean ok = redis.opsForValue().setIfAbsent(key, token, ttl);
        return Boolean.TRUE.equals(ok) ? token : null;
    }

    public boolean unlock(String key, String token) {
        if (token == null) {
            return false;
        }
        Long result = redis.execute(UNLOCK_SCRIPT, List.of(key), token);
        return result != null && result == 1L;
    }
}

使用 StringRedisTemplate 而不是自定义 RedisTemplate 的原因很实际：Lua 脚本的 KEYS / ARGV 会被模板的序列化器处理。若 value 序列化器是 JSON，ARGV[1] 会变成带引号的 "uuid"，而 GET 返回的原始值不一定带引号，比较必然失败，锁永远删不掉。这是一个非常典型的线上事故。

9.6 注解式缓存

package com.example.redis.service;

import org.springframework.cache.annotation.CacheEvict;
import org.springframework.cache.annotation.Cacheable;
import org.springframework.stereotype.Service;

@Service
public class UserQueryService {

    private final UserRepository repository;

    public UserQueryService(UserRepository repository) {
        this.repository = repository;
    }

    @Cacheable(cacheNames = "user", key = "#id", unless = "#result == null")
    public User findById(long id) {
        return repository.findById(id).orElse(null);
    }

    @CacheEvict(cacheNames = "user", key = "#user.id")
    public void update(User user) {
        repository.save(user);
    }
}

启用注解需要 @EnableCaching，并注册 CacheManager：

package com.example.redis.config;

import org.springframework.cache.annotation.EnableCaching;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.cache.RedisCacheConfiguration;
import org.springframework.data.redis.cache.RedisCacheManager;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.RedisSerializationContext;
import org.springframework.data.redis.serializer.StringRedisSerializer;

import java.time.Duration;

@Configuration
@EnableCaching
public class CacheConfig {

    @Bean
    public RedisCacheManager cacheManager(RedisConnectionFactory factory) {
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
                .entryTtl(Duration.ofMinutes(30))
                .prefixCacheNameWith("cache:")
                .disableCachingNullValues()
                .serializeKeysWith(RedisSerializationContext.SerializationPair
                        .fromSerializer(new StringRedisSerializer()))
                .serializeValuesWith(RedisSerializationContext.SerializationPair
                        .fromSerializer(new GenericJackson2JsonRedisSerializer()));

        return RedisCacheManager.builder(factory)
                .cacheDefaults(config)
                .build();
    }
}

@Cacheable 有几个必须知道的行为边界：

十、常见坑与排查手册

10.1 生产事故高发清单

10.2 排查命令对照表

常用扫描方式（替代 KEYS）：

redis-cli --scan --pattern 'user:*' --count 1000
redis-cli --bigkeys
redis-cli --memkeys
redis-cli --hotkeys          # 需要 maxmemory-policy 为 lfu 系列

10.3 监控指标的最小集合

十一、实践准则清单

把全文压缩成可以直接贴进团队规范的条目：

1. 每个缓存实例必须设 maxmemory 与 maxmemory-policy，两者缺一不可。
2. 禁止在生产使用 KEYS，统一走 SCAN；批量删除用 UNLINK。
3. 单 value 控制在 10KB 以内，集合元素控制在 5000 以内；超出即拆 key。
4. 相关性强的 key 用同一个 hash tag，兼顾 Cluster 多 key 操作与批量读取。
5. TTL 必须带随机抖动，避免整批同时失效。
6. 持久化优先混合模式（aof-use-rdb-preamble yes + appendfsync everysec）。
7. 主从必须配 min-replicas-to-write，防止脑裂写入。
8. 锁的 value 必带唯一 token，释放必须用 Lua 原子比较删除，且统一用 StringRedisTemplate。
9. 序列化只用 String 与 JSON，禁用 JDK 序列化；不可信数据不要开 default typing。
10. 所有 Redis 操作必须有超时，客户端超时要小于上游服务的超时，避免线程池被拖垮。
11. 缓存只是优化，正确性由 DB 唯一约束与幂等逻辑兜底。
12. 上线前跑一遍 --bigkeys 与 SLOWLOG，把问题留在压测阶段。

十二、可选的后续方向

这篇文章覆盖了机制与工程实践，但每个方向都还能再往下挖一层，按需可以继续：

如果后续要把这套内容落到具体业务，建议的推进顺序是：先定数据结构与 key 规范 → 再定淘汰与持久化策略 → 最后写缓存与锁的代码。顺序反了，代码写得再漂亮也会被配置问题打回去。