… 数据库人员可能是在努力迎合队列。理想情况下，我会对数据进行规范化并建立关系模型，这样事务就不会锁定整个表。然后我开始质疑，当数据库（除了SQLite，它本身已经足够快）是用来对数据库进行池化访问的，我为什么还需要队列。Kafka支持将数据管道传输到关系型数据库，但在这部分你必须有经验，否则很容易出错，而我还没有达到那个水平。我认为将它用作队列，即绕过关系型数据库管道，这在Kafka中是非标准的。我怀疑这就是很多对Kafka的厌恶的来源。如果分布式事务部分很麻烦，我理解，但那时你为什么还要跳过数据库呢？我想你是在试图获得免费的午餐。我有一个替代方案。尝试将所有内容插入到一个SQLite文件中。遇到并发问题？使用第二个SQLite文件。两台电脑？通过网络发送。更多问题？既然它是SQL，就切换到一个真正的数据库，它可以对客户端进行池化。…
源讨论Ask HN：2025年你常用的消息队列是什么？原帖 97 条评论 · 导入时统计这个领域令人困惑至极。 消息队列通常是任何分布式架构的核心部分，选项是无限的：Kafka、RabbitMQ、NATS、Redis Streams、SQS、ZeroMQ……还有“直接使用Postgres”的阵营，用于更简单的用例。 我正在努力理解以下方面的权衡： - 异步的“发布-订阅”与同步的“点对点”通信 - 简单的FIFO队列与优先级队列和延迟队列 - 智能代理（例如RabbitMQ、带过滤器的NATS）与最小代理（例如Kafka的客户端驱动模型） 此外，还存在相当多的意识形态或情感依附——有些人支持他们最喜欢编程语言写的“小众”工具，而另一些人则本能地排斥任何不是“企业级”的东西。当然，供应商也总是参与其中，试图引导对话朝着他们自己的解决方案发展。 如果你已经构建了一个生产系统…
完整原文把你的经验，加入这段讨论。
这更多是关于数据库人员或不是的问题。 我们中的许多人使用过两边，然后选择了一个领域开始。 Kafka 等工具非常棒。但通常在最初几个月或几年内都过于复杂。 用像 Postgres 这样的东西首先建模你的队列并不是太大的跳跃，它奇怪地提供了一些传统关系型数据库之外的功能，当领域中的模型实现显现出来时，它可以在 Kafka 等方向上发出很好的光芒。
完整原文我已经花时间校对过它，但忘了我这么久之后不能编辑它。除非仁慈的管理员允许我掷12面骰子来替换上面的尴尬内容，换成我用肥皂雕刻出的下面这段内容。 --- 我总是会检查我编程语言中是否有维护良好的消息库。Kafka、ZeroMQ 和 NATS 在许多语言中的绑定都是一致的。 Kafka 是一个预写日志，而不是一个队列。它处理到磁盘的事务。网络是简单的广播，而不是共享队列。你也不能（至少在标准意义上）弹出/插入/删除行。它是追加-only 的。它只能进行基本的查找，比如从头开始重放。 ZeroMQ 是学习的好选择，因为它有出色的文档，适合对 C 编程感兴趣的程序员。可能是一个进入 Beej 网络指南的好途径。ZeroMQ 是一个特例，因为它没有中央代理（"Zero"…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。