……“什么没有成功？”——在我的职业生涯中，我学到的一般来说，我真的很喜欢可重复性，所以Kafka通常是我的首选，除非我知道重新生成消息非常简单，这时候我更倾向于选择RabbitMQ或SQS。我多次被消息队列（MQ）所困扰，因为无法轻松地重新生成队列，导致丢失了关键消息。“你在哪些地方后悔增加了复杂性？”——再次强调，较小的系统只是“作业队列”（而不是服务间异步通信）不需要太多复杂性。所以我学到，如果是一个小系统，首先使用MQ（任何MQ都可以），只有在你开始超越单个简单系统进行扩展时才使用Kafka。“如果你坚持使用基于数据库的队列——它能扩展吗？”——我过去做过。它能扩展，直到它不能。根据我使用MQ和Kafka的经验，设置MQ/Kafka的工作量微不足道，而使用基于数据库的队列却得不到任何额外的好处。……
源讨论Ask HN：2025年你常用的消息队列是什么？原帖 97 条评论 · 导入时统计这个领域令人困惑至极。 消息队列通常是任何分布式架构的核心部分，选项是无限的：Kafka、RabbitMQ、NATS、Redis Streams、SQS、ZeroMQ……还有“直接使用Postgres”的阵营，用于更简单的用例。 我正在努力理解以下方面的权衡： - 异步的“发布-订阅”与同步的“点对点”通信 - 简单的FIFO队列与优先级队列和延迟队列 - 智能代理（例如RabbitMQ、带过滤器的NATS）与最小代理（例如Kafka的客户端驱动模型） 此外，还存在相当多的意识形态或情感依附——有些人支持他们最喜欢编程语言写的“小众”工具，而另一些人则本能地排斥任何不是“企业级”的东西。当然，供应商也总是参与其中，试图引导对话朝着他们自己的解决方案发展。 如果你已经构建了一个生产系统…
完整原文把你的经验，加入这段讨论。
> 这意味着你只能为每个主题拥有一个客户端，因为一旦消息被消费，它就对其他人不可用了。 这取决于你的使用场景（或者你所说的“客户端”具体指什么）。如果我有一堆需要被“某个”客户端处理的消息，那么当一个客户端处理完消息后，消息就消失，这正是你想要的。
完整原文我们构建应用程序的方式非常不同。多年来，我经常使用SQS队列，有数千个客户端。同样，也有数千个队列（每个客户端设备一个，它们是免费的）。无需维护，未使用时零成本。难以置信的可扩展性。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。