несколько узлов для обработки сообщений Kafka

Question

у нас в Kubernetes развернуто приложение весенней загрузки, которое обрабатывает сообщения: оно читает из топологии Kafka c, затем выполняет некоторые сопоставления и, наконец, записывает в темы Kafka

, чтобы достичь более высокого уровня. производительность, нам нужно обрабатывать сообщения быстрее, и, следовательно, мы представляем несколько узлов этого весеннего загрузочного приложения.

, но я считаю, что это приведет к проблеме, потому что:

• Сообщения должны обрабатываться в следующем порядке:

• сообщение содержит состояние

Существует ли какое-либо решение для поддержания порядка сообщений и гарантии того, что сообщение, уже обработанное узлом, не будет обработано другим, и для решения любых других проблем, вызванных обработкой в ​​нескольких узлах.

Пожалуйста, не стесняйтесь обращаться ко всем возможным решениям, потому что мы создаем PO C.

Полезно ли использование apache flink или spring-cloud-stream для этого вопроса?

Answer 1

Предел масштабирования с помощью Flink будет равен количеству разделов в вашей топике Kafka c - другими словами, каждый экземпляр потребителя Flink Kafka будет подключаться и считывать данные с одного или нескольких разделов. С Flink порядок будет сохранен, если вы не переразметите данные. Flink действительно предоставляет гарантию «один раз».

Быстрый способ познакомиться с Флинком и Кафкой в ​​действии - исследовать операционную площадку Флинка . Эта докеризованная игровая площадка настроена так, чтобы вы могли исследовать масштабирование, восстановление после сбоев и т. Д. c., И должна сделать все это гораздо более конкретным.

Answer 2

Вы можете запускать несколько потребительских потоков в одном приложении или даже запускать несколько приложений с несколькими потребительскими потоками. Когда все потребители принадлежат к одной группе и Kafka topi c имеет достаточное количество разделов, Kafka выполнит балансировку между разделами topi c.

Сообщения в одном разделе всегда упорядочены, но для сохранения порядка по ключу сообщения Вы должны установить max.in.flight.requests.per.connection=1. Посредник всегда записывает сообщения с одним и тем же ключом в один и тот же раздел (если только вы не измените номер раздела), поэтому у вас будут заказаны все сообщения с одним и тем же ключом.

Один раздел считывается только одним потребителем, поэтому единственный способ, когда другой потребитель получает обработанные сообщения, это перебалансировка разделов до того, как сообщение будет подтверждено. Вы можете установить ack-mode=MANUAL_IMMEDIATE и подтвердить сообщение сразу после обработки или использовать другие методы подтверждения.

Я бы рекомендовал прочитать эту статью https://medium.com/@felipedutratine / kafka-ordering-гарантии-99320db8f87f

Answer 3

При использовании сообщений от Kafka важно помнить о концепции Consumer Group . Эта концепция гарантирует, что узлы, которые читают из топологии Kafka c и совместно используют одну и ту же группу потребителей, не будут мешать друг другу. Все, что было прочитано одним из потребителей в рамках Группы потребителей, больше не будет прочитано другим потребителем из той же группы потребителей.

Кроме того, приложения для чтения и записи в Kafka масштабируются с количеством разделов в топике Kafka c.

Это не окажет никакого влияния, если у вас есть несколько узлов, использующих топи c только с одним разделом, так как один раздел может быть прочитан только от одного потребителя в группе потребителей. Более подробную информацию вы найдете в документации Kafka по Потребителям .

Если у вас есть топи c с более чем одним разделом, порядок может стать проблемой. Kafka гарантирует только порядок внутри раздела.

Вот отрывок из документации Kafka, описывающей взаимодействие между группой потребителей и разделами :

Обладая понятием параллелизма - разделения - по темам, Kafka может обеспечить как гарантии упорядочения, так и балансировку нагрузки в пуле процессов потребителей. Это достигается путем назначения разделов в topi c потребителям в группе потребителей, так что каждый раздел потребляется ровно одним потребителем в группе. Делая это, мы гарантируем, что потребитель является единственным читателем этого раздела и использует данные по порядку. Поскольку существует много разделов, это по-прежнему балансирует нагрузку на множество пользовательских экземпляров. Однако обратите внимание, что в группе потребителей не может быть больше экземпляров потребителей, чем разделов.