镜像分层缓存对拉取速度的核心作用，是让重复拉取同一镜像或共享基础镜像时只下载缺失层，多数场景下能把后续拉取时间压缩到首次拉取的很小一部分。 理解这个结论,先要看清镜像分层的工作方式。
镜像分层缓存对拉取速度有什么作用
容器镜像不是一个大文件，而是一层层堆叠起来的只读文件系统，每一层对应Dockerfile里的一条指令，比如RUN apt-get update、COPY app.jar，据Docker官方文档，这些层在构建完成后会被打上唯一的内容摘要，也就是digest，本地Docker守护进程和远程Registry都会按层存储和比对,而不是只认镜像名和标签。
拉取镜像时，客户端先拿manifest清单，清单里列出这个镜像所有层的digest，守护进程逐个检查本地是否已经有相同digest的层，命中就标记为Already exists，不产生实际下载流量，只有本地缺失的层才会进入Downloading状态。
这种机制对拉取速度的作用主要体现在四个方面：
- 只下载变更层：同一个应用多次发布，如果只是最后业务代码层变了，基础镜像层、依赖层、配置层都走缓存,实际下载量可能只有几兆到几十兆。
- 跨镜像复用基础层：
nginx:1.25和nginx:1.26的底层操作系统层可能完全相同，拉取过其中一个,再拉另一个时共享层直接复用。 - 并发拉取多个层：缺失的多个层可以并行下载，而不是一个完整文件从头下到尾，网络质量越好,并发收益越明显。
- 减少Registry出口压力：私有仓库和公共仓库都能少吐数据，节点响应更快,间接提升拉取速度。
用一个场景概括：你在测试环境已经拉取过openjdk:17-slim，生产环境要拉取基于同样基础镜像的业务镜像，第二次拉取时，基础镜像那几十到上百兆的数据基本不用再下,真正下载的是业务新增的那几层。
Docker镜像分层缓存拉取慢怎么解决
拉取慢不等于缓存完全没起作用，常见原因是缓存命中率低、单层体积过大、镜像层数过多，或者网络到Registry本身延迟高,下面按实操路径拆解。
第一步：确认哪些层命中了缓存
在Linux服务器上执行：
docker pull your-registry.example.com/app:latest
观察输出状态：
Already exists：该层本地已有,走缓存。Pull complete：没有缓存,但下载完成。Downloading：正在下载,通常对应缺失层。
如果大量层显示Downloading，说明本地缓存没被利用，可以检查镜像是否频繁更换基础镜像,或者CI构建时是否清空了本地缓存。
第二步：构建时让层顺序更稳定
Dockerfile里变化越频繁的内容越要放后面。
FROM openjdk:17-slim WORKDIR /app COPY pom.xml . RUN mvn dependency:resolve COPY src ./src RUN mvn package
依赖层和源码层分离后，只改业务代码时，前面依赖层不会重新生成，构建和后续拉取都能复用缓存，相反的写法会让几乎每一层都变化,缓存形同虚设。
第三步：配置国内镜像加速器
如果你在国内服务器拉取Docker Hub镜像，网络到海外Registry的延迟往往比缓存本身更影响速度,配置加速器是成本最低的优化。
编辑/etc/docker/daemon.json：
{
"registry-mirrors": [
"https://mirror.ccs.tencentyun.com",
"https://docker.m.daocloud.io"
]
}
然后执行：
systemctl daemon-reload systemctl restart docker
再次拉取公共镜像时，会先从国内镜像节点获取，减少跨国网络波动，这个地址只是常见示例,实际可用性需要结合你的云厂商和地域测试。
第四步：拉取前预热基础镜像
对于生产节点,可以在业务发布前主动拉取一次基础镜像。
docker pull openjdk:17-slim docker pull nginx:1.25-alpine
等真实镜像到达时，基础层已经在本地，拉取速度会明显加快,这个操作也适合放在节点初始化脚本里。
镜像分层缓存和普通缓存区别在哪
很多人把镜像分层缓存和普通文件缓存混为一谈,实际机制差别很大。
普通缓存通常以完整文件、完整镜像包或URL响应为粒度，比如你缓存了一个ubuntu.tar，下次请求同一文件时直接返回整个包，只要镜像标签没变，就可能复用完整包，缺点是底层系统只是一个小版本升级,完整包也要重新缓存。
镜像分层缓存以只读层为粒度，一个镜像拆成几十层，每层独立寻址、独立缓存，更新依赖时只有依赖层失效，操作系统层、运行时层继续命中,两者的关键差异如下表：
| 对比维度 | 普通缓存 | 镜像分层缓存 |
|---|---|---|
| 缓存粒度 | 完整镜像或文件 | 单层只读文件系统 |
| 命中条件 | 标签或URL一致 | 层digest一致 |
| 基础镜像复用 | 通常不感知 | 跨镜像自动复用 |
| 增量更新效果 | 较弱 | 只下载变化层 |
| 存储开销 | 容易出现重复 | 内容寻址去重 |
简单说，普通缓存解决“同一个东西别下两遍”，镜像分层缓存解决“没变的部分别下两遍”，后者更适合容器镜像这种动辄几百兆、层结构稳定的对象。
国内拉取Docker镜像慢怎么办
国内环境拉取慢，很多时候不是分层缓存逻辑失效，而是网络链路长、Registry节点远，分层缓存仍然能在第二次拉取时发挥作用,但第一次拉取慢的问题需要从网络侧解决。
选择地域就近的Registry
如果你用的是云厂商容器镜像服务，把镜像仓库和业务集群放在同一地域，比如集群在华南，仓库也选择华南节点,跨地域拉取会产生公网流量和额外延迟。
搭建私有Registry缓存代理
企业内网可以部署Harbor或Docker Registry作为缓存代理，配置上游为Docker Hub，内网节点统一从Harbor拉取，第一次某个镜像经过Harbor时缓存到内网，后续所有节点拉取都走局域网，速度提升非常直接，Harbor的代理缓存项目可以按需开启,并设置缓存过期策略。
提前规划基础镜像版本
基础镜像版本越稳定，分层缓存收益越大，频繁从ubuntu:20.04换到ubuntu:22.04再换到debian:bookworm，会导致底层缓存反复失效，尽量在项目启动时确定基础镜像系列,后续只更新安全补丁层。
镜像分层缓存多久更新一次
镜像分层缓存没有固定的过期时间，它由内容寻址驱动，只要某一层的digest没变，本地和Registry就会持续复用这一层，只有当镜像重新构建、层内容发生变化或存储驱动发生切换时,对应层才会被识别为新层并重新下载。
本地层面，Docker会在存储空间不足时清理未被引用的层，Registry层面，管理员可以配置缓存代理的过期策略，例如Harbor支持按天或按容量清理代理缓存，日常使用中，你不需要手动更新缓存，但需要避免无意义的镜像重建，否则层digest会频繁变化,缓存命中率随之下降。
镜像分层缓存能加快多少拉取速度
这个问题的答案取决于层复用比例和网络环境,不能用一个固定数字概括。
首次拉取一个几百兆的镜像，缓存不会帮你，第二次拉取，如果只有业务层变了几兆大小，理论流量就是几兆左右，其余层走本地缓存，网络传输时间可能缩短到首次的很小一部分，但在层复用比例低的情况下，比如基础镜像更换、构建参数变动导致所有层digest改变,缓存收益就会很小。
影响缓存收益的还有单层体积，一个RUN apt-get install可能生成几百兆的层，即使其他层都复用，这一层也会拖慢拉取，控制单层体积、使用多阶段构建、清理包管理器缓存,都能提高分层缓存的整体收益。
镜像分层缓存不是万能加速器，但它把“重复下载没变的部分”这个动作从流程里拿掉了，稳定基础镜像、控制层顺序、配置就近缓存代理,分层缓存就能把拉取速度拉到接近网络链路上限。
镜像分层缓存对拉取速度的常见问题
为什么镜像分层缓存有时候不生效？
多数情况下是因为层digest变了，哪怕同一命令的输出不一致、文件时间戳变化、构建上下文不同，都可能导致层digest变化，比如COPY . .会把本地所有文件打进一层，只要一个文件改动，整层失效，解决方法是把稳定文件先拷贝，把易变文件放最后，如果Docker守护进程配置了--no-cache构建，或者拉取时使用了不同的存储驱动,也会影响缓存表现。
镜像分层缓存能减少多少带宽消耗？
带宽消耗的减少量取决于复用层的大小，如果基础镜像占镜像总大小的较大比例，后续拉取就能省下相当一部分带宽，对于每天大量拉取相同基础镜像的集群，分层缓存和内网缓存代理叠加使用,出口带宽压力会明显下降。
国内生产环境怎么利用镜像分层缓存加速拉取？
生产环境应把镜像仓库放在集群同地域，节点初始化时预热基础镜像，并通过Harbor等内网代理缓存公共镜像，业务镜像构建时保持基础镜像版本稳定，把变化频繁的层放在Dockerfile最后，这样分层缓存命中率最高，即使偶发需要回源,也只需要回源少量变化层。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/642013.html
