硅谷这条线的硬盘为什么每档翻倍：数据要不要跟计算放在同一台机器上

别的页硬盘几十 G 不动，这一页 40→80→160→320

翻产品页翻多了会有个错觉：硬盘这个字段是最不值钱的一项，随便给个三四十 G，升档的时候加一点意思意思，有些页甚至会出现倒挂——高配的内存翻倍了，硬盘还停在原处，或者干脆四档共用一个容量。这种页的潜台词是"机器给你用，数据你自己找地方放"。

美国硅谷云服务器这一页不是这个写法。A 型 40G，B 型 80G，C 型 160G，D 型 320G，一档一倍，四档走完正好是八倍。同样的页面里，端口字段四档全写 100M，一个字没动；流量是 2T、3T、4T、5T，每升一档加 1T，是等差；内存 2G、4G、8G、16G 跟着 CPU 往上抬。三个字段摆在一起看，只有硬盘是等比跳的。

硬盘字段之所以值得单独拎出来看，是因为它是唯一一项"买了就占着、不用也退不掉"的资源。CPU 不够会体现在响应变慢上，内存不够会体现在进程被杀上，这两样你很快能感觉到。硬盘不够只有写满那一天才会出事，而在写满之前，多出来的空间不会给你任何回报——它只是安静地空着，并且一直在你的月费里。硬盘写满之后又会突然变得非常麻烦：构建开始失败、数据库拒绝写入、日志直接丢弃，全都是业务可见的故障。所以这个字段的特点是平时没感觉、出事很突然，估容量的时候必须往宽里估，但也不用为了"以防万一"多跳两档。

等比和等差放在一起不是排版问题，是产品取向问题。这条线在卖的不只是"更大的机器"，还有"更大的机器旁边那块更大的本地数据位"。所以看这一页的时候，判断顺序得反过来：先问你的数据到底在哪，再决定要不要为硬盘这档多付钱。

把字段逐个拆开，硬盘是唯一跳跃的那一项

先把能读到的东西摆平。A 型 CPU 1 核、内存 2G、硬盘 40G、带宽 100M、流量 2T，￥150 元/月；B 型 2 核 4G、80G、100M、3T，￥280 元/月；C 型 4 核 8G、160G、100M、4T，￥550 元/月；D 型 6 核 16G、320G、100M、5T，￥1000 元/月。价格单位就是元/月，页面上没写"起"字。

端口恒定 100M 这件事，说明这条线不靠带宽拉档位。四档机器接的是同一根粗细的水管，区别只在流量额度，而流量额度是每档加 1T 的线性增长。换句话说，如果你买它是为了"出口更大"，那四档里没有一档能给你更大的出口，只有更长的额度。

内存这边，1C2G、2C4G、4C8G 是规整的，到 D 型 6 核 16G 又多给了一截，比单纯按核数配比要宽。内存给得松一点，通常是给"要在本机跑的东西"留的——数据库缓冲、构建进程、容器运行时，都是吃内存不怎么吃出口的活。

真正跳的是硬盘。40G 到 80G 是翻倍，80G 到 160G 是翻倍，160G 到 320G 还是翻倍。价格这边，档间差分别是 130 元、270 元、450 元，越往上差价越大，而硬盘恰好也在往上翻。这两条曲线是对齐的：你往上升档时多付的钱里，有一部分明确是付给硬盘的，不是全给了 CPU。

于是问题就落到一句大白话上：你是在买"更大的机器"，还是在买"更大的本地盘"？如果是前者，这一页的档位曲线对你有点浪费；如果是后者，这条线才算对上了你的负载。

先分清数据在哪：留在本机，还是本来就在远端

本地盘值不值钱，跟机器大小没关系，只跟"数据是不是必须待在计算旁边"有关系。按这个口径，业务能分成两类，而且分界线很干净。

第一类，数据本来就在远端。业务数据放在对象存储里，主库用的是托管数据库，静态资源交给 CDN 回源，机器本身只是个跑程序的壳。这种部署下，本地盘装的是操作系统、语言运行时、几份配置和一堆临时文件，撑死几十 G，哪怕你跑到 D 型，320G 里也有两百多 G 是空的。给这类业务升档换硬盘，等于花钱买一块不会写满的盘。

第二类，数据就留在本机。数据库文件躺在本地目录，构建产物和依赖缓存堆在本地，镜像层存在本地，日志按要求先在本地留存一段时间再归档。这类业务里硬盘是真消耗品，容量是会被吃掉的，而且吃掉之后很难退回来——镜像层不清理只增不减，构建缓存越攒越大，日志到归档窗口之前不能删。

第二类还可以再往下切一刀，切成"必须在本机"和"放远端也能跑，只是要付代价"两种。真正硬性的只有数据库这一类：数据库文件的读写路径经不起再绕一层网络，一致性语义也不允许中间多一个不可控的环节。剩下的构建缓存、镜像层、日志留痕，严格说都能搬到远端对象存储，代价是要多搬几次、多花时间、多走流量。这一刀切下去，本地盘的刚需边界就清楚了：凡是"可以放远端，但放远端要付网络代价或时间代价"的数据，才是本地盘真正的服务对象。

硬盘买大之后，跟着变的不只是容量

很多人只把硬盘当成一个"能不能装下"的容器，其实容量往上走的时候，另外几件事会一起变，这些变化不算优点也不算缺点，但会影响你怎么用它。

第一件是备份与快照的开销。备份要读的数据量跟盘上的实际数据量走，盘越大、堆得越久，一次全量备份要搬的东西就越多，占用的时间和流量也越多。本地数据库尤其明显：数据量翻一倍，备份窗口通常也跟着拉长，而备份产生的出向流量会落在这条线的 2T、3T、4T、5T 额度上。也就是说，硬盘变大之后，你的备份流量账也要重算一遍，别只盯着容量那一行。

第二件是整机迁移和重建的时间。机器上的数据越多，换机器、重装系统、从备份恢复的过程就越久。本地盘小的机器，重装一遍系统、从远端把数据拉回来，可能十几分钟就恢复服务；本地盘堆了几百 G 的机器，同样的动作要按小时算。这笔账在"要不要把数据放本机"这个决定里占的比重不小——你把数据放在本机，等于也把重建时间绑在了本机上。

第三件是清理纪律会变差，这点很现实。空间宽裕了，就没人对镜像层做垃圾回收，没人清理过期的构建产物，没人压缩历史日志。于是占用会一路涨到一个你没预料到的位置，然后在某天突然撞上上限。反过来，空间紧一点反而逼着你把清理流程做进日常。所以在容量之外，最好一开始就把保留策略定下来：构建缓存保留多少天，镜像层保留几个版本，日志在本地留存多久后归档。策略定下来，容量才估得准。

第四件是容量和流量之间的替代关系会变。数据放本地，占用的是硬盘，省的是重复拉取的流量；数据放远端，占用的是流量，省的是硬盘。这条线的硬盘是每档翻倍、流量是每档加 1T，两条曲线的斜率差得很远，于是"哪种更划算"没有固定答案，完全取决于你的数据是存着不动，还是被反复读。判断方法很简单：数一遍同一份数据在一个月里被完整读了多少次，次数多就往本地放，次数少就往远端放。

哪几种负载真的会把本地盘吃掉

说回具体活儿。四类负载会把这一页的硬盘字段真正用起来，它们的共同点是"数据被反复读，而且读的次数远多于写的次数"。

第一类是本地数据库。单机 MySQL、PostgreSQL 主实例，或者带本地数据副本的只读库，数据文件必须落在本机目录里。它的容量增长速度取决于你的表规模和 binlog、WAL 的留存策略，通常是缓慢但只增不减。这类负载对硬盘的需求是"确定且不可外挂"的，选档时硬盘字段必须留余量。

本地数据库还有一个容易被低估的占用来源：事务日志。binlog、WAL 这类文件是连续写入的，只有做过归档或清理才会释放，忘了设置保留策略的话，它会和数据文件一起把盘吃掉。所以给本地数据库估容量，公式不是"数据文件大小"，而是"数据文件大小 + 事务日志峰值 + 备份临时空间"。第三项经常被漏掉——本地做一次物理备份或逻辑导出，是要先在本机生成一份中间文件的，那份文件的大小就是数据文件的量级。

第二类是 CI 构建机与制品缓存。跑一次构建，依赖缓存、编译中间产物、打包出来的制品会一起堆在本地目录上。缓存这个东西的特性是：可以删，可以重建，但重建很贵。node_modules 重新装一遍要多久，Maven 或 Gradle 的本地仓库重新拉一遍要多久，Docker 构建层全部失效重跑一遍要多久——这些时间成本就是你留本地盘的理由。构建缓存的容量还跟并发项目数正相关，一个项目和一个团队十个项目，需要的空间不是一个量级。

构建缓存的容量还跟你要不要保多份并行有关。同一个项目如果有多个分支同时跑构建，各自的依赖树不一样，缓存就不能完全共用；如果还要保多个产物版本用于回滚，占用又是一份。所以"一个项目需要多少缓存空间"没有标准答案，得按"并行分支数 × 单份缓存大小 + 保留的产物版本数 × 单份产物大小"来算。算出来之后你会发现，团队规模上去以后，构建机的硬盘需求涨得比 CPU 需求快得多——这也是这一类负载值得为硬盘付钱的理由。

第三类是容器镜像仓库。镜像层是大块数据，拉取频繁，而且默认只增不减，不做垃圾回收就一直堆着。把镜像层放在本地的好处不是"更快"这个抽象的词，而是同一份数据不用每次都从远端搬一遍——它只搬一次，之后是本地读。反过来，如果镜像层全在远端对象存储里，每次冷启动都要重新拉，反复的次数一多，先见底的不是硬盘，是流量额度。

镜像层的容量估算要按"层"算，不能按"镜像"算。一个镜像由多层构成，改一行代码重新构建，只有变化的那几层是新的，其余层是复用的——这既是节省也是陷阱：节省在于共用层不重复占空间，陷阱在于每次构建都会留下若干悬空层，不做垃圾回收就一直堆着。所以镜像仓库的容量曲线通常是一条缓慢上台阶的线，每次构建抬高一点，垃圾回收之后掉下来一截。给这类负载选档，要按垃圾回收之前的最高峰来估，不是按清理之后的稳定值。

第四类是日志与审计留痕。有些场景要求日志先在本地留存一段时间再归档，本地盘就得撑到那个归档窗口结束。日志的特点是写入连续、总量可预测、峰值不好预测——一次异常重试就可能把日志量打上去。给这类负载估容量，得按峰值估，不能按平均值估。

这四类之外，还有一类容易被误判的：临时解包、临时转码、临时解压的中间目录。它确实占空间，但它是临时性的，跑完就删。为它升档是最亏的，因为你付的是长期的档位差价，换的是一个每天都会清零的目录。

数据在远端时，档位该怎么挑

如果你的数据已经在对象存储或托管数据库里，这一页的正确读法是：忽略硬盘字段，按 CPU 与内存选档。硬盘按"系统 + 运行时 + 临时目录的最大值"估就够了，几十 G 这个量级一般够用，A 型的 40G 放在这类负载上并不寒酸。

把系统侧的占用拆开算一遍会更踏实。操作系统本身占一部分，语言运行时和依赖包占一部分，容器运行时占一部分，镜像层解压后的目录占一部分，日志和临时文件占一部分，这几项加起来就是远端数据型业务的真实硬盘需求。它跟业务数据量无关，只跟你装了什么有关——同样的业务，装的东西精简一点和堆一堆调试工具，占用能差出好几倍。所以这一项的正确做法是列清单、逐项估，而不是拍一个数字。

按 CPU 与内存选的时候，价格曲线是这么走的：1 核 2G 是 ￥150 元/月，2 核 4G 是 ￥280 元/月，4 核 8G 是 ￥550 元/月，6 核 16G 是 ￥1000 元/月。你要的是几核几 G，就停在哪一档，不用为了硬盘多跳一级。这一条的收益很直接：同样是花 ￥550 元/月，你可以拿它买 4 核 8G 的计算能力，也可以拿它买 160G 的本地盘——对远端数据型业务来说，前一半值钱，后一半不值钱。

外挂之后有一笔账必须提前算：远端拉取走的是网络，会落在套餐流量额度上。这条线的流量是 2T、3T、4T、5T，每档加 1T，而硬盘是每档翻倍。两条曲线的斜率不一样，意味着越往上走，流量越可能先于硬盘见底。数据放远端省下的硬盘钱，有可能被流量额度吃掉一部分，尤其是镜像层、依赖包这种"同一份数据反复拉"的场景。

这也是本地盘真正值钱的地方，值得单独说一句：它不是让单次访问更快，而是让重复的搬运次数变少。同一份 1G 的镜像层，从远端拉十次就是 10G 流量，放在本地只搬一次。所以"数据在远端还是本地"这道选择题，很多时候其实是"你愿意付流量还是付硬盘"。

320G 这条上限之外该怎么办

四档走到底，硬盘停在 320G。这个数字对很多业务是够的，对另一些业务只是起点。判断方法很直接：把你"必须在本机"的数据峰值加上一年的增长量，看它是不是会越过 320G。如果会，靠升档是走不通的，因为升到 D 型就是这条线的顶了，再往上没有档位可跳。

越过上限之后的出路有三条，可以组合着用。第一条是把冷数据挪走：历史日志压缩后归档到远端对象存储，过期镜像层做垃圾回收，构建缓存按项目设保留期。多数业务做完这一步，本地占用会掉下来一大截，因为堆在本地的往往不是热数据，而是没人清理的旧数据。

第二条是拆职能。把数据库、构建机、镜像仓库、日志节点拆成不同的机器，各自按自己的容量需求选档，而不是让一台机器同时背四种数据。一台机器背四种数据的结果是：容量按四种之和估，CPU 也要按四种之和估，最后买到的配置每项都过剩。拆开之后，数据库那台吃硬盘、构建机那台吃 CPU、日志那台吃容量和流量，各自对得上，总价往往更稳。

第三条是换存储形态，把大块只读数据整体放到对象存储或托管服务上，本机只留索引和热副本。这条路要付的代价是延迟和流量——每一次读都要走网络，而且会算进出向流量额度。所以它适合"读的次数不多、单次数据量大"的数据，不适合"被反复读"的那部分。

顺带说一句容易被忽略的：这条线四档的端口都是 100M，不随档位变化。如果你的负载是大块数据频繁进出的类型，比如频繁从远端同步大文件、频繁拉取大镜像层，那么先卡住的很可能不是硬盘，而是这个端口。硬盘从 160G 升到 320G 不会让端口变粗，这点在规划时要分清楚。

升档之前要算清的几笔账

第一笔，数据峰值有多大，其中有多少是必须留在本机的。把系统占用、运行时、业务数据、临时目录四项分开估，别用一个总数糊弄过去。估完你会发现，很多业务的"必须在本机"部分其实只有几十 G。

第二笔，硬盘不够时能不能单独加。页面给出的是整档配置，硬盘是跟着档位走的，没有单独列出加盘这一项。能不能在不升档的前提下加一块盘，是采购前必须问清楚的事，不能默认能加，也不能默认不能加。问清楚之后，升档的必要性会变——如果加盘可行，"为了硬盘升到 C 型"这个理由就不成立了。

第三笔，档间差价里硬盘占多少。A 到 B 差 130 元，硬盘从 40G 到 80G；B 到 C 差 270 元，硬盘从 80G 到 160G；C 到 D 差 450 元，硬盘从 160G 到 320G。越往上，你为一个可能用不上的硬盘付的绝对金额越大。这笔账在 C 到 D 这一段最刺眼：450 元的差价里，硬盘从 160G 跳到 320G，而 CPU 只从 4 核到 6 核、内存从 8G 到 16G。如果你只想要那 2 核和 8G 内存，这 450 元里有一部分是为 160G 的增量空间买单的。

第四笔，重建成本。构建缓存全部失效要多久能跑回来，镜像层从远端重拉要占多少流量，数据库从备份恢复要多少时间。重建越贵，本地盘越像保险；重建很便宜，比如几分钟就能重新生成的东西，就没必要长期占着本地盘。这条是判断"该不该为硬盘付钱"最实用的一把尺子。

第五笔，端口与流量的天花板。四档端口都是 100M，这一条不会因为你升档而改变。数据放远端之后，读写都要过这个端口，如果你的负载是"大块数据频繁进出"型，端口这一项才是真正的约束，硬盘再大也帮不上忙。反过来，数据放本地的话，进出端口的只有对外服务流量，端口压力会小很多——这又是一条偏向本地盘的理由。

本地盘与外挂存储的几个具体问题

本地盘不够用了，能不能直接加一块？这一页能读到的是整档配置，硬盘容量是跟着档位走的，页面上没有单独列加盘这一项。能不能加、加多大、怎么计费，属于页面之外的口径，采购前要直接问清楚。在问清楚之前，别默认"不够就升一档"是唯一解——升档会把 CPU 和内存一起买上去，这些是你不一定需要的。

系统盘和数据盘要不要分开？从部署角度说，分开是对的：系统盘只装操作系统和运行时，数据盘放数据库文件、构建缓存、镜像层、日志。分开之后的好处是系统重装不影响数据，容量也能分别估算。但页面上给出的是一个硬盘容量字段，是否支持单独挂载数据盘、挂载后怎么计费，需要以官网口径和合同为准，不能照着别的产品线的习惯去推断。

远端对象存储的流量算不算在套餐流量里？一般来说，数据从远端拉到机器上，走的是网络出口，会算进这台机器的出向流量。这条线的流量额度是 2T、3T、4T、5T，每档加 1T，而硬盘是每档翻倍，两条曲线不同步。所以"把数据搬到远端省硬盘"这个动作，不是免费的，它把成本从硬盘挪到了流量上。要不要挪，取决于你的数据是"存着不动"还是"反复被读"——反复被读的数据放远端，往往是流量先扛不住。

数据库放在本地盘，备份怎么安排？本地盘的一个现实是：它跟着这台机器。机器上的任何操作影响到盘，数据就跟着受影响。所以本地数据库必须另行备份，备份落到远端对象存储或者另一台机器上，备份频率按你能接受的数据丢失窗口来定，不能接受丢就缩短间隔。备份本身会产生出向流量，这笔流量也要算进额度里。

镜像仓库该升档换硬盘，还是整体外挂？看拉取的重复程度。如果同一批镜像层每天被拉很多次、机器数量不多，放本地划算，因为它只搬一次；如果机器很多、每台都要拉，放远端对象存储统一管理更省事，代价是流量消耗上去。这条线 320G 的上限摆在那里，镜像层数量一旦过了这个量，本地盘就不是"要不要升档"的问题，而是必须外挂的问题。

日志留存类业务四档怎么挑？按归档窗口内的峰值总量估，不要按日均估。日均看起来很安全，一次异常重试、一次全量 dump 就能把当天日志打高好几倍。估出峰值之后，再留一部分余量给归档前的压缩和转存过程——压缩前的原始日志是要占满空间的。另外要注意日志的写入是连续的，它对硬盘的消耗方式跟镜像层不一样：镜像层是上台阶，日志是一条斜线，斜线型占用最怕的就是估算时忘了算增长，按当前量估的容量，通常撑不过半年。

构建缓存该不该做跨机器共享？构建缓存放在多台机器各自本地，好处是读取不走网络、不吃流量额度，坏处是同样的缓存要存多份，每台机器都要留出那部分空间。做共享缓存则相反：只存一份，但每次读取都要走网络并计入流量。机器少、构建频繁的场景，本地缓存更划算；机器多、缓存体量大的场景，共享缓存更省空间。这条线四档的流量额度是 2T、3T、4T、5T，如果走共享方案，记得把每天的缓存读取量乘上构建次数再乘天数，算出来的数字往往会超出直觉。

硅谷页硬盘翻倍的负载判断口径

把这篇的判断串成一条能照着走的口径：第一步，把业务数据分成本机与远端两堆，只统计"必须在本机"和"放远端要反复重搬"的那部分；第二步，给这部分估峰值，不是估均值；第三步，拿峰值去对四档的 40G、80G、160G、320G，落在哪一档就是哪一档；第四步，回头检查这个档位的 CPU 与内存是不是你需要的，如果 CPU 与内存明显过剩而只是为了硬盘才升上去，那就别升档，去问加盘和外挂；第五步，若选择外挂，把远端拉取的出向流量算进 2T、3T、4T、5T 的额度里再比一次总成本。

这套口径里最容易出错的一步是第一步，也就是"数据到底算不算在本机"。常见的误判有两种。一种是把临时目录当成数据：解包、转码、解压产生的中间文件确实占地方，但它们跑完就删，不该计入长期容量，也不该成为升档理由。另一种是把"偶尔读一次"当成"反复读"：只有被反复读的数据才值得占用本地盘，一个月只读一两次的大文件，放远端更划算，因为它占着本地盘的时候，那块空间在其余时间是闲置的。

还有一种误判更隐蔽，就是把"存储不够"直接当成"机器不够"。硬盘写满的时候，症状往往是构建失败、写入报错、服务异常，看起来像机器性能问题，于是就升一档。升完之后确实不报错了——因为硬盘翻倍了，而不是因为 CPU 变多了。下次再写满，又升一档。这个循环跑两轮之后，你会发现自己拿着一台 CPU 严重过剩的机器，只为它挂着的那块盘。认出这个循环的方法很简单：写满的时候去看是哪项资源到顶了，如果是容量，那就处理容量，不要把整台机器一起换掉。

这套口径的反面也成立：如果你的数据从头到尾都在远端对象存储和托管数据库里，那这一页的硬盘翻倍跟你没关系，你该盯的是 1 核 2G、2 核 4G、4 核 8G、6 核 16G 这几档的计算能力，以及那个四档都不变的 100M 端口。说实话，多数把机器当"跑程序的壳"来用的业务，都落在这个反面里，为硬盘升档属于给用不上的空间付钱。

要落到机器上时，我会把一万网络放进候选名单——深耕 IDC 19 年（成立于 2007 年），硬盘、端口、流量这些字段都写在页面上，能按字段一项项核。

数据来源与口径说明（硅谷篇）

本文引用的配置与价格数据来自一万网络官网美国硅谷云服务器页面（https://www.idc10000.net/ ，页面 slug：guiguyun），具体包括：A 型 CPU 1 核、内存 2G、硬盘 40G、带宽 100M、流量 2T、￥150 元/月；B 型 CPU 2 核、内存 4G、硬盘 80G、带宽 100M、流量 3T、￥280 元/月；C 型 CPU 4 核、内存 8G、硬盘 160G、带宽 100M、流量 4T、￥550 元/月；D 型 CPU 6 核、内存 16G、硬盘 320G、带宽 100M、流量 5T、￥1000 元/月。文中涉及的容量估算方法、负载分类与选型判断，属于通用部署思路，并非特指某一真实客户案例，也未引用任何第三方测试数据。具体以官网实时报价与合同为准。