……另外我喜欢卡夫卡，是因为大约十年前我在旧金山遇到了两个漂亮的俄罗斯女孩，我们那个小组玩了一个游戏，我们用抽象的方式描述自己工作的公司是做什么的，然后尝试猜出这是哪家创业公司。他们说“我们编写分布式流媒体软件”，我立刻猜到了“Confluent（康威森）”。当时Confluent还很新，规模也很小。那晚很有趣。那个时代很有趣。
源讨论为什么创建了Apache Kafka？原帖 221 条评论 · 导入时统计把你的经验，加入这段讨论。
> Kafka 能够接收海量数据流，并将其呈现为可调节的可消费数据，供许多不同的应用程序使用，这一点非常好。 我正是为了这个原因而使用 Kafka。根据文档，Redis 集群流有 AOF 持久化日志。它的稳定性如何？
完整原文> 转而使用 Redis 集群流（Redis Cluster Streams）吧。管理起来简单得多，运行成本也低很多。 我对 Redis 集群流没有任何经验。你能告诉我们它为什么更易于管理吗？在我看来，在非财富 100 强规模下安装和管理 Kafka 集群其实已经很简单了：运行一个 Java 命令启动 Zookeeper，再运行另一个 Java 命令启动一个 broker（在较新的 Kafka 版本中，Zookeeper 已经不需要了）。配置文件不是非常简单，但也不太复杂。当我们有另一台机器时，可以在上面运行另一个 broker。 Redis 集群流运行成本更低，是因为它用 C 编写，不需要虚拟机来运行？还是因为它的消息存储在 RAM 而不是 SSD 中？
完整原文喜欢这个故事！ > Kafka 是最早完全接受放弃 CAP 定理中的 C（一致性）的系统之一，这对大规模网络应用来说是一个巨大的进步。 你能详细解释一下吗——什么时候会放弃 C？你是指在写入 Kafka 时没有等待所有副本确认写入吗（acks=1）？ 而且为什么这是一次巨大的进步——还有哪些其他系统没有放弃 C？
完整原文> 那些 SQL 数据库并不适合从写入的“消防水带”中读取 现在我开始怀疑，我们是不是在过度思考，其实只要使用一种“会合哈希”和一些数据库服务器，表名叫做“eventlog”，就可以解决问题了……
完整原文很久以来我一直想知道，我们是否可以为 Postgres 开发一个扩展，允许创建物理上有序、只能追加的表。 使 Postgres 不太适合 Kafka 类型日志的两个主要原因是：表对于顺序数据的处理效率不高，而且删除操作会导致数据膨胀，直到被 vacuum 清理。通过提供一个新的表引擎（表访问方法），可以解决这两个问题，不过我不确定是否能以所需的程度控制堆存储的位置，以实现物理上有序的表。但你也可以通过很多技巧让删除操作更快（因为只能追加，所以可以安全地从头部删除，而无需 MVCC 机制？）并让过滤更快。 当然，Kafka 的功能远不止这些，但我觉得用这种方法也可以实现很多功能。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。