茶叶电子商务网站建设的结论/自媒体代运营

茶叶电子商务网站建设的结论,自媒体代运营,上海免费模板建站,怎么看一个网站用什么程序做的本内容是对知名性能评测博主 Anton Putra Kafka vs RabbitMQ Performance 内容的翻译与整理, 有适当删减, 相关数据和结论以原作结论为准。简介在本视频中，我们将首先比较 Apache Kafka 和传统的 RabbitMQ。然后，在第二轮测试中，会将 Kaf…

本内容是对知名性能评测博主 Anton Putra Kafka vs RabbitMQ Performance 内容的翻译与整理, 有适当删减, 相关数据和结论以原作结论为准。

简介

在本视频中，我们将首先比较 Apache Kafka 和传统的 RabbitMQ。然后，在第二轮测试中，会将 Kafka 与 RabbitMQ Streams 进行对比，后者在架构和使用场景上更接近 Kafka(RabbitMQ Streams 是一个相对较新的项目，旨在直接与 Kafka 竞争)。

与往常一样，我们将关注 四大核心指标：

吞吐量（Throughput） --- 以 每秒消息数（Messages per second） 衡量。
延迟（Latency） --- 追踪每条消息的发送和接收所需时间。
系统负载（Saturation） --- 包括 CPU 使用率（相对于虚拟机的 CPU 限制）、内存使用情况，以及 磁盘操作（因为 Kafka 采用追加式日志，需要将每条消息存储到磁盘）。
客户端 CPU 负载 --- 统计所有发送和接收消息的客户端的平均 CPU 使用率。

为了运行这些测试，我使用了 AWS。消息代理部署在 i3en.large 规格的实例上，而客户端则运行在 EKS 集群 的 Graviton 实例 上。老实说，这次测试成本不低---要让一个Kafka 代理崩溃，需要消耗大量计算资源。

测试设计

首先，我会快速讲解 Kafka 和 RabbitMQ。

在 Kafka 中，最常用的消息协议之一是 RPC 消息，它采用 二进制格式，相比 JSON 消息 体积更小。这不仅降低了消息代理的负载，还提高了延迟和 吞吐量指标。此外，你可以在 gRPC 和 服务间通信（Service-to-Service Communication） 中复用这些消息。

在本次测试中，我使用 Device RPC 消息，它包含以下字段：

UUID（设备唯一标识符）
MAC 地址
固件版本
设备创建的时间戳

你可以在我的 GitHub 公开仓库中找到源代码。

测试流程

在生产者端，我们使用 随机设备数据 生成 Device RPC 消息，并记录当前时间戳。
然后，我们同时将该消息发送到 Kafka 的Topic 和 RabbitMQ 队列（Queue）。
在消费者端，收到消息后，我们从 created_at 字段中提取时间戳，并计算 消息延迟。

注意：我们不依赖 Kafka 或 RabbitMQ 内部指标 来测量延迟，而是直接在 客户端 端测量，这样测试方式对两者是 公平且准确 的。

如果你认为 测试设计 或 客户端源码 可以优化，欢迎提出建议或提交 Pull Request！

第一轮测试：Kafka vs. 传统 RabbitMQ

让我们开始第一轮测试，比较 Kafka 和 传统 RabbitMQ（后者主要将消息存储在内存中）。

刚开始，你就会注意到：

RabbitMQ 的消息发送和接收延迟比 Kafka 低近一半。这对于某些应用场景可能至关重要，也可能无关紧要，但总体来说，RabbitMQ 的延迟更低。
右侧图表 显示了每个消息系统每秒 处理的消息数。
Kafka 的 CPU 使用率更高，因为它必须将 每一条消息写入磁盘。
左侧图表 显示 Kafka 正在 频繁进行磁盘写入，而 RabbitMQ 几乎不访问磁盘（甚至完全不触碰磁盘）。

另一个重要点：Kafka 的 生产者 和 消费者 的 CPU 使用率 约为 RabbitMQ 客户端的两倍。

当 Kafka 的 CPU 使用率达到 50% 时，延迟开始显著上升。也就是说，当 Kafka 的 CPU 超过 50% 时，其延迟会开始恶化，如果你对低延迟有严格要求，这一点需要特别注意。

RabbitMQ 的极限

当 RabbitMQ 处理达到 15,000 条消息/秒 时，CPU使用率达到 100% ，开始崩溃，延迟急剧上升。
当 RabbitMQ 处理达到 33,000 条消息/秒 时，生产者和消费者 超时（默认超时 5 秒），开始 请求失败。这意味着 RabbitMQ 的最大吞吐量约为 33,000 条消息/秒。