apache/iggy

Apache Iggy 适合已经理解消息流、想要一个 Rust 原生、支持多种传输协议的服务器的人。它目前还不是 Kafka 的即插即用替代品，但对新管道来说是一个可信的自包含日志。

解决什么问题

团队需要把事件从生产者送到多个消费者，还要保证顺序和重放，比如一边喂实时看板，一边让批处理重读昨天某个区间的数据。默认做法是搭 Kafka 或基于数据库的队列，随之而来的是 broker 基础设施、JVM 运维和序列化约定。换成 Iggy，broker 就是一个 Rust 单二进制，存储持久化的追加日志，生产者通过 TCP、QUIC、WebSocket 或 HTTP 发布，消费者可以按 offset、时间戳、首/末 N 条或下 N 条轮询。结果是一样的可重放流模型，但少了 JVM 那一层。

有什么不同

README 的核心主张是：这是专门构建的日志，而不是架在 Kafka 或 SQL 数据库之上的扩展。机制是 Linux 上的 thread-per-core、shared-nothing 设计加 io_uring，自定义零拷贝序列化，直接处理二进制载荷、不强制 schema。segment 大小、持久性和刷盘阈值可以按 topic 配置，这对同机跑一个高吞吐摄取流和一个审计流很有意义。集群能力编进同一个 iggy-server 二进制，用 cluster.enabled 开关，靠 Viewstamped Replication 做 quorum 提交和主节点选举。

代价是生态锁定和成熟度。Kafka 线协议网关存在，但 README 说它还在开发、尚未进入发行版，所以现有 Kafka 客户端不能直接指过来。server、SDK 和 CLI 各自独立版本化，配版本前要查 server 兼容性表。

谁值得试

适合：用 Rust、Go、Java、Python、C# 或 Node.js 新建事件管道、想要低延迟流式处理、并且愿意采用较新 broker 的团队。多语言 SDK 和快速入门指南降低了上手门槛，自带的 CLI 和 Web UI 方便管理。不适合：已有大规模 Kafka 部署和客户端工具链的组织，因为网关是预发布状态，迁移还不是受支持的路径。也不适合需要在 broker 层强制 schema registry 的人，因为二进制载荷是直接接收的。

使用条件与边界

最顺的路径是 Linux：README 把最佳性能绑定在现代 Linux 的 io_uring 和 thread-per-core 上，其他平台拿不到这个卖点。载荷是无类型的，schema 校验和契约管理归你的应用负责。集群默认关闭，需要配置 VSR 并按 quorum 部署，不是生产里改个开关那么简单。server 与 SDK 各走独立 semver，版本漂移是需要长期留意的问题。edge 版本（-edge.N）跟踪最新改动，但 README 明确说不建议用于生产，所以应固定稳定版。Connector 是 Rust 插件，实现 Source 或 Sink trait，灵活但自定义管道多一步构建。部署前请读集群文档和架构说明。

HotRepo 点评

HotRepo 只有两天样本：2026-10-24 是 5,191 星、当天 +7，2026-10-25 是 5,192 星、当天 +6，都在日榜。可比历史不足，无法判断热度是持续还是短期，只能当作快照。采用前具体要确认的是你所选语言的 server 与 SDK 兼容性表；版本不匹配最可能成为第一次集成的绊脚石。