我想知道我的设置是否缺少某些东西,以方便长期运行的工作。
就我而言,可以传递At most once
消息是可以的,这意味着不需要考虑提交偏移量(或者至少可以在收到每个消息偏移量后就提交)。
为了达到竞争的消费者模式,我有以下几点:
我的问题是,我要处理的消息可能需要15分钟左右的时间(但可能会波动多达50%)。为了避免消费者撤销分区分配,我增加了max.poll.interval.ms
的值来反映这一点。
但是,这会带来一些负面影响:
max.poll.interval.ms
的值才能重新平衡max.poll.interval.ms
的值才能进行重新平衡,以便处理任何新消息目前看来,我可以按照以下步骤进行操作:
max.poll.interval.ms
设置为一个较小的值,并接受每个处理每条消息的使用者都会超时并经历取消分配并等待少量时间进行重新平衡的过程但是,我不喜欢这样,并且正在考虑为我的消息队列寻找替代技术,因为我没有发现任何明显的解决方法。 诚然,我是Kafka的新手,上面的东西是不可取的,只是一种直觉。 过去,我曾在这些场景中使用过RabbitMQ,但是目前我们的架构中需要Kafka用于其他目的,如果Kafka可以实现这一目标,那么不必引入另一种技术将是一件很不错的事情。
对于任何人都可以就此主题提供的建议,我深表感谢。
答案 0 :(得分:0)
将Kafka用作作业队列来安排长时间运行的流程不是一个好主意,因为从最严格的意义上来说,Kafka并不是一个队列,并且故障处理和重试的语义也受到限制。尽管您可以通过为重新平衡或超时而进行某些配置来达到折中的目的,但它可能仍会保持脆弱的设计。简单的答案是,Kafka并非针对此类用例而设计。
B
的想法是为了防止出现活锁情况(see),但是在您的情况下,消费者将向Kafka经纪人发送误报,并会触发重新平衡,因为没有办法区分活动锁和合法的长进程。
您应该考虑生活与提到的负面影响之间的权衡。引入一项新技术,可以帮助您更好地建模作业队列。有关更复杂的用例,请查看how slack is doing it。
答案 1 :(得分:0)
我们在评论中提出的解决问题的方法。 我们决定将消息处理与用户轮询分离。
每个工人/消费者都有2个线程,一个用于进行实际处理,另一个用于定期给Kafka打电话。
我们还做了一些工作,试图减少消息的处理时间。 但是,某些消息仍然需要花费几分钟才能测量的时间。 现在已经为我们工作了一段时间,没有任何问题。
感谢@Donal评论中的建议