Как справиться с отказом публикации kafka надежным способом

Question

Я использую Kafka, и у нас есть прецедент для создания отказоустойчивой системы, где даже не должно быть пропущено ни одного сообщения. Итак, вот в чем проблема: Если публикация в Kafka завершилась неудачей по какой-либо причине (ZooKeeper down, брокером Kafka и т. Д.), Как мы можем безопасно обрабатывать эти сообщения и воспроизводить их, как только все будет снова восстановлено. Опять же, как я уже сказал, мы не можем позволить себе даже один отказ сообщения. Другой случай использования - нам также необходимо знать в любой момент времени, сколько сообщений не удалось опубликовать в Kafka по какой-либо причине, например, что-то вроде функции счетчика, и теперь эти сообщения нужно снова опубликовать повторно.

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

Этот вопрос больше с точки зрения архитектуры, а затем, какую технологию использовать, чтобы это произошло.

PS: Мы обрабатываем некоторые, например, 3000TPS. Таким образом, при сбое системы эти неудавшиеся сообщения могут расти очень быстро за очень короткое время. Мы используем фреймворки на основе Java.

Благодарим за помощь!

Answer 1

Причина, по которой Kafka была построена в распределенном, отказоустойчивом способе решения таких проблем, как ваша, несколько экземпляров основных компонентов должны избегать прерываний обслуживания. Чтобы избежать использования Zookeeper, разверните по крайней мере 3 экземпляра Zookeepers (если это в AWS, разверните их в зонах доступности). Чтобы избежать сбоев брокера, разверните несколько брокеров и убедитесь, что вы указываете несколько брокеров в своем производителе bootstrap.servers. Чтобы убедиться, что кластер Kafka написал ваше сообщение в надежной усадьбе, убедитесь, что свойство acks=all установлено в качестве производителя. Это подтвердит, что клиент пишет, когда все синхронизированные копии подтверждают получение сообщения (за счет пропускной способности). Вы также можете установить ограничения на очередность, чтобы гарантировать, что если запись в брокер начнет резервное копирование, вы можете поймать исключение и обработать его и, возможно, повторить попытку.

Использование Cassandra (еще одна продуманная распределенная, отказоустойчивая система), чтобы «сценировать» ваши записи, похоже, не добавляет никакой надежности к вашей архитектуре, но увеличивает сложность, плюс Cassandra не была написана очередь сообщений для очереди сообщений, я бы избегал этого.

Правильно сконфигурированный, Kafka должен быть доступен для обработки всех ваших сообщений и предоставления соответствующих гарантий.

Answer 2

Крис уже рассказал о том, как сохранить отказоустойчивость системы.

Kafka по умолчанию поддерживает at-least once семантику доставки сообщений, это означает, что при попытке отправить сообщение что-то происходит, оно попытается отправить его повторно.

При создании Kafka Producer свойств, можно настроить, установив retries вариант более 0.

Properties props = new Properties(); 
props.put("bootstrap.servers", "localhost:4242"); 
props.put("acks", "all"); 
props.put("retries", 0); 
props.put("batch.size", 16384); 
props.put("linger.ms", 1); 
props.put("buffer.memory", 33554432); 
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); 
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"); 

Producer<String, String> producer = new KafkaProducer<>(props); 

Для получения дополнительной информации ознакомьтесь this.