使用多个子拓扑优化Kafka Streams应用程序
我正在运行一个Kafka Streams应用程序，它有三个子拓扑。活动的阶段大致如下：
流主题A
主题A、B和C都是物化的，这意味着如果每个主题有40个分区，我的最大并行度是120。
起初，我运行5个流应用程序，每个线程8个。在这种设置下，我遇到了不一致的性能。似乎某些共享同一线程的子拓扑比其他子拓扑更渴望CPU，过了一会儿，我会得到这个错误：组[consumer_group]中的成员[client_id]失败，将其从组（kafka.coordinator.group.Group协调员）中删除。一切都会重新平衡，这可能会导致性能下降，直到下一次失败并重新平衡。
我的问题如下：
- 多个子拓扑如何能够在一个线程上运行？轮询队列？
- 每个线程如何决定如何将计算资源分配给它的每个子拓扑？
- 在这种情况下，您如何优化线程到主题分区的比例以避免周期性的消费者故障？例如，1:1的比例会确保更一致的性能吗？
- 如果您使用1:1的比例，如何确保每个线程都分配了自己的主题分区并且一些线程没有空闲？
共有1个答案
>
线程将轮询（）不同子拓扑的所有主题，并检查记录topic元数据，将其输入正确的任务。
每个子拓扑都被视为相同的，也就是说，如果您愿意，可用资源是均匀分布的。
只有当你有足够的内核时，1:1的比例才有用。我建议您监控CPU利用率。如果太高（更大）
Kafka Streams会自动为您处理此问题。
几点一般性意见：
- 你可以考虑增加
max.poll。间隔ms配置以避免消费者退出该组 - 你可以考虑减少
max.poll。records以减少每次poll（）调用的记录，从而减少连续两次调用poll（）之间的时间 - 注意，
max.poll。记录并不意味着增加网络/代理通信——如果单个获取请求返回的记录多于max.poll。记录config，数据只是缓冲在消费者中，下一个poll（）将从缓冲的数据中提供，避免代理往返
-
在准备拓扑优化时，我偶然发现了以下几点： 目前，Kafka Streams在启用时会执行两种优化： 1-源KTable将源主题重新用作变更日志主题。 2-如果可能，Kafka流会将多个重新分区主题压缩为单个重新分区主题。 这个问题是关于第一点的。我不完全明白这里发生了什么。只是为了确保我没有在这里做任何假设。有人能解释一下，以前是什么状态吗： 1-KTable使用内部变更日志主题吗？如果是，有人能
-
我正在研究一个storm拓扑，需要为不同的客户端位置构建多个拓扑。 谢谢你的回复。
-
本文向大家介绍使用Javascript DFS进行拓扑排序，包括了使用Javascript DFS进行拓扑排序的使用技巧和注意事项，需要的朋友参考一下 有向图的拓扑排序或拓扑排序是其顶点的线性排序，这样对于从顶点u到顶点v的每个有向边UV，在该排序中u都位于v之前。这仅在有向图中有意义。 在很多地方，拓扑排序很有意义。例如，假设您正在遵循一个食谱，在这个食谱中，必须执行一些步骤才能进行下一步。但是
-
首先诚挚的道歉，如果我的问题是重复的，我尝试搜索，但没有找到我的问题的相关答案 首先真诚的道歉，如果我问一些很基本的东西，因为我是Storm的初学者。如果我的问题是重复的，因为我试着搜索但是找不到相关的答案 请就我下面的用例提出建议。 > 因此以25秒为频率的所有元组将汇集在一起，并由Bolt on每25秒发射一次（如果在25秒内收到重复的元组，则只考虑最新的一个元组）。 类似地，所有以10分钟为
-
问题内容： 我必须修改一个dropwizard应用程序以缩短其运行时间。基本上，此应用程序每天接收大约300万个URL，然后下载并解析它们以检测恶意内容。问题在于该应用程序只能处理100万个URL。当我查看该应用程序时，发现它正在进行许多顺序调用。我想对如何通过使其异步或其他技术来改进应用程序提出一些建议。 所需代码如下：- 我在考虑以下方法： 我直接通过调度程序调用，而不是通过POST调用dro
-
所需代码如下：- 我在考虑以下方法：- > 不是通过POST调用dropwizard资源方法，而是直接从计划程序调用。 谢了。 编辑：我能想到两个瓶颈： 网页下载 将结果插入数据库（数据库位于另一个系统中） 似乎一次执行1个URL的处理