在构建基于 SQLite 的实时通知系统时，开发者面临一个关键抉择：采用轮询机制还是文件系统事件驱动。Honker 项目作为 SQLite 的 NOTIFY/LISTEN 语义扩展，其设计文档详细阐述了选择 stat (2) 轮询而非 FSEvents/inotify 的技术决策依据。本文将从实时性、CPU 占用和延迟三个维度，深入对比这两种方案的性能特征，并为实际选型提供可落地的参数清单。
WAL 轮询方案的实现原理
Honker 采用了一种看似简单却高效的策略：通过 stat (2) 系统调用轮询 WAL 文件的 size 和 mtime 属性变化，以此作为跨进程提交信号。其核心实现包含一个每秒执行 1000 次的 stat 线程，每次轮询开销约 0.5 毫秒， Idle 状态下仅有一次 stat 调用，当 WAL 文件发生变更时，变化会通过 bounded channel 扇出到所有订阅者，每个订阅者随后执行一条基于部分索引的 SELECT 查询获取新数据。
这种设计的关键优势在于跨平台一致性。Honker 明确指出，FSEvents 在 macOS 上会丢弃同一进程内的写事件，意味着如果监听器和写入者在同一个 Python 进程中，FSEvents 将永远无法感知到变更。stat (2) 则不存在这个问题，它在 Linux、macOS 和 Windows 上的行为完全一致，提供了可靠的单机信号机制。从延迟角度看，stat 轮询在 M 系列 Mac 上实现了一至二毫秒的中位数延迟，这一性能足以满足大多数实时任务队列场景的需求。
文件事件驱动机制的特性
FSEvents 和 inotify 代表了操作系统层面的文件事件通知能力，两者都能在事件发生时立即向应用程序推送通知，避免了轮询的固定间隔开销。inotify 是 Linux 内核提供的文件系统监控接口，能够监视特定文件或目录的创建、删除、写入和属性变更等事件，延迟接近于零。然而，当监控大量文件或目录时，inotify 实例的扩展会面临较高的系统调用开销，且内存队列可能因消费者处理不及时而溢出。
FSEvents 是 macOS 的文件系统事件框架，采用批量交付机制并支持延迟参数，能够在短时间内将多次变更合并为一次事件通知，从而降低重复扫描的开销。FSEvents 还具备应用重启后的历史事件回放能力，这是 inotify 所不具备的特性。不过，FSEvents 提供的事件粒度较 inotify 粗糙，应用程序往往需要进行更高层次的状态协调。
值得注意的是，这两个文件系统事件机制在与 SQLite WAL 文件交互时存在特殊问题。由于 WAL 模式的数据库包含.db-wal 和.db-shm 两个辅助文件，且写入模式是通过追加而非覆盖实现，某些文件系统监控工具可能无法正确检测到所有变更。
实时性对比分析
从实时性角度评估，理论上的事件驱动方案应该优于轮询，因为前者能够即时响应而后者存在最大一个轮询间隔的延迟。然而，实际表现需要考虑更多因素。FSEvents 的批量交付机制在高频写入场景下会引入额外延迟，因为系统会等待更多事件累积后再统一交付，这可能导致数秒的感知延迟。inotify 虽然理论上延迟更低，但当监控实例数量超过系统限制时会导致事件丢失。
Honker 的 stat (2) 轮询以一毫秒为间隔，这意味着最大延迟被严格限制在一毫秒以内。在实际测试中，其延迟中位数为一至二毫秒，已经足够接近理论上的即时响应。更重要的是，stat (2) 方案不存在事件丢失风险，因为文件大小和时间戳的变化是单调递增的物理属性，不会因消费者处理速度不足而被丢弃。
CPU 占用与资源消耗
两种方案在 CPU 占用方面呈现不同的特征。stat (2) 轮询的固定开销极低，每毫秒一次的系统调用在现代硬件上几乎可以忽略不计。Honker 的实测数据表明，即使存在上百个订阅者，也仅需一个 stat 线程即可驱动所有监听器，因为唤醒信号通过共享的 channel 分发。空载状态下，stat 轮询几乎不消耗 CPU 资源。
文件事件驱动方案的 CPU 占用模式则更加复杂。在事件发生时，inotify 需要为每个监控实例触发一次回调，如果应用程序在同一事件上注册了多个监听器，处理逻辑会被多次执行。FSEvents 的批量交付虽然降低了事件分发次数，但应用程序需要处理更大的事件批次，可能导致峰值 CPU 占用上升。更关键的是，当消费者处理速度跟不上事件产生速度时，两种机制都面临队列积压问题：inotify 将未交付事件保留在内存中，可能导致内存压力；FSEvents 则将事件持久化到磁盘，虽然缓解了内存问题但增加了 I/O 负担。
延迟参数的量化对比
基于上述分析，可以提炼出以下选型参数供实际决策参考。延迟维度上，stat (2) 轮询的典型延迟为一至二毫秒，最大延迟不超过轮询间隔一毫秒；inotify 的理论延迟接近零毫秒，但在高负载下可能因队列溢出产生秒级延迟；FSEvents 的延迟取决于批量参数设置，延迟参数设为零时接近即时，否则可能累积数十至数百毫秒。
CPU 占用方面，空载状态下 stat (2) 轮询的消耗可视为零，仅有每毫秒一次的系统调用成本；inotify 在空载时同样几乎不消耗 CPU，但每个监控实例会占用一定的内核内存；FSEvents 的空载消耗与 inotify 相当，但批量模式可能在事件处理时产生更高的瞬时 CPU 占用。
可靠性维度上，stat (2) 轮询不存在事件丢失问题，WAL 文件的追加写入模式确保每次变更都会反映在文件大小变化中；inotify 在队列溢出时会丢失事件，需要应用程序处理 IN_Q_OVERFLOW 情况；FSEvents 通过磁盘缓存提供了更强的可靠性保证，但需要应用程序处理历史事件的去重逻辑。
选型决策清单
根据以上对比，可以给出以下场景化建议。当应用场景要求跨进程通知且涉及混合语言绑定时，stat (2) 轮询方案如 Honker 是更稳妥的选择，其跨平台一致性和简单性能够降低维护成本。当监控系统需要监控大量文件或目录时，inotify 的细粒度事件能力更具优势，但需要注意调整 max_user_watches 等系统参数。当应用运行在 macOS 且需要应用重启后的事件恢复能力时，FSEvents 的持久化特性可以简化状态管理逻辑。
对于大多数 SQLite 实时通知场景，stat (2) 轮询已经提供了足够的性能且具备更好的可预测性。Honker 项目的实际部署经验表明，即使面对数千条消息每秒的吞吐量，基于一毫秒轮询的方案也能保持稳定的低延迟表现，同时将 CPU 占用维持在可忽略的水平。
参考资料
- Honker 项目 GitHub 仓库：https://github.com/russellromney/honker
- FSWatch 项目文档：https://github.com/emcrisostomo/fswatch