总结
在云中保持传统 Kafka 的低延迟颇具挑战。这在过度预置带来的高成本与流量高峰期的低性能之间造成了艰难的权衡。为了解决这一问题，新的云原生流式系统以不同的架构方式应运而生。
在本文中，您将了解：
- AutoMQ 是新一代的开源 Kafka 解决方案，基于 Apache 2.0 许可证在 GitHub 上发布
- 它经过精心设计，可在云中经济高效地运行
- Azul Zing 作为 Azul Platform Prime 的 JVM，是一个高性能的 Java 平台
- AutoMQ 对 Azul Zing 与标准 OpenJDK HotSpot 进行了正面对比
- OpenJDK HotSpot 的平均 CPU 利用率为 92.4%
- Azul Zing 的平均 CPU 利用率为 59.1%。
为什么延迟对 Kafka 如此重要？
Kafka 中低延迟的重要性取决于它所支持的用例。许多依赖 Kafka 的应用程序都对时效性有严格要求。
- 金融交易平台、欺诈检测系统和实时监控服务等实时应用程序依赖于获取最新的可用信息。短短几秒的延迟，可能决定一笔交易是成功达成还是错失良机，也可能决定欺诈交易是被成功阻止还是导致财务损失。
- 用户体验是延迟发挥重要作用的另一个领域。想想应用内通知、实时更新的数据看板或多人游戏。反应迅速、响应及时的系统使用起来体验很好。反之，反应迟缓的系统则可能让用户兴致大减。
- 从操作角度来看，延迟是一项衡量 Kafka 集群运行状况的指标。延迟突然升高可能是潜在问题的早期预警信号，例如网络瓶颈或消费者处理缓慢；若对此置之不理，可能会导致消息积压，进而引发系统不稳定。
在云中保持传统 Kafka 的低延迟颇具挑战。其架构将计算和存储结合在一起，由于数据重新平衡，使得扩展缓慢且代价高昂。这在过度预置带来的高成本与流量高峰期的低性能之间造成了艰难的权衡。为了解决这一问题，新的云原生流式系统以不同的架构方式应运而生。
AutoMQ 简介
AutoMQ 是新一代的开源 Kafka 解决方案，基于 Apache 2.0 许可证在 GitHub 上发布。通过彻底重新构建其设计，它可在云中经济高效地运行。AutoMQ 的核心创新是计算（代理）和存储的完全分离。与将数据绑定到代理磁盘的传统 Kafka 不同，AutoMQ 使用云对象存储（例如 Amazon S3）作为其主要且持久的数据存储。这使得计算和存储资源可以相互独立地扩展 [图 1]。
这种现代架构为云部署提供了多项关键优势：
- TCO 最多可降低 90%：通过利用 Amazon S3 等经济实惠的对象存储并消除昂贵的跨可用区数据复制流量，AutoMQ 大幅降低了总拥有成本。
- 真正的弹性：集群可以在数秒内进行扩展或缩减，以满足实时需求。这样避免了传统 Kafka 中常见的缓慢且具有破坏性的数据重新平衡过程，该过程可能需要数小时甚至数天。
- 自我平衡与修复：代理的无状态特性意味着集群可以自动平衡工作负载并从节点故障中恢复，而无需手动干预。
- 100% Kafka 兼容性：AutoMQ 是 Kafka 的直接替代品。您可以使用相同的熟悉协议和 API 迁移现有应用程序并连接您的工具，而无需更改任何代码 [图 2]。
OpenJDK 的 Azul Zing 构建版本简介
Azul Zing 是 Azul Platform Prime 的一部分，是一种高性能 Java 虚拟机 (JVM)，专门设计用于为 Java 应用程序提供一致、低延迟的性能。它可以作为 OpenJDK HotSpot 等标准 JVM 的直接替代品，这意味着您可以在不更改应用程序代码的情况下使用它。
Azul Zing 通过多种相互独立的方式提升 Java 应用程序的性能 [图 3]：
- 消除垃圾收集 (GC) 引起的暂停 – C4 收集器在应用程序运行的同时清理内存，避免其他 JVM 中常见的全局暂停。这种设计有效地消除了垃圾收集作为延迟来源的问题。对于像 Kafka 这样的高时效性服务，这是一个关键问题。
- 生成更高效的机器代码 – Falcon JIT 编译器会在运行时优化您的应用程序代码。Zing 的 Falcon JIT 编译器生成的代码平均比 OpenJDK 的 HotSpot JIT 编译器快 40%。
- 改进 JVM 预热并消除因去优化而导致的暂停 – Zing 的 ReadyNow 技术通过保留先前运行的分析信息，大幅改进了 Java 应用程序的预热行为，使得后续运行不必从头开始学习优化模式。这解决了 Java 的预热问题，并确保立即提供峰值应用程序性能，而不会出现较长的预热期或由于无效优化而导致的延迟异常值。
对于代理和客户端应用程序基于 Java 构建的 Kafka 生态系统，Azul Zing 提供了实现卓越性能的直接途径。通过确保底层 JVM 不会引入随机暂停并进一步提升整体性能，Azul Zing 能让整个数据管道以现代服务所需的平滑、可预测的低延迟运行。
性能测试及说明
为了了解 JVM 对 Kafka 工作负载的实际影响，我们对 Azul Zing 和标准 OpenJDK HotSpot 进行了正面对比。对于任何大规模消息系统，我们重点关注两个关键指标：端到端延迟和 CPU 利用率。
测试环境配置
| 组件 | 规格 |
|---|---|
| 基础设施 | 规格 |
| 测试工作负载 | 2 x r6in.large AWS EC2 实例（1 个服务器，1 个客户端） |
| Oracle Hotspot 版本 | OpenJDK 17.0.15 |
| Azul Zing 版本 | Zing 25.06.0.0, JDK 17.0.15 |
| AutoMQ 版本 | AutoMQ Enterprise 5.20 |
延迟：优化尾部延迟
对于像 Kafka 这样的系统，平均延迟只能说明部分情况。真正的问题在于那些异常值（延迟最高的请求），它们可能会破坏服务稳定性并影响用户体验。这正是尾部延迟（p99 及以上）成为关键指标的原因。
我们的结果显示，Azul Zing 在这一方面具有明显的优势 [图 4]。
尽管平均延迟相当，但差异在较高的百分位处变得明显。在 OpenJDK HotSpot 上运行时，第 99.99 个百分位的延迟平均为 48.9 毫秒，最大峰值超过 118 毫秒。
相比之下，Azul Zing 的性能更加稳定。第 99.99 个百分位的延迟平均仅为 18.3 毫秒，最大延迟仅为 35.1 毫秒。它可以防止可能影响最敏感操作的极端延迟峰值，从而确保系统更加可预测且稳定可靠。
CPU 利用率：事半功倍
第二个关键发现是在持续负载下 CPU 消耗的差异。Azul Zing 的 Falcon JIT 编译器致力于持续优化正在运行的代码。经过初始优化阶段后，结果很明显。
我们连续测试运行的数字突显了效率提升 [图 5]。在我们的 2 核测试服务器（最大利用率为 200%）上，平均 CPU 利用率为：
- OpenJDK HotSpot: 92.4%
- Azul Zing: 59.1%
完全优化后，与 OpenJDK HotSpot 相比，Azul Zing 的 CPU 使用率减少了约三分之一，同时处理完全相同的工作负载。
这种 CPU 开销的降低非常显著。这意味着应用本身拥有更多的处理空间，从而可以在相同硬件上处理更多流量或降低基础设施成本。
未来展望
我们的性能对比显示，在 Azul Zing JVM 上运行 AutoMQ for Kafka 相较于标准 OpenJDK 环境，带来了显著的提升。Azul 平台消除了极端的尾部延迟峰值，从而确保性能更加可预测。此外，它还降低了处理相同流量所需的 CPU 负载，从而可以提高吞吐量或降低基础设施成本。
最终，该测试凸显了引人注目的协同作用。AutoMQ 利用云对象存储为 Kafka 提供现代、弹性且经济高效的架构。与提供稳定、无暂停运行时环境的 Azul Zing 搭配使用时，可得到高度可靠且资源高效的流式解决方案。这种组合旨在满足现代实时应用程序的需求，提供架构创新和运行时稳定性。
有关在 Azul Zing 上运行 AutoMQ 或 Kafka 工作负载的详细信息，请参阅 https://www.azul.com/technologies/kafka/。
如果您已准备好深入体验，AutoMQ 现已简化流程，让您轻松开始免费试用。
