本文深入分析了 AWS 新发布的 S3 Files 是否适合作为 Kafka 的存储后端，指出直接挂载存在持久性、可用性、延迟和成本四大挑战，并介绍了 AutoMQ 基于可插拔 WAL 的共享存储架构作为更优解。
📝 详细摘要
文章以 AWS 新发布的 S3 Files（为 S3 提供 NFS 接口，小文件读取延迟亚毫秒级）为切入点，探讨了将 Kafka 构建在共享存储上的可行性。作者首先分析了共享存储对 Kafka 的吸引力：消除跨 AZ 流量费、实现存算分离、简化运维。随后，文章深入剖析了直接将原生 Kafka 跑在 S3 Files 上会遇到的四个根本问题：持久性缺口（Kafka 异步 I/O 依赖副本，单副本下 Page Cache 数据易丢）、可用性耦合（无 Follower 副本导致故障转移机制失效）、延迟现实（P99 尾延迟高达 704ms，不可预测）以及成本结构不匹配（按流量计费 + 高额 EFS 驻留费，对持续高吞吐写入场景极不友好）。文章随后介绍了 AutoMQ 的解决方案：通过可插拔的 WAL（Write-Ahead Log）层作为写入缓冲，实现低延迟持久化、S3 API 成本优化和真正的无状态 Broker。文章最后评估了 S3 Files 作为 WAL 后端的可能性，认为技术上可行但当前定价模型使经济账算不过来，并展望了云存储分化趋势下，AutoMQ 可插拔架构的适应性。
💡 主要观点
- 直接使用 S3 Files 作为 Kafka 的存储后端存在根本性架构不匹配。 Kafka 的异步 I/O、基于副本的 HA 机制与共享存储的设计哲学冲突，导致持久性缺口、可用性耦合和不可预测的尾延迟等问题，无法通过简单配置解决。
💬 文章金句
- 不是把 Kafka 搬到共享文件系统上，而是从存储引擎层重新设计，让 Kafka 真正运行在共享存储架构上。
- 从 P95 到 P99 出现了断崖式跳跃：5ms 直接飙到 704ms，延迟放大了 140 倍。这意味着每一百次请求就有一次要等超过一秒。
- S3 Files 的定价模型是为「读多写少、活跃工作集小」的场景设计的------Kafka 恰好相反：持续高吞吐写入，所有数据都是「活跃」的。
- AutoMQ 的架构已经为那一天做好了准备。
📊 文章信息
AI 初评：88
来源：InfoQ 中文
作者：InfoQ 中文
分类：软件编程
语言：中文
阅读时间：21 分钟
字数：5067
标签： Kafka, S3 Files, 共享存储, AutoMQ, 消息队列