在现代软件的世界中，人们越来越渴望那些即使在没有互联网连接时，也能感觉像是运行在本地设备上的应用程序。这种通常被称为“本地优先”（local-first）的软件方法，允许你在离线时编辑文档或更新列表，待连接恢复后再将更改发送到中央服务器。挑战在于连接恢复的那一刻：计算机如何决定哪个版本的数据是正确的，以及如何在不让用户等待的情况下，尽可能快地更新中央服务器？为了使这一过程顺畅运行，系统需要一种可靠的方式来监听新信息并即时交付。如果更新太慢，用户会感到延迟；如果系统过于复杂，则会消耗电池或导致崩溃。工程师的核心问题在于如何构建这种监听机制：是让设备不断询问服务器是否有变化，还是让服务器立即向外广播变化，亦或是让数据库本身保留一份可供稍后读取的操作日志？
印度理工学院卡拉格普尔分校的一位研究人员着手对这三种常见的策略进行并排测试，以观察在受控环境下哪种策略的表现实际上最好。该研究对比了三种方法：一种是客户端按固定时间间隔检查更新的方法；一种是服务器通过永久连接即时推送变化的方法；以及一种是数据库向订阅者流式传输变更日志的方法。为了确保测试公平，研究人员构建了三个在用户看来完全相同、但内部机制不同的系统。其中一个系统使用标准数据库配合简单的“签到”循环；另一个使用相同的数据库，但添加了一个在发生变化时触发信号的触发器；第三个系统则使用了另一种旨在流式传输其自身历史记录的分布式数据库。其目标是测量用户所做的更改通过系统传输并在监听器屏幕上显示的精确时间，测试范围涵盖了从单个用户到五十个用户同时写入的情况。
结果清晰地描绘了每种方法在压力下的表现。依靠服务器通过永久连接即时“大声喊出”变化的系统被证明是最快的。在最佳情况下，变化仅需两毫秒即可出现在监听器的屏幕上，即使在五十人同时写入时，延迟也极少超过六十三毫Milliseconds。这种方法保持了极其稳定的速度，即使是最慢的更新也在不到四分之一秒内到达。依赖于客户端每百毫秒请求一次更新的方法虽然可预测，但速度较慢。由于客户端必须等待轮到自己询问，平均延迟约为六十毫秒，但它永远无法比两次检查之间的时间间隔更快。当许多用户同时写入时，这种等待时间会增加，将平均延迟推高到一百毫秒以上。使用数据库内部变更日志的系统表现则毁誉参半。虽然典型的更新到达得很快（通常在不到一秒内），但该系统在处理最慢的几次更新时遭遇了严重的延迟。偶尔，一个变化会花费超过两秒钟才到达，在某些情况下，延迟甚至达到了三秒半以上。
研究人员发现，日志系统中出现最慢更新的原因并非日志记录本身的想法有误，而是由于特定软件的连接方式导致的。该系统使用了一种变通方法来读取数据库日志，因为标准的连接工具无法正确理解数据库的语言。这种变通方法要求在每次连接中断时都启动一个新进程，这为延迟增加了一到四秒的沉重惩罚。如果没有这个特定的技术障碍，基于日志的方法可能会表现得好得多，但在本次测试中，长延迟使其不适用于用户期望即时反馈的应用场景。研究还证实了关于“检查法”的一个简单规则：两次检查之间的等待时间越长，平均延迟就越大。如果系统每五十毫秒检查一次，平均等待时间约为三十六毫秒；如果五百毫秒检查一次，平均等待时间则会跃升至三百毫秒以上。
这些发现为构建需要保持同步的软件提供了实用的指南。对于对速度要求极高的应用，例如用户实时共同协作的编辑工具，由服务器即时推送变化的方法是明确的选择。它提供了最低的延迟和最一致的性能，即使在许多人同时使用系统时也是如此。客户端定期检查更新的方法对于那些可以接受数百毫秒延迟、或者维持连接较为困难（例如移动设备为了节省电量）的简单应用来说是一个可靠的选择。而流式传输数据库日志的方法对于移动大量数据或创建备份非常强大，但本次测试的具体实现对于交互式使用来说过于缓慢且不可预测。研究结论指出，虽然这三种方法都有效，但最佳选择完全取决于优先级是瞬时响应性还是操作的简易性。
技术摘要：实时数据库同步架构基准测试
问题陈述
“本地优先”（local-first）和“离线优先”（offline-first）软件范式的兴起，要求必须具备高效的机制来同步客户端数据存储与中央服务器数据库。虽然目前已出现三种主流架构来解决这一问题——REST 轮询（REST polling）、WebSocket 推送（WebSocket push）以及变更数据捕获（CDC）——但它们缺乏在相同实验条件下进行的系统性、并排对比基准测试，特别是在针对移动端和浏览器端同步的端到端延迟方面。现有文献通常侧重于一致性语义（如 CRDTs）或分布式事务一致性，而未解决用户体验所需的特定延迟粒度问题。
研究方法
本研究通过使用 FastAPI 后端服务器进行受控基准测试，对比了这三种架构。实验设计通过在单台机器（macOS, Apple Silicon）上运行所有组件，从而隔离了同步架构，并消除了网络抖动这一变量。
系统架构
- REST 轮询（架构 A）： 客户端定期查询
/poll 端点（默认间隔 100 ms），以获取自水印时间戳以来的变更。至关重要的一点是，轮询循环被实现为一个独立的、固定调度的定时器，从而纠正了常见的基准测试错误（即在写入操作后立即触发轮询）。
- WebSocket 推送（架构 B）： 服务器维护持久的 WebSocket 连接。通过 PostgreSQL 的
LISTEN/NOTIFY 机制（由行级数据库触发器触发）实现变更的实时广播。
- CockroachDB CDC（架构 C）： 消费数据库内部的复制日志，通过
EXPERIMENTAL CHANGEFEED 实现。由于存在协议不兼容问题（详见下文），该架构通过一个流式传输 cockrox sql CLI 输出的子进程来实现，随后将输出广播给 WebSocket 客户端。
实验协议
- 工作负载： 每个测试用例包含 80 次写入操作，涵盖五个并发水平（1, 5, 10, 25, 50 个并发写入者）。
- 指标： 端到端同步延迟（L=trecv−tsend），测量从发出写入请求到监听器接收到相应变更事件之间的时间。
- 试验： 架构 A 和 B 进行了三次独立试验（每个单元 240 个观测值）；由于架构 C 的单次试验时间成本较高，仅进行了一次试验（100 个观测值）。
- 敏感性分析： 对架构 A 在不同轮询间隔（50, 100, 250, 500 ms）下的表现进行了测试，以表征延迟与频率之间的权衡关系。
核心贡献
- 公平实现： 所有三种架构均使用符合惯用法（idiomatic）的 Python/FastAPI 实现，并采用等效的 Schema，从而实现了直接的延迟对比。
- 正确的轮询方法论： 本研究实现了一个真正的独立轮询循环，无论写入活动如何，都会按固定调度运行，解决了以往基准测试中的缺陷。
- 全面的指标： 研究报告了中位数（P50）、标准差、P95 和 P99 延迟，提供了对典型性能和尾部延迟（tail latency）的细粒度观察。
- 发现协议不兼容性： 作者记录了
asyncpg 的扩展查询协议与 CockroachDB 变更馈送（changefeed）游标语义之间的特定不兼容性，并提供了一个基于子进程的有效变通方案。
- এতে 敏感性分析： 研究确定了 REST 轮询间隔与同步延迟之间存在近似线性的关系。
结果
延迟性能
- WebSocket 推送（架构 B）： 在所有并发水平下均实现了最低的中位数延迟，范围从 2.2 ms（1 个并发写入者时）到 63.2 ms（50 个并发写入者时）。其 P99 尾部延迟保持在可预测范围内（10–227 ms）。
- REST 轮询（架构 A）： 交付了与轮询间隔一致的有界延迟。在 100 ms 间隔下，P50 延迟范围为 60.5 ms 至 140.8 ms。其 P99 延迟最多受限于两个轮询间隔（109–210 ms）。
- CockroachDB CDC（架构 C）： 展现了具有竞争力的中位数性能（22.7 ms 至 93.9 ms），但表现出极高的尾部延迟，其 P99 值在 2.2 s 至 3.6 s 之间波动。
敏感性分析
REST 轮询间隔实验证实了轮询间隔与延迟之间呈近似递增关系。在单机环境下的经验近似公式显示，P50 延迟约为轮询间隔的 0.6 倍，其余部分归因于 HTTP 往返开销。
协议不兼容性
研究发现 asyncpg 的扩展查询协议（使用命名端口/named portals）与 CockroachDB 的变更馈送实现不兼容，因为后者会在每次 Execute 响应后关闭端口。这导致无法通过 asyncpg 进行可靠的流式传输。作者通过在子进程中通过 cockroach sql CLI 流式传输变更馈送解决了此问题，尽管这引入了 1–4 秒的重连开销，并主导了尾部延迟。
意义与结论
本文声称提供了第一个针对移动端/浏览器同步用例，对这三种特定架构进行受控、可复现对比的基准测试。
- WebSocket 推送 被确定为延迟敏感型、交互式协作功能的最佳选择，它提供了最低的中位数延迟和可预测的尾部行为。
- REST 轮询 推荐给那些优先考虑运维简单性、且可以接受数百毫秒延迟场景的团队。它为设计延迟服务水平协议（SLA）提供了最可预测的行为。
- CockroachDB CDC 虽然在架构上具有吸引力（适用于最终一致性的批量同步），但在本文测试的实现下，被发现不适用于交互式同步，因为其尾部延迟过高（2–4 秒）。作者指出，这部分是由于子进程变通方案和已解决时间戳（resolved-timestamp）批处理导致的，这表明使用具有更短解析间隔的原生流式客户端可能会得到不同的结果。
研究明确指出，其结论仅限于单机部署，并指出在分布式环境中，由于网络 RTT 的存在，绝对延迟数值将会增加，但相对排名预计将保持稳定。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。