Лучшие практики топологии Кафки

Question

У меня есть 4 машины, в которых кластер Kafka настроен с топологией, в которой у каждой машины есть один зоокейпер и два брокера.

С этой конфигурацией, что вы посоветуете для максимальной темы и раздела для лучшей производительности?

Фактор репликации 3: использование Кафки 0.10.XX

Спасибо?

Answer 1

Каждая тема ограничена 100000 разделов независимо от количества узлов (по состоянию на июль 2017 г.)

Что касается количества тем, которые зависят от размера самой маленькой оперативной памяти на всех машинах. Это происходит из-за того, что Zookeeper хранит все в памяти для быстрого доступа (также он не разделяет znodes, просто реплицируется между узлами ZK при записи). Это фактически означает, что когда вы исчерпаете память одной машины, ZK не сможет добавить больше тем.

Чтобы процитировать документы KAFKA на их сайте (6.1 Основные операции Kafka https://kafka.apache.org/documentation/):

Журнал каждого сегментированного раздела помещается в отдельную папку в каталоге журнала Kafka. Имя таких папок состоит из названия темы, добавляемого тире (-) и идентификатора раздела. Поскольку типичное имя папки не может быть длиннее 255 символов, будет ограничение на длину названий тем. Мы предполагаем, что количество разделов не будет превышать 100000. Поэтому имена тем не могут быть длиннее 249 символов. Это оставляет достаточно места в имени папки для тире и потенциально 5-значного идентификатора раздела.

Чтобы процитировать документы Zookeeper ( https://zookeeper.apache.org/doc/trunk/zookeeperOver.html):

Реплицированная база данных является базой данных в памяти, содержащей все дерево данных. Обновления записываются на диск для восстановления, а записи сериализуются на диск перед их применением к базе данных в памяти.

Спектакль:

В зависимости от вашей семантики публикации и потребления конечный раздел раздела будет меняться. Ниже приводится набор вопросов, которые вы должны задать себе, чтобы получить представление о потенциальном решении (ваш вопрос очень открыт):

• Являются ли данные, которые я публикую, критически важными (то есть не могут их потерять, должны быть уверены, что я их опубликовал, они должны иметь ровно один раз потребления)?
• Должен ли я сделать так, чтобы продюсер product.send() выполнялся как можно более синхронно, или продолжать использовать асинхронный метод с пакетной обработкой (компромисс между публикациями и гарантиями скорости)
• Являются ли публикуемые мной сообщения зависимыми друг от друга? Должно ли сообщение A использоваться до сообщения B (подразумевается, что A опубликовано до B)?
• Как выбрать раздел для отправки моего сообщения? Должен ли я: назначить сообщение разделу (дополнительная логика производителя), разрешить кластеру принять решение в виде циклического перебора или назначить ключ, который будет хешировать одному из разделов для темы (необходимо придумать равномерно распределенный хэш чтобы получить хорошую балансировку нагрузки между разделами)
• Сколько тем вы должны иметь? Как это связано с семантикой ваших данных? Будут ли эффективными автоматически создаваемые темы для многих отдельных логических областей данных (подумайте о влиянии на Zookeeper и административной боли при удалении устаревших тем)?
• Разделы обеспечивают параллелизм (возможно большее количество потребителей) и, возможно, повышенные положительные эффекты балансировки нагрузки (если производитель публикует правильно). Желаете ли вы назначить части элементов вашего проблемного домена определенным разделам (при публикации отправьте данные для клиента A в раздел 1)? Какие побочные эффекты это имеет (думаю, рефакторируемость и ремонтопригодность)?
• Хотите ли вы создавать больше разделов, чем вам нужно, чтобы при необходимости вы могли расширяться с большим количеством брокеров / потребителей? Насколько реалистично автоматическое масштабирование кластера KAFKA с учетом вашего опыта? Будет ли это сделано вручную? Является ли ручное масштабирование жизнеспособным для вашей проблемной области (вы строите KAFKA вокруг фиксированной системы с хорошо известными характеристиками или вам необходимо уметь обрабатывать серьезные всплески в сообщениях)?
• Как мои потребители будут подписываться на темы? Будут ли они использовать предварительно настроенные конфигурации или использовать регулярные выражения, чтобы использовать много тем? Являются ли сообщения между темами зависимыми или приоритетными (нужна дополнительная логика для потребителя для реализации приоритета)?
• Следует ли использовать разные сетевые интерфейсы для репликации между брокерами (например, порт 9092 для производителей / потребителей и 9093 для трафика репликации)?

Хорошие ссылки:

http://cloudurable.com/ppt/4-kafka-detailed-architecture.pdf https://www.slideshare.net/ToddPalino/putting-kafka-into-overdrive https://www.slideshare.net/JiangjieQin/no-data-loss-pipeline-with-apache-kafka-49753844 https://kafka.apache.org/documentation/