Apache Kafka
Apache基金会旗下的分布式流数据平台，已成为流数据处理的事实标准，受益于Apache的厂商中立治理结构
核心事实
时间轴 (近 90 天)
RabbitMQ、Apache Kafka 和 Cloudflare Queues 三者共通的语义是「至少一次投递」，消息代理保证消息最终被消费但不保证只被消费一次。
RabbitMQ 基于 AMQP 协议，支持复杂路由规则与消息确认机制；Apache Kafka 以分布式提交日志为核心，具备高吞吐与分区有序性，支持回放消费；Cloudflare Queues 是边缘原生的无服务器队列，按需弹性伸缩。
事件驱动拓扑用异步发布/订阅模型替代同步循环，底层由 RabbitMQ、Apache Kafka 或 Cloudflare Queues 等消息代理支撑。
消息队列采用生产者-消费者模型，常见实现包括RabbitMQ、Apache Kafka、RocketMQ
Kafka 的核心模型基于「主题（Topic）+ 分区（Partition）+ 消费者组（Consumer Group）」三层结构，通过 offset 追踪消费进度
对于已深度运行自建 Kafka 且有成熟运维团队的大型组织，迁移到 K2 的动力可能不足
在 Kafka 中消费者组允许多个消费者实例并行读取不同分区，某实例宕机时自动触发再均衡，且每个消费者组独立维护自己的 offset
Kafka 提供至少一次（at-least-once）或精确一次（exactly-once）投递语义，并将消息持久化到磁盘
常见的死信队列实现包括 Apache Kafka 的独立 Topic、AWS SQS 的 Dead Letter Queue 配置以及 RabbitMQ 的死信交换机
Pub/Sub是分布式系统中经典的消息传递模式，通过消息代理解耦生产者与消费者，广泛应用于Kafka、Redis、Google Cloud Pub/Sub、RabbitMQ
还有 13 条时间轴事件
全部知识事实 (20)
现代NVMe SSD的fsync延迟约为20-100微秒，传统SATA SSD约为200-500微秒，机械硬盘可能达到5-15毫秒
75%已验证Kafka由LinkedIn于2011年开源，采用日志存储模型，消费者通过维护偏移量独立推进读取进度
65%已验证仅追加（Append-only）日志的著名实现包括Apache Kafka的提交日志和数据库的预写日志（WAL）
65%待验证Kafka被Netflix、Uber、LinkedIn等公司大规模使用
90%待验证Kafka底层存储机制基于分区日志（Partitioned Log），采用顺序写入和零拷贝（Zero-Copy）技术，单集群可支持每秒数百万条消息的吞吐
85%待验证Pulse机制在技术实现上通常依赖WebSocket长连接、消息队列（如Apache Kafka）或操作系统级别的文件系统监听（如Linux的inotify机制）
75%待验证AI编程工具在处理Apache Kafka的Node.js微服务系统等复杂专业场景时，生成的代码质量很差
75%待验证追加式日志（append-only log）架构中数据只能追加写入，不能就地修改或删除，Apache Kafka、事件溯源等技术都基于这一理念
60%待验证Kafka 采用持久化追加写入（append-only log）模型，消息默认保留数天甚至数周，消费者通过偏移量控制消费进度
60%待验证Apache Kafka是由LinkedIn最初开发、后捐赠给Apache软件基金会的分布式事件流平台
60%待验证RabbitMQ、Apache Kafka 和 Cloudflare Queues 三者共通的语义是「至少一次投递」，消息代理保证消息最终被消费但不保证只被消费一次。
50%待验证事件驱动拓扑用异步发布/订阅模型替代同步循环，底层由 RabbitMQ、Apache Kafka 或 Cloudflare Queues 等消息代理支撑。
50%待验证RabbitMQ 基于 AMQP 协议，支持复杂路由规则与消息确认机制；Apache Kafka 以分布式提交日志为核心，具备高吞吐与分区有序性，支持回放消费；Cloudflare Queues 是边缘原生的无服务器队列，按需弹性伸缩。
50%待验证消息队列采用生产者-消费者模型，常见实现包括RabbitMQ、Apache Kafka、RocketMQ
50%待验证对于已深度运行自建 Kafka 且有成熟运维团队的大型组织，迁移到 K2 的动力可能不足
50%待验证Kafka 的核心模型基于「主题（Topic）+ 分区（Partition）+ 消费者组（Consumer Group）」三层结构，通过 offset 追踪消费进度
50%待验证Kafka 提供至少一次（at-least-once）或精确一次（exactly-once）投递语义，并将消息持久化到磁盘
50%待验证在 Kafka 中消费者组允许多个消费者实例并行读取不同分区，某实例宕机时自动触发再均衡，且每个消费者组独立维护自己的 offset
50%待验证常见的死信队列实现包括 Apache Kafka 的独立 Topic、AWS SQS 的 Dead Letter Queue 配置以及 RabbitMQ 的死信交换机
50%待验证Pub/Sub是分布式系统中经典的消息传递模式，通过消息代理解耦生产者与消费者，广泛应用于Kafka、Redis、Google Cloud Pub/Sub、RabbitMQ
50%