标签：消费者 环境中运行 经验教训 分区 主题 Kafka 日志 kafka
在生产环境中运行 Kafka 后的经验教训
Kafka logo
在生产环境中运行自托管 Kafka 超过 2 年。在这里，我编制了一个提示和陷阱列表。
背景：我们使用 Kafka 作为我们的主要 Pub-Sub 来设置多个管道和接近 100 个主题，超过 5000 个 pod（客户端）连接到它，每天在最繁忙的主题之一上产生和消费超过 1 千万（1000 万）条消息.
1. 什么是卡夫卡？
场景：你有 10 个消费者在听一个主题，比如主题 A。
- 所有消费者都有不同的组 ID：在这种情况下，主题 A 上的每条消息都将到达所有 10 个消费者。
- 所有消费者具有相同的组 ID：在这种情况下，消息将在所有消费者之间平均分配（前提是您设置了正确数量的分区。）
2. 卡夫卡的闪光点
- 即使数据量很大，Kafka 也能很好地工作，尤其是在数据包很小的情况下。
- 它确保“至少一次”消息传递，这意味着没有消息在传输过程中丢失。
- 一旦你让 Kafka 在充足的 RAM 和 HDD 上正常运行，它将运行很长时间并且维护成本很低，在 2 年多的生产中使用与 kafka 相关的事件不到 5 次。
- 可以处理大量的连接， linkedIn 报告每个节点有超过 10k 的连接。
- 甚至我们的 微不足道的 单节点 , 自托管 Kafka 可以很好地处理 5k 个连接和 100 个主题以及许多 1000 个分区主题。
3. 卡夫卡的不足之处
- 对于自托管的 Kafka——初始设置肯定不容易，新版本经常出现，有 许多 过时的指南，并且有无数错误需要您深入研究 Kafka 日志。看着那（这 ” ** 常见的陷阱** ”本文的部分以获取更多信息。
- 大消息：如果您的消息大小超过 1Mb，则需要进行配置更改，即使配置正确，我发现 Kafka 在处理低于 10Mb 的消息时遇到了困难，吞吐量非常低，并且需要大量的消费者才能无延迟地操作。
- *** 重要的 *** 滞后分布不均匀：我们有一个运行 ML 模型的奇怪场景，我们在 GKE 中运行了近 100 个 Pod，消耗来自 Kafka 主题并执行一些 CPU 密集型任务。在峰值负载后，我们看到总共 100 个 Pod 中有 30-40 个处于预期 CPU 使用率水平，而其余 60-70 个 Pod 的使用率接近 0%，而 Kafka 延迟为 1000 秒，这意味着仍有充足的消息来处理。我们有一个基于 Kafka 延迟的扩展设置，这意味着除非延迟达到所需的水平，否则工作负载不会缩减并关闭 Pod。所以基本上大多数工人都在闲着，而还有很多工作要做。深入挖掘发现，Kafka 为所有消费者分配了分区，分区的分配是轮询的，单个消费者可以有多个分区。我们发现，与使用率高的 pod 相比，使用率为 0% 的 pod 分配的分区数量更少。该问题的解决方案在 ** “为主题选择分区数”** 部分，它实际上促使我写这篇文章。
- 速度：消费者消费消息的速度以及清除 Kafka 延迟的速度并不是市场上最快的。为了证明这一点，我们进行了以下测试：在关键主题之一上，我们将 Kafka 替换为 GCP pubsub。我们跟踪的指标：从发布者发布到消费者消费的平均时间。该指标从 8-9 分钟下降到 50 秒。
4. 选择主题的分区数
通过选择适当数量的分区，可以部分避免上一节中描述的“滞后分布不均匀”问题。这取决于一个 您计划运行的最大消费者数量，例如 N , 那么数量 分区应始终是 N 的倍数 ，以防止分区分配不均给消费者。现在将继续发生的一个问题是，如果您正在运行基于负载自动扩展的设置，那么消费者的数量并不总是处于正确的比例，并且一些消费者将有额外的分区。由于 Kafka 无法在分区之间重新分配消息，因此这个问题无法用 kafka 解决。 GCP pubsub 等其他 pubsub 完全解决了这个问题。
如果分区数量太大，如果消费者数量非常少，就会出现问题，而大量的分区需要Kafka创建、打开连接和写入更多的日志文件，这可能是一个问题描述在“常见陷阱”部分， ** 打开文件限制** 在这种情况下需要适当。
一般来说，如果你在谷歌上搜索“如何确定分区数量”这个主题，你会得到这样的答案，比如如果你想要更多的并行性，你应该有更多的分区，对于像我这样的新手来说，这听起来像是如果你想要更多的可扩展性，有一个令人讨厌的数字，因此以后不会成为瓶颈。但“更多的并行性”实际上意味着拥有 至少 与消费者一样多的分区。
TLDR：至少有与最大消费者数（C）一样多的分区（P），但分区数应始终是消费者数的倍数。 P = n * C, n =1,2,3…
5. 常用Kafka命令精选列表
我创建了一个我最常用的命令行 Kafka 命令列表：
[
kafka-commands,下载kafka-commands的源码_GitHub_帮酷
Kafka 安装这些命令需要命令行 在 kafka 的 bin 目录下运行 创建一个新主题：bash...
github.com
](https://github.com/hardiktaneja/kafka-commands/tree/main)
6. 臭名昭著的“Kafka is rebalancing”问题
我们遇到的最令人困惑的问题之一与 Kafka 相关，但这个信息日志让我们这么想。每当一个新的消费者加入一个消费者组并开始监听一个主题时，Kafka 都会为其分配一个分区。同样，如果消费者离开一个组，则需要重新分配其分配的分区。因此，如果您的日志中不断出现“Kafka is rebalancing”，则意味着消费者不断地离开或被添加到您的消费者组。所以问题可能是运行 Kafka 消费者的应用程序/脚本过早崩溃。
7. 常见的陷阱
- 打开文件限制：由于 Kafka 是基于日志的消息代理，它需要写入日志文件，并且本质上根据您拥有的主题数量以及这些主题拥有的分区数量成比例地打开许多连接。这是 资源 为了这。
- 日志保留：如果设置不正确，运行 kafka 的服务器上的 HDD 可能会耗尽导致停机。估计您将在一小时/天/周内通过 Kafka 发送多少数据并进行相应设置。
感谢您阅读本文，希望您有所收获。
如果您有任何问题或反馈，请随时与我们联系。
电子邮件：[email protected]
领英： www.linkedin.com/in/hardik-taneja
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
标签：消费者,环境中运行,经验教训,分区,主题,Kafka,日志,kafka 来源： https://www.cnblogs.com/amboke/p/16654113.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。