在分布式系统设计中，跨进程事件推送一直是一个核心挑战。传统方案依赖外部消息队列（如 Redis、RabbitMQ），但这意味着引入额外的存储系统和运维成本。honker 项目提供了一种优雅的替代方案：利用 SQLite 的 WAL（Write-Ahead Logging）机制，通过 stat (2) 系统调用轮询文件变更，在不使用内核事件通知的情况下实现了单毫秒级的跨进程事件推送。本文将深入解析其技术实现细节。
WAL 模式的核心优势
honker 的设计理念建立在 SQLite WAL 模式的独特特性之上。与传统的 DELETE 日志模式不同，WAL 模式会将修改追加到独立的 .db-wal 侧写文件中，而不是直接修改主数据库文件。这一设计带来了三个关键特性，使其成为事件推送的理想基础设施。
首先，WAL 模式支持读写并发。多个读者可以在写者持有锁的同时读取数据，而不会阻塞写操作。其次，WAL 文件在每次提交时都会增长，其大小和修改时间是单调递增的变化信号，这为检测提交事件提供了可靠的物理指标。最后，WAL 的这种结构意味着任何进程都可以通过观察 WAL 文件的变化来判断是否有新事务提交，而无需轮询数据库内容。
honker 在启动时会强制要求数据库处于 WAL 模式。如果检测到非 WAL 模式的文件后端数据库，honker_bootstrap() 函数会拒绝初始化。语言绑定在默认打开路径中也会设置 PRAGMA journal_mode = WAL，确保始终使用 WAL 模式。
为什么选择 stat (2) 而非内核事件通知
在文件变更检测领域，Linux 提供了 inotify，macOS 提供了 FSEvents，BSD 系统提供了 kqueue。这些内核事件通知机制看似是更优的选择，因为它们可以在文件变化时主动通知应用程序，避免了轮询的开销。然而，honker 选择了 stat (2) 作为唯一的文件变更检测手段，这一决策背后有深思熟虑的技术考量。
FSEvents 在 macOS 上存在一个关键限制：它会丢弃同一进程内的文件写事件。这意味着如果一个进程的写入者通过 FSEvents 监听同一数据库文件的变化，监听器将永远无法收到来自同一进程写入的通知。对于需要实现进程内和进程间统一通知机制的 honker 来说，这是不可接受的。
inotify 和 kqueue 虽然没有同进程丢弃的问题，但它们在跨平台实现时引入了复杂的条件分支。每个操作系统需要不同的 API、不同的监视标志、不同的行为语义。stat (2) 则提供了一个完全统一的接口，在 Linux、macOS 和 Windows 上的行为完全一致。虽然 stat (2) 轮询会带来约 0.5 毫秒的理论延迟上限（相比内核通知的即时触达），但这种延迟在实际工作负载中几乎可以忽略不计，而获得的跨平台一致性和可靠性才是关键。
轮询实现的技术细节
honker 的轮询机制实现精致而高效。核心组件是 SharedWalWatcher，它维护一个独立的轮询线程，以固定的 1 毫秒间隔检查 WAL 文件的状态。轮询线程不执行任何 SQL 查询，只是执行轻量的 stat (2) 系统调用，读取 .db-wal 文件的元数据（主要是文件大小和修改时间）。
当检测到 (size, mtime) 发生变化时，轮询线程会向每个订阅者的 bounded channel 发送一个 tick 信号。这个 fan-out 机制设计巧妙：无论有多少个并发监听器，整个数据库只需要一个轮询线程。每个调用 db.wal_events() 的监听器都会注册为一个订阅者，获得一个独立的 channel。轮询线程检测到变化后，依次向所有 channel 发送信号，唤醒所有正在等待的监听器。
这种设计实现了近乎零成本的监听器扩展。100 个并发监听器不会导致 100 次 stat (2) 调用，只会触发 1 次系统调用加上 channel 发送的边际成本。而当没有任何监听器活跃时，轮询线程仍然运行但只消耗极少的 CPU（每次 stat 调用约 1 微秒）。
监听器的实现采用迭代器模式。当收到 WAL 变化的 tick 信号后，每个监听器执行一条带有条件过滤的 SELECT 查询：SELECT … FROM table WHERE id > last_seen。通过在 WHERE 子句中比较主键与上次已见到的最大 ID，实现增量读取。这个查询利用部分索引（partial index）加速，确保只扫描活跃行而非整个表的历史数据。
过度触发与可靠性权衡
honker 的架构有一个重要的设计取舍：WAL 变化会唤醒数据库上的每一个订阅者，而不是只唤醒与该变化相关的订阅者。这意味着即使某个监听器关注的是完全不同的表或通道，只要数据库有任何提交发生，它都会被唤醒并执行一次 SELECT 查询来检查是否有新数据。
这种「过度触发」的行为是故意的。开发者认为，错过一次通知是静默的正确性错误，而多执行几次无关的 SELECT 查询只是轻微的性能浪费。相比漏掉重要事件的风险，过度触发是可以接受的代价。多个小查询在 SQLite 中非常高效，因为 SQLite 优化了这类短查询的执行路径。实际的性能测试表明，即使在每秒数千次提交的高负载下，系统仍能保持稳定的吞吐量。
这种设计还带来了一个额外的好处：监听器不需要提前声明感兴趣的事件通道。通道过滤发生在 SELECT 阶段而非触发阶段，这简化了订阅机制的实现，同时保持了足够的灵活性。
与 Postgres 语义的对齐
honker 的最终目标是完整模拟 PostgreSQL 的 LISTEN/NOTIFY 语义。在 Postgres 中，一个会话可以监听某个通知通道，另一个会话可以向该通道发送通知，通知是即时的且不持久化。honker 通过三个原语实现了这一目标的各个侧面。
notify() 函数提供最基础的即发即忘语义，它向 _honker_notifications 表插入一条记录（而非真正通过内核通知），然后通过 WAL 轮询机制唤醒监听者。stream() 提供持久的发布订阅，每个命名消费者跟踪自己的偏移量，支持重放历史消息。queue() 提供至少一次交付的工作队列语义，支持认领、确认、重试和死信处理。
所有三种原语都支持与业务写事务原子提交。通过在同一个 db.transaction() 块中执行业务 INSERT 和队列 / 流 / 通知操作，事务提交时两者同时持久化，事务回滚时两者同时丢弃。这正是「事务性发件箱模式」的核心思想，而 honker 将其作为默认行为内置，无需额外安装库或配置。
性能表现与适用边界
honker 的性能测试结果显示，在现代笔记本电脑上能够处理每秒数千条消息，跨进程唤醒延迟受 1 毫秒的 stat 轮询周期限制，中位数约为 1 到 2 毫秒。这已经非常接近内核事件通知的延迟水平，同时保持了跨平台的简单性和可靠性。
需要明确的是，honker 适用于单机单写场景。SQLite 的锁机制设计针对单主机优化，在 NFS 等共享文件系统上多服务器写入同一数据库会导致数据损坏。如果需要多写架构，应该按文件分片或切换到 PostgreSQL。对于单服务器内的多进程协作（典型的 Web 应用 + 后台 worker 架构），honker 提供了一个轻量且强大的解决方案。