Короткие тезисы по стриму о Kafka от Монса

Монс, он же Владимир Перепелица - огромный спец в распределенных технологиях и архитектурном "харде". Один из авторов Tarantool и VK S3, на котором мы строим свои Лейкхаусы.

Тезисы, которые выписал себе по ходу стрима о Кафке, НАТСе, очередеях и стриминге данных.

Когда внедряем Kafka

1️⃣ Kafka - Commodity инструмент для работы с потоками данных. Если нужна СУБД, берешь Postgres, если нужен стрим, берешь Kafka.

2️⃣ Kafka добавляет в данные измерение времени. В СУБД как правило - текущий снапшот данных. В Кафке автоматически и почти бесплатно генерируются истории изменений, которые потом может прочитать любой потребитель, а не только тот, кто их генерировал.

3️⃣ Идеальный сценарий работы для Kafka - генерируем поток данных или лог изменений состояний, не зная заранее, кому и зачем он может понадобиться.


О движках

1️⃣ Kafka 4.x - переход на KRaft с Zookeeper. Отныне эта опция по умолчанию.

2️⃣ KRaft лучше и стабильнее, так как все данные и метаданные о топиках, консьюмерах хранятся в одной системе а не двух. Не тратим время на согласование из системы в систему и нет риска, что данные и метаданные в какой-то момент разъедутся.

3️⃣ Граница между движком очереди и движком стрима практически стерта сейчас. Стримы умеют в семантику очереди, очереди умеют в стримы.


О растянутых между ЦОД кластерах

1️⃣ На расстоянии между ЦОД в десятки милисекунд синхронные транзакции работают хорошо. Этого достаточно чтобы сходить туда-обратно и подтвердить, что данные зафиксированы.

2️⃣ Проблема с синхронными транзакциями начнется когда и если на один пользовательский запрос мы начинаем тратить 10-50 транзакций. Это неверная архитектура приложения. Так делать не надо.

3️⃣ Правильный путь - делаем свои 10-50 изменений в приложении и в конце подтверждаем все одной распределенной транзакцией.

4️⃣ Альтернатива - садим в соседний ЦОД а-синхронную реплику и смиряемся с тем фактом, что некоторые данные при плохом раскладе мы моежм потерять

💾💾💾💾💾💾💾💾💾💾💾💾💾💾💾💾💾

Запись стрима можно посмотреть здесь

Архитектор Данных