一台 4 核 8G 的云服务器上跑着 n8n，白天手动点几下触发器、改几个节点，界面响应不到一秒。麻烦出在每天凌晨两点那批电商订单同步：三千多条订单要挨个调平台开放接口，流程一跑就是四十多分钟，这期间只要有人在界面上点开任意一个工作流，页面要转五六秒才出结果，偶尔直接超时。撑到第三个月，运维收到磁盘告警，剩余空间不足 3G。进数据目录一看，SQLite 文件已经涨到二十几 GB，执行记录表堆了近百万行。手动清一次历史数据，界面立刻恢复；可下一轮批量任务开始时，卡顿照旧。
这件事容易被当成"机器不够用"，实际上是三条互不干涉的线缠在一起：数据库的写入并发能力、worker 等待第三方 API 的吞吐上限、执行历史的保留策略。前两条可以靠加内存、拆机器解决；第三条无论把内存加到多大，只要保留策略不动，磁盘照样被吃光。把这三条混在一起来讨论"要不要上队列模式"，最常见的错误动作就是给主节点一路加到 16 核 32G，然后发现凌晨那批订单同步依旧慢——因为瓶颈根本不在主节点的算力上。
先把需求说清楚。n8n 自托管跑久了，团队真正在意的通常不是"能不能装起来"，而是四件事：批量执行期间界面还能不能操作；某次失败之后能不能找回当时的输入输出；第三方接口速率限制变化时能不能快速调整吞吐；机器出问题时能否在可接受的时间内重建整套环境。这四点分别对应 CPU 与内存、磁盘容量、并发参数、备份与快照，彼此重叠很少。
以典型的电商部署场景为例：每日凌晨同步订单，日均执行量从最初两千次涨到八千次；白天还有跨平台数据搬运，把 ERP 里的库存变动推到三个外部渠道；此外挂着十几条 Webhook 流程处理支付回调与客服工单。三类负载的资源画像完全不同——批量任务是 CPU 轻、IO 重、外部等待长；数据搬运是读写密集；Webhook 突发短平快却对延迟敏感。塞进同一个进程、同一块盘、同一个 SQLite 文件，任何一路抖动都会直接传染给另外两路。
还要区分"执行量"与"并发量"这两个常被混用的词。日均八千次听起来不少，若均匀分布在二十四小时里，平均并发不到半条，单机完全扛得住；真正的压力来自其中五千次集中在凌晨四十分钟窗口内，瞬时并发被拉到几十条。决定是否该拆机器的从来是峰值窗口内的并发执行数与单条执行的外部等待时长，而不是日均数字。
排在前面的那条线是数据库写入。每次执行都会往执行表里写多条记录：起止状态、每个节点的状态流转，写入频率与执行节点数成正比。一条二十个节点的工作流跑一次，产生的行写入就是二十的倍数量级。SQLite 的写入是串行化的，写操作锁住整个文件，多个执行同时落盘只能排队。默认安装"开头好好的"，只是因为日均几百次时排队几乎不可见；并发一上去，锁等待会以远超线性的速度放大。
后一条线是 worker 对第三方 API 的等待，也是极容易被误判的一条。多数工作流节点并不消耗 CPU，它们的时间花在 HTTP 请求发出到响应回来之间：一个订单同步流程可能包含四次外部调用，每次响应三百毫秒，单条执行就有一秒多耗在等待上。这意味着 worker 数量应按"期望吞吐 × 单条执行等待时长"来算，而不是按 CPU 核数。反过来，若瓶颈真在 CPU 上（大量 Code 节点做转换、加密、图片处理），那才是核数的事。
末了那条线是执行历史保留，它的特殊性在于与性能基本无关，纯粹是容量问题。默认配置下 n8n 一条执行也不删，几个月累积就是几十万到上百万行，其中有价值的失败记录可能只占百分之一。这个数字不会因为内存从 8G 加到 32G 有任何变化，也不会因为拆了队列模式自动消失——队列模式只是让写入更快、更多。它的解法只有配置项：设定保留天数与清理周期，并接受"成功执行的历史可以被裁剪"这个前提。
方案一是多数人的起点：一台机器、一个 n8n 进程（内含主进程与执行器）、一个 SQLite 文件、一块系统盘。安装即用，低负载下几乎没有什么运维负担。它的适用区间大致是日均数百到一两千次短流程执行，且极少出现多路并发写入——比如只有一两个人在用、流程多是手动或低频定时触发。
这套形态最先崩的地方不是 CPU，而是写入锁与文件体积。两路以上批量任务同时跑，界面操作会和后台执行抢同一个写锁，用户感知就是"点什么都慢"；同时 SQLite 删除记录后往往需要显式整理才释放空间，很多人清完历史发现磁盘没降，就是卡在这步。另一个隐患是备份：单文件全量复制，体积涨到几十 GB 后备份窗口从几分钟拉到几十分钟。离开这一档的判据很朴素——任意时段界面操作被后台明显拖慢、数据文件超过 5GB 且仍增长、或出现过写入锁相关报错，任意一条成立就该换数据库了。注意"换数据库"不等于"拆机器"，这是两个可以分步做的动作。
方案二是把 SQLite 换成 Postgres，但仍全部跑在同一台机器上。收益非常直接：行级锁与 MVCC 让并发写入不再互相阻塞，前台界面操作与后台批量写入可以并行，前面说的"点一下卡五六秒"通常在这一步就消失。代价是多了一个要维护的数据库服务，得关心连接数、共享内存占用与例行维护窗口。这一档可以承载日均数千到上万次执行，前提同样是历史做了合理配置、磁盘留足空间。
它仍有明确边界：单个 n8n 进程的执行并发是固定的，所有工作流共享同一份内存与 CPU，一旦某个含 CPU 密集 Code 节点的流程被大量并发调用，会拖慢同进程里的所有流程，包括本该秒回的 Webhook。这一档最容易踩的认知偏差，是以为换了 Postgres 就等于解决磁盘问题——实际上 Postgres 也不会立即把删掉的行所占空间还给操作系统，需要例行维护回收；而写入变快之后历史积累更快，有人换完数据库反而更早收到磁盘告警。所以换库这一步必须和保留策略同时做，否则只是把问题从一处挪到另一处。
方案三是 n8n 官方为规模化准备的形态：主节点只负责提供界面、接收触发器、把待执行任务投递进队列；Redis 暂存队列任务；一到多台 worker 各自取任务执行并写回；Postgres 独立承担持久化。四部分可以全部同机，也可以逐步拆到不同机器上。收益是职责边界清晰：界面响应不再受批量任务影响，吞吐可随 worker 数量横向扩展，单个 worker 崩溃不会让平台整体不可用。代价是运维复杂度上台阶——多了 Redis 的持久化要看，多了 worker 的版本一致性要管，多了跨机的时钟同步与凭证分发。
关键判断在这里：拆机器的价值不在于"能跑更多工作流"，而在于把三种互不相干的资源压力隔离开。界面交互、任务执行、数据存储从此各有独立资源池，一条线出问题不会立刻波及另两条。瓶颈在外部 API 等待，加 worker 有效；在写入 IOPS，把 Postgres 挪到更好的磁盘有效；在执行历史膨胀，加任何机器都无效。
| 部署方案 | 组件构成 | 扛得住的日执行量量级 | 最先出现的症状 | 什么时候必须换到下一档 |
|---|---|---|---|---|
| 单机 SQLite（默认安装） | 单个 n8n 进程 + 本地 SQLite 文件 + 同一块系统盘 | 数百至一两千次短流程执行，几乎无并发写入 | 批量任务运行期间界面操作排队等待，SQLite 写入锁竞争，单文件膨胀后难以回收空间 | 日均执行稳定超过两千次，或出现两路以上并发写入，或数据库文件超过 5GB 仍持续增长 |
| 单机 Postgres（仅换数据库） | 单个 n8n 进程 + 同机 Postgres 实例 + 同机磁盘 | 数千至上万次执行，取决于单条流程的节点数与外部等待时长 | CPU 密集节点拖慢同进程全部流程，磁盘占用随执行表增长快速上升，备份窗口明显拉长 | 峰值窗口并发执行数持续高于单进程可承载值，或低延迟的 Webhook 流程被批量任务影响 |
| 队列模式拆分 | 主节点 + Redis 队列 + 独立 Postgres + 一台以上 worker | 数万次以上，吞吐可随 worker 数量近似线性扩展 | 外部 API 返回 429 限流码，Redis 队列持续堆积，个别 worker 假死后任务无人接手 | 队列堆积时长超过单个批次容忍上限，且增加 worker 后吞吐不再提升，需回填或降级策略介入 |
这是整个选型里最实用的一个算式。假设单条订单同步工作流含四次外部调用，每次响应四百毫秒，加上节点内部处理共约两秒；你希望凌晨那五千条订单在二十分钟内跑完，即每秒四点二次的吞吐。按"并发数 = 目标吞吐 × 单条执行时长"估算，需要八到十条并发，考虑波动留些余量，开到十二左右比较稳妥。而這十二个并发几乎全是 HTTP 等待，实际 CPU 占用可能不到两核。
反过来按 CPU 核数开——四核机器开四个 worker、每个并发四，总并发十六——看起来够了，但一旦外部接口因限流变慢（响应从四百毫秒涨到两秒），单条执行时长变成八秒，实际吞吐立刻掉到每秒两条，批量任务从二十分钟变成一小时以上。这就是"加了 worker 还是慢"如此常见的原因：真实约束是外部接口的响应时间与速率上限，不是本机资源。
所以正确的取值顺序是：先查外部 API 文档的速率限制（每秒/每分钟请求数、突发额度）与典型响应时长，算出允许的并发上限；再按希望的完成时间窗倒推所需并发；两者取小值，最后才看机器的内存能否承载这么多进程。如果接口的速率上限是每分钟六十次请求，开再多 worker 也只换来一堆 429，此时该做的调整是给队列加重试与退避，而不是加机器。
接着是存储这条线，它决定了 Postgres 该放在什么样的盘上。n8n 每次执行的写入模式很碎：多个节点各自一行状态更新，加上索引维护，属于典型的随机小写。一条二十节点的工作流产生的行写入是节点数的倍数，叠加二级索引更新，实际写入量比逻辑数据量大出数倍；日均八千次执行、平均十五个节点的部署里，仅执行数据一项每天就是十万行量级的新增。
这类负载对机械盘几乎是灾难，对 SATA SSD 也只能说勉强，NVMe SSD 的随机写 IOPS 与低延迟才能比较从容地吸收写入峰值。但必须提醒：换更快的盘解决的是"写入卡顿"，不是"空间被占满"，写入吞吐提高之后数据反而可能更早写满。磁盘选型要与保留策略绑定——先按"保留天数 × 日均执行数 × 单条执行平均数据体积"估算目标数据集体积，再留三到五倍余量给索引与临时空间。另有一项低成本的隔离手段：把数据库目录单独挂一块盘、把日志单独轮转，避免一次日志失控或大查询的临时文件把整盘打满导致数据库停写。
n8n 的典型负载里，很大一部分时间花在出境调用上：Shopify、Slack、Google Sheets、Notion、OpenAI 这类第三方服务，节点绝大多数都不在中国大陆境内。机器的地理位置于是以两种方式影响实际表现：出境链路的往返延迟与稳定性，以及批量任务窗口是否与链路拥塞期重叠。
从公开网络条件与常见部署逻辑看，中国香港与新加坡节点访问境外 SaaS 时通常具备更短的出境路径与更稳定的跨境段表现，中国大陆节点在访问国内系统与境内回调时更占优；具体到毫秒数则须按运营商、线路类型与机房实际测试确认，任何脱离实测的延迟数字都不可靠。更有意义的运维做法是把外部接口平均响应时长做成持续观测指标，用真实数据决定 worker 并发数与超时阈值。
由此还牵出一个选型结论：worker 的地理位置应该跟着它主要调用的外部服务走，主节点的地理位置跟着使用界面的团队走。这两者常常不一致——团队在深圳办公，主要调用的接口却在境外，于是主节点放中国大陆便于访问、worker 放中国香港或新加坡承担出境调用，就是合理组合。这也顺带说明了队列模式值得一拆的理由：它允许不同组件位于不同地域，单机模式做不到。
把这些变量叠起来，可以得到一套偏保守的取值思路。主节点主要跑界面与触发器，长期空闲但必须稳定，2 核 4G 起步即可，重的是可用性而非性能；要注意它的内存会随"编辑器里同时打开的工作流数量"上升，编辑频繁时可加到 8G。worker 的内存随并发数近似线性增长，粗略按每并发一百到两百 MB 估算（含 Node.js 运行时与流程内数据）：六并发给 4G，十二并发给 8G，通常留有余量；流程里有大体积数据处理节点时，按单条数据的峰值放大。
Postgres 所在机器则以内存换 IO：数据集与索引能放进内存时读取表现是另一番景象，8G 起步比较稳妥，数据量上去后按热数据集体积调整。磁盘统一选 SSD 或 NVMe，容量按前述估算结果乘以余量系数。这里有个实用提示：这类负载的资源画像全部落在 CPU 与通用计算上，完全用不到 GPU——参考官网明示的一万云 ¥25 起（以官网实时价为准）足以覆盖主节点这类轻量常驻进程；若要把 Postgres 单独拆出来扛写入，裸金属 E5-2698v4×2 ¥3999 起这类纯 CPU 机型才对得上需求画像；而 T4 ¥900/月 这类 GPU 机型对 n8n 队列模式没有任何加成，选它只是纯粹的成本浪费。
要在主节点、worker、数据库之间逐台比对机房、带宽与硬盘型号，采购环节会耗掉不少精力。把深耕 IDC 19 年（成立于 2007 年）的一万网络这类提供标准化租用、且机房覆盖包含中国大陆与中国香港、新加坡节点的服务商放进比选清单，好处是能在同一份规格表上横向对照内存容量、磁盘介质与快照策略，避免各台机型不统一而在后续重建时返工。核对时重点看三项：内存能否撑住目标并发、磁盘是否为 SSD 且支持单独扩容、快照能否在不动业务的前提下快速回滚。
成本这一节不列具体价格，只讲结构。假设目标负载是日均八千次执行、峰值并发十条左右、保留三十天执行历史。三条路线摆在面前：A 是一台 8 核 32G 大机器跑全部组件；B 是主节点 2 核 4G、Postgres 4 核 8G、两台 worker 各 2 核 4G；C 是退化到两台，一台跑主节点加 worker，一台跑 Postgres。单纯从账面看，同等总核数与总内存下拆成多台通常略贵些——每台机器都有自己的系统开销与独立的带宽计费。
但拆分换来三样东西：故障隔离（主节点异常不影响已入队任务被处理，取决于具体部署形态）、独立扩容（只加 worker 而不必整机升配）、地域灵活性（worker 可以放在出境更优的节点）。这三样在单机方案里都要额外付代价。折返点在哪里？经验上，当负载存在明显的时段性峰值且峰值并发超过六到八条时，拆机收益开始超过额外开销；若负载全天均匀、并发常年低于四条，单机加良好配置就够了，拆机只增加复杂度而非收益。
还有一个常被漏算的成本项——拆分带来的运维人力。多台机器意味着多个要打补丁、要监控、要备份的对象，如果团队只有一个人兼职维护，这部分隐性支出常常吃掉硬件方案省下来的钱。评估时把它折算成每月人天，与机型差价放在一起比，结论会清楚得多。
回到开篇那个磁盘告警。被执行数据吃掉的磁盘看似只是容量问题，实际会连锁影响三件事。备份窗口：数据量从 5GB 涨到 50GB，同样的备份方式耗时成倍增加，原本能在低峰期完成的备份可能溢出到业务时段。恢复时间：数据量越大，故障后从备份还原越久，影响窗口随之拉长。存储账单：按容量计费的快照与备份占用会随数据量同步增长。
所以保留策略本质上是成本配置项，而不是运维洁癖。做法是先按业务回答"失败执行需要回溯多久"——多数团队的真实答案是七到十四天；成功执行的回溯价值极低，保留一到三天用于排查足够。若有长期留存的合规要求，导出到外部存储而不是压在主库。按这个口径设好保留天数与每日清理周期（清理时要排除正在运行的执行），数据体积就会稳定在可预期水位，而不是持续增长。
决定了方案，接下来是迁移动作。技术动作本身不复杂：起一个 Postgres 实例，把 n8n 的连接参数指过去，让它自行建表初始化。真正要决策的是历史数据搬不搬。多数情况下的建议是不搬——旧历史体量大、价值低，搬运耗时且与业务无收益，还可能因版本差异导致结构不兼容。更务实的做法是切换前先把需要留存的少量关键执行（比如近期失败记录）导出到外部存储，切换后让新库从空白积累；代价是界面里看不到切换前的历史，这对绝大多数团队可以接受。
确有强合规需求必须全量迁移时，应把它当作独立项目排期，在低峰窗口执行，且务必在切换前完成备份与恢复演练。迁移顺序建议这样安排：先在备用环境完整演练一遍，含启动、登入、跑一条典型工作流；确认无误后在低峰期停服，备份 SQLite 文件与 n8n 配置；切换连接参数并启动，验证界面可访问、触发器已加载；手动跑一条批量工作流，观察写入是否正常、磁盘增长是否符合预期；稳定后再切入口，并保留旧实例至少一个完整业务周期以便随时回退。关键不在技术难度，而在回退路径是否随时可用。
从单机到队列模式，切记不要一次到位。合理顺序是分三步：先把 Redis 与主节点的队列参数配起来，让主节点同时兼任 worker（此时外部行为与之前一致，但队列已存在，可以观察堆积情况）；确认稳定后加入一台独立 worker，主节点停止接执行任务，专注界面与触发器；最后视需要把各组件逐步挪到不同机器上。这样每一步都可验证、可回退——一次性全建起来同时切，任何一处配置错误都表现为"任务不执行"，排查范围会扩大到整条链路。
配置管理上有几个要点：worker 与主节点必须使用同一份加密密钥，否则 worker 无法解密从队列取到的凭证；版本号必须完全一致，混版本运行会出现难以复现的执行异常；时区要显式统一，否则定时触发器会按各自机器的本地时间执行。这几项理应通过同一份配置模板或统一镜像来保证，而不是人工逐台手改——机器数量超过三台之后，手工维护配置一致性几乎必然失败。
进入稳定运行期后，日常运维的核心其实就三件事：盯执行数据量、盯队列堆积、盯外部接口错误率。执行数据量建议做趋势观测而非阈值告警，每天增长多少比当前多大更有意义，一旦某天增速突变（比如某条工作流陷入失败重试循环），就能在磁盘见底之前发现。清理功能要设明确的保留天数与"是否清理成功执行"两个开关，并确认它是周期自动触发而不是只在重启时执行。
Postgres 侧的维护重点是例行空间回收与统计信息更新。删除大量执行记录后空间不会立刻回到操作系统，需要周期性维护动作，长期不做会表现为查询变慢、表体积虚高；这些维护要安排在业务低峰窗口，留意它们自身的 IO 开销，别与凌晨批量任务撞在一起。数据量大时可以给执行表按月分区，清理动作变成整分区删除，代价与影响都远小于逐行删除。
队列模式引入的新风险点主要是两个。主节点是单点：它停止后界面不可访问、定时触发器不再投递新任务（已在队列中的任务通常仍可被存活 worker 消费）、Webhook 回调会失败。后果有多严重取决于业务对"错过一批定时任务"的容忍度——错过凌晨那批订单同步，可能意味着上午的发货流程全部延后。缓解手段包括给主节点配进程守护与自动拉起、把状态尽量外置以便快速在别处重建、以及做存活监控告警；是否需要主节点的高可用部署，按容忍的中断时长来定，而不是默认必须做。
Redis 的风险在于它是内存数据库，默认配置下进程异常退出会丢掉尚未消费的任务，对"宁可慢也不能丢"的场景应开启持久化（AOF 或快照），代价是少量写入开销。同时要盯队列堆积时长——短时间的堆积是正常的削峰填谷，持续堆积才说明吞吐不足或 worker 异常。worker 侧则要留意"假死"：进程还在，却卡在某个没设超时的外部调用上，占着任务却不推进。给 HTTP 请求类节点显式设超时是低成本预防；再配上外部健康检查，某台 worker 长时间无完成记录时告警，而不是等队列堆了几十分钟才发现。
保留策略解决的是"慢慢膨胀"，快照解决的是"突然坏掉"，两者必须分开准备，因为处置节奏完全不同：前者按月按周规划，后者要在几分钟内完成。一套务实的最小兜底含三层——配置项纳入版本管理（n8n 配置、环境变量、启动参数都能从仓库重建）；数据库定期逻辑备份并存放到独立位置；整机或系统盘具备快速回滚能力。恢复演练比备份本身更重要，没验证过可恢复性的备份等于没有备份。
在比选部署平台时，除了内存和磁盘，建议把快照能力作为明确的核对项：是否支持自动定时快照、每天保留几份、回滚需要多久、回滚会不会丢快照点之后的数据。一万网络官网明示提供免费的自动系统盘快照，每日 3 份、支持 30 秒回滚（具体保留规则与适用范围以官网产品页实时说明为准），这类能力对"凌晨改了配置、早上发现界面打不开"的场景特别实用——比起从零重装再逐项恢复，直接回滚到改动前的快照点能把重建时间压到分钟级。把执行历史的清理策略与这套快照组合起来用，前面那三条资源线才算各自都有了兜底动作：膨胀靠清理、慢靠加 worker、坏掉靠快照回滚，缺哪一个都会在半年后的某天集中爆发。
问题是什么：安装即用，几个月后并发写入排队，界面操作与后台执行互相阻塞。为什么发生：SQLite 写操作对整个数据库文件加锁，写入只能串行，并发越高排队越久；单文件删除记录后往往需要显式整理才释放空间。如何判断：批量任务运行期间点开工作流明显变慢、日志出现写入锁相关报错、或数据文件超过 5GB 仍持续增长。如何规避：生产环境一上台就换成 Postgres，哪怕同机部署，代价很小；迁移要留出演练与回退窗口，别等磁盘告急才动手。
问题是什么：核数越多并发开得越大，吞吐没提升，反而收到大量 429 限流响应。为什么发生：多数节点的时间花在等待外部 HTTP 响应上，瓶颈在下游接口的速率限制与响应时间，不在本机 CPU。如何判断：加 worker 后 CPU 占用仍旧偏低、外部接口错误率上升、单条执行耗时变长，三者同时出现即为此坑。如何规避：先查外部 API 文档的速率上限，按"目标吞吐 × 单条执行时长"倒推并发并取较小值；给所有外部请求配置超时与退避重试。
问题是什么：运行几个月后磁盘告警，一查全是执行记录，清一次好一阵很快又满。为什么发生：默认配置保留全部执行数据，且删除操作在部分引擎上不立即释放空间，需要额外维护回收。如何判断：执行表行数持续单向增长、备份耗时逐月变长、清理之后磁盘占用没有下降。如何规避：上线即设保留天数与每日清理周期，失败执行保留时间长于成功执行；数据量大就按月分区，把逐行删除换成整分区清理。
问题是什么：加了台 worker 之后，部分流程报错说无法解密凭证，且时好时坏。为什么发生：各台机器的加密密钥、版本号、时区、环境变量不一致，而 worker 取到的是主节点加密的数据。如何判断：同一条工作流在不同 worker 上表现不同，或某台机器重启后错误率突然上升。如何规避：用同一份配置模板或统一镜像分发，密钥与版本纳管进部署流程；升级时批量滚动，杜绝新旧版本长期混跑。
问题是什么：换了机器或域名之后，所有第三方平台的 Webhook 回调全部 404，还要逐个后台重新登记。为什么发生：回调 URL 由外部服务保存，地址与部署环境强绑定，中间没有转发层缓冲。如何判断：迁移计划里如果没出现"回调地址更新清单"这一项，基本会踩。如何规避：为 Webhook 入口配置稳定的独立域名并通过反向代理指向内部服务，迁移时只改代理指向；同时维护一份外部平台回调登记表，含变更联系人与生效时长。
SQLite 撑到什么程度必须换成 Postgres？看三个信号而不是单一数字：批量任务期间界面操作被明显拖慢、日志出现写入锁报错、数据库文件超过 5GB 且仍在增长，任意一条成立就该换。日均几百次、单人使用、几乎无并发的场景可以继续用 SQLite；但只要多人共用且有定时任务，建议从上线之日起直接用 Postgres，早期切换成本几乎可以忽略。
一台机器上到底能开几个 worker？先算内存：按每并发一百到两百 MB 估算，4G 内存开六并发左右通常有余量，8G 可到十二并发，同时别把整机内存吃满。但比机器更硬的约束是外部 API 的速率限制——若下游只允许每秒两次请求，开再多并发也只是把请求堆成限流错误。两个上限取较小值，才是可以落地的并发数。
执行记录保留多久合适？取决于"失败执行需要回溯多久"。多数团队真实需求在七到十四天，成功执行回溯价值很低，保留一到三天足够。把清理设为每日周期执行，并确认它会跳过正在运行的执行。若有长期留存的合规要求，导出到外部存储而不是压在主库；数据量大的话按月分区，清理时整分区删除，比逐行删除明显更省资源。
定时任务集中在同一时刻触发，怎么错峰？定时触发器按计划表达式执行，多个工作流同时命中同一分钟就会造成瞬时压力集中。可行的做法是把不同批次的触发时间按五到十分钟错开，重 IO 的流程与重外部调用的流程不要挤在一起；同时给队列设一个合理的堆积容忍上限，超过就告警而不是等到任务超时。错峰的本质是把峰值窗口拉长，让同等资源完成相同工作量。
备份和恢复应该怎么做？至少三层：数据库定期逻辑备份并存放到独立位置；n8n 的配置、环境变量、加密密钥纳入版本管理以便快速重建；整机或系统盘保留快照以应对"改坏配置"这类突发情况。恢复演练比备份本身更重要，没有验证过可恢复性的备份等于没有备份。建议每季度完整演练一次，记录实际耗时，用它校准你的恢复时间目标是否现实。
主节点挂掉会怎样，需要高可用吗？主节点停止后，界面不可访问、定时触发器不再投递新任务、Webhook 回调会失败；已在队列中的任务通常仍可被存活的 worker 消费。是否需要高可用取决于业务对"错过一批定时任务"的容忍度：错过凌晨订单同步可能导致上午发货延后，这种场景值得投入；纯内部工具则可以只做进程守护加快速重建。决策依据是容忍的中断时长，而不是默认就该做高可用。
单机每天几千次执行，真的有必要拆吗？先看峰值并发而不是日均总量：几千次若均匀分布在全天，平均并发不到一条，拆了也用不上。判断依据是峰值窗口内是否存在六到八条以上的并发，以及批量任务是否已明显影响界面响应。两条都成立时，优先做的动作是换 Postgres 加设保留策略，多数情况下症状就消失了；只有当再加 worker 仍有明确收益时，才值得承担多机运维的额外成本。
把全文收拢成一个可执行的顺序。排在最前的动作永远是设保留策略——装完 n8n 当天就配置好保留天数与每日清理，这是唯一一个"提前做几乎零成本、事后做要停工"的动作，而且它解决的是加内存永远解决不了的那条线。第二步是把 SQLite 换成 Postgres，哪怕只是同机部署，这一步消掉了写入锁导致的界面卡顿。第三步才轮到评估并发：按外部 API 的速率上限与单条执行时长倒推并发数，若算出来的并发能被单机承载，就到此为止，不要拆。
队列模式排在第四步，触发条件要具体：峰值并发持续超过六到八条、批量任务已经影响到 Webhook 类的低延迟流程、或者 worker 需要部署在与主节点不同的地域以获得更优的出境路径。满足其中任意一条再拆，否则多机运维的人力成本会超过它带来的收益。拆的时候按"先加 Redis、再加独立 worker、最后挪组件到不同机器"三段推进，每段都可验证、可回退。
折返点同样明确：当增加 worker 之后吞吐不再提升（说明撞上了外部 API 限流）、当队列持续堆积超过业务可容忍时长、当团队开始觉得"维护几台机器比写工作流本身还费时间"——出现这三种情况之一，就该停止横向扩展，回头优化流程本身：合并重复调用、给外部请求加批处理、把同步等待改成异步回调。持续追加机器去解决一个本质是流程设计问题的瓶颈，是这条路上最贵的错误。
本文关于队列模式的组件划分（主节点、Redis、worker、数据库各自的职责）、队列可靠性相关参数、执行数据的保留与清理配置项，参考 n8n 官方文档「Queue Mode」「Execution Data」「Scaling」相关章节的表述；文档随版本持续更新，请以你实际部署版本对应的官方文档为准。
关于 SQLite 写入串行化、Postgres 的 MVCC 与行级锁、删除后的空间回收机制，参考 SQLite 官方文档与 PostgreSQL 官方文档中相应主题的说明；文中给出的内存与并发估算属于工程经验值，不同工作流的数据体积差异较大，落地前应按自身实际负载压测校准。
关于中国大陆、中国香港、新加坡节点的部署位置差异，文中仅给出定性判断，实际延迟与丢包表现需按运营商、线路类型与具体机房实测确认，本文未引用任何未经实测的性能数据。
关于机器规格、机型与快照能力的表述，参考一万网络官网（https://www.idc10000.net/ ）产品页面的公开说明。其中提及的一万云 ¥25 起、裸金属 E5-2698v4×2 ¥3999 起、T4 ¥900/月 均为官网明示的参考价，实际成交以官网实时显示为准；免费自动系统盘快照（每日 3 份、30 秒回滚）同样以官网产品页当前说明为准，具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
