Интерпретация точно-когда-то семантики Кафки

Почему именно один раз важен

Существуют определенные варианты использования (например, финансовые приложения, приложения IoT и другие потоковые приложения), которые не могут позволить себе ничего меньше, чем один раз. Вы не можете позволить себе иметь дубликаты или потерять сообщения при пополнении или снятии денег с банковского счета. Это нужно ровно один раз в качестве окончательного результата.

Почему это трудно достичь

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

Проблема 1: Дублирование или множественные записи

Обратитесь к рисунку 1а. Сообщение m1 обрабатывается и записывается в тему B. Сообщение m1 успешно записывается в тему B (как m1 ‘ ), но подтверждение не принимается. Причиной может быть, скажем, задержка сети, и это в конечном итоге истекает.

Рисунок 1a: Дублирующая проблема записи.

Рисунок 1b: Дублирующая проблема записи из-за повторной попытки.

Поскольку приложение не знает, что сообщение уже успешно записано, так как оно никогда не получало подтверждение, оно повторяет попытку и приводит к повторной записи. Обратитесь к рисунку 1b. Сообщение m1 ‘ переписывается в тему B. Это дублирующая проблема записи, которую необходимо исправить.

Проблема 2: перечитать входную запись

Рисунок 2a: Перечитайте проблему из-за сбоя приложения.

Рисунок 2b: Перечитайте проблему при перезапуске аварийного приложения.

Обратитесь к рисунку 2а. У нас тот же сценарий, что и выше, но в этом случае потоковое приложение вылетает непосредственно перед фиксацией смещения. Поскольку смещение не зафиксировано, когда потоковое приложение снова появляется, оно перечитывает сообщение m1 и снова обрабатывает данные (рисунок 2b). Это снова приводит к дублированию записей сообщения m1 в теме B.

Как Apache Kafka помогает

Apache Kafka решает описанные выше проблемы с помощью семантики с точным однократным использованием, используя следующее.

Идемпотент Продюсер

Идемпотентность на стороне производителя может быть достигнута путем предотвращения многократной обработки сообщений. Это достигается сохранением сообщения только один раз. При включенной идемпотентности каждое сообщение Кафки получает две вещи: идентификатор производителя (PID) и порядковый номер (seq). Назначение PID полностью прозрачно для пользователей и никогда не раскрывается клиентами.

Рисунок 3: Идемпотентный производитель

producerProps.put("enable.idempotence", "true");
producerProps.put("transactional.id", "100");

producer.initTransactions();
try {

producer.beginTxn(); 
 // ... read from input topic
 // ... transform

producer.send(rec1); // topic A 
producer.send(rec2); // topic B 
producer.send(rec3); // topic C 

producer.sendOffsetsToTxn(offsetsToCommit, “group-id”);

  producer.commitTransaction();
} catch ( Exception e ) {
  producer.abortTransaction();
}