Гибкость в хранении информации и масштабировании в Kafka

Сложно спорить с тем, что одно из важных преимуществ Kafka -- это возможность долговременного хранения информации. Мало того, используя настройки, вы можете как указать определенное время хранения топиков, так и ограничить размер топика в байтах -- в случае превышения сообщения станут недействительны и будут удалены. Разве не удобно, что сообщения хранятся лишь до той поры, пока они нужны? Однако это еще не всё.

Второй момент -- масштабирование.

Когда поток сообщений становится все больше и больше, а одного кластера будет мало, можно развернуть их несколько. К примеру, это актуально, если вы имеете несколько ЦОД, а вам надо копировать между ними информацию. Или же представьте ситуацию, когда в требованиях по доступности информации указано, что вы обязаны иметь в каждом ЦОД полноценную копию данных.

Да, механизмы репликации в кластерах Kafka поддерживают лишь работу внутри одного кластера, а репликация между несколькими кластерами не выполняется. Но выход есть -- утилита Mirror Maker из пакета Kafka. Она не просто свяжет очередью продьюсера и консьюмера, но и будет получать сообщения из одного кластера, публикуя их в другом.

Пример использования MirrorMaker смотрите ниже. Там сообщения из 2-х локальных кластеров агрегируются в составной кластер, а он потом копируется в другие ЦОД. Красота!

По материалам https://habr.com/ru/company/otus/blog/725168/.