3. Kubernetes 缓存架构：Pod内缓存、Sidecar缓存、分布式缓存（Redis/Memcached）在K8s中的部署模式
在Kubernetes环境中，缓存系统的部署模式直接影响数据一致性、资源利用率与故障恢复速度。本章从Pod内缓存、Sidecar缓存、分布式缓存三种架构出发，分析其在K8s中的部署模式、适用场景与性能特征。
3.1 三种缓存架构的部署模式对比
| 缓存类型 | 部署模式 | 数据一致性 | 延迟 | 典型实现 |
|---|---|---|---|---|
| Pod内缓存 | 应用容器内嵌缓存库（如lru-cache、Caffeine） | 单副本强一致 | 纳秒级 | Go map、Java ConcurrentHashMap |
| Sidecar缓存 | 同Pod独立容器，共享网络/存储卷 | 单Pod内一致 | 微秒级 | Envoy本地缓存、Redis Standalone Sidecar |
| 分布式缓存 | 独立StatefulSet/Deployment集群 | 最终一致/强一致（取决于配置） | 毫秒级 | Redis Cluster、Memcached集群 |
性能调优要点：Pod内缓存适合高频只读热点数据；Sidecar缓存适合服务网格场景下的请求级缓存；分布式缓存适合跨Pod共享的全局数据。三者可组合为多级缓存架构，但需引入一致性治理策略。
3.2 Pod内缓存：零网络开销的本地加速
Pod内缓存将缓存数据存储在应用进程的堆内或堆外内存中，完全避免网络往返。在K8s中，这种模式通过应用代码直接集成缓存库实现。
- 部署特征：缓存生命周期与Pod绑定，Pod重启后缓存丢失。
- 一致性模型：单副本强一致，无需跨节点同步。
- 性能指标：读写延迟通常在10-100纳秒，吞吐量受限于单Pod CPU。
- 典型场景：配置元数据、用户会话（单副本）、静态字典数据。
// Go示例：Pod内LRU缓存
import lru "github.com/hashicorp/golang-lru"
cache, _ := lru.New(10000)
cache.Add("user:1001", profile)
if val, ok := cache.Get("user:1001"); ok {
return val.(UserProfile)
}
避坑指南：Pod内缓存无法感知其他副本的更新，在Deployment多副本场景下会出现数据不一致。必须配合消息队列或轮询机制进行失效通知，否则将产生脏读。
3.3 Sidecar缓存：同Pod隔离的缓存代理
Sidecar缓存将缓存进程部署为Pod内的辅助容器，与应用容器共享网络命名空间和emptyDir卷。这种模式在服务网格（Service Mesh）中尤为常见。
- 部署特征：Sidecar容器独立于业务容器，可单独配置资源限制。
- 一致性模型：单Pod内强一致，跨Pod需额外同步机制。
- 性能指标：本地回环网络延迟约10-50微秒，比分布式缓存快10-100倍。
- 典型场景：Envoy本地缓存、Redis作为Sidecar提供本地热点缓存。
# Pod YAML示例：Redis Sidecar
apiVersion: v1
kind: Pod
metadata:
name: app-with-cache
spec:
containers:
- name: app
image: my-app:latest
ports:
- containerPort: 8080
- name: redis-sidecar
image: redis:7-alpine
ports:
- containerPort: 6379
resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "256Mi"
cpu: "200m"
架构优势：Sidecar缓存不侵入业务代码，通过localhost访问即可获得低延迟缓存。在Istio/Envoy中，Sidecar缓存可缓存上游服务响应，减少重复请求。
3.4 分布式缓存：Redis/Memcached在K8s中的部署模式
分布式缓存以独立集群形式部署，为多个微服务提供共享缓存能力。在K8s中，Redis和Memcached是最主流的两种选择。
3.4.1 Redis Cluster部署模式
- StatefulSet + Headless Service：保证Pod标识稳定，支持主从复制与分片。
- 数据分片：16384个哈希槽自动分配，支持在线扩缩容。
- 高可用：主节点故障时，从节点自动提升为主。
- 一致性：异步复制，默认最终一致；可通过WAIT命令实现强一致。
3.4.2 Memcached集群部署模式
- Deployment + Service：无状态设计，客户端一致性哈希路由。
- 无持久化：纯内存缓存，重启即丢失。
- 一致性：无复制机制，节点故障导致数据丢失。
- 性能：多线程架构，适合高吞吐量、低延迟的KV读取。
| 特性 | Redis Cluster | Memcached集群 |
|---|---|---|
| 数据持久化 | 支持RDB/AOF | 不支持 |
| 数据结构 | 丰富（String/List/Set/Sorted Set/Hash） | 仅KV |
| 复制机制 | 主从异步复制 | 无 |
| 扩缩容 | 在线reshard | 需客户端感知拓扑变化 |
| K8s部署复杂度 | 高（需Operator或Helm Chart） | 低（Deployment即可） |
3.5 三种缓存架构的协同关系图
下图展示了Pod内缓存、Sidecar缓存与分布式缓存在K8s集群中的层级关系与数据流向。
3.6 部署模式选择决策树
根据业务需求与性能目标，可按以下决策路径选择缓存部署模式：
- 数据是否跨Pod共享？
- 否 → 使用Pod内缓存（最低延迟，零网络开销）
- 是 → 进入下一步
- 是否需要独立于业务进程管理缓存？
- 是 → 使用Sidecar缓存（隔离性好，可独立扩缩）
- 否 → 进入下一步
- 数据量是否超过单Pod内存限制？
- 否 → Sidecar缓存 + 本地持久化
- 是 → 使用分布式缓存（Redis Cluster / Memcached）
- 一致性要求：
- 强一致 → Redis Cluster + WAIT命令 + 读写quorum
- 最终一致 → Memcached或Redis异步复制
性能调优建议：在K8s中部署Redis Cluster时，建议将Pod分散到不同可用区，使用反亲和性策略避免同一节点部署多个主节点。Memcached集群建议使用DaemonSet模式在每个Node上部署一个实例，配合客户端一致性哈希实现本地优先访问。
3.7 缓存一致性治理的初步思路
三种缓存架构共存时，一致性治理成为核心挑战。后续章节将深入讨论以下治理策略：
- 失效广播：通过消息队列（Kafka/NATS）广播缓存失效事件，所有Pod内缓存和Sidecar缓存订阅并清除本地条目。
- 版本号校验：缓存条目携带全局版本号，每次读取时与分布式缓存中的版本号对比，不一致则回源并更新。
- TTL分层：Pod内缓存TTL最短（秒级），Sidecar缓存TTL中等（分钟级），分布式缓存TTL最长（小时级），形成时间衰减的一致性保障。
本章为后续的缓存一致性治理与索引重构奠定了架构基础。理解三种缓存模式的部署特征与性能边界，是设计高性能、高一致K8s缓存系统的前提。