Kafka 处理中的公平性和饥饿性
Fairness & starvation in processing with Kafka
我的用户可以在一天中的任何时间上传任意数量的文件，例如每个文件中有 10000 条记录。个人记录发布到 5 个分区 P1、P2、P3、P4、P5 进行处理。我在组中有 5 个消费者，他们将从这 5 个分区中消费并处理记录。
所以当用户上传文件F1时，P1会排队2500条记录，P2会排队2500条，以此类推。
在此处理过程中，另一个用户上传了文件 F2。但是在 F1 的记录被处理（先进先出）之前，F2 中的记录不会被消费者处理。
如何保证Kafka处理的公平性。也就是说，F2中的记录也应该被处理，而不是等待F1中的记录从队列中完成？
制作方面，为了公平起见，没有什么特别要做的。
如果每个文件都有一个 KafkaProducer 实例，您将确保生成公平。
假设您的文件 F1 处理线程 T1 带有 KafkaProducer Kp1。
T1 将开始从 F1 读取记录并使用 Kp1 生成记录。
假设 T1 它达到了记录 100 'R100'
Kp1 产生了 R100..
然后，此时，您实例化 T2，它将处理另一个具有自己记录的文件 F2。
T2 将读取 R1，Kp2 也会生成 R1'。
因此最终会出现两个交错的文件记录流，从而公平地消费。
Kp1 生产了 R101..
Kp2 产生 R2'...
Kp1 生产 R102...
Kp2 产生了 R3'...
等等
消费端，这取决于你的文件记录是如何产生的。如果您的 10000 条记录需要 1 秒来生成，但需要 1 分钟才能生成 consume/process，并且您希望每分钟最多 5 个文件，那么您可以设想每个分区都有一个专用文件（使用密钥），但您仍然如果两个连续文件的密钥散列相同，则不公平......（100％的时间不公平）。
Kafka 并不是避免饥饿的最佳解决方案。它不是像 rabbitMQ 那样的队列技术。
您最终最多会为每个分区配备一个专用的使用者，但您无法确定您的文件是否会均匀分布在各个分区之间（除非您开发了一种在分配之前寻找空闲分区的观察器对记录的分区)..
雅尼克
我的用户可以在一天中的任何时间上传任意数量的文件，例如每个文件中有 10000 条记录。个人记录发布到 5 个分区 P1、P2、P3、P4、P5 进行处理。我在组中有 5 个消费者，他们将从这 5 个分区中消费并处理记录。
所以当用户上传文件F1时，P1会排队2500条记录，P2会排队2500条，以此类推。
在此处理过程中，另一个用户上传了文件 F2。但是在 F1 的记录被处理（先进先出）之前，F2 中的记录不会被消费者处理。
如何保证Kafka处理的公平性。也就是说，F2中的记录也应该被处理，而不是等待F1中的记录从队列中完成？
制作方面，为了公平起见，没有什么特别要做的。 如果每个文件都有一个 KafkaProducer 实例，您将确保生成公平。
假设您的文件 F1 处理线程 T1 带有 KafkaProducer Kp1。 T1 将开始从 F1 读取记录并使用 Kp1 生成记录。 假设 T1 它达到了记录 100 'R100' Kp1 产生了 R100..
然后，此时，您实例化 T2，它将处理另一个具有自己记录的文件 F2。 T2 将读取 R1，Kp2 也会生成 R1'。
因此最终会出现两个交错的文件记录流，从而公平地消费。
Kp1 生产了 R101.. Kp2 产生 R2'... Kp1 生产 R102... Kp2 产生了 R3'... 等等
消费端，这取决于你的文件记录是如何产生的。如果您的 10000 条记录需要 1 秒来生成，但需要 1 分钟才能生成 consume/process，并且您希望每分钟最多 5 个文件，那么您可以设想每个分区都有一个专用文件（使用密钥），但您仍然如果两个连续文件的密钥散列相同，则不公平......（100％的时间不公平）。
Kafka 并不是避免饥饿的最佳解决方案。它不是像 rabbitMQ 那样的队列技术。
您最终最多会为每个分区配备一个专用的使用者，但您无法确定您的文件是否会均匀分布在各个分区之间（除非您开发了一种在分配之前寻找空闲分区的观察器对记录的分区)..
雅尼克