同步性能与服务器友好性

v1.10.0 新增

本页描述的是 WCPOS v1.10.0 中引入的同步引擎。若想了解引擎在机制上如何工作，请先阅读 同步引擎的工作原理。

大多数 WCPOS 商店运行在共享 PHP 主机上：只有少量 PHP 工作进程，每个 REST 请求都要完整引导一次 WordPress，还有对突发流量限速的安全插件。那些客户端视为免费的请求会拖慢店面、触发限速器，并与收银员自己的流量竞争——而且会被您运行的每一台收银台和每一个浏览器标签页成倍放大。

v1.10.0 的同步引擎把这一点当作设计约束，而不是事后补救：保护商家的主机是同步引擎职责的一部分。 本页解释引擎遵循的规则以及支撑它们的测量结果。

四条长期规则

引擎中每一项计划性的同步行为都受四条不变式约束：

1. 开销随变化量增长，绝不随目录规模增长。 任何批量获取之前，总会先有一次廉价的摘要或短路检查。一个没有发生变化的 50,000 件产品的商店，其保持同步的开销与一个没有发生变化的 500 件产品的商店大致相同。
2. 不允许无界扇出。 每条后台通道都声明单次运行的请求上限，并由自动化测试强制执行。较大的任务以带可恢复游标的有界批次运行——扫描工作会分摊到它的整个排程中，而不是一次性爆发。
3. 维护绝不挡收银员的路。 让收银台可以开始销售的请求最先运行；完整性审计和后台预热在其后、在空闲时间运行。
4. 压力之下，最先退让的是维护。 当您的服务器发出困难信号时，引擎会先放慢自己的后台工作，然后才会触及任何面向收银员的部分。

同步给您的服务器带来多少开销

稳态开销由 同步预设 决定，它在 商店健康 → 性能 中按设备选择：

预设	检查间隔	每次请求的记录数	名义每日检查次数
节能	5 分钟	25	288
均衡（默认）	60 秒	50	1,440
实时	10 秒	75	8,640

两个调节项都很重要，而对共享主机来说，真正产生开销的通常是页面重量——一页较重的记录会占用实实在在的服务器时间，而间隔只是把它乘以次数。没有任何预设会使用 100 条记录的最大页；这只能通过自定义滑块达到（间隔 5 秒–5 分钟，10–100 条记录）。

在预设之上还有：

• 一次空闲检查开销很低。 引擎发送条件请求，因此无变更的检查只会得到一个无正文的 304 Not Modified 响应——仍然算一次请求，但没有负载，服务器工作量极小。
• 检查带有 ±20% 的抖动，因此一组收银机会把请求分散开，而不是同步成突发流量。
• 空闲的收银台会衰减 到较慢的节奏（10 分钟无交互之后），并在任何活动（包括条形码扫描）时立即恢复。
• 后台维护有上限。 一次无漂移的完整性检查最多只需几个廉价的聚合页，且 零 次明细获取——可被证明与服务器一致的分桶会被直接跳过。当发现漂移时，深入查询每次运行上限为 两次，并通过持久化游标续接，而不是一次爆发。完整的删除审计限制为 每次运行 11 个请求，摘要预热限制为每次运行 5 个分块。这些上限在代码中声明，并由 CI 强制执行。

应用内的“每日请求数”是名义值

商店健康根据所配置的间隔推导出 约 N 次请求/天 的估算值。请把它当作名义检查频率，而不是上限或预测：±20% 的抖动会让实际数量上下浮动，而 304 也仍然算一次请求。空闲衰减只会降低快于其 60 秒下限的预设的请求量；它不会让默认的均衡预设变得更慢。

服务器吃力时的退避

引擎收到的每个响应都会输入到一个按商店划分的压力监控器。它对以下情况作出反应：

• HTTP 429（立即反应），
• 反复出现的 5xx 错误或传输失败（滚动一分钟内出现三次），
• 持续的缓慢（响应时间中位数超过 2 秒），
• Retry-After 响应头，它会成为下一次检查的硬性下限。

其中任何一项被触发时，引擎会 将变更检查间隔逐级加倍，同时维护通道会完全跳过本次运行。收银员驱动的请求——搜索、条形码查询、结账——永远不会被限流；目的是卸掉可推迟的负载，而不是拖慢销售。

恢复过程是有意不对称的：退避是即时的，但间隔只有在 连续十次健康响应 之后才会回落一级，这样不稳定的服务器就不会在快慢节奏之间来回摆动。压力状态也不会因为商家选择了更快的预设而失效——保护机制运行在所配置层级的下方，并且无法被关闭。

保持设备端的响应性

性能的另一半是收银台本身——后台同步绝不能让界面卡顿。

• 审计让位于事件循环。 完整性审计会把工作切成块并在块之间让出，使其最长的不间断执行块保持在约 30 毫秒——低于人类察觉到延迟的约 100 毫秒阈值。在 10,000 件本地产品上实测，一次完整的审计约耗费 68 毫秒 的计算，分散在 17 次以上的让出中；在 50,000 件产品上，低于 300 毫秒。
• 负载之下首个结果依然很快。 即便有批量应用或完整审计并发运行，首个结果的耗时约定也会在 CI 中被固定——在基准测试环境中，典型目录规模下为个位数毫秒。
• 只有可见的那一页会跨入应用。 查询工作（筛选、排序、分页）在存储层内部执行，因此一次屏幕更新搬运的是十行数据，而不是一万行。

这些数字来自引擎固定的性能约定测试套件，它在 CI 中隔离运行，预算设定为实测稳态的大约十倍——目的是捕捉数量级的退化，而不是在缓慢的运行器上判定失败。

已在真实商店中验证

这些友好性规则不只经过单元测试。一次针对真实 WordPress 商店的端到端实测检查，验证了在真实主机上最重要的那些不变式：

• 在开店时产品目录渲染出来之前，维护请求（完整性或摘要流量）为 零。
• 在开店后的保持期结束之后，最多只有少量廉价的聚合页，且深入明细不超过两次。

这个场景来自一次真实的退化：审计的一个早期开发版本在每次开店时、每台设备上都会发出约 41 个请求（1.2 MB）。取代它的摘要门控设计把一次无漂移的审计缩减到只剩聚合页，别无其他——这一类缺陷现在由 CI 中声明的上限来防守，而不是靠人工评审的警觉。

我们不作的声称

有几件事本页有意不去说，因为我们（目前）还没有站得住脚的数据：

• 没有端到端的“初次同步需要 X 分钟”数字。 初次下载时间绝大程度上取决于您服务器的响应时间和目录规模。设备端应用记录的开销很小（批量应用 10,000 件产品实测低于 10 毫秒的计算时间）；网络传输和服务器才是主导因素。
• 没有“比 v1.9 快 X%”的说法。 两者的架构差异足够大，单一的比较数字带来的误导会多于信息。结构性差异列在 v1.10.0 有哪些变化 中。
• 上面的基准数字来自引擎的测试环境（内存存储、隔离运行器）。真实设备和真实商店各不相同；这恰恰就是 商店健康 → 性能 显示您收银台过去 24 小时实测请求数和典型响应时间、而不是显示预测值的原因。其数据量数字是一个下限，因为未声明大小的响应计为零。

有关服务器端调优——主机要求、HPOS、缓存以及诊断慢响应——请参见 服务器性能。