Skip to main content

无状态 Broker

AutoMQ 采用存算分离技术将 Kafka 的存储层通过 S3Stream 卸载至云存储，Broker 节点本身变为了无状态。无状态的 Broker 在运维和扩缩容方面有巨大的优势。同时，无状态的 AutoMQ 在云上还能采用 Spot 实例进行部署，进一步降低计算成本。

AutoMQ 如何完全无状态化​

S3Stream 包含两个存储组件：

  • WAL 存储，WAL 存储采用的存储介质是多样的，既可以用 EBS 作为 WAL，也可以用 S3 作为 WAL。

  • S3 存储，采用对象存储作为数据的主存。

S3Stream 访问对象存储是通过 HTTP 协议，完全无状态的访问形式，所以如果部署 AutoMQ 时 WAL 也选择 S3 作为存储介质，整个架构是完全无状态的。但如果选择 EBS 作为 WAL，以文件 API 来访问 EBS，这时让整个架构变为无状态是一件有挑战的事情。

AutoMQ 核心是使用 EBS 提供的多重挂载能力，将 EBS 变成共享存储后，就能做到完全的无状态化。核心的流程非常简单：

  • Broker A 的故障被 Controller 检测到后，将其 EBS WAL 以多重挂载的形式挂载给 Broker B。

  • Broker B 接管后，将 WAL 中不在 S3 存储上的少量数据完成恢复上传。

  • 此时 Broker A 的状态就完成了卸载，Controller 随后将原本属于 Broker A 的分区均匀分布给其他 Broker 即可。

上述的流程设计可以应用于故障恢复场景，也可用于缩容和下线流程，是一种完全无状态的设计。

无状态的优势​

采用存算一体架构的存储软件，基本上都是有状态的软件，它们在运维、扩容和缩容等方面都会面临巨大的挑战。AutoMQ 通过将 Apache Kafka 改造为无状态的存储软件，运维 AutoMQ 可以像运维一个微服务应用程序一样简单。

  • 极简运维：对于 AutoMQ，日常的运维也变得足够简单，Broker 节点停机后状态就完成了转移，客户端完全无感，运维人员有足够的时间去决定被停机的 Broker 是否需要恢复上线，或者永久下线。集群升级也可以通过 Rolling Update 的方式低成本和低风险地完成。

  • 自动扩缩容：无状态的 AutoMQ 可以像一个微服务应用程序，或者一个 Kubernetes Deployment 那样随意的扩容和缩容，真正做到 Auto Scaling，能节省大量的成本。

  • 可以采用 Spot 实例：云厂商提供的 Spot 实例相比较正价的虚拟主机，最多能便宜 90%，但因为 Spot 实例随时会被中止回收的特性，也只有无状态的应用程序能利用起来。