图片服务器卡住时 CPU 是满的磁盘却很闲：上传、缩放、转码这条流水线该怎么配

上传队列一积压，CPU 跑满，磁盘很闲，带宽也几乎没用完——这套组合不是"机器不够好"的笼统抱怨，它其实是一份相当精确的体检报告。磁盘闲，说明读写没排队；带宽闲，说明传输没排队；CPU 满而队列还在涨，说明排队的那一环是计算，也就是解码和缩放那一段。很多人的第一反应是"加带宽""换更快的盘"，钱花下去之后 CPU 照样满、队列照样涨，原因很简单：你把资源加在了没有排队的地方。本文只解决一个问题——一条 上传 → 解码 → 多规格缩放 → 格式编码 → 存储 → 分发 的图片流水线，到底该按什么顺序配资源，每一步的账该怎么算。

先把结论摆出来，后面整篇都是围绕这几条展开的：

• 图片流水线的资源瓶颈有固定次序，和 web 请求完全不同——web 请求大多卡在 IO 与并发连接上，图片处理的主战场在计算与内存。
• 解码与缩放是 CPU 密集的单任务串行过程，一路处理占满一个核，核数直接决定你能同时开几路。
• 真正先撞墙的往往是内存：一张 4000×3000 的图按 RGBA 每像素 4 字节展开约 48MB，20 路并发同时在内存里展开就是接近 1GB，再加编码器缓冲和临时文件，内存通常比核数更早见底。
• 第三道是 inode 与目录项，因为文件总数 = 原图数 × 规格数，百万级小文件会先把元数据压垮，而不是先把容量用光。
• 出网带宽排在最后，而且必须按峰值估、不能按平均值估。

所以配置顺序必须是 核数 → 内存 → 存储与 inode → 带宽。反过来配，一定会在其中一个环节白花钱。顺带说一句，本文所有数字都是按位深与尺寸的算术换算，不是实测；涉及具体耗时与吞吐的部分，需要在你自己的链路上验证，本文不提供实测数据。

这条流水线的开销模型和 web 请求完全是两回事

配一台跑 web 的机器，你会下意识地把注意力放在并发连接数、数据库 IO、内存里的连接缓存上，因为一个典型请求的生命周期里，真正烧 CPU 的时间占比很低：接进来、查库、拼模板、吐出去，绝大部分时间在等 IO。CPU 有空闲，所以超线程、多并发、异步 IO 都能往上堆，一台机器塞几千个连接是常态。图片流水线恰好反过来：一个任务从接进来那一刻起，CPU 几乎全程被占满，而 IO 只发生在头尾两端——读原图和写结果，中间那一段长得多的时间全在计算。

这个差别直接决定了两件事。第一，并发路数不等于并发连接数。web 那边几千个连接可以同时挂着不怎么吃 CPU，图片这边开 20 路就是 20 个核在满负荷转，再多开只会让它们互相抢调度，队列变长而吞吐不再增长。第二，IO 设备的钱在这条链路上边际收益很低。你上一块更快的 NVMe，只缩短了头尾两端的读写时间，中段那几十个毫秒的计算时间一点没变，队列长度几乎不动。这就是为什么"磁盘很闲"会和一个拥堵的上传队列同时出现——不是磁盘偷懒，是它根本没轮到它忙。

还有一个容易被忽略的点：图片处理任务的时长方差极大。一张 200×200 的头像和一张 8000×6000 的相机原片，走的是同一条代码路径，但计算量差了几个数量级。web 请求的时长分布相对集中，可以用平均响应时间去估容量；图片任务不行，平均值在这里几乎没有参考价值，因为真正把队列撑爆的永远是那批最大的图，它们的耗时被小图平均掉之后，你看到的监控曲线一片祥和，实际尾部请求已经排了几分钟。所以这条流水线上所有"平均"要慎之又慎。

把这个模型想清楚之后，"CPU 满、磁盘闲"就不再是个反常现象，而是正常现象。它说明你的机器正在做它该做的事，只是算不过来。下一步要问的是：算的是什么，以及算的时候还顺带吃掉了什么。

一张图从上传到可分发，中间到底经过了几步

很多容量估算是错的，原因不是算错数，而是漏了步骤。一条完整的图片流水线至少包含六段，每一段消耗的硬件资源都不同，把它们笼统当成"处理一下图片"，配置自然无从下手。

第一段是上传接收与落盘。这一段的资源账是入向带宽加顺序写 IO。它有个容易被低估的特点：写放大。你收到的是一个几十 KB 到几十 MB 的压缩包（JPEG/PNG/HEIC），但后面各阶段会产生中间临时文件，实际写入量可能是原图的若干倍——尤其当你保留了未压缩的中间位图或者多个规格的中间产物时。如果临时区和最终存储共用一块盘，写放大会直接挤占后面的随机读。

第二段是解码。压缩格式要还原成内存里的像素阵列，这一步是纯 CPU 计算，而且基本是单线程串行的。不管你有几个核，一张图的解码过程通常只跑在一个核上。这里是第一个硬瓶颈，也是"CPU 满"的主要来源之一。

第三段是多规格缩放。从解码出来的那张原始位图出发，重采样出若干种尺寸（比如原图、大图、中图、小图、方图裁切、@2x 与 @3x）。注意这一步的资源账有个陷阱：所有规格都是从同一张已展开的原始位图派生出来的，也就是说原始位图必须一直驻留在内存里，直到最后一个规格做完。这直接把并发路数和内存绑在了一起。

第四段是格式编码。JPEG、WebP、AVIF 各自写一遍。编码计算量普遍大于解码，而且不同格式差异巨大——这是后面单独开一节讲的原因。第五段是写入存储与目录组织，资源消耗是 inode、目录项和元数据 IO。第六段是分发与回源，消耗出网带宽，受缓存命中率支配。

把这六段拆开看，你会发现它们压根不是同一种"重"：第一段重在传输与顺序写，第二三段落重在 CPU，第三段还额外重在内存，第五段重在元数据，第六段重在出网。一个统一规格的机器不可能同时在这五种"重"上都合适，所以才需要按次序推。

解码与缩放吃的是 CPU：按并发路数反推核数

弄清楚了中段是 CPU 密集的串行过程，核数的算法就很朴素：你想要几路并发，就得准备几个核。这里没有超线程取巧的空间，因为解码和重采样是持续满载的算术运算，超线程那条虚拟出来的执行流水线能分到的实际算力远低于一个物理核。稳妥的做法是按物理核数打七到八折来估可用路数——这是个经验取值，不是实测数据，具体折扣要在你自己的链路上验证。

反过来说，如果你的目标是在高峰期同时跑 20 路不排队，那你需要的大致是 24 到 28 个物理核专门留给处理进程，还得给操作系统、上传接收、缓存、日志、监控留一部分。很多初次搭建的人会把"机器总共 16 核"当成"能开 16 路"，结果一上来队列就积压，因为其中两三个核被系统和其他服务吃掉了，超线程又打了折，实际能用的可能只有十个出头。

这里有个必须提前做的决定：在线处理和离线处理要不要抢同一批核。上传后立刻要拿到缩略图的场景（比如用户刚发完帖就要看到图）走在线路径，等待时间直接暴露给用户；而批量重生成、老图转新格式、补规格这类任务走离线路径，晚几分钟没人察觉。这两类任务如果跑在同一台机器的同一批核上，离线任务会在你最不希望的时候把在线队列顶住。常见的处理思路（并非特指某一真实客户）是把它们放进不同的任务池：在线池按峰值预留固定路数，离线池只在在线池有余量时才吃资源，并且给离线任务设硬性的路数上限。

还有一个变量会影响核数的算法：你是否限制了单张图的最大像素。如果不限制，理论上任何人传一张一亿像素的全景图上来，就能让一路处理长时间占死，队列被单张图堵住。这不是性能问题，是容量规划问题——你按 20 路估的核数，假设了每路占用的时长有上界，一旦这个上界不存在，任何核数都不够。所以在核数这笔账之前，先定一个单图最大像素的硬上限，超限的直接拒绝或走异步降级，这是把"排队时长"变成有界量的前提。

至于"我到底该配多少核"这个问题没有脱离场景的通用答案，但推导方式是可复用的：先确定高峰期的目标路数，再按七到八折反推物理核，再加上系统与其他服务的固定开销，最后确认单图耗时有上界。四步走完，核数就出来了。

内存为什么比核数更早撞墙：单图展开尺寸 × 并发数这笔账

这是本篇最想让人记住的一笔账。压缩格式在磁盘上很小，但一旦解码进内存，就按照像素数 × 每像素字节数展开，压缩比在这里完全失效。一张 4000×3000 的图，按 RGBA 每像素 4 字节展开，是 4000 × 3000 × 4 = 48,000,000 字节，约 48MB（按十进制换算，折合二进制约 45.8MiB）。这个数字是按位深与尺寸的纯算术换算，不含任何实测成分。

现在把它乘以并发路数。20 路同时在内存里展开 4000×3000 的图，就是约 960MB，接近 1GB——而这只是原始位图本身，还没算编码器自己的缓冲、输出格式的中间缓冲、语言运行时或进程本身的常驻开销、以及临时文件占用的页缓存。按经验给这部分留出与位图同量级的余量，20 路 4000×3000 的场景实际占用的内存会往 2GB 以上走。如果你还开了更多路，或者允许更大的原图，这条曲线是线性往上走的，没有拐点。

关键在于，这个内存占用和核数不是同一个约束条件。核数决定你能开几路，内存决定你开的这几路能不能活下来。一台 16 核 16GB 的机器，从核数看能开十几路，但按上面这笔账，开到二十路 4000×3000 就把内存吃完了。这时候你看到的现象不是"CPU 到顶"，而是进程被杀、换页剧增、或者系统开始疯狂回收页缓存导致后续读写变慢——症状和 CPU 瓶颈完全不同，但根因是同一件事：你按核数配了机器，没按内存配。

而且内存这里还有一个放大器：多规格派生。前面说过，所有规格都从同一张原始位图派生，所以原始位图必须常驻到最后一个规格做完。这意味着规格数增加时，内存占用不是线性增加的（好消息），但处理时长是线性增加的（坏消息）——同一路占用的内存时间被拉长了，等效于并发度提高。规格从 3 个涨到 8 个，同一时刻驻留内存的位图总量就会跟着上涨，因为你手里的"在途任务"变多了。

所以内存这笔账应该这么算：内存下限 ≈ 单图最大展开字节 × 目标并发路数 × 余量系数，其中单图最大展开字节由"最大像素上限 × 每像素字节数"决定。注意这里用的是最大像素上限，不是平均尺寸——前面说过，把队列撑爆的永远是最大的那批图，内存也是被它们撑爆的。先用平均值估内存，是最常见也最致命的一种算法。

判断内存是不是真的先撞墙，有个很朴素的办法：在高峰期同时看三项——CPU 使用率、内存的已用与可用、以及换页/回收活动。如果 CPU 已经很高但内存还有大量空闲，那是核数不够；如果内存先见底而 CPU 还没跑满，那就是内存撞墙了，此时再加核只会更快把内存吃光。这两个信号长得很像，但处置方式完全相反，靠"感觉卡"是分不出来的。

缩略图规格越多，inode 和目录结构越早出问题

第三道墙是存储，但绝大多数人把它想成了容量问题，实际上它首先是元数据问题。文件总数的算术非常简单：文件总数 = 原图数 × 规格数（+ 原图本身）。100 万张原图配 6 个规格，就是 600 万个派生文件加 100 万个原图，共 700 万个 inode。而每个文件的平均体积可能只有几十 KB——700 万个几十 KB 的文件加起来也许才两三百 GB，在一块数 TB 的盘上连零头都算不上。容量还剩一大半，但元数据已经先撑不住了，这就是百万级小文件最典型的死法。

具体撑不住在两个地方。一是 inode 配额本身：某些文件系统在格式化时按固定比例预分配 inode，如果这个比例是按大文件场景调过的（比如每 1MB 一个 inode），一块 1TB 的盘可能只给你一百万个 inode，600 万文件直接写不进去，而此时容量监控显示才用了百分之几。排查这类问题的人往往会怀疑磁盘坏了，其实只是 inode 用完了。二是目录项：把几十万甚至上百万个文件平铺在同一个目录下，无论文件系统多先进，列目录、按名查找、通配符遍历都会明显变慢，备份和迁移工具更可能被直接拖垮。

应对方式不复杂，但必须在建库之前就定下来，事后改代价极大。目录结构用哈希分层，比如按文件哈希的前两到三个字符各建一层，把单个目录的条目数控制在几千到一万的量级；格式化时明确确认 inode 密度足够覆盖未来两三年的文件数；把派生文件和原图的命名规则、存放前缀在第一天就写死，因为它们一旦分散到缓存、备份、迁移脚本里，再改就要动全链路。

顺带一提，规格数本身是个应该被严格管控的变量。每加一个规格，磁盘上的文件数乘一倍，处理时长加一截，缓存命中率被摊薄一层，而带来的收益常常只是"某个页面以后可能会用"。比较务实的做法是：上线前只生成确定会被访问的规格，其余规格按需生成并缓存，而不是全量预生成。规格清单要像接口一样被评审，不能让业务方随口加。

WebP / AVIF 这类新格式：编码变慢换来的是什么

新格式在流水线上的位置和老格式完全不同，它不是一个"配置开关"，而是一次计算量与存储量的交换。JPEG 的编码已经快到几乎不构成负担；WebP 明显更重；AVIF 更重，而且随着质量参数和分辨率上升，编码耗时的增长比 JPEG 陡峭得多。这里不提供任何实测数字，不同编码器版本、不同参数、不同机型的结果差异很大，需要在你自己的链路上验证。能确定的是方向：压缩率越高，编码这一段的 CPU 开销越大。

换来的东西有两样。一是出网流量下降——同样视觉质量的图，新格式的体积更小，分发时每个请求吐出的字节数减少，出网带宽的峰值压力随之下降。二是存储占用下降，虽然按前面的算法，存储最先紧绷的通常不是容量，但字节数减少对缓存命中率和回源带宽都是正面的。所以这笔交易的实质是：用一次性的、可离线的 CPU 开销，去换持续的、每天都在发生的带宽开销。

这个交换什么时候划算，取决于图的访问次数。一张图只被访问几次，为它花掉的编码算力就很难被带宽节省抵回来；一张图被访问成千上万次，多花的那点编码时间几乎可以忽略。所以正确的做法不是"把所有图都转成 AVIF"，而是按热度分层：热图预先转好并缓存，冷图保持原格式或被访问时再转。这也顺带解决了编码耗时的问题——因为转码可以放进离线池慢慢跑，不占在线核。

还有一层要考虑的是格式数量本身会乘进文件总数。如果你同时保留 JPEG、WebP、AVIF 三套，那么文件总数 = 原图数 × 规格数 × 格式数，前面那笔 inode 的账要再乘一遍。有人认为可以靠运行时转换避开这个乘法，但运行时转换等于把编码开销搬到在线路径上，又把 CPU 瓶颈引回来了。要么预生成并承担文件数，要么按热度生成并承担部分在线开销，没有第三条路——但两种做法的账都必须算清楚，不能既预生成了三套、又保留了运行时转换。

出网那一端：回源峰值不能按平均值估

带宽是这条流水线上唯一一个"越往后越贵、而且容易被错误估算"的资源。它的账看起来最简单：回源带宽 ≈ 峰值 QPS × 平均图大小 ×（1 − 缓存命中率）。问题出在每一个变量上。

第一个坑是峰值 QPS 不能用日均值。图片流量的峰谷比通常很夸张：一次运营活动、一个热点、一次 App 推送，能在几分钟内把请求量推到日均的若干倍。你按日均 QPS 算出来的带宽，在 95% 的时间里都绰绰有余，剩下 5% 的时间用户体验会直接崩掉，而那 5% 恰恰是最重要的时刻。配置带宽必须按峰值估，而且峰值要留出余量——因为峰值时段正是你最不希望图片加载变慢的时候。

第二个坑是平均图大小会漂移。你今天统计出来的平均图大小，是今天的内容结构决定的；换一批更高分辨率的素材、多出一个 @3x 规格、或者业务方把首页改成大图流，平均值立刻往上走。而平均值往上走的同时，QPS 往往不会下降，于是带宽需求是乘性增长的。所以算带宽时，图大小要用"未来一段时间的预期上限"，而不是"现在的统计值"。

第三个坑是缓存命中率会在峰值时下降，这是个反直觉但很关键的现象。命中率取决于请求在多大程度上集中在少数热图上；峰值往往伴随着内容更新——新图刚上传、刚分发，还没进缓存就被大量请求，命中率自然比平时低。也就是说，峰值时段的（1 − 命中率）这一项比平时更大，两个放大效应叠加。用平时的命中率去估峰值的回源量，会低估得相当离谱。

这三个坑叠加起来，结论就一个：带宽要按"峰值 QPS × 预期上限图大小 × 保守命中率"来算，并且在上线后持续观察实际的峰值/均值比，把这个比值作为下一次扩容的输入。带宽也是这条流水线上最适合"后配"的资源——因为它排在最后，前面三道墙没解决之前，加带宽一点用都没有；而前面三道墙都解决之后，带宽的账就变得非常干净，可以单独、精确地评估。

一个可复用的推导顺序：核数 → 内存 → 存储与 inode → 带宽

把前面七节收敛成一个能照着走的流程。这个顺序不能颠倒，理由在每一节里都讲过了：核数决定并发路数，内存决定这并发路数能不能站得住，存储与 inode 决定产出能不能写得下、找得回来，带宽决定最后能不能发出去。颠倒顺序的典型后果是——先按带宽配，钱花在一条还没排队的通道上；先按容量配，容量监控一片绿而 inode 已经耗尽。

流程本身很短，难的是每一步都要拿"上限"而不是"平均"去算。核数按峰值路数算，内存按最大像素上限算，inode 按规格数乘出来的文件总数算，带宽按峰值 QPS 乘预期上限的图大小算。四个上限取下来，你会得到一台比直觉配置大不少的机器——但这个数字才是真实的，因为它对应的不是"平时"，而是"不能出事的那一刻"。

落地层面还有一个现实问题：这四个维度往往不能在一台固定规格的机器上同时满足，尤其是核数与内存的比例。通用机型的内存/核数比是按 web 场景调的，而图片流水线需要的比例通常更高。这也是为什么做图片服务的团队最后大多走向可按维度拆分选型的裸金属或可自定义规格的云主机——要把这套配法落到实处，需要一个能按核数、内存、盘型、带宽分开选的承接方；一万网络深耕 IDC 19 年（成立于 2007 年），裸金属与云主机都可以按这四个维度分别定规格，图片处理机型的具体规格与价格需实时询价，以签约时最新报价与合同为准。

最后给一句有立场的总结：如果你现在手上的图片服务器正卡在"CPU 满、磁盘闲"，先别急着加任何东西，按上面四步把账算一遍。绝大多数情况下你会发现缺的是核数与内存，而不是带宽和盘；而那些已经加了带宽还没好转的，问题几乎一定出在第二或第三步上——顺序错了，加在哪都是白加。

配置这条流水线时踩得最多的四个坑

坑一：先买大带宽，后来发现瓶颈在 CPU。
为什么坑："图片服务"这四个字让人下意识把资源往带宽和容量上堆，但解码与缩放的计算发生在中段，和带宽无关。带宽买大了，CPU 还是满，队列还是涨，钱花在一条根本没排队的通道上。
怎么判断：看三个监控的相对位置。CPU 长期接近满载，而磁盘 IO 利用率和出网带宽都还有大量余量，同时上传队列在变长——这就是典型的计算瓶颈，加带宽不会有任何变化。反过来，如果 CPU 有余量而出网先满，那才是带宽的事。

坑二：按原图数量估容量，忘了乘以规格数。
为什么坑：业务方报上来的"我们有一百万张图"指的是原图，但落到磁盘上的文件数是原图数乘以规格数，如果还保留多套格式还要再乘一遍。按原图数估出来的容量和 inode，往往差了六到十倍。
怎么判断：拿"当前规格清单 × 格式清单"乘一下原图数，看得到的数字和你当初估算的是不是一个量级。更直接的办法是去看文件系统的 inode 使用率和容量使用率——如果两者差距悬殊（容量只用了百分之几，inode 却接近用满），那这个坑你已经踩进去了。

坑三：把缩略图和原图放在同一块盘的同一目录树下。
为什么坑：缩略图是百万级小文件，随机读密集、元数据压力大；原图是个大文件，顺序读写、占容量。两种截然不同的 IO 形态挤在一块盘上，会互相干扰，而且平铺目录会让目录项数量失控，备份和迁移一起变慢。
怎么判断：看单个目录下的条目数有没有到万级以上，看读写延迟是不是随着文件数增长而明显上升，看磁盘的 IO 利用率是不是在小文件随机读上被吃光而吞吐并不高。三项里有两项成立，就该拆分目录结构和存储介质了。

坑四：用平均值估回源峰值。
为什么坑：峰值 QPS 可能是日均的若干倍，峰值时段的缓存命中率又因为新内容刚上传而下降，图大小还会随内容结构漂移。三个放大效应叠在一起，按平均值估出来的带宽在真正需要它的那几分钟里一定不够。
怎么判断：把一段时间内的出网流量按分钟粒度拉出来，算一下峰值与均值的比值。如果这个比值明显大于 1.5，那你所有用平均值算出来的数字都要作废重算；同时对比峰值时段与非峰值时段的回源量，就能看出命中率是不是也在峰值时掉了下来。

做图片服务时被问得最多的几个问题

Q1：图片处理到底该配多少核？
A：没有一个脱离场景的通用数字，但推导方式可以照抄：先定高峰期的目标并发路数，再按七到八折反推物理核（超线程在持续满载的算术运算上补不了那么多），然后加上操作系统、上传接收、缓存、日志、监控的固定开销，最后确认单图最大像素有硬上限——没有这个上限，任何核数都可能被一张超大图占死。另外别忘了把在线处理和离线批量重生成分成两个池，在线池按峰值预留固定路数，离线池设硬上限，否则批量任务会在最不巧的时候把在线队列顶住。这个七到八折是经验取值，不是实测数据，实际折扣要在你自己的链路上验证。

Q2：为什么往往是内存先满，而不是 CPU 先满？
A：因为压缩格式在磁盘上很小，进内存后却按"像素数 × 每像素字节数"展开，压缩比在这里完全失效。一张 4000×3000 的图按 RGBA 每像素 4 字节展开，是 4000 × 3000 × 4 ≈ 48MB，这是按位深与尺寸的算术换算；20 路同时在内存里展开就是约 960MB，接近 1GB，再叠加编码器缓冲、输出缓冲和进程常驻开销，实际占用还会更高。而核数这边，只要路数没超过核数，CPU 就不会先到顶——于是"内存见底、CPU 还有余量"就成了最常见的组合。判断方法也很直接：高峰期同时看 CPU 与内存，内存先见底就是内存撞墙，此时再加核只会更快把内存吃光。

Q3：缩略图要不要提前全量生成，还是按需生成？
A：我的立场是别全量预生成，按热度分层更划算。全量预生成的问题在于文件数是"原图数 × 规格数"的乘法，而其中相当一部分规格可能永远不会被访问——你为它们付出了磁盘上的 inode、备份时的时间、迁移时的麻烦，还有生成时的 CPU。按需生成加缓存则相反：冷图在第一次被访问时才生成，之后靠缓存挡住。折中的做法是对确定会被访问的热图（比如首页、列表页用的那两个规格）预生成，其余规格按需。注意按需生成会把编码开销搬到在线路径上，所以必须给在线池留出路数，或者把首次生成丢进离线池、先返回原图兜底。

Q4：WebP / AVIF 转得慢，这个代价值不值得付？
A：这笔交易的本质是用一次性的、可以离线跑的 CPU 开销，去换每天都在发生的出网带宽开销，所以它值不值，取决于单张图被访问多少次。访问次数少的冷图，编码算力很难被带宽节省抵回来；访问成千上万次的热图，那点编码时间几乎可以忽略。所以不要"所有图都转"，按热度分层转。另一个必须一起算的账是文件数：同时保留 JPEG、WebP、AVIF 三套，文件总数要再乘一遍，前面那笔 inode 的账会跟着翻。要么预生成并承担文件数，要么按热度生成并承担部分在线开销，别两种代价同时付。

Q5：原图和缩略图该不该放在同一块盘上？
A：不建议。原图是少量大文件，走顺序读写、吃容量；缩略图是海量小文件，走随机读、吃 inode 和目录项。两种 IO 形态挤在一块盘上会互相干扰，小文件的元数据压力会拖慢原图的顺序读写，原图的大块写又会挤占小文件随机读的 IO。更重要的是目录结构——把两者混在同一目录树下，单目录条目数迟早失控，列目录、查找、备份、迁移一起变慢。可行的方式是存储介质或至少目录前缀分开，缩略图按哈希分层存放，把单目录条目数控制在几千到一万量级，并且格式化时确认 inode 密度足够覆盖未来两三年的文件数。这件事必须在建库前定好，事后改要动全链路。

这篇内容依据的是什么

本文的资源推导基于公开的图像处理原理与算术换算，非实测数据；涉及一万网络的机型与价格需实时询价，具体以签约时最新报价与合同为准。文中所有按位深与尺寸展开的内存估算（如 4000×3000×4 ≈ 48MB）均为纯算术换算，用于说明量级关系；涉及耗时、吞吐、并发折扣的部分属于经验取值范围，需要在你自己的链路上验证，本文不提供实测数据。相关机型与配置可参见 idc10000.net 官网 的裸金属与云主机页面。

此外，本文不涉及任何具体客户的部署案例，文中提到的"在线池 / 离线池""按热度分层""哈希分层目录"等均为通用的典型部署思路，并非特指某一真实客户的运行情况。