Kafka模式则不同。kafka集群本身只存储数据流。计算发生在Kafka星团之外。因此，共定位的概念是有限的，即数据总是通过网络发送给进行处理的消费者/流应用程序。
对于kafka流，例如，如果执行连接，则连接的两个输入流的数据子流（基于kafka分区）将位于单个kafka streams示例中，以计算正确的结果。
注意，数据流处理是一个不同的模型，因此“将代码传送到数据”对于批处理并不重要。

我们为什么要这样？减少网络流量？减少延迟？
如果可能的话，我们希望尝试将每个分区分配给本地使用者。下列任何一种情况都不可能或不可取：
代理的主机不运行任何使用者
本地消费者不订阅经纪人的主题
与一些外部消费者相比，本地消费者负担过重
即使是相对简单的 StickyAssignor ，这个问题原来是一个多目标优化问题：
优化均匀分布的用户负载
优化以保留以前分配的分区
总之，在主题分布和消费者成员关系动态变化的情况下！
下一步将引入一些局部性的数值度量。理想的分配是尝试将代理和使用者连接到同一主机、机架、数据中心或大陆上。例如，您可能希望使用ping时间作为进程之间距离的度量；或者一些啤酒花。
另一个方面是主机功能和负载的变化。消费者的主机还能处理多少个分区？
必须有一种方法将所有需求聚合为一个数字：将主题x分配给消费者y有多好。
最后，你可能会得到一个 n * m 分配分数矩阵：对于每个消费者-经纪人对，您可以计算分配惩罚。通过解决作业问题 O(n^3) 到时候你会得到最好的任务，这对你的申请很重要：
接近布洛克
接近最终用户
消费者的缓存状态
用户节点的cpu负载和可用磁盘空间
可能还有其他一些标准，如：法规要求、计划维护、运行节点的成本
Kafka有一个 PartitionAssignor 类，它控制主题和使用者之间的关系。default是一种非常简单的算法，但是还有一些更复杂的实现，比如stickyassignor，它试图保留消费者的缓存。它是一个可插拔的接口，开放供实验使用。
Kafka的哲学主张稳健性和普遍性。也许这就是为什么如此脆弱和多方面的优化不是标准发行版的一部分。