4. 缓存层设计：Redis容器化部署、缓存策略（LRU/TTL）与缓存与搜索的读写流程

在搜索缓存一致性架构中，Redis 作为缓存层承担着“流量缓冲”与“数据加速”的核心角色。容器化部署使 Redis 实例的扩缩容、配置管理和故障恢复变得标准化，而 LRU 与 TTL 策略则决定了缓存命中率与数据新鲜度之间的平衡。本节将深入剖析 Redis 容器化部署的最佳实践、缓存淘汰策略的选择依据，以及缓存与搜索引擎之间的完整读写数据流。

4.1 Redis 容器化部署：从单机到哨兵集群

生产环境下的 Redis 容器化部署通常采用 StatefulSet 控制器，以保证稳定的网络标识（Pod 名称）和持久化存储。以下是一个典型的 Redis 哨兵模式部署清单（关键片段）：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis-master
spec:
  serviceName: redis-master-svc
  replicas: 1
  selector:
    matchLabels:
      app: redis
      role: master
  template:
    metadata:
      labels:
        app: redis
        role: master
    spec:
      containers:
      - name: redis
        image: redis:7.2-alpine
        ports:
        - containerPort: 6379
        volumeMounts:
        - name: redis-data
          mountPath: /data
        resources:
          requests:
            memory: "2Gi"
            cpu: "500m"
          limits:
            memory: "4Gi"
            cpu: "1"
  volumeClaimTemplates:
  - metadata:
      name: redis-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi
---
apiVersion: v1
kind: Service
metadata:
  name: redis-master-svc
spec:
  ports:
  - port: 6379
    targetPort: 6379
  selector:
    app: redis
    role: master

4.2 缓存策略：LRU 与 TTL 的协同机制

Redis 提供多种内存淘汰策略，在搜索缓存场景中，LRU（Least Recently Used） 与 TTL（Time To Live） 是最常用的组合。LRU 负责在内存达到上限时淘汰最久未访问的键，TTL 则确保数据不会无限期驻留，避免“脏数据”长期存在。

TTL 的设置需要根据搜索数据的更新频率来定。对于商品搜索，建议 TTL 设置在 30 秒～5 分钟 之间；对于用户画像类缓存，可延长至 1 小时。过短的 TTL 会导致缓存穿透，过长的 TTL 则增加数据不一致风险。

4.3 缓存与搜索的读写流程

缓存层位于应用与搜索引擎（如 Elasticsearch）之间，采用 Cache-Aside 模式。读请求优先查询 Redis，命中则直接返回；未命中则回源到搜索引擎，并将结果写入缓存。写请求则采用“先更新搜索引擎，再删除缓存”的策略，以最小化不一致窗口。

4.4 延迟双删：解决写操作中的缓存一致性问题

在 Cache-Aside 写流程中，如果先删除缓存再更新搜索引擎，在删除缓存后、更新完成前，另一个读请求可能将旧数据重新写入缓存，导致缓存与搜索引擎长期不一致。延迟双删 策略通过两次删除来消除这个窗口：

1. 第一次删除： 在更新搜索引擎之前，立即删除缓存中的对应键。
2. 更新搜索引擎： 执行实际的索引更新操作。
3. 延迟等待： 休眠一个短时间（通常 200～500ms，大于可能的并发读耗时）。
4. 第二次删除： 再次删除缓存键，清除在更新期间可能被回填的旧数据。

// 延迟双删伪代码
public void updateSearchAndCache(String key, Object newData) {
    // 1. 第一次删除缓存
    redisTemplate.delete(key);

    // 2. 更新搜索引擎
    searchEngine.updateIndex(key, newData);

    // 3. 延迟等待（异步或线程休眠）
    Thread.sleep(500);

    // 4. 第二次删除缓存
    redisTemplate.delete(key);
}

4.5 缓存穿透、击穿与雪崩的防护

在搜索缓存场景中，以下三种异常情况需要重点防范：

4.6 容器化环境下的监控与故障排查

在 Kubernetes 中运行 Redis 时，需要关注以下关键指标：

• 内存使用率： used_memory / maxmemory，超过 80% 应触发告警。
• 缓存命中率： keyspace_hits / (keyspace_hits + keyspace_misses)，低于 85% 需检查缓存策略。
• 逐出键数量： evicted_keys，突增说明内存不足或 TTL 设置不合理。
• 慢查询日志： 通过 SLOWLOG GET 100 分析耗时命令，常见于 KEYS * 或大 key 操作。