问HN：在2025年，你最常用的消息队列是什么？
这个领域至少可以说是令人困惑的。<p>消息队列通常是任何分布式架构的核心部分，选择几乎是无穷无尽的：Kafka、RabbitMQ、NATS、Redis Streams、SQS、ZeroMQ……还有“只需使用Postgres”的阵营，适用于更简单的用例。<p>我正在试图理清以下几个方面的权衡：<p>- 异步的“发而不顾”的发布/订阅 vs. 同步的类似RPC的点对点通信<p>- 简单的FIFO队列 vs. 优先级队列和延迟队列<p>- 智能代理（例如RabbitMQ、带过滤器的NATS） vs. 简单代理（例如Kafka的客户端驱动模型）<p>此外，还有相当多的意识形态/情感依附——有些人支持用他们喜欢的编程语言编写的“黑马”，而其他人则本能地拒绝任何不是“企业级”的东西。当然，供应商总是试图将讨论引导到他们自己的解决方案上。<p>如果你在过去几年中构建了一个生产系统：<p>1. 你选择了哪个队列？<p>2. 有什么没有成功的？<p>3. 你在哪些地方后悔增加了复杂性？<p>4. 如果你坚持使用基于数据库的队列——它是否能够扩展？<p>我很想听听大家的经历、遗憾和看法。
查看原文
The space is confusing to say the least.<p>Message queues are usually a core part of any distributed architecture, and the options are endless: Kafka, RabbitMQ, NATS, Redis Streams, SQS, ZeroMQ... and then there's the “just use Postgres” camp for simpler use cases.<p>I’m trying to make sense of the tradeoffs between:<p>- async fire-and-forget pub/sub vs. sync RPC-like point to point communication<p>- simple FIFO vs. priority queues and delay queues<p>- intelligent brokers (e.g. RabbitMQ, NATS with filters) vs. minimal brokers (e.g. Kafka’s client-driven model)<p>There's also a fair amount of ideology/emotional attachment - some folks root for underdogs written in their favorite programming language, others reflexively dismiss anything that's not "enterprise-grade". And of course, vendors are always in the mix trying to steer the conversation toward their own solution.<p>If you’ve built a production system in the last few years:<p>1. What queue did you choose?<p>2. What didn't work out?<p>3. Where did you regret adding complexity?<p>4. And if you stuck with a DB-based queue — did it scale?<p>I’d love to hear war stories, regrets, and opinions.