去年底有个做供应链金融的团队找到我们，说他们的电子签平台出了个很别扭的故障：一份三方合同，第一方签完、第二方签完，到第三方点确认的那一瞬间，页面转圈，十几秒后报 502，刷新回来发现签署状态还停在"待第三方"。三个人里面两个人已经签了，却全部作废，因为最终 PDF 没有合成出来，存证链条断在最后一步。运维第一反应是 CPU 不够，加了核数，问题照旧；第二反应是带宽不够，换了出口，还是照旧。最后在应用日志里翻到一条内存相关的报错，才发现真正的问题在于合成那一刻把整份文档的所有页面、所有图层、所有嵌入字体一次性在内存里铺开，机器内存不够用了，进程被系统杀掉。
这类故障在电子签系统里非常典型，因为它跟我们平时调优的 Web 应用完全不是一个资源模型。普通业务系统的瓶颈通常在请求数、在数据库连接、在缓存命中率，压力是持续的、可平均的。电子签系统的压力是脉冲式的：绝大多数时间机器很闲，签署页面的渲染很轻，但每隔一段时间就会有一次合成动作，把内存顶到天花板，然后回落。按平均值买机器，一定会在这类尖峰上翻车。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。
这篇按 DocuSeal 的实际部署形态来拆：它是 Ruby on Rails 应用，数据库用 PostgreSQL，附件与签署件走 ActiveStorage，存储后端可以是本地磁盘也可以是对象存储。全文只讲这四类文件——模板、待签文档、最终签署件、审计日志——在磁盘和内存上怎么占地方，以及什么规模下该怎么配机器。所有资源数字都是公式型口径，具体到某个模板的耗用，需按压测确认。
把 DocuSeal 的签署流程拆开，其实是一条很清楚的文件流水线：模板定义字段 → 生成待签文档 → 各方签署 → 合成最终 PDF → 存证。表面上这是五个步骤，实际上是三次落盘加两次计算，理解这一点，资源配置的思路就顺了。
第一步是模板。模板是运营人员上传的底稿 PDF，加上在页面上拖出来的字段定义——签名位、日期位、文本框、勾选框，每个字段带坐标、尺寸、必填属性和签署方归属。模板本身是一份 PDF 加一份结构化的字段描述，字段描述存在 PostgreSQL 里。模板的特点是数量少、单份体积中等、几乎不删，一个中型平台跑三年，模板存量通常停留在几百到几千份的量级，因为它代表的是业务类型，不是业务笔数。
第二步是生成待签文档。当一笔签署任务发起时，系统按模板复制出一份待签件，把各方的字段位置渲染成可交互的表单，同时写入本次签署的元信息：谁签、什么顺序、什么时候到期。这份待签件是要落盘的，因为它要发给各方去打开，链接必须能稳定访问。注意这里有一个容易忽略的点：待签件的数量不等于签署任务数，因为一份多方合同在每一方手里可能是同一条记录的不同视图，也可能在部分流程里被复制出多份中间态。判断磁盘时按"签署任务数 × 平均中间态份数"来估，中间的倍数需按压测确认。
第三步是逐方签署。每一方提交签名后，系统记录这一次动作：签名图像、签署时间、来源 IP、浏览器标识、签署顺序。这些是审计日志的原料，逐条写库，单条很小，但笔数最多。这一步不产生大文件，却决定了后面审计日志的增长曲线。
第四步是合成最终 PDF。所有签署方完成后，系统把签名图像、时间戳水印、完成页说明按字段坐标压回原始 PDF 的对应位置，重新序列化输出一份终稿。这一步是全链路唯一的重计算环节，也是内存峰值出现的地方，后面单独讲。
第五步是存证。终稿落盘，同时把这一笔的审计记录做成可核验的存证材料：文件摘要、事件序列、时间戳。存证材料的价值在于事后能证明"这份文件从未被改过"，所以它必须跟终稿绑定在一起存，不能分开放、不能分开备。
五步里有三步要落盘，意味着磁盘不是"够用就行"的配角，而是这条链路的物理边界。有三步要依赖数据库事务，意味着 PostgreSQL 的写入可靠性直接决定签署动作能不能重放。链路中间任何一环失败，前面已经完成的签署都会变成悬空状态——就像开头那个案例，两个人签了，第三次合成失败，整笔作废重来。所以配置机器时要按链路里的最重一环来定，而不是按平均负载来定。
很多人第一次给电子签系统配机器，会把它当成一个文档上传下载服务来算：上传是流式的，边读边写盘，内存占用基本恒定；下载也是流式的，占的是连接数不是内存。按这个模型算出来的配置，往往在合成环节直接崩掉。
差别在于合成这件事没法流式做。要在一份 PDF 的指定坐标上盖章、写时间戳、插入签名图像，处理库需要把页面对象解析出来，把新的内容层合并进去，再重新生成页面树、交叉引用表和字体子集。页数越多，同时驻留的对象越多；图层越复杂，合并时的中间结构越大；嵌入的字体和矢量图越重，序列化时的缓冲区越大。这三个因素叠加，让内存占用跟页数之间不是简单的线性关系，而是明显往上翘的曲线。
还有一个常被低估的变量：签名图像的原始分辨率。手机拍照上传的签名照片动辄是几百万像素的 JPEG，如果在合成前没有统一压缩和缩放，每张签名图在解码后占的内存是文件体积的很多倍。一份六方合同、六个签名位、每个位放一张未压缩的高清照片，光图像解码就能吃掉相当可观的内存。这不是理论推演，是这类系统最常见的现场问题之一。
反过来说，一个常见的误判是"我们合同都很短，只有两三页，所以不用担心"。短文档确实省内存，但电子签系统里通常还有另一类文件：报价单附件、资质证明、银行开户资料，这些动辄几十页，而且经常被挂在同一个签署包里。判断内存需求时，要按"最长的那个模板"来算，而不是按平均值。行业内比较稳妥的做法是先取业务里最长的一类文档，取它的页数上限，再乘以一个随签署方数量增长的安全系数，这个系数具体取多少需按压测确认。
还有一个结构性判断：合成动作应该跟 Web 请求分开。如果把合成放在请求线程里同步执行，用户在页面上等着，超时时间一到连接就断了，可合成还在跑，最后的结果是钱花了、CPU 占了、用户还看到失败。正确做法是把合成扔进后台队列，请求立刻返回"处理中"，前端轮询或靠 webhook 回调拿结果。这个改动看起来小，但它把"用户等待"和"机器计算"解耦了，是电子签系统能不能扛住并发签署的分水岭。
给电子签系统算磁盘，最容易犯的错是把所有文件当成一类来估。实际上这四类文件的增长曲线完全不同，混在一起算，要么算大浪费钱，要么算小中途扩容。
模板是"台阶型"增长。业务不扩张的时候，模板存量几个月都不动；新上一个合同类型，一次加几份。它的特点是单份体积大（几十页的底稿很常见），但份数少、几乎不删。做容量规划时这部分可以直接按"业务类型数 × 单份平均体积"给一个固定基数，三年内基本不用再动。
待签件是"流水型"增长，而且是四类里最容易被算漏的。它的份数跟签署任务数正相关，单份体积跟模板相当。麻烦在于生命周期不整齐：正常流程里它在合成完成后就可以清理或者归档，但总有那么一批任务签了一半就停在那里——某一方离职了、某一方拖着不签、某一方要求改条款重新发起。这些僵尸任务会长期占着待签件，比例因行业而异，做预算时按 5% 到 15% 的滞留率给余量比较稳妥，具体比例要看自己的历史数据。另一个容易忽略的点是：如果业务里允许"撤回重签"，同一笔业务会产出多份待签件，份数要按"任务数 × 平均重发次数"来算。
最终签署件是"只增不减型"增长，也是磁盘的绝对大头。这份文件一旦生成就是证据，不能压缩到失真、不能删、不能改，只能按留存策略到期后归档到更便宜的介质。它的体积通常是四类里最大的：原始页面 + 压入的签名图层 + 完成页 + 时间戳信息。粗算口径是"月签署笔数 × 单份平均页数 × 每页平均体积（含图层与字体开销）"，再乘以留存年数。这个算法里三个变量都要用自己的历史数据代，任何一环用行业均值代都可能差出一倍，需按压测与实测样本确认。
审计日志是"条数型"增长。单条记录很小，就是几行结构化数据，但条数跟事件数成正比，而事件数比签署笔数多得多：一笔签署可能要记发起、打开、填写、上传、签名、完成、下载、撤回等十来个事件，多方合同还要乘以签署方数量。它的体积在头一年看起来微不足道，三五年后可能变成不可忽视的一块，尤其是当审计日志要做成不可篡改的追加存储、还要保留历史版本时。按"月签署笔数 × 每笔平均事件数 × 单条记录体积 × 12 × 留存年数"给口径，每笔事件数取自己系统的实际计数，不要拍脑袋。
四类文件加起来的容量，才是磁盘需求。但配置磁盘不能只按容量买，还要看访问模式：最终件是"写一次、读很多次"，适合放在对象存储或者带版本控制的存储桶；待签件是"短周期高频读写"，放在本地盘响应更快；审计日志是"只追加、顺序读"，对随机 IO 要求不高但对完整性要求极高；模板是"读多写少"，可以缓存。把这四种访问模式压到一块盘上，结果是互相拖累。
审计留痕这件事，行业里最常见的错误做法是"我们记了日志，所以有留痕"。记日志和可证明的留痕是两件事。前者只要往文件里写一行就行，后者要能在事后向第三方证明：这份文件从签署完成那一刻起，一个字节都没变过。
要做到这一点，工程上有三个动作是必须的。第一个是文件摘要。每一份最终签署件在生成的那一刻计算一次摘要，把摘要值连同这笔业务的主键一起写进审计记录。以后任何时候要验真，重新算一遍摘要、跟存档的值比，一致就说明文件没被动过。这一步的关键是摘要要在文件落盘之后、在被任何后处理接触之前计算，中间不能有别的环节插进来。
第二个是时间戳。摘要只能证明"内容一致"，证明不了"这个内容是什么时候产生的"。要让一份文件在时间上站得住，需要一个可信的时间来源，把摘要跟时间绑定。工程上的做法是记录可信时间服务的返回结果，并把它作为审计记录的一个字段一起存。这里不讨论具体法规对时间戳的效力要求，只讲设计方法：时间来源要外部、要可追溯、要跟摘要绑定在同一条记录里。
第三个是不可改。审计日志的存储层必须从架构上禁止修改和删除，而不是靠应用层自觉。可选的路径有几条：追加写的日志文件配合外部归档、带对象锁或者保留策略的对象存储、开启版本控制并禁止覆盖的存储桶。三条路径的共同点是"写入之后就没有修改这个动作"，只存在追加。应用层的代码再怎么写，也改不了已经封存的记录，这才叫不可篡改。反过来说，如果审计日志和应用日志写在同一个目录、同一个滚动策略下，应用日志一清理，审计记录跟着没了，这种设计在事后核查时是完全站不住的。
还有一个细节：审计日志的完整性本身也需要保护。如果攻击者能删掉一整条记录，那"没有记录"和"没有发生"就分不清了。常见的加固方式是链式摘要——每条记录里带上一条记录的摘要，形成一条链，中间断了一环就能被发现。这个做法不复杂，但在设计初期不做，后期补的代价很大，因为要重建整条链。
判断标准很简单：把服务器的时间改掉、把应用日志删掉、把存储桶里的对象覆盖一次，如果这三件事做完之后你的系统还拿不出"这份文件被改过"的证据，那这套留痕就不算成立。
电子签系统有一类故障特别隐蔽：签署页面没报错，数据库也没报错，但用户点完确认之后状态就是不更新，过一会儿再点又提示"已签署"，来回反复。查到最后发现，问题出在邮件服务器或者某个 webhook 接收端。
原因在于这两个外部依赖天然不可靠。邮件通知走 SMTP，要跟对方服务器握手、认证、投递，对方限流、灰名单、TLS 协商慢，都可能让这次调用挂在那里几十秒。webhook 回调是发给我们自己或者客户的业务系统，对方接口慢、对方在重启、对方的证书过期，同样会让调用长时间不返回。如果这些调用写在签署事务的同步路径里，事务就会被拖住，数据库连接被占着不释放，连接池很快耗尽，然后整个平台的签署功能一起变慢。这时候你看监控，CPU 不高、内存不高、磁盘不忙，但就是慢——因为瓶颈在等一个不属于你的服务器。
正确的结构是把这两个依赖都推到队列后面。签署事务只做三件事：校验权限、写入签署状态、投递一个任务。任务进队列之后立刻返回，用户看到"签署成功"。队列消费者再去发邮件、再回调 webhook，失败了按退避策略重试，重试次数要有上限，超过上限进死信队列并告警。
这里有三个参数必须配，而且经常被漏掉。一是超时。对外调用必须设连接超时和读取超时，不能依赖对方库的默认值，很多默认值是"无限等"。二是重试上限与退避。邮件投递失败重试是合理的，但无限重试会把队列越堆越长，最后拖慢的不是某一个任务，是整个队列的吞吐。三是幂等。webhook 回调可能被重投，接收端必须能识别重复事件，否则一次签署会在业务系统里生成两条记录。
还有一个反常识的判断：在这套系统里，队列的深度比队列的速度更值得盯。速度慢了，用户只是晚几分钟收到邮件；深度涨了，说明下游有东西在持续失败，等到队列占满内存或者占满磁盘，签署功能就会连带受影响。监控要盯的是"最老任务等了多久"，而不是"平均处理了多少条"。
下表的四档是按月签署笔数划分的，不是一个精确的分界线，而是一个配置思路的参照。每一档里的 CPU、内存、数据库、存储都是"起步口径"，实际采购要按自己的模板页数分布、签署方数量、留存年数三个变量做二次折算。前面说过，合成那一刻的内存峰值由最长文档决定，所以哪怕月签署量很小，只要业务里有超长文档，内存也不能按最低档配。
| 签署量档位 | CPU | 内存 | 数据库 | 存储留存与关键约束 |
|---|---|---|---|---|
| 月 100 份以内，单方或双方签署为主 | 4 至 8 核，合成与 Web 同机可接受 | 按最长模板页数折算，起步建议 8GB 起，需按压测确认 | PostgreSQL 与应用合置，本地盘 | ActiveStorage 走本地盘，四类文件同盘分目录；关键约束是备份必须覆盖最终件与审计日志 |
| 月 2000 份，多方合同占比上升 | 8 至 16 核，合成队列与 Web 分进程 | 按合成峰值内存乘以同时合成数，需按压测确认 | PostgreSQL 独立实例，连接池按队列消费者数核定 | 最终件转对象存储，待签件留本地盘；关键约束是审计日志独立留存路径 |
| 月 2 万份，多模板多签署方并行 | 16 核以上，合成节点可横向加，按队列积压扩容 | 按"单份峰值 × 并行合成数 × 安全系数"折算，需按压测确认 | PostgreSQL 独立机型，读写分离可选，审计表单独表空间 | 最终件与审计日志全部对象存储并开版本控制；关键约束是留存期倒推的容量上限 |
| 多租户 SaaS，按租户隔离留存 | 按租户并发合成数配，计算与 Web 分层部署 | 按最大单租户峰值乘以并发租户数，需按压测确认 | PostgreSQL 独立集群，按租户做逻辑隔离与配额 | 存储按租户前缀分区，留存策略按租户合同定制；关键约束是导出与迁移能力 |
表格里的"起步"两个字要理解准确：它假设你的文档页数在常规区间、签名图像做了统一压缩、合成在队列里异步执行。这三个前提缺一个，配置就要往上抬。特别是签名图像压缩这一条，很多平台在早期图省事，直接把上传的原图存下来，等到签署量上来，内存和磁盘一起吃不消。这种问题的修复成本很低，但要先被发现。
小规模阶段，把 Rails 应用、PostgreSQL、队列消费者全放在一台机器上，是最省钱的方案，也是完全合理的方案。合置的好处不只是省钱：网络往返是内存拷贝，没有跨机延迟，备份可以一次性做完，运维只有一台机器要看。月签署量在几百份量级、模板不超过二十个、最长文档不超过十页的场景，合置没有任何问题，不用为了"架构优雅"提前拆。
第一条拆分线是内存。当合成峰值内存已经逼近整机内存的一半，合置就不安全了，因为合成进程一旦超预期，会跟数据库抢内存，数据库被系统杀掉之后恢复要时间，而这段时间所有签署都停。判断口径很简单：把最长模板的合成峰值内存量出来，乘以你允许同时合成的数量，如果这个乘积超过物理内存的四成，就该考虑把合成单独放一台。
第二条拆分线是 IO。PostgreSQL 的写入模式是随机小写加周期性的检查点刷盘，合成输出是大块顺序写，两者在机械盘上会互相干扰，在 SATA SSD 上也会抢带宽。当你发现签署动作的响应时间随签署量上升而变差，但 CPU 和内存都还有余量，八成是 IO 在打架。这时候最有效的动作不是加 CPU，是把最终件的输出目录挪到另一块盘，或者干脆挪到对象存储。
第三条拆分线是留存与备份。当最终件和审计日志的总体积超过单机盘位能覆盖的范围，就必须把存储外挂出去。ActiveStorage 的好处在这里体现得很直接：本地磁盘和对象存储只是配置上的差别，业务代码不用改。所以从合置到外挂存储的迁移，成本主要在数据搬迁和一致性校验上，不在代码改造上。这个特性值得在项目初期就用上，哪怕一开始还指向本地盘。
有一个反向的判断也要说清楚：不是所有规模都该拆。见过月签署量一百多份的平台，把应用、数据库、存储拆成三台机器，结果备份要做三次、时间点对不齐、故障排查要跨三台看日志，运维成本远超省下来的那点资源。这种规模下，一台配置扎实的机器加上一块独立的数据盘，是更理性的选择。
电子签系统存的是合同，合同里往往带身份信息、金额、交易对手、履约条款。这类数据在选机房时不能只看性能和价格，还要看三个问题：数据物理上落在哪里、加密密钥由谁掌握、数据能不能完整导出。
第一个问题是法域。数据的物理位置决定了它受哪套规则约束，也决定了发生纠纷时谁有权要求提供。跨境业务常见的诉求是"数据留在境内"，这时候机房位置、存储桶区域、备份副本位置三处都要一致，只把主库放对地方、备份同步到境外，等于没做。多地域部署时，要明确哪一份是主副本、哪一份是备份、备份是否允许跨法域，这些要在架构图上写清楚，而不是留在口头约定里。
第二个问题是密钥。文件加密了但密钥跟文件放在同一台机器上，加密就只是防了"盘被单独拿走"这一种场景。更稳妥的分层是：文件内容用数据密钥加密，数据密钥用主密钥加密，主密钥放在独立的密钥管理服务里，访问需要授权并留痕。这样一来，即使存储层被完整拿走，没有主密钥也解不开。判断自己的方案够不够，可以问一句：如果运维拿到存储凭证，他能不能直接读出合同内容？能，就说明密钥分层没做到位。
第三个问题常被忽略：能不能导出。电子签平台一旦跑了三年，里面存着几万份合同，这时候如果供应商要换、或者业务要迁到自建系统，导出能力就成了硬约束。可导出的标准是"文件本体 + 元数据 + 审计日志 + 校验信息"四样齐全，只导出 PDF 是不够的，因为离开了审计日志，那些 PDF 就证明不了自己是原件。选型时把这一条写进合同，比事后补救便宜得多。
这三点都不涉及具体法规条文的适用判断，那是法务的事。工程侧要做的是把"数据在哪、钥匙在谁手里、能不能搬走"这三个事实做成可核查的配置项，而不是靠一句"我们很安全"。
备份这件事在电子签系统里有个特殊要求：最终签署件和它的审计日志必须是同一时刻的状态。如果出现"文件备份到了 10 点，日志备份到了 11 点"，恢复之后就会出现一批文件找不到对应的签署记录，或者一批记录指向不存在的文件。这种不一致在事后核查时是致命的，因为它意味着证据链本身有缺口。
做法上，数据库的逻辑备份要跟文件存储的快照对齐。具体路径是：先让存储层打一个快照（记录快照时间点），再导出一份数据库备份，把两个时间点记在同一个备份清单里。恢复时按清单同时还原，还原完做一次抽样校验——随机抽若干笔业务，检查文件摘要跟审计记录里的摘要是否一致。这个校验动作比备份本身更重要，因为备份能不能用，只有恢复过才知道。
快照不能替代逻辑备份，这一点要说清楚。快照解决的是"整机或整卷回到某个时刻"，逻辑备份解决的是"把数据搬到另一套环境"。前者应对误删和系统故障，后者应对迁移、升级和部分数据恢复。电子签系统的数据里有相当一部分是不可重建的，所以两条路径都要有，不能只做一条。
还有一个细节是保留梯度。最终件和审计日志都是长期留存对象，全量保留在高性能存储上，成本会随年份线性上升。比较务实的做法是做冷热分层：近一年的放高性能存储，随取随用；一到三年的转到低频存储；三年以上转到归档存储，取回要等一点时间但成本低很多。分层的前提是每一层的对象都要能独立校验，不能出现"归档里的文件取回来才发现损坏"的情况。归档前做一次全量摘要校验，这个动作不能省。
这八条里，前四条是配置问题，改起来快；后四条是设计问题，改起来要动数据模型和流程。选型阶段把后四条问清楚，比上线之后再补要省太多事。
同样是电子签，不同业务的资源画像差别很大，按一套配置套所有场景，总有一边不合适。
法务合同的特点是单份页数多、签署方多、留存期长。这类业务对内存的压力最大，因为长文档合成就是内存杀手；对磁盘的压力也最大，因为最终件体积大且不能删。配置上应该把内存给足，合成单独一台机器，存储直接上对象存储并开版本控制。CPU 反而不是重点，因为签署笔数通常不多。这类业务最不该省钱的地方是留存的冗余度，最该省钱的地方是 CPU 核数。
人力入职的特点是单份页数少、签署笔数多、集中在特定时点。招聘旺季一天几百份入职材料是常事，签署动作集中、合成动作密集、邮件通知量大。这类业务的瓶颈往往不在合成内存，而在队列吞吐和邮件投递。配置上要多给队列消费者，邮件通道要有独立的发送配额和退避策略，存储压力不大但要注意按员工生命周期做归档。这类业务最容易被低估的是邮件——几百封通知同时发，被对方邮件服务商标记成垃圾邮件，比机器不够更常见。
供应链对账的特点是附件多、单份文件不大但笔数稳定、审计要求细。这类业务里，主合同可能只有两三页，但附的发票、对账单、验收单加起来几十页，实际合成体积不小。同时它对审计留痕的要求往往最细，因为涉及金额争议，每一条状态变更都要能追溯。配置上要把审计日志的独立存储路径做好，把附件走对象存储，数据库的写入压力会比前两类都大。
判断自己的业务属于哪一类，看三个指标就够了：最长模板的页数、月签署笔数的波动幅度、单笔业务平均附件数量。这三个数决定了内存、队列和磁盘的配比，比任何通用建议都准。
电子签平台的容量规划有个特点：它的负载不是平滑增长的，而是随业务签约节奏波动——季度末、年末、大客户集中签约的时段，签署量可能是平峰的几倍。按峰值买机器，一年里有大半年在浪费；按平峰买机器，一到旺季就出故障。比较务实的路径是分阶段扩容，每次扩容解决一个明确的瓶颈。
第一次扩容通常发生在月签署量破千的时候，要解决的瓶颈是"合成和 Web 抢资源"。动作是把合成挪到独立的进程组或者独立机器，给合成设明确的内存上限和并发数，超出的任务在队列里等。这次扩容不需要买很贵的机器，一台中等配置就够，重点是隔离而不是性能。
第二次扩容通常发生在月签署量破万的时候，要解决的瓶颈是"存储和备份"。动作是把最终件和审计日志迁到对象存储，本地盘只留待签件和临时文件；同时把备份策略从"整机快照"改成"数据库逻辑备份 + 存储版本化"。这次扩容的收益不只是容量，还包括恢复速度——从对象存储恢复一批文件，比从一台机器的盘上拷要快得多，也不受单机盘位限制。
第三次扩容通常发生在多租户或者月签署量破两万的时候，要解决的瓶颈是"数据库写入"。动作是 PostgreSQL 独立机型、审计表单独表空间、按租户做配额。到这一步，架构上已经不太可能回到合置了，因为数据量和写入模式都不允许。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付，签署件的存储规格与留存盘位以官网实时信息或咨询确认为准。
三次扩容的节奏不用卡得很死，判断依据是三个监控指标：合成队列的最老任务等待时长、数据库的写入等待、存储的月度增量。这三个指标里任何一个开始持续上升，就是该做下一次扩容的信号，不用等到用户投诉。机器的具体配置和带宽规格属于参考预算范畴，需要按实际压测结果询价，任何脱离压测的报价都不可靠。
回到开头那份三方合同。它的失败不是因为机器不行，是因为配置逻辑错了：把合成当成了一次普通的文件处理，按平均值给了内存，而合成恰恰是全链路里唯一一个"必须把整份文档铺在内存里"的动作。上传可以流式，下载可以流式，邮件可以排队，唯独合成不行——它要读原文档、要合并图层、要重新序列化页面树，这些中间结构都得同时存在。
所以给这类系统配内存的正确顺序是倒着来的：先量出最长模板的合成峰值，再乘以你允许同时合成的份数，再加上数据库和队列的常驻占用，最后留出余量。这个算法里最容易被跳过的是第一步——很多人根本没有量过自己最长文档的合成峰值是多少，就直接按"合同都不大"给了配置。量一次的成本很低，在测试环境跑一份最长模板、看着内存曲线走一遍就行，需按压测确认。
还有一个结构性建议：合成进程要有硬性的内存上限和失败处理。上限的意义不是限制业务，而是把故障控制在一次签署的范围内——超限就失败、就重试、就告警，而不是让操作系统在内存耗尽时随机杀掉一个进程。随机杀进程最坏的情况是杀到了数据库，那时候损失的不是一份合同，是整个平台的可用性。
做容量规划时，正向算是"我有多少盘，能存多少年"；真正有用的是倒推："我要留存这么多年，需要多少盘"。倒推的第一步是确定留存期，这一步由业务和法务给，不是运维能定的；第二步是算出每年的新增体积；第三步是按访问频次做冷热分层；第四步才是买盘。
每年新增体积的算法前面给过：月签署笔数 × 单份平均页数 × 每页平均体积 × 12。这里三个变量都要用自己的数据。笔数看业务预测，页数看模板分布（不是平均值，是用了加权后的实际分布），每页体积看自己历史文件的实测均值。三个数乘出来的结果，再分别乘以最终件和审计日志各自的系数，就是一年的增量。审计日志的增量单独算，用"每笔平均事件数 × 单条记录体积"来估，量级通常比最终件小一到两个数量级，但它的留存期往往跟最终件一样长，所以不能忽略。
第三步的分层决定了实际要买多少高性能盘。假设三年的最终件总量里，只有最近一年的会被频繁调阅，那高性能存储只需要覆盖一年的量，其余两年放低频或归档介质，成本能降下来一大截。这里的关键是要能说清楚"频繁"的阈值——是每月被调阅一次，还是一年一次。这个判断做错，要么花冤枉钱，要么每次调阅都等半天。
最后要给一个提醒：留存期不是越长越安全，而是越长越贵。有些业务把所有文件都按最长的期限留存，看起来保守，实际上是在为一批永远不会被调阅的文件持续付费。合理的做法是按合同类型分级，把真正的长期留存对象挑出来单独管理，其余按业务需要定期清理。清理策略要可审计——清了什么、什么时候清的、依据是什么，这些记录本身也要留。倒推容量这件事，算清楚比买够更重要，算清楚了才知道哪些钱是该花的，哪些是可以省的。
上一篇：2026 机房 IP 台账服务器租用对比：phpIPAM 与 RackTables 的扫描发现、机柜端口与容量账避雷手册
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
