网站推广方式组合新手学做网站学哪些知识

网站推广方式组合,新手学做网站学哪些知识,天晴创艺网站建设百度小程序,百度app关键词优化介绍 今天#xff0c;我们正式宣布#xff1a;继 S3 WAL、EBS/Regional EBS WAL[1] 之后#xff0c;AutoMQ 将在 2025 年的 12 月的新版本中全面支持以 AWS FSx 作为新的 WAL 存储选项。AutoMQ 本身是一款完全兼容 Apache Kafka 协议、基于 S3 对象存储构建的新一代 Diskle…介绍今天我们正式宣布继 S3 WAL、EBS/Regional EBS WAL[1] 之后AutoMQ 将在 2025 年的 12 月的新版本中全面支持以 AWS FSx 作为新的 WAL 存储选项。AutoMQ 本身是一款完全兼容 Apache Kafka 协议、基于 S3 对象存储构建的新一代 Diskless Kafka通过自研的「WAL 对象存储」创新流存储引擎将写入日志与大规模持久化存储解耦在保证 Kafka 语义和稳定性的同时大幅降低存储成本、简化运维并已在行业内获得广泛认可。随着 FSx WAL 的引入AWS 上的 AutoMQ 终于补齐了关键的一块拼图在 AWS 上你可以在一套真正 Diskless 的 Kafka 方案中同时兼顾消除跨 AZ 流量成本、多 AZ 级别容灾能力以及接近本地磁盘体验的低延迟。Diskless Kafka 的延迟挑战近些年来随着 S3 API 凭借极致低成本、弹性与共享存储特性逐渐成为云上数据基础设施的新标准基于对象存储重构流存储引擎的 Diskless Kafka 方案开始兴起。自 AutoMQ 在 2023 年率先提出基于共享存储的 Kafka 架构以来Diskless Kafka 已经成为 data streaming 领域的一股重要趋势在云上它天然具备计算与存储解耦、按需弹性扩缩容、以及显著的成本优势。尤其是借助共享存储消除跨 AZ 流量费用在 AWS、GCP 等主流公有云上多 AZ 部署的 Kafka 集群每月可以节省数千到数万美元的网络成本这一点已经获得大量云上 Kafka 客户的高度认可也是推动他们考虑迁移到 Diskless Kafka 方案的核心驱动力之一。但 Diskless Kafka 也面临一个根本性挑战如果只是简单抛弃本地磁盘把所有数据直接同步写入对象存储就会彻底丧失 Kafka 最重要的能力之一——低延迟。对象存储的设计目标是高可靠与高吞吐而不是亚毫秒级写入延迟。通常情况下直接写 S3 这类对象存储的平均写入延迟在 200–500ms 区间即便使用诸如 S3 Express One ZoneS3 E1Z这类最新产品写入延迟依然大约在 150ms 左右。对于微服务链路、撮合引擎、风控决策、实时风控等延迟敏感的金融与交易场景这样的延迟是远远不能接受的也极大限制了市面上大多数 “对象存储直写型” Diskless Kafka 的适用范围使其更多只能用于可观测性、日志采集、准实时事件流分析等对端到端延迟要求不那么严苛的场景。AutoMQ 在 2023 年提出并实践了一条不同的技术路径基于「WAL 加速层 对象存储」的共享存储架构。通过在对象存储之前引入一层高性能、低延迟的共享存储作为 Write-Ahead LogWALAutoMQ 将写入路径与低成本的对象存储解耦在保证 Kafka 语义的前提下将大部分写入与读热点落在低延迟存储上再以批量方式异步刷新到对象存储从而实现了真正意义上的低延迟 Diskless Kafka。这种架构有两大关键价值一是利用云上低延迟共享存储显著提升写入与读取性能二是通过 WAL 做批量聚合写入降低 S3 API 调用次数进一步提升吞吐并控制成本。在 GCP、Azure 等支持 Regional EBS或等价多 AZ 共享块存储的云上基于 Regional EBS 的 WAL 对象存储架构被业界普遍认为是当前 Diskless Kafka 的“理想形态”。真正的技术难题出现在 AWS 上。与 GCP、Azure 不同AWS 一直缺乏类似 Regional EBS 这种多 AZ 共享块存储服务这意味着在 AWS 上构建低延迟的 Diskless Kafka 架构时我们过去只能在 EBS 和 S3 之间做艰难取舍使用 EBS 做 WAL可以获得较好延迟但仍然逃不开跨 AZ 复制带来的网络成本和复杂性直接用 S3 做 WAL可以彻底避免跨 AZ 网络流量成本但端到端延迟难以满足延迟敏感业务的需求。这也是为什么在很长一段时间里Diskless Kafka 在 AWS 上始终存在“要么便宜但不够快要么够快但不够便宜”的结构性短板。为了解决这一矛盾AutoMQ 在调研了 AWS 生态下的多种共享存储服务后最终选择了AWS FSx for NetApp ONTAP作为 WAL 层的关键基础设施。FSx ONTAP 既是一个跨 AZ 高可用的共享文件存储服务又可以在多 AZ 部署场景下实现低于 10ms 级别的平均写入延迟同时在计费模型上不叠加跨 AZ 流量费完美契合 Diskless Kafka 对“低延迟 共享存储 多 AZ”的复合诉求。借助 AutoMQ 的 WAL 抽象我们只需要一些固定容量的 FSx 作为高性能 WAL 空间就可以将写入先持久化到 FSx WAL 上再批量刷写到 S3从而在 AWS 上首次实现保持 Diskless Kafka 的所有优势计算存储分离、弹性扩缩、S3 级别的低成本消除跨 AZ 流量成本支持多 AZ 部署与容灾同时获得接近本地盘体验的低延迟写入与消费。这使得 AutoMQ 成为目前 AWS 上少有的、在成本、多 AZ 高可用与低延迟三个维度上几乎没有明显短板的 Diskless Kafka 方案也真正打开了 Diskless Kafka 在延迟敏感业务场景的应用空间。FSx 如何消除跨AZ 流量费要理解 FSx 如何帮助 AutoMQ 消除 Kafka 跨 AZ 流量费可以先从“我们到底改了 Kafka 的哪一层”入手再看 FSx 在这个新架构里的具体职责。Apache Kafka 本身可以被拆分为三层网络层负责处理 KafkaApis 请求计算层包含事务、压缩、去重、LogCleaner 等核心逻辑占 Kafka 代码的绝大部分最底层是存储层通过 LocalLog 和 LogSegment 将无限长日志落到本地文件系统。AutoMQ 保留了 Kafka 原生的网络层和计算层代码只在存储层的 LogSegment 这一非常薄的切面上将本地磁盘替换为基于 “S3 低延迟 WALFSx” 的共享存储引擎并在网络层之上增加了一个 Zone‑routing interceptor。FSx 以区域级共享卷的形式承担持久 WAL 的角色所有写入首先顺序落到 FSx再异步下沉到 S3。在多 AZ 部署下传统 Kafka 的跨 AZ 流量主要来自三部分三副本复制、跨 AZ 消费、以及跨 AZ 写入。AutoMQ 通过单副本 云存储S3/FSx来承担持久化与多 AZ 可用性天然消除了集群内三副本带来的复制流量再结合 rack‑aware 调度可以让消费者优先就近读取避免消费侧跨 AZ。剩下最难的一块是生产者写入导致的跨 AZ 流量。这里 FSx 起到了关键作用作为共享 WAL它让不同 AZ 的 Broker 可以“对着同一份日志写”不需要在 Broker 之间再做数据复制同时Zone‑routing interceptor 会将跨 AZ 写入“就地代理”到本 AZ 的 Broker只把极少量控制信息跨 AZ 发送而真正的大数据块始终在本 AZ 写入 FSx 并最终落到 S3。通过这套设计AutoMQ 在保留 Kafka 协议兼容和跨 AZ 高可用的前提下将跨 AZ 数据面流量压缩到接近理论下限。从结果上看这个架构让 AutoMQ 在 AWS 上实现了三个目标通过 FSx 提供的低延迟 WAL保持接近本地盘的写入与读取体验通过区域共享存储和 Zone‑routing 机制将跨 AZ 数据面流量压缩到几乎为零仅保留少量控制消息通过 S3 承担主存储继续享受 Diskless Kafka 在成本和弹性上的全部优势。更多实现细节可以参考 How does AutoMQ implement a sub-10ms latency Diskless Kafka?收益引入 FSx 之后AutoMQ 在 AWS 上的 Diskless 架构不再需要在“极致低延迟”和“极致低成本”之间做取舍一方面继续保持存算分离、消除跨 AZ 数据面流量和基于 S3 的超低存储成本另一方面只需少量、固定容量的 FSx 作为区域级低延迟 WAL就可以把端到端延迟拉回到适配微服务、金融交易等核心实时场景的水平。下面我们分别从性能和成本两个维度来说明这一组合方案带来的收益。性能解读从架构上看AutoMQ FSx 解决的是“跨 AZ 高可用场景下如何在不引入跨 AZ 复制流量的前提下继续获得本地盘级别延迟”的问题。我们选择 AWS 提供的FSx for NetApp ONTAP Multi‑AZ 部署模式在同一 Region 内由 FSx 在两个 AZ 内托管一对 HA 节点对外暴露为一个区域级共享文件系统所有 Broker 都将其挂载为唯一的持久 WAL 设备。基于这层区域级共享 WAL整个系统在高可用、弹性和网络成本上形成了一个新的平衡点FSx 提供接近本地 EBS 的随机 IO 能力同时在多个 AZ 之间自动冗余天然满足跨 AZ 高可用要求AutoMQ Broker 仍然是无状态的计算节点可以按负载弹性伸缩而热数据写入全部汇聚到 FSx 上再异步下沉到 S3由于数据不再在 Broker 之间复制跨 AZ 的数据面流量基本被消除只保留控制面通信。在这样的前提下我们在 AWS us-east-1 用一个典型的高吞吐场景来测试端到端性能环境6 台 m7g.4xlarge 作为 BrokerFSx ONTAP 采用 Multi‑AZ 双节点部署二代配置 1,024 GiB 容量、4,000 预置 IOPS、1,536 MB/s 吞吐负载模型4:1 读写比64 KB 消息持续 460 MB/s 写入、1,840 MB/s 读取模拟线上高并发微服务和实时计算任务的混合压力结果写入平均延迟 6.34 ms、P99 17.50 ms端到端平均延迟 9.40 ms、P99 28.00 ms。这组数据可以这样理解在保证跨 AZ 容灾、完全存算分离、以 S3 作为主存储的前提下AutoMQ 通过一个固定大小的 FSx 层把 Diskless Kafka 的 平均写入延迟从“几百毫秒量级”拉回到“ 10 毫秒以下”接近传统本地盘 Kafka 的体验。这意味着客户不需要再为“是否能用 Diskless 架构承载核心业务”担心——包括链路复杂的微服务调用、毫秒级敏感的风控决策与订单撮合等场景都可以在 AutoMQ FSx 上获得既稳定又可预测的延迟表现。成本解读在成本层面AutoMQ 的核心设计是用少量 FSx 构建一个可靠的区域级持久 WAL用海量 S3 承接长期数据从而形成与传统 Kafka 完全不同的成本结构。FSx 只承担高可靠、低延迟的持久 WAL 职责用来承载最新一段写入日志而不会用来长时间堆积业务数据S3 负责存放绝大部分历史数据是集群实际容量扩展的主要载体主数据始终在 S3 上整体存储单价稳定在对象存储量级由于副本冗余集中在 FSx 与 S3 的服务级高可用上AutoMQ 不再需要在 Broker 之间做日志复制也不需要跨 AZ 复制数据从根源上降低了存储和区域间流量开销。得益于这种分层设计即便是 10 Gbps 写入、50 节点规模的 AutoMQ 集群在 FSx 上也只需要不到 100 GB 的 WAL 空间而在 1 Gbps 写入 / 1 Gbps 消费、TTL 3 天的典型场景下只需 6 台 m7g.4xlarge 和 2×1536 GB 的 FSx 即可满足性能与可靠性需求。也就是说虽然 FSx 单位容量价格更高但我们只需要一小块、基本固定容量的 FSx 用于 WAL这部分成本与业务 TTL 长短、历史数据规模几乎无关不会像传统 Kafka 那样随着保留周期拉长而指数式增加副本存储费用。同时通过架构上取消跨 AZ 日志复制和大部分跨 AZ 数据面流量AutoMQ 避免了传统 Kafka 在多 AZ 部署中巨额的网络与复制成本使得整体 TCO 依然由廉价的 S3 存储和按需伸缩的计算实例主导而不是被大规模高价块存储和跨 AZ 带宽费用绑架。接下来我们通过下面这个具体的价格例子来说明价格优势单位月。从这组对比数据可以更直观地看出 FSx 在整体成本结构中的价值在生成端 P99 10ms 的同等延迟目标下传统 Apache Kafka 需要依赖大量高规格实例、三副本存储以及跨 AZ 复制才能勉强达标单月总成本高达约 22.7 万美元其中绝大部分支出都被昂贵的块存储和区域间流量吞噬。而 AutoMQ BYOC FSx 通过固定容量 FSx WAL S3 的架构将副本冗余下沉到 FSx/S3 的服务级高可用上不再在 Broker 之间做日志复制也几乎不产生跨 AZ 数据面流量在提供同等级别甚至更可预测的亚 10ms 生成延迟的前提下总成本仅约 1.8 万美元量级整体节省接近 10×。与 AutoMQ 开源S3 直写的方案相比引入 FSx 后虽然新增了约 8,000 美元的 FSx 成本但 S3 API 调用开销显著下降同时将 P99 从近 900ms 直接拉回到几十毫秒量级完成了“以极小的额外成本换取接近本地盘体验的低延迟”的升级。这也说明在 AWS 上选择 AutoMQ FSx本质上是用一个可控、线性可预估的 FSx 成本换取传统 Kafka 难以实现的低延迟、多 AZ 高可用和跨 AZ 流量成本近乎归零的综合收益。AutoMQ BYOC x FSx: 云市场试用安装 AutoMQ BYOC 控制面你可以参考 AutoMQ 官方文档[2] 从 AWS Marketplace 完成 AutoMQ 控制面的安装。创建集群登入 AutoMQ 控制面的 Dashboard点击Create Instance按钮开始创建集群流程。在集群创建步骤 Network Specs 部分选择 3 AZ 部署。在 AWS 上如果选择单 AZ 部署我们仍然首先推荐使用 EBS WAL它具有最佳的性能、成本表现。在多 AZ 部署的时候考虑到跨 AZ 网络传输成本你可以选择 S3 WAL 或者 FSx WAL。关于 AutoMQ 选择不同 WAL 时在成本、性能上的差异请参考官方文档[3]。选择多 AZ 部署以后你可以在计算存储规格中勾选FS WAL然后对集群容量进行配置。当你选择 EBS WAL 或 S3 WAL 等选项时集群的容量规划被简化为仅需配置一个参数AKUAutoMQ Kafka Unit。你无需再为如何选择 EC2 实例类型、规格和数量而操心AutoMQ 会自动为你挑选经过充分压测验证、在性能与成本之间最优的 EC2 实例组合并确保集群能够稳定满足平台所承诺的吞吐性能指标。例如在 3 AKU 的配置下AutoMQ 承诺可提供 60 MB/s 写入、60 MB/s 读取、2,400 RPS以及不少于 3,375 个分区。通过将底层容量与算力抽象为 AKUAutoMQ 将传统 Kafka 部署中复杂而易出错的容量规划过程收敛为一个清晰可量化的指标关于 AKU 的设计理念、基准测试方法和容量换算规则可参考 AutoMQ 官方文档获取详细说明[4]。在本示例中我们选择 FSx WAL除了配置 AKU 之外还需要额外选择Amazon FSx for NetApp ONTAP的实例规格和数量。AutoMQ 已对不同 FSx ONTAP 实例规格进行了系统化的性能压测与验证用户无需从 IOPS、带宽、容量等维度自行做复杂规划只需根据目标写入吞吐量结合下表即可快速估算所需 FSx 实例数量。在当前配置中我们选择了 3 AKU可支持 60 MB/s 的读取与写入只需搭配 1 个 384 MBps 规格的 FSx 实例即可满足 WAL 写入性能需求。FSx 384MBps 规格提供 150MiB/s Kafka 写入FSx 768MBps 规格提供 300MiB/s Kafka 写入FSx 1536MBps 规格提供 600MiB/s Kafka 写入读写测试集群创建完成后你可以在集群详情页面查看集群的基础信息并按需对集群容量进行弹性调整。FSx得益于 AutoMQ 存算分离的共享存储架构主数据全部持久化在对象存储之上FSx 仅用于加速 WAL 等热路径 I/O。你可以通过增加或减少 FSx 实例数量进行水平扩容而无需像传统 Kafka 那样进行繁重的分区迁移和数据搬移从而以业务无感的方式提升或收缩 FSx 可用容量与带宽。AKU在完成 FSx 实例调整后你可以进一步调整 AKU 的数量使集群的最大处理能力与 FSx 能够提供的最大写入能力相匹配实现计算与存储的解耦伸缩和整体资源利用率的最优化。在本示例中我们使用 AutoMQ 基于 OpenMessaging[5] 封装的 perf 工具[6]来进行性能测试。我们在同一 VPC 内的一台 EC2 上发起了如下的测试负载。KAFKA_HEAP_OPTS-Xmx2g -Xms2g ./bin/automq-perf-test.sh \ --bootstrap-server 0.kf-t1rf19ju6yrtl9fh.fsx-test-wanshao.automq.private:9092,1.kf-t1rf19ju6yrtl9fh.fsx-test-wanshao.automq.private:9092,2.kf-t1rf19ju6yrtl9fh.fsx-test-wanshao.automq.private:9092 \ --producer-configs batch.size0 \ --consumer-configs fetch.max.wait.ms1000 \ --topics 10 \ --partitions-per-topic 128 \ --producers-per-topic 1 \ --groups-per-topic 1 \ --consumers-per-group 1 \ --record-size 52224 \ --send-rate 160 \ --warmup-duration 1 \ --test-duration 5 \ --reset以下是本次示例场景下的读写性能测试结果供参考。从实际测试数据可以看到FSx 的写入延迟与原生 Apache Kafka 处于同一量级能够满足绝大多数对端到端延迟敏感的事件流与实时处理场景的要求。总结在这篇文章中我们展示了 AutoMQ 在 AWS 上引入 FSx 作为 WAL 层之后如何在保持 Diskless Kafka 架构全部优势的前提下把端到端延迟拉回到适配核心实时业务的水平一方面借助「FSx S3」的共享存储架构AutoMQ 实现了真正意义上的存算分离、多 AZ 高可用以及跨 AZ 数据面流量几乎为零另一方面通过在 FSx 上构建一个小而高效的区域级 WAL将写入与读热点全部收敛到低延迟共享存储再异步下沉到 S3从根源上重塑了 Kafka 在云上的性能与成本结构。本次示例中我们也对基于 FSx 的 AutoMQ 进行了简单的性能验证可以稳定实现亚 10ms 级别的平均写入延迟和几十毫秒量级的端到端延迟同时继续享受 S3 级别的低成本存储和无状态 Broker 带来的极致弹性伸缩能力。如果你正在评估如何在 AWS 上为微服务、金融交易、风控决策等延迟敏感业务构建一套真正云原生、低成本、可横向扩展的 Kafka 基础设施欢迎直接在 AWS Marketplace [8]上一键部署并体验 AutoMQ 搭配 FSx 的方案亲自验证 Sub-10ms Latency Diskless Kafka 在你的生产环境中的表现与价值。参考资料[1] AutoMQ WAL Storage[2] Guide: Install AutoMQ from AWS Marketplace[3] AutoMQ’s WAL Storage[4] AutoMQ’s AKU definition[5] The OpenMessaging Benchmark Framework[6] AutoMQ’s Open Source Perf Tool[7] AutoMQ AWS Marketplace