3、缓存架构基础：本地缓存、分布式缓存、Registry缓存、CDN缓存的工作原理

容器镜像缓存命中率低，根源往往不在单一环节，而是整个缓存链路的设计缺陷。理解每一层缓存的工作原理，是定位瓶颈、制定优化策略的前提。本章从最靠近拉取端的本地缓存开始，逐层向上剖析至CDN边缘，构建完整的缓存知识图谱。

3.1 四层缓存体系总览

容器镜像拉取路径中，缓存按距离与粒度分为四个层级。下表从核心机制、典型实现、失效场景三个维度进行对比：

3.2 本地缓存：节点级的第一道防线

本地缓存是容器运行时（如containerd）在节点磁盘上维护的镜像层（Layer）与清单（Manifest）的副本。其工作原理遵循“写时缓存、按需拉取”原则：

• 存储结构： 每个镜像层以Content-Addressable方式存储，地址为SHA256摘要。containerd使用content store管理Blob，使用metadata store管理Manifest与索引。
• 命中判定： 拉取镜像时，运行时首先检查本地/var/lib/containerd/io.containerd.content.v1.content下是否存在对应摘要的Blob。若存在且未过期，则直接复用。
• 失效机制： 本地缓存受GC策略控制。默认情况下，containerd的GC会清理未被任何镜像引用的Blob。当磁盘使用率超过阈值（如80%）时，GC会强制回收最旧的未使用层。

# containerd 本地缓存GC配置示例（/etc/containerd/config.toml）
[plugins."io.containerd.gc.v1.scheduler"]
  pause_threshold = 0.02          # GC暂停阈值
  deletion_threshold = 0.05       # 删除阈值
  mutation_threshold = 100        # 突变阈值
  schedule_delay = "0s"           # 调度延迟
  startup_delay = "100ms"         # 启动延迟

3.3 分布式缓存：集群内的共享加速层

当本地缓存未命中时，请求进入分布式缓存层。这一层的核心目标是避免每个节点都回源Registry，通过P2P或代理缓存实现集群内共享。

以Dragonfly为例，其工作原理分为三个阶段：

1. 调度阶段： 客户端（dfget）向Scheduler注册下载任务。Scheduler根据集群拓扑与负载，分配最优的Peer节点作为种子。
2. 回源阶段： 若集群内无任何节点缓存该层，则第一个Peer回源Registry下载完整Blob，同时将数据分片（Piece）广播给其他Peer。
3. P2P分发阶段： 后续Peer从多个已缓存节点并行拉取不同Piece，最后在本地重组为完整Blob。每个节点既是消费者也是提供者。

3.4 Registry缓存：仓库层的存储与索引

Registry缓存是镜像仓库（如Harbor、Docker Registry）自身的存储层。它负责持久化存储所有镜像Blob与Manifest，并提供高效的拉取接口。

其核心工作原理包含三个组件：

• Blob存储： 通常使用对象存储（S3、GCS、MinIO）或本地文件系统。每个Blob以sha256:<digest>为键存储，支持Content-Addressable寻址。
• Manifest索引： Registry维护一个数据库（如PostgreSQL、MySQL），记录每个镜像Tag与Manifest Digest的映射关系。拉取时先查索引，再根据Digest获取Manifest。
• GC与清理： Registry定期执行Garbage Collection，删除未被任何Manifest引用的Blob。若GC策略过于激进，可能导致缓存层频繁回源。

# Harbor Registry 存储配置示例（harbor.yml）
storage:
  filesystem:
    rootdir: /data/registry
  cache:
    layerinfo: redis          # 使用Redis缓存层信息
    blobdescriptor: redis     # 使用Redis缓存Blob描述符
  maintenance:
    uploadpurging:
      enabled: true
      age: 168h               # 清理超过7天的未完成上传
    garbagecollection:
      enabled: true
      workers: 3

3.5 CDN缓存：边缘节点的静态资源加速

CDN缓存位于整个链路的最远端，负责将镜像层缓存到离用户（Kubernetes节点）最近的边缘节点。其工作原理基于“预热+回源”模型：

• 预热机制： 运维人员通过API或自动化工具，将常用镜像层主动推送到CDN边缘节点。预热后的层在TTL内直接命中，无需回源。
• 回源策略： 当边缘节点未缓存请求的层时，CDN会向源站（Registry）发起回源请求。回源路径通常经过CDN的L2缓存层，避免直接穿透到Registry。
• 缓存失效： CDN基于URL（如/v2/<name>/blobs/<digest>）和HTTP头（如Cache-Control）判断缓存是否有效。镜像层通常设置为不可变（Immutable），因此TTL可以设置得很长（如30天）。

3.6 四层缓存的协同与瓶颈

理解各层缓存的工作原理后，需要从全局视角审视它们的协同关系。以下表格总结了每层缓存的核心瓶颈与优化方向：