Хотя у меня не было такого сценария резервирования с одним постоянным током, но я вижу, что это может быть интересно для некоторых клиентов.Так что это гипотетическое решение.
На мой взгляд, было бы плохой идеей рассматривать инфраструктуру не-Kafka в качестве решения для резервного копирования.Ваши программисты будут плакать во время кодирования, поскольку API-интерфейсы зависят от множества метаданных, связанных с Kafka, для получения соответствующих сообщений из тем и разделов.Как приложение найдет последнюю запись, которую оно обрабатывает из темы-1: Раздел 27?куда пойдут будущие записи, поскольку производители также используют API-интерфейсы Kafka.
Я бы построил вторичный кластер Kafka, меньший по сравнению с вашим основным кластером с изолированными брокерами, zookeeper и дисками.Используйте средство для создания зеркал или репликатор (https://docs.confluent.io/current/multi-dc-replicator/mirrormaker.html), чтобы заполнить этот кластер фактическими данными. Вы можете сократить время хранения, чтобы управлять дисковым пространством и т. Д., Но при этом все ваши приложения реального времени будут работать гладко.
Когда ваш основной кластер выйдет из строя, приложения должны будут использовать посредников этого кластера для регулярной обработки.
Потребительские приложения должны будут сохранять смещения за пределами Kafka, чтобы иметь возможность просто перезапускать с последней контрольной точки.изменить идентификатор брокера. Этот переключатель может быть запрограммирован в прокси или независимом микросервисе, поддерживающем соединения Kafka, если вы хотите перейти на этот уровень.