当Kafka架构显露“疲态”：共享存储领域加速新升级

摘要：先说最现实的痛点。很多团队还在跑传统 Kafka，数据写进每台 Broker 的本地盘，然后在 Broker 之间做副本，常见的副本因子是 RF=3。也就是说，写入 1GB，最终在 Broker 层面上存在 3GB。再算上云厂商对块存储的冗余/复制和为避免磁盘

AutoMQ 把日志放到对象存储，Broker 变成无状态，新增或下线节点时不用搬数据，扩容、恢复都快得多。这是事实，不带修饰。

接下来把来龙去脉按顺序讲清楚，从问题说起，再到为什么以前那些折中办法没彻底解决，再到 AutoMQ 怎么干的。写得直白点儿，少绕弯子，大家好理解。

先说最现实的痛点。很多团队还在跑传统 Kafka，数据写进每台 Broker 的本地盘，然后在 Broker 之间做副本，常见的副本因子是 RF=3。也就是说，写入 1GB，最终在 Broker 层面上存在 3GB。再算上云厂商对块存储的冗余/复制和为避免磁盘告警预留的空间，实际需要付费的磁盘空间往往被放大到大约 12GB。举个电商的例子：每小时进 1GB，保留 7 天，理论原始数据是 168GB，但按上面放大因子，最终要准备约 2016GB 的磁盘。就算你只关心最近一小时的数据，也得为整整七天的三份副本买单，成本一下子就扎心了。

网络成本也不小。跨可用区的复制会产生大量流量。按上面 1GB/小时、RF=3 的场景，每小时大概有 2GB 的跨区流量，折合到月度是约 1460GB，按常见计费就是几十美元。把数据速率推到 100MB/s，跨区流量就能达到数百 MB/s，月账单立马飙到上万块——这不是小数目，尤其对预算紧张的团队伤得更深。

这些麻烦的根子在于 Kafka 的 shared-nothing 设计：每个 Broker 自己在本地盘上保存数据，不共享存储。2011 年那会儿裸金属是主流，本地盘读写快、可靠，这设计合情合理。可现在云时代不同了，对象存储像 S3 这种东西既便宜又可靠、弹性好。继续把 shared-nothing 按老办法搬到云上，等于付出多倍的重复存储成本，还带来复杂的运维负担。

社区也不是没动脑子，分层存储（Tiered Storage）就是一次妥协方案。热数据留在 Broker 本地，冷数据异步上传到 S3/GCS，理论上能省钱。问题是，热数据的长尾没被解决。在高峰期，一个活跃的日志段可能有几十 GB，乘以三倍副本，单个分区对本地盘的需求仍然很大。扩容时，分区的重平衡还是要搬这些热数据，耗时依旧让人头疼。运维也更复杂了：你得同时盯两套存储、处理两类故障，告警成倍增加，数据在两层之间卡住的尴尬也常见。

这就引出 Diskless（无盘）思路：把持久化完全交给对象存储，Broker 不再把日志持久化到本地盘，只负责计算和协议处理。听起来像把锅全推给 S3，但 AutoMQ 就是按这路子走的，并做了大量工程工作来兼容 Kafka API。它不在 Broker 本地维持三份副本，而是把日志段存到 S3 这样耐用的持久层。Broker 变轻了，变成了无状态的工作进程，随时可以替换。扩容变成加更多的计算容器，不必拖着数据做慢吞吞的重平衡。常见的磁盘告警、长期副本同步、分区迁移这些噩梦多数都没了。

当然，直接把所有写请求扔给对象存储有它的代价：延迟和 API 开销不能忽视。AutoMQ 的折中是加一层 WAL（预写日志）：消息先写到小型耐用的块存储（比如 EBS、NVMe）做暂存，然后异步把日志段上传到对象存储。WAL 让写入延迟接近本地盘的感觉，而长期持久性靠 S3 之类的对象存储来保证。对那些对延迟极其敏感的场景（像金融系统），AutoMQ 还有更深的商业化方案：把 WAL 打造成云原生级别的服务，消息第一时间写到可挂载的小卷，读取靠内存或缓存来应对瞬时的高吞吐。方案看起来复杂，但工程上是能实现的。

把 Diskless 和分层存储同时摆在眼前比较，就能看出本质差别。分层存储仍然要求 Broker 写本地盘并在 Broker 间复制，只有冷数据上 S3。Diskless 让所有耐久性都建立在对象存储或云卷上，Broker 不再承担持久状态。出问题时的应对方式也不同：传统 Kafka 出事通常靠副本同步，过程慢；AutoMQ 的做法是把小卷挂到别的实例上，新 Broker 直接继承 WAL，能做到更快地恢复。存储的生命周期被提升到一个更稳定的层级上，计算实例则像无状态的短期工人，随来随走。

要注意两点实际工程挑战。第一，对象存储的延迟比 SSD 高，写入语义和一致性需要设计来掩盖这些差异。第二，兼容性不是小事。AutoMQ 在尽力保持对 Kafka 协议的兼容性，避免把整个生态链撕裂。运维上的习惯也得换：过去关注磁盘 I/O、磁盘使用率，现在要盯对象存储的 API 调用限制、上传延迟、小对象聚合等新指标。

我个人的感受是，看到 Broker 从“宠物”变成“牛群”那会儿挺激动。把不可共享的状态抽离掉，换来的是更干净的运维模型。现实不会一刀切：对延迟极端敏感的应用，WAL 的细节一条条都要打磨，不能马虎。AutoMQ 把方向选对了，但工程细节还得逐项验证。