Honker 最近在开发者圈冒头。它用 Rust 实现为 SQLite 扩展，目标很直接：在 SQLite 里做通知、队列、持久事件流和事务性出箱。

最该注意的不是“SQLite 要替代 Kafka”。这话太满，也太虚。Honker 真正补强的是另一件事：让很多原本要拉 Redis、Celery、RabbitMQ、Kafka 或 Postgres LISTEN/NOTIFY 的小系统，先在一个 SQLite 文件里把异步能力跑起来。

最新资料把旧判断补得更硬：Honker 不只是在 SQLite 里塞一个任务表。它提供了 20 多个自定义 SQL 函数，支持类似 Postgres NOTIFY/LISTEN 的语义，能做 durable streams，还依赖 WAL 模式通过观察 .db-wal 文件接近实时唤醒 worker。更关键的是 transactional outbox：业务事务提交成功，消息才进入队列；事务失败，任务不乱飞。

发生了什么：SQLite 多了一层轻量异步能力

Honker 的核心形态是 SQLite 扩展，不是独立消息服务器。

它目前展示了几类能力：

  • 通知.类似 Postgres 的 NOTIFY/LISTEN，可用 SELECT notify('orders', '{"id":42}') 触发。
  • 队列.应用可以 enqueue 任务，worker 用 claim 认领，处理后 ack。
  • 持久流.类似轻量事件流，可按 consumer 订阅，例如把 user-events 推给 dashboard。
  • SQL 函数.提供 20 多个自定义函数，包括读取 stream 的函数。
  • transactional outbox：消息和业务写入绑在同一个事务结果上。

这最后一点最有价值。很多小团队真正怕的不是“没有队列”，而是“用户表写成功了，邮件任务没发出去”，或者“任务发出去了，业务事务回滚了”。这种裂缝最恶心，排查成本高，复现概率低，半夜最会找人。

Honker 试图把裂缝收窄：数据写入和任务发布同生共死。事务成，消息成；事务败，消息败。

为什么重要：少一个系统，就是少一层债

后端工程有个坏习惯：一见异步，就默认 Redis；一见事件流，就喊 Kafka；一见后台任务，就套 Celery。大公司这么干有理由。小产品照抄，常常是在给自己加刑。

SQLite 的基本盘一直很清楚：单文件、本地优先、部署轻、嵌入方便。它适合桌面软件、CLI 工具、移动端、本地优先应用、小型 SaaS、边缘节点。Honker 顺着这条路走，没有把 SQLite 打扮成分布式神兽。

受影响最大的不是普通用户，而是两类开发者：

对象过去常见做法Honker 改变了什么
独立开发者、小团队SQLite + cron + 临时脚本，或硬上 Redis/Celery后台任务可以更规整，部署仍然轻
桌面、本地优先、边缘应用本地数据库和事件机制分开做事件、任务、业务数据可以落在同一套 SQLite 语境里

这不是性能炫技。它更像减法工程。

《道德经》里说“知止不殆”。放在这里很贴切。Honker 的可贵之处，不是它想接管所有消息系统，而是它知道很多项目根本不该那么早拥有一套消息系统。

边界在哪里：它不是 Kafka，也不是 RabbitMQ

把 Honker 叫成“SQLite 版 Kafka”，听着爽，判断上不合格。

Kafka 的关键不只是持久日志。它有分区、有复制、有消费者组、有跨机器容错、有吞吐和生态工具。RabbitMQ 也不只是队列，它有路由、确认、重试、死信、协议和成熟运维模型。Postgres LISTEN/NOTIFY 本身也不是任务队列银弹。

Honker 更像一把短刀。短刀不攻城，但随身好用。

它的现实限制也已经露出来：

  • 需要 SQLite WAL 模式。
  • worker 可每 1ms 对 `.db-wal 文件做一次 stat` 轮询，以减少完整 SQL 查询开销。
  • “接近实时”不是“真正推送”。
  • 轮询成本低，不等于没有成本。
  • 单文件数据库方便，不等于获得分布式消息系统的扩展性。

这几个细节很重要。它们把 Honker 从营销口号拉回工程事实：能省掉一批默认基础设施，但不能替你解决高吞吐、多节点、跨区域、复杂背压和严格隔离这些问题。

如果你的系统已经有 Kafka，不必为了新鲜感迁走。如果你的队列吞吐很高，worker 很多，失败重试复杂，死信和监控已经成体系，Honker 也不是更优解。

但如果你只是要发邮件、生成缩略图、同步本地事件、推送 dashboard、记录用户行为变更，它就很香。因为你要的不是帝国，是一间能住人的屋子。

我更在意它暴露出的行业病

Honker 让我喜欢的一点，是它戳中了后端行业的默认膨胀。

很多架构图不是为业务画的，是为安全感画的。Redis 一层，队列一层，worker 一层，监控一层，部署一层。看起来专业，实际上把一个低并发产品提前拖进了运维泥潭。

“天下熙熙，皆为利来。”基础设施也一样。每多引入一个系统，就多一个学习成本、多一个故障面、多一个版本升级、多一份值班焦虑。供应商、云平台、资深工程师都可能从复杂性里获益。真正买单的，常常是那个只有两个人的小团队。

Honker 的意义就在这里：它不是把 SQLite 神化，而是提醒开发者别把架构复杂化当成年礼。

历史上类似的事反复发生。PC 早期很多软件把数据、状态、任务都放在本地，后来互联网服务化把一切拆散；拆散有它的红利，也带来了新的税。今天本地优先、边缘计算、轻量部署重新变热，不是怀旧，而是大家发现“全都上云、全都分布式”并不总是便宜。

这个类比不完全一样。今天的软件要面对同步、协作、安全和跨设备。但底层人性很像：工具一旦变强，工程师就想多用；系统一旦可拆，组织就想多拆。拆到最后，产品没变强，值班表先变厚。

Honker 给出的不是万能药，而是一条更克制的路：在规模真正到来前，别提前支付规模的成本。

接下来该看什么

现在还不能把 Honker 当成熟基础设施吹。

最该盯三个变量：

  • 吞吐和延迟基准.低并发好用，不代表高并发不抖。
  • 崩溃恢复语义.进程挂掉、长事务、ack 前后失败时，队列状态是否清楚。
  • 多语言绑定稳定性.Python 示例漂亮，但真实项目还要看 Node、Go、Rust 等生态是否可靠。

还有一个细节不能忽略：1ms WAL 轮询在服务器、笔记本、边缘设备上的成本不一样。文件系统、睡眠唤醒、容器环境、网络盘，都可能把“轻量”变成“微妙”。

所以我的判断很简单：Honker 适合把小系统从 Redis/Celery 的默认负担里救出来，不适合拿来冒充 Kafka。它赢在知止，也必须守住知止。一旦开始许诺分布式消息帝国，它就会输在自己最初反对的复杂性上。