知行之桥 Schedule 端口支持每小时最大文件数限流
© All rights reserved. • 西安知行软件有限公司 • 陕ICP备09022277号
在企业集成场景中，文件不是总按“均匀节奏”到达的。订单可能在促销后集中涌入，对账文件可能在固定时间批量推送，外部系统 API 也可能明确限制“每小时最多调用 1000 次”。在没有“每小时最大文件数”这个独立配置时，企业通常只能通过 Schedule 触发间隔和每次处理数量去近似控制小时级流量；这种方式一旦遇到文件集中到达，就容易出现高峰排队、低峰配额浪费的问题。
知行之桥 Schedule 端口新增的“每小时最大文件数”限流能力，正是为这类场景设计。它不是要求用户手工把一小时配额拆成每分钟或每次执行的固定额度，而是以任意连续一小时作为统计窗口，动态判断当前是否还有处理配额。这样既能避免超过目标系统 API 限制，又能在文件集中到达时尽快消化当前批次。
适用版本
本文介绍的 每小时最大文件数 是 Schedule 端口新增的限流配置，适用于 知行之桥 26.2.9645.0 及之后版本。
如果当前环境中的 Schedule 端口高级设置里看不到 每小时最大文件数，通常说明当前版本暂不支持该功能，建议先确认产品版本是否低于 26.2.9645.0，或升级到 26.2.9645.0 及之后版本后再使用。
为什么 Schedule 端口需要“每小时最大文件数”？
Schedule 端口用于在工作流中按计划延迟或定时将消息发送到下一个端口。它本身已经支持基于时间的流控制、批处理控制、计划消息发布和 Cron 表达式等能力，适合用来控制后续处理时机。
在实际项目中，很多后续动作并不只是“移动文件”这么简单，而是会触发 API 调用、数据库写入、订单同步或业务系统处理。如果外部系统 API 或目标业务系统有严格的小时级处理限制，就需要一个更贴近真实流量的限流机制。
Schedule 端口高级设置包含两个容易混淆但作用不同的参数：
- 最大文件数：限制每个发送间隔内处理的最大文件数；
- 每小时最大文件数：限制在一小时时间段内，所有计划发送累计处理的文件数量。
图：Schedule 端口高级设置中，可通过“每小时最大文件数”控制一小时窗口内的累计处理数量。
核心机制：按滑动窗口统计，而不是按整点重置
“每小时最大文件数”的关键，不是自然小时，也不是简单地在 9:00、10:00、11:00 这种整点清零。它采用更灵活的滑动窗口逻辑：当端口准备接收或处理文件时，系统会从当前时刻向前回溯 60 分钟，统计这段时间内已经处理的文件数量。
实际判断逻辑可以理解为：
- Schedule 端口按配置的自动化频率检查是否有待处理文件；
- 当有文件准备处理时，系统统计“当前时刻往前 60 分钟”内已经处理的文件数量；
- 如果统计值低于“每小时最大文件数”，则允许继续处理；
- 如果统计值已经达到上限，则暂停处理，等待时间窗口继续向前滑动，释放新的配额。
这种方式允许系统在短时间内集中处理大量文件，只要任意连续一小时内的总处理量不超过设定上限即可。
核心参数解析：上限决定总量，频率决定检查节奏
从配置角度看，这个能力主要涉及两个概念：每小时最大文件数和 Schedule 自动化频率。
| 参数/概念 | 实际含义 | 作用机制 |
|---|---|---|
| 每小时最大文件数 | 任意连续一小时内允许处理的文件总量上限 | 从当前接收或处理时刻往前推一小时，统计已处理数量；达到上限后暂停处理 |
| 滑动窗口 | 动态回溯 60 分钟的统计区间 | 不按自然小时重置，而是随每次处理时刻移动 |
| 检查间隔 | Schedule 端口自动化触发频率 | 决定系统多久检查一次待处理文件及剩余配额 |
如果希望系统更快响应配额变化，可以把 Schedule 自动化频率设置得更短，例如每 1 分钟检查一次。这样当较早处理的文件滑出最近 60 分钟统计窗口后，系统能更快发现新的可用配额。
图：Schedule 端口自动化频率决定系统多久检查一次待处理文件和可用配额。
适用场景：外部系统 API 有严格流量限制，文件到达又不均匀
“每小时最大文件数”特别适合那些既有流量限制、又有批量波动的业务链路。它的价值不在于强制把处理节奏变慢，而是在不超限的前提下尽量处理得更快。
外部系统 API 限流
某些外部系统 API 会限制每小时调用次数，例如每小时最多 1000 次。如果业务文件处理会触发 API 调用，那么 Schedule 端口可以将“每小时最大文件数”设置为对应阈值，避免因瞬时高峰导致调用超限、请求被拒或账号被临时限制。
批量文件集中到达
客户或交易伙伴可能在某一时刻集中推送大量文件。如果只能通过“多久执行一次、每次最多处理多少个”来近似控制小时级流量，一批明明已经到达的文件可能被人为拆成很多分钟甚至更长时间处理。新增的小时级总量控制允许系统在配额允许范围内快速消化当前批次。
不均匀流量
很多业务流量天然不规律：有时连续几分钟没有文件，有时突然来了几百个文件。滑动窗口限流能更贴近这种真实波动，减少低峰配额浪费和高峰排队等待。
配置建议：按目标系统 API 阈值设上限，按业务节奏设频率
配置“每小时最大文件数”时，建议先确认外部系统 API 或目标业务系统的真实限制。例如 API 文档中写明每小时最多 1000 次调用，就可以将 Schedule 端口的“每小时最大文件数”设置为 1000，或根据业务安全余量略低于该值。
| 场景 | 每小时最大文件数 | 检查间隔（Schedule 频率） | 说明 |
|---|---|---|---|
| 目标系统 API 严格限流 | 等于或略低于目标系统限制的每小时调用次数 | 较短，如 1-5 分钟 | 快速响应配额变化，避免超限被拒 |
| 批量集中到达 | 略高于平均预期量，但不超过系统承载能力 | 较短，如 1 分钟 | 允许文件集中到达时快速消化，减少等待 |
| 流量平稳 | 接近平均每小时文件量 | 较长，如 10-30 分钟 | 降低系统检查开销，适合稳定流量 |
与过去的近似控制方式相比，小时级限流更贴近真实业务流量
在没有“每小时最大文件数”配置时，如果企业要遵守“每小时最多处理 1000 个文件”的限制，常见做法是通过 Schedule 执行频率和“最大文件数”组合出一个保守策略。例如每分钟执行一次、每次最多处理约 16 个文件，从而近似控制在每小时 1000 个以内。这个方式看似稳定，但在真实业务中容易产生配额浪费和延迟：
- 某一分钟只有 2 个文件，剩余 14 个分钟配额无法充分利用；
- 某一分钟突然到达 50 个文件，却只能处理约 16 个，其余文件必须等待后续分钟；
- 文件越集中，积压越明显，业务处理延迟越高。
新增的“每小时最大文件数”允许更灵活的节奏：可以前 10 分钟处理 800 个，剩余 50 分钟处理 200 个；也可以前 50 分钟较空闲，最后 10 分钟集中处理到小时上限。核心原则只有一个：任意连续一小时内的总量不超过设定阈值。
注意事项：这是按文件个数限流，不是按字节限流
在配置和沟通时，需要明确“每小时最大文件数”是按文件个数计算，而不是按文件大小或字节数计算。如果业务关注的是传输带宽、下载字节量或单文件大小限制，应结合对应端口的传输限制能力另行评估。
同时，这项能力更适合“对实时性要求不高，但对小时级流量限制非常敏感”的场景。如果某些业务要求每个文件必须秒级处理，则需要在限流保护和实时性之间做权衡。
总结
Schedule 端口新增的“每小时最大文件数”限流能力，让知行之桥在处理批量文件和小时级配额时更加灵活。它通过滑动一小时窗口动态统计已处理文件数量，避免外部系统 API 或目标业务系统被超限请求冲击，同时减少过去依靠执行间隔和单次最大数量近似控制带来的等待和配额浪费。
对于电商订单同步、财务对账文件、外部系统 API 调用受限、文件到达不均匀等场景，这项能力可以帮助企业在“稳定合规”和“处理效率”之间取得更好的平衡：不超限、不浪费、少等待，让批量集成流程更稳、更可控。
