News Hacker｜极客洞察

🎯 讨论背景

讨论起源于一篇把 Kafka 与在 Postgres 中实现事件日志/队列对比的文章。参与者围绕吞吐、延迟、事务一致性、消费者偏移管理以及运维/团队成本展开辩论，既有声称在生产中用 Postgres 做队列能满足多数需求的案例，也有指出 Kafka/Redpanda 在小机器上能提供远高吞吐的证据。对话中频繁提到的技术与项目包括 Redpanda（Kafka-compatible 消息代理）、pgmq/PGQueuer/pgflow（将 Postgres 当作队列的库）、KRaft（Kafka 去除 Zookeeper 的元数据架构）、以及替代品如 Redis Streams、NATS JetStream、Apache Pulsar 和 CDC/逻辑复制工具。总体讨论集中在“当下的需求与团队能力”如何决定是否引入专用消息系统还是优先用已有 RDBMS。

📌 讨论焦点

Postgres 作为事件日志/队列（简化堆栈）

一部分评论者主张把事件日志或工作队列直接存在 Postgres，以简化运维和开发流程并利用事务一致性（比如 outbox 模式），这样能把消息处理与业务数据写入捆绑在同一事务中以接近“exactly-once”的效果。实践案例被多次提及：有人在生产中用 Postgres 做队列实现数千到上万条/秒（评论中提到 5–10k msg/s），也有人用单节点 RDS 处理几百 KB/s 的日志流，成本远低于新增分布式消息系统。Postgres 的单库快照与 point-in-time-recovery 对故障恢复很有用，且已有若干社区项目（如 pgmq、PGQueuer、feedapi-spec/pgflow）在填补生态空白。主要限制是客户端/生态层面的工具不够成熟：实现可回放的消费者游标、错误处理和多订阅方的 fanout 仍需额外工程工作。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]

Kafka/Redpanda 等专用消息系统适合高吞吐与多消费者场景

另一派强调 Kafka（及兼容实现如 Redpanda）天生为分布式 append-only log 设计，分区（partition）和 consumer group 机制让不同消费者独立维护偏移量并并行处理，从而在较小硬件上实现极高吞吐。评论里引用了 Redpanda 在笔记本上演示 250k msgs/s、历史上 Kafka 在特定配置下接近百万写入/s 的实例，且 Kafka 的元数据演进（例如 KRaft 取代 Zookeeper）和 fsync/复制语义在可靠性上有成熟讨论。批评者指出原文在 96 vCPU 上测 Postgres 得到较低吞吐是误导性的：正确调优的 Kafka/Redpanda 在更小资源上通常能跑更高吞吐。尽管如此，评论也提醒 Kafka 并非万能，误把它当作传统 work-queue（有 per-message ack、DLQ 等语义）是一种常见误解。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]

工程权衡：性能之外的团队、运维與成本考量

许多评论把讨论焦点从原始吞吐转向组织与成本权衡：采用 Kafka 带来学习曲线、运维开销和长期支出（有评论提到为多套 Kafka 集群付出高额成本），即便是托管服务也不能完全消除 API、客户端配置与开发负担。“简历驱动设计”被反复指出——新技术的倡导者离职后，遗留团队要承担复杂系统的维护成本。评论普遍建议按业务需求与团队能力选型：若流量和并发不大，先用 Postgres 快速交付并让瓶颈自然显现，再在必要时迁移到专用系统；同时指出 NATS、Redis Streams、Pulsar 等可作为折中选项以减少运维或复杂度。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]

在 Postgres 上重现 Kafka 特性的技术难点

把 Kafka 那类可回放、全序号的事件日志在 Postgres 上重建涉及若干分布式一致性与并发陷阱，评论详细讨论了“唯一单调递增偏移”问题：序列号若在事务提交前分配会导致读者漏读或被永久卡住，常见解决办法（独立计数表加锁、事务后批量分配、补 noop）各有串行化或复杂性代价。其他 Postgres 特有的问题还包括 LISTEN/NOTIFY 的扩展性有限、频繁删除带来的 vacuum/GC 成本、以及实现 Kafka 式 consumer group 所需的心跳、代际和提交协调逻辑。实践者指出 SELECT FOR UPDATE SKIP LOCKED 能很好地支持工作队列取任务，但要实现可回放的多消费者日志并独立管理偏移，往往需要额外的服务端/客户端库支持。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]

可替代的轻量方案与生态（Redis、NATS、Pulsar、pgmq 等）

不少评论推荐中间选项：Redis Streams 可提供带 consumer group 的事件日志语义并且部署简单；NATS JetStream 被多次点名为低运维、高性能的折中方案；Pulsar 可同时提供队列与流的语义（多种 subscription 类型），但自建集群相对复杂。Postgres 生态已有专门库（pgmq、PGQueuer、pgflow）用 SELECT FOR UPDATE SKIP LOCKED + LISTEN/NOTIFY 把数据库变成持久化队列，PGQueuer 还实现了重试、调度与 graceful shutdown 等特性。评论呼吁需要一个更完善的“Kafka-in-SQL”客户端/库以降低重复造轮子，或采用 CDC（Change Data Capture）与逻辑复制工具把 DB 改动作为事件源。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]

📚 术语解释

consumer group: 在 Kafka 等流处理系统中，consumer group 是一组消费者共享同一组 topic 的消费责任，组内每个分区只会分配给组内的一个消费者，从而实现并行处理同时保证每条消息被组内某个实例处理一次。

partition（分区）: Kafka 中的 partition 是把 topic 拆分为多个有序子日志的单位，分区提供并行性和顺序保证：同一分区内消息有严格顺序，但不同分区之间无全局顺序。

offset / event sequence number（偏移量／事件序号）: 消费者用 offset（或游标）记录已读取到的事件位置；对于可回放和多消费者语义，必须保证偏移量的递增与可控回退，否则会出现漏读或重复读的问题。

SELECT FOR UPDATE SKIP LOCKED: Postgres 中并发取任务的常用模式：对未处理行加锁并跳过被其它事务锁定的行，从而让多个工作者安全并发地从同一表中取任务，适合工作队列场景。

LISTEN/NOTIFY: Postgres 的内建轻量化 pub/sub 机制，允许会话通过 NOTIFY 发信号、其他会话通过 LISTEN 接收通知；优点是低实现成本，但在高并发或大规模 fanout 场景下存在扩展性和可靠性限制。

outbox pattern: 一种把事件写入数据库同一事务中的模式：业务变更和要发布的事件一起写入“outbox”表，由后台进程异步读取并发送到消息总线，从而实现事务性事件发布与较强的一致性保障。