Releases2 下载最新的正式二进制安装包,用于安装 AutoMQ。 在 MinIO 上创建两个自定义命名的对象存储桶, automq-data 和 automq-ops。 aws s3api create-bucket --bucket automq-data --endpoint=http://10.1.0.240:90002安装并启动 AutoMQ 集群 第一步:生成 S3 URLAutoMQ 提供了 automq-kafka-admin.sh 工具,用于快速启动 AutoMQ。 对于 AutoMQ 新增的参数4,将使用 AutoMQ 提供的默认值。要覆盖默认配置,可以在命令末尾添加额外的 --override key=value 参数来覆盖默认值。
AutoMQ 作为 Apache Kafka 的继任者,由于其对 Kafka 的完全兼容,可以充分利用其生态中的产品。AutoMQ 企业版已经提供了非常强大的控制面能力。 如果你使用的是 AutoMQ 也可以使用像 Kafdrop 、Redpanda Console 1 等这样的产品来管理 AutoMQ 集群。 Redpanda Console 官方示例 01前置条件部署 AutoMQ 集群准备 Redpanda Console 环境 部署 AutoMQ 集群请参考 AutoMQ 官方文档:集群方式部署 | AutoMQ 3。 GitHub 地址:https://github.com/AutoMQ/automq 官网:https://www.automq.com?utm_source=openwrite
本文将介绍如何使用 Apache Doris Routine Load 将 AutoMQ 中的数据导入 Doris。详细了解 Routine Load 请参考 Routine Load 基本原理文档。 创建库和测试表:create database automq_db;CREATE TABLE automq_db.users ( id bigint 假设解压目录为 $AUTOMQ_HOME,在本文中将会使用 $AUTOMQ_HOME/bin 下的工具命令来创建主题和生成测试数据。 1.3 准备 AutoMQ 和测试数据参考 AutoMQ 官方部署文档部署一套可用的集群,确保 AutoMQ 与 Doris 之间保持网络连通。 在 AutoMQ 中快速创建一个名为 example_topic 的主题,并向其中写入一条测试 JSON 数据,按照以下步骤操作。
得益于 AutoMQ 对 Kafka 的完全兼容,因此可以无缝与 Kafdrop 进行集成。 下面我将先搭建 AutoMQ 集群,再启动 Kafdrop。 02安装并启动 AutoMQ 集群 配置S3 URL第一步:生成 S3 URLAutoMQ 提供了 automq-kafka-admin.sh 工具,用于快速启动 AutoMQ。 第 3 步:启动 AutoMQ参数说明使用启动命令时,未指定的参数将采用 Apache Kafka 的默认配置。对于 AutoMQ 新增的参数,将使用 AutoMQ 提供的默认值。 ,展示了如何轻松地监控和管理 AutoMQ 集群。
本文所述 AutoMQ 的元数据管理机制均基于 AutoMQ Release 1.1.0 版本 1。 对象存储为 带来可观成本优势的同时,其与传统本地磁盘的接口和计费方式的差异也为 AutoMQ 在实现上带来了挑战,为解决这一问题,AutoMQ 基于 KRaft 进行拓展,实现了一套针对对象存储环境的流存储元数据管理机制 02AutoMQ 需要哪些元数据KV 元数据在之前的文章中(AutoMQ 如何做到 Apache Kafka 100% 协议兼容 2),我们介绍过了 AutoMQ 的存储层如何基于 S3Stream 3 参考资料1 AutoMQ Release 1.1.0:https://github.com/AutoMQ/automq/releases/tag/1.1.0 2 AutoMQ 如何做到 Apache GitHub 地址:https://github.com/AutoMQ/automq 官网:https://www.automq.com?utm_source=openwrite
02 AutoMQ 的架构优势得益于 AutoMQ 对云原生能力的深度应用,我们将 Apache Kafka 的底层存储完全基于云的对象存储进行了重新实现,由此带来的优势有:完全的存算分离架构,Broker 故我们有机会在 AutoMQ 内部实现一个内置的、轻量化的数据自动平衡组件,持续监控集群状态,自动执行分区迁移。 03 AutoMQ 重平衡组件的实现3.1 整体架构AutoMQ 持续重平衡组件(AutoBalancer)的实现,主要分为以下三个部分:指标采集状态维护决策调度除了 Broker 侧完成指标采集外,状态感知和决策调度由 决策开始前,AutoMQ 会先对 ClusterModel 进行一次快照,并使用快照的集群状态进行后续的调度,快照完成后,ClusterModel 即可继续更新。 AutoMQ 的决策过程采用了类似 Cruise Control 的启发式调度算法,如下图:可以看到,决策的重点在于如何定义一个合理的目标。
本文将简要介绍系统测试的原理、演示系统测试过程,并给出 AutoMQ 对系统测试的实践。 03 AutoMQ系统测试现状 AutoMQ 完全适配并继承了 Apache Kafka 的系统测试。 你也可以通过 5 和 6 查看 AutoMQ main 分支下的代码每天全量系统测试的结果。 利用系统测试,AutoMQ 可以确保 0.9.x 版本以来的 Kafka 客户端与 AutoMQ 的兼容性,以及 Kafka Connect 等衍生产品与 AutoMQ 的兼容性。 500+ 系统测试案例在一定程度上保证了 AutoMQ 代码的健壮性,同时能够保证 AutoMQ 对 Apache Kafka 的 100% 兼容性。
AutoMQ 的无状态云原生 Kafka 平台现已深度集成 Aklivity 的多协议网关技术。 通过采用计算与存储完全解耦的共享存储架构,AutoMQ 将 Kafka Broker 转变为无状态的计算节点。 AutoMQ × Aklivity:云原生流处理的无状态技术栈AutoMQ 的无状态共享存储架构与 Aklivity 的流原生网关深度集成,实现了云原生数据架构的再次进化。 展望未来AutoMQ 与 Aklivity 将持续深化技术融合,共同驱动云原生实时数据基础设施的发展。 立即访问 AutoMQ 官网,了解下一代云原生 Kafka 的极致性能与成本优势:AutoMQ 官网访问 Aklivity 官网,探索用于实时数据管理的多协议网关解决方案:Aklivity 官网
AutoMQ 的共享存储结构:02AutoMQ 的可观测接口由于 AutoMQ 对 Kafka 的完全兼容,并且支持开放基于 Prometheus 的 Metrics 收集端口,因此可以利用观测云提供的数据采集工具 03集成观测云的步骤 AutoMQ 开启 Metric 拉取接口参考 AutoMQ 文档:集群方式部署 | AutoMQ 4 部署启动前,添加如下配置参数开启 Prometheu的拉取接口。 AutoMQ 采集器配置与生效这里我们要在每个待采集数据的节点所在的服务器上配置好 DataKit 的 AutoMQ 采集器配置。 : https://www.automq.com 4 集群方式部署 AutoMQ:https://docs.automq.com/zh/docs/automq-opensource/IyXrw3lHriVPdQkQLDvcPGQdnNh GitHub 地址:https://github.com/AutoMQ/automq 官网:https://www.automq.com?utm_source=openwrite
数据 03部署 AutoMQ、Prometheus 以及夜莺监控 部署 AutoMQ参考 AutoMQ 文档:集群方式部署 | AutoMQ 5 。 04夜莺监控 AutoMQ 集群状态接下来,我将介绍夜莺监控提供的一部分功能,帮助你更好地了解夜莺与 AutoMQ 集成的可用功能。 我们从AutoMQ 和夜莺的基本概念入手,逐步讲解了如何部署 AutoMQ、Prometheus 和夜莺,并配置监控和告警规则。 :https://docs.automq.com/zh/docs/automq-opensource/IyXrw3lHriVPdQkQLDvcPGQdnNh 6 Metrics | AutoMQ:https GitHub 地址:https://github.com/AutoMQ/automq 官网:https://www.automq.com?utm_source=openwrite
2.2 为什么选择AutoMQ 为了解决Kafka在大规模数据处理中的问题,得物可观测性平台选择了AutoMQ作为替代方案。 AutoMQ的优势包括: 100%兼容Kafka协议:AutoMQ完全兼容Kafka客户端和生态工具,迁移过程顺畅,避免了大规模改造。 AutoMQ自动流量重平衡 vs. Apache Kafka手动迁移 案例 AutoMQ通过监控集群流量和CPU等指标,自动进行扩缩容。 五、引用 [1]AutoMQ基于S3的共享流存储库:https://docs.automq.com/zh/automq/architecture/s3stream-shared-streaming-storage 性能白皮书:https://docs.automq.com/zh/automq/benchmarks/benchmark-automq-vs-apache-kafka [6]AutoMQ秒级分区迁移:https
01前言 AutoMQ 作为一款使用对象存储作为主要存储介质的消息系统,在写入链路,会将所有 Partition 的数据在内存中进行攒批(同时持久化至 EBS),当攒批大小达到一定阈值则将该批次的数据上传至对象存储 通过这种方式,使得对象存储的 API 调用成本和文件数量仅和吞吐相关,且不会随着分区数量的增加而线性增大,如下图:在将攒批数据上传至对象存储的过程中可能产生两类对象(从分区到 Stream 的映射关系可参考「AutoMQ 03Compaction 过程 AutoMQ 实现了两级 Compaction:SSO Compaction:将多个 SSO Compact 成不超过一个 SSO 和多个 SOSO Compaction 04结语 本文介绍了 AutoMQ 如何在有限的内存下实现大规模 SSO 对象的 Compaction。 ,感兴趣的同学欢迎深入 AutoMQ 代码仓库进行了解。
AutoMQ[1] 是新一代基于共享存储架构实现的云原生 Kafka。 因此,AutoMQ 在进行分区移动时无需复制数据,能够做到真正的秒级无损分区迁移。这也是支撑 AutoMQ 流量实时重平衡和秒级节点水平扩缩容的原子能力。 AutoMQ 从成本和架构上对 OSS 提供的能力进行了充分挖掘,但这仅仅是起步,共享存储将为 AutoMQ 带来丰富的技术和产品创新上的想象力。 AutoMQ 在公有云上的交付在 Kubernetes 和 ESS 之间选择了 ESS,背后主要有几点考虑: AutoMQ 推出的第一个产品形态是 BYOC,为了简化依赖,避免每个用户在部署 AutoMQ 引用文章 开源的云原生版 Kafka——AutoMQ:https://github.com/AutoMQ/automq Confluent 全新发布 Tableflow,统一流和分析型计算:https
01、背景 AutoMQ1 作为一款流系统,被广泛应用在客户的核心链路中,对可靠性的要求非常的高。 02、架构总览 首先来看一下总体架构图 Marathon 项目的 Controller 和 Worker 以及 AutoMQ 企业版控制面都位于 K8S 中: Controller 调用位于同一 VPC 的 AutoMQ 企业版控制面接口管理 Kafka 集群的创建/变更/销毁,同时负责测试任务编排与管理 Worker 的数量与配置。 AutoMQ 控制面 Worker:运行 Kafka 客户端产生任务所需的负载,同时负责可观测数据的上报和客户端侧的 SLA 检查 AutoMQ 企业版控制面:为数据面提供完整产品化能力包括集群生命周期管理 支持多种 Kafka 集群类型: 已存在的 Kafka 集群:对指定集群快速验证功能是否可用 托管 Kafka 集群:由 Controller 管理集群的整个生命周期,托管的 Kafka 集群依赖 AutoMQ
本文今天将具体解读 Kafka 线程模型的不足以及 AutoMQ 如何对其进行改进优化,从而实现更好的单分区写入性能。 因此 AutoMQ 参照 CPU 的流水线将 Kafka 的处理模型优化成流水线模式,兼顾了顺序性和高效两方面:1. Apache Kafka 完成 4 批消息的处理耗时需要 4T,在 AutoMQ 的流水线处理模型下,处理耗时缩短到 1.x T。 的持久化等级;测试使用的 Kafka 和 AutoMQ 版本如下:ꔷ AutoMQ:1.1.0 https://github.com/AutoMQ/automq/releases/tag/1.1.0- 从测试的结果列表中我们可以看到:ꔷ AutoMQ 的极限吞吐是 Apache Kafka 的 2 倍,达到了 350MB/s; ꔷ AutoMQ 在极限吞吐下的 P99 延时是 Apache Kafka
最终,他们选择了基于云原生架构的 AutoMQ。 下图清晰地展示了腾讯音乐基于 AutoMQ 构建的现代化实时数据流处理架构。 为什么选择 AutoMQ 在评估下一代 Kafka 解决方案时,我们团队有几个非常明确的目标。经过深入的技术调研和对比,我们认为 AutoMQ 是最能满足我们当前和未来需求的方案。 这个场景重点考验的是 AutoMQ 在处理高频元数据请求、客户端连接管理以及小 I/O 聚合能力上的性能极限。 在这两个月的测试中,我们通过构造多组不同的测试负载,对 AutoMQ 进行了全面的评估。 AutoMQ 组件标准化与推广: 我们计划将 AutoMQ 打造成腾讯音乐内部标准化的基础设施组件,并积极将其推广应用到更多样化的业务场景中,让更多的业务线受益于新架构带来的极致弹性和低成本优势。
本期概要欢迎来到 AutoMQ 第十一期双周精选!在过去两周里,主干动态方面,AutoMQ 跟进了 Apache Kafka 3.4.x BUG 修复,并进行了CPU & GC 性能优化。 AutoMQ 主干动态AutoMQ 1.0 跟进 Apache Kafka 3.4.x BUG 修复https://github.com/AutoMQ/automq/pull/1391KAFKA-14644 NPE 导致异常退出的问题;KAFKA-15489 & KAFKA-16144 修复 KRaft Leader 网络分区可能导致脑裂的问题;CPU & GC 性能优化https://github.com/AutoMQ /automq/pull/1316AutoBalancing 的 Reporter 和 Retriever 支持指定 Listener Name 配置接入点。 以上是第十一期《双周精选》的内容,欢迎关注我们的公众号,我们会定期更新 AutoMQ 社区的进展。同时,也诚邀各位开源爱好者持续关注我们社区,跟我们一起构建云原生消息中间件!END
Kafka Scaling on Kubernetes AutoMQ 如何解决京东 Kafka 挑战 在寻求解决京东内部 Kafka 挑战的调研过程中,我们发现了 AutoMQ[1] 这一优秀产品。 这使得 AutoMQ 能够与京东内部的 CubeFS 服务自然整合。 AutoMQ 在京东生产应用的效果 当前,京东采用的是 AutoMQ S3 WAL [2] 的模式。AutoMQ 的架构设计中对于 WAL 进行了高度的抽象,可以将不同的存储介质作为 WAL。 AutoMQ Deployment on Kubernetes in JD.com 下图展示了京东内部一个 AutoMQ 生产集群的核心指标。 参考资料 [1] AutoMQ: https://www.automq.com/ [2] AutoMQ WAL Storage: https://docs.automq.com/automq/architecture
本期概要欢迎来到 AutoMQ 第十二期双周精选! 在过去两周里,主干动态方面,AutoMQ 跟进了 Apache Kafka 3.4.x BUG 修复,并进行了CPU & GC 性能优化,另外,AutoBalancing 的 Reporter 和 Retriever AutoMQ 主干动态Direct On S3 抢先体验https://github.com/AutoMQ/automq/releases/tag/1.2.0-beta0Direct on S3 抢先体验版发布 TimelineHashMap,避免元数据频繁变更引发 Map 拷贝;StreamSetObject 内存索引信息卸载到对象存储,降低 KRaft 元数据内存占用和 Checkpoint 空间占用;阶段性优化结果:AutoMQ GitHub 地址:https://github.com/AutoMQ/automq 官网:https://www.automq.com
在这个过程中,AutoMQ Kafka 所在计算实例接受实例终止信号到新的 Spot 实例被替换后启动 AutoMQ Kafka 并且重新接受流量整个冷启动过程的耗时长短决定着 AutoMQ Kafka 在 AutoMQ 内核不再成为冷启动瓶颈的情况下,AutoMQ 也将不断探索利用容器技术、GraalVM AOT 编译等手段提升整个端到端冷启动的效率,给大家带来更快、更好的弹性能力。 按需实例与 Spot 实例混部AutoMQ Kafka 虽然大量应用了 Spot 实例来降低成本,但是仍然在两个纬度上保留了少量按需实例的使用,从而确保 AutoMQ 可以给用户提供可靠的 Kafka ,在 AutoMQ 这种无状态和极致弹性的设计下对业务基本是无感的。 简单而言,适合自己的才是最好的,也欢迎大家真正来体验 AutoMQ ,看看我们到底几斤几两。AutoMQ Kafka 核心代码均已在 GitHub 开源,欢迎来社区一起交流。