Apache Iggy：用 Rust 重写消息流平台

基本定位

Apache Iggy 是一个用 Rust 编写的持久化消息流平台，目前处于 Apache 孵化器阶段。Iggy 的目标是成为 Kafka 和 RabbitMQ Streams 的高性能替代品，号称能够以极低延迟处理每秒数百万条消息。项目始于 2023 年作为创始人学习 Rust 的副业项目，2025 年 2 月正式进入 Apache 孵化器。

Iggy 不是在现有基础设施上的扩展，而是从头构建的消息流日志系统。它使用底层 I/O、线程每核（thread-per-core）共享无（shared-nothing）架构、io_uring 和 compio 运行时来追求最大的速度和效率。项目名称来自意大利灵缇犬（Italian Greyhound）的缩写，寓意小型但极快。

Iggy 的核心卖点是极致的性能。官方声称可以处理每秒数百万条消息，延迟在微秒级别，p99+ 延迟可预测。基准测试显示在合适的硬件和配置下，吞吐量可以超过 5000 MB/s（比如每秒 500 万条 1KB 的消息）。这些数字来自优化的配置和测试环境，实际生产环境的表现还需要验证。

架构设计

Iggy 采用经典的消息流架构，但在实现细节上做了激进的优化。数据模型包括 Stream（流）、Topic（主题）、Partition（分区）和 Segment（段）四层结构。

Stream 是逻辑上的命名空间，可以用来区分不同环境（开发、测试、生产）或不同租户。每个 Stream 包含一个或多个 Topic，Topic 是消息的实际分类。Topic 可以有多个 Partition 来实现水平扩展和高可用。Partition 的物理存储是 Segment，每个 Segment 是一个固定大小（比如 1GB）的二进制文件，存储实际的消息记录。

这个结构和 Kafka 基本一致，但 Iggy 的实现更激进。它使用 append-only log 作为核心数据结构，针对追加操作进行优化。消息按 offset 顺序写入，每条消息有唯一的 offset。读取时通过 offset 定位消息，支持随机访问和顺序扫描。

Iggy 在 0.6.0 版本进行了核心架构的重写，从基于 Tokio 的 poll 模型切换到基于 io_uring 的 completion 模型，使用 compio 作为异步运行时。这是一次重大的技术转向。

io_uring 是 Linux 内核提供的新一代异步 I/O 接口。传统的 epoll 和 poll 是轮询模型，应用需要不断询问内核 I/O 操作是否完成。io_uring 使用完成队列（completion queue），内核主动通知应用操作完成，减少了系统调用和上下文切换。用户空间和内核空间通过两个无锁环形缓冲区通信：提交队列（SQ）用于提交 I/O 请求，完成队列（CQ）用于接收结果。

配合 io_uring，Iggy 采用了 thread-per-core 共享无架构。每个 CPU 核心运行独立的事件循环，拥有专属的资源。数据按核心分片，最小化跨线程同步和缓存失效。这种设计消除了锁竞争，每个核心可以独立处理请求，互不干扰。

这种架构的好处是充分利用现代多核处理器，避免了传统多线程模型的协调开销。每个核心就像一个独立的小服务器，处理自己的数据分片。缺点是实现复杂度高，需要仔细的数据分片策略和负载均衡。

协议支持

Iggy 支持四种传输协议：QUIC、TCP、WebSocket 和 HTTP。每种协议有不同的特点和适用场景。

TCP 使用自定义的二进制协议，是性能最好的选项。QUIC 基于 UDP，提供了类似 TCP 的可靠性，但延迟更低，特别是在高丢包网络环境中。WebSocket 适合浏览器客户端和流式仪表板，HTTP 提供标准的 RESTful API，便于集成和调试。

所有协议都支持 TLS 加密，保证传输安全。Iggy 还实现了自定义的零拷贝序列化和反序列化，直接操作二进制数据，避免了不必要的内存分配和拷贝。

在 0.6.0 版本中，Iggy 实现了基于 io_uring 的原生 WebSocket 支持。这是一个技术挑战，因为 Rust 生态中的 WebSocket 库（如 tungstenite）大多是为 poll 模型设计的，不适配 completion 模型。Iggy 贡献了 compio-ws 到 compio 生态，提供了原生的 completion-based WebSocket 实现。

基准测试显示，WebSocket 的延迟比 TCP 高约 0.8-1.0ms（30-40%），但即使在 P9999 仍然可以达到 9.48ms 的延迟。这是在启用 fsync 每条消息的持久化配置下的结果，已经相当不错。

客户端 SDK

Iggy 提供了多语言的客户端 SDK，覆盖主流编程语言。正式支持的包括 Rust、C#、Java、Go、Python 和 Node.js，C++ 和 Elixir 正在开发中。

SDK 的设计注重易用性。以 Rust SDK 为例，用户通过 IggyClient 连接服务器，进行身份认证，然后创建 Stream、Topic、Partition，发送和接收消息。API 是异步的，使用 async/await 模式。认证是强制的，除了 ping 和 login，所有操作都需要用户有相应的权限。

Iggy 提供了默认的 root 用户（用户名和密码都是 iggy），拥有所有权限且无法删除。生产环境中应该创建额外的用户并分配细粒度的权限。0.6.0 版本增强了安全性，root 密码如果未配置会自动生成，密码哈希改用 Argon2。

工具和生态

Iggy 提供了完整的工具链来简化开发和运维。

CLI 工具可以通过 cargo install iggy-cli 安装，提供交互式的命令行界面来管理 Stream、Topic、Partition，浏览消息等。这对于喜欢命令行的开发者很友好。

Web UI 是一个图形化的管理面板，可以执行 CLI 的大部分功能。虽然还在持续开发中，但已经可以用于基本的管理任务。Docker 镜像可以通过 docker pull apache/iggy-web-ui 获取。

Connectors Runtime 是一个高性能的模块化运行时，用于加载和运行连接器插件。用户可以通过实现 Source 或 Sink trait 来创建自定义的 Rust 插件，构建数据处理管道。从外部源摄取数据推送到 Iggy 流，或从 Iggy 流拉取数据推送到外部系统。

0.6.0 版本增加了几个重要的连接器：Iceberg Sink 支持 S3 兼容存储和 REST catalog，可以将流数据写入数据湖仓；Elasticsearch Sink 和 Source 提供完整的 Elasticsearch 集成；Flink Processor 实现了与 Apache Flink 的流处理集成。

MCP Server 是 Model Context Protocol 的实现，用于消息流基础设施。MCP 是 Anthropic 推出的标准协议，用于应用向 LLM 提供上下文。Iggy MCP Server 可以让 LLM 实时访问消息流数据，提供更准确和相关的响应。这是 Iggy 探索 Agentic AI 用例的一部分。

性能和基准测试

Iggy 对性能和基准测试非常重视，将其作为一等公民。项目提供了 iggy-bench 工具，用于运行性能测试和回归测试。基准测试的结果发布在 benchmarks.iggy.apache.org，任何人都可以查看和贡献。

Iggy 强调基准测试的透明性和可复现性。测试代码是开源的，测试环境和配置都有详细文档。这和很多项目只展示最优场景的做法不同。Iggy 希望用户可以在自己的环境中验证性能，而不是简单地相信宣传数字。

官方基准测试显示 Iggy 可以处理每秒数百万条消息，吞吐量超过 5000 MB/s。延迟方面，p99+ 在微秒级别。这些数字是在优化的配置下达到的，包括使用 io_uring、启用 huge pages、调整内核参数等。实际生产环境中，性能会受硬件、网络、配置等多种因素影响。

重要的是，Iggy 还在快速迭代优化中。0.6.0 版本切换到 io_uring 和 thread-per-core 架构后，性能有显著提升。未来还计划引入更多优化，如 kTLS、DirectIO、NUMA、TCP 连接跨分片转移等。

当前限制

Iggy 仍处于早期阶段，有一些明显的限制。最大的限制是只支持单节点运行，还没有集群功能。创始人提到集群会基于 Viewstamped Replication 实现，但目前还在规划中。

没有集群意味着 Iggy 无法提供高可用保证。单节点故障会导致整个系统不可用。对于生产环境的关键应用，这是一个严重的问题。用户需要自己实现外部的高可用方案，或者接受单点故障的风险。

其他限制包括功能还不完整。很多高级特性还在开发中，比如事务支持、消息压缩、更复杂的权限模型等。文档也在持续完善中，有些地方还不够详细。

作为一个年轻的项目，Iggy 的生产案例很少。虽然进入了 Apache 孵化器，但实际生产部署的用户数量和场景还不清楚。这意味着稳定性和边界情况的处理还需要时间验证。

社区和发展

Iggy 于 2025 年 2 月加入 Apache 孵化器，这是一个重要的里程碑。进入 Apache 意味着项目承诺遵循开源治理模式，建立多元化的社区，而不是单一公司控制。

项目采用 monorepo 方式管理所有相关代码，包括服务器、SDK、工具、连接器等。这简化了贡献流程，也便于保持一致性。所有代码托管在 GitHub 的 apache/iggy 仓库，使用 Discord 作为社区交流平台。

Iggy 被 Thoughtworks 的 Technology Radar 列为值得试验的工具，这增加了项目的曝光度。但作为一个孵化器项目，Iggy 还需要建立更广泛的社区和贡献者基础，才能最终成为 Apache 顶级项目。

项目的长期愿景包括：扩展性能基准测试，推动超低延迟流的极限；扩展与现代数据基础设施的集成；建立充满活力的开发者生态，让消息流变得无摩擦。这些目标很宏大，能否实现取决于社区的参与和支持。

评价

Iggy 的技术路线可以概括为：用 Rust + io_uring + thread-per-core 重新实现一遍 Kafka 的数据模型。从架构层面看，并没有本质创新。Stream、Topic、Partition、Segment 这套四层结构完全是 Kafka 的翻版，只是在实现细节上做了性能优化。

这种"重新实现"的路线面临根本性的竞争力问题。Iggy 的核心卖点是极致性能，但性能优势在 Rust 生态中并不稀缺。Redpanda 用 C++ 重写 Kafka，同样声称有数倍的性能提升。其他用 Rust 写的消息队列项目，比如你正在开发的 RobustMQ，同样可以通过 io_uring、零拷贝、高效序列化等技术达到相似的性能水平。单纯的性能优势很难构成护城河。

如果真要追求极致性能，NATS 才是这条路线的王道。NATS 是纯内存的消息系统，没有持久化的开销，架构极简，单机可以处理千万级消息/秒。这才是真正的极致性能。Iggy 作为持久化消息流系统，受限于磁盘 I/O 和持久化保证，性能天花板远低于 NATS。在极致性能这个维度上，Iggy 既打不过 NATS 这样的纯内存系统，又拿不出足够的差异化来挑战 Kafka。

更关键的是生态问题。Iggy 是全新的系统，没有 Kafka 协议兼容，没有现成的连接器生态，没有成熟的监控和运维工具。用户要迁移到 Iggy，意味着放弃整个 Kafka 生态，从零开始构建周边工具。这个代价是巨大的，而收益只是"可能更快一些"。在消息队列领域，生态的价值远大于性能的边际提升。

技术路线本身也有明显的局限。io_uring 依赖 Linux 5.1+，thread-per-core 架构实现复杂，compio 运行时小众。这些选择在追求极致性能的同时，限制了适用范围，提高了使用门槛。而且这些优化都是单机层面的，一旦加入集群和复制，性能必然大打折扣。

Iggy 目前缺乏集群功能是致命伤。消息队列的核心价值是可靠性和可用性，单机再快也解决不了高可用问题。没有集群就无法用于生产环境的关键场景。虽然集群在规划中，但基于 Viewstamped Replication 实现分布式系统并不容易，何时能稳定可用是未知数。

从技术演进的角度看，Iggy 更像是一个技术练习项目，展示了如何用现代技术栈实现高性能消息队列。io_uring 和 thread-per-core 的实践有参考价值，对 Rust 生态的贡献（如 compio-ws）也有意义。但要成为有竞争力的消息队列系统，光有性能远远不够。

Iggy 对性能基准测试的透明态度值得肯定，这体现了技术诚实。但透明的基准测试并不能改变架构缺乏创新、生态几乎为零的现实。进入 Apache 孵化器说明项目有一定的社区认可，但孵化器里成功毕业的项目比例并不高。

对于同样用 Rust 开发消息队列的项目来说，Iggy 的价值主要是技术参考。可以学习它的零拷贝实现、io_uring 使用方式、性能优化技巧。但在战略选择上，Iggy 展示的是一条风险很大的路：放弃生态兼容性，赌纯粹的性能优势能吸引用户。从目前看，这个赌注不太可能成功。

消息队列的竞争已经不在单机性能层面。Kafka 的性能对大多数场景够用，真正的差异化在于云原生架构（如 Pulsar 的存算分离）、成本优化（如 Ursa 的湖仓集成）、协议兼容性（复用现有生态）。Iggy 选择的方向——极致单机性能 + 全新生态——在当前的市场格局下，竞争力是很弱的。