* [Архитектура брокера](#архитектура-брокера)

* [Архитектура продюсера](#архитектура-продюсера)

* Стриминг больших данных

* Много клиентов (producer и consumer)

* Требуется кратное масштабирование

* Это не брокер сообщений

* Отложенные сообщения

* `replication.factor`

* **Описание**: Количество реплик для каждой партиции топика

* **Пример**: `replication.factor=3`

* `min.insync.replicas`

* **Описание**: Минимальное количество синхронизированных реплик

* **Пример**: `min.insync.replicas=2`

* `retention.ms`

* **Описание**: Время хранения сообщений в топике в миллисекундах

* **Пример**: `retention.ms=604800000` (7 дней)

* `retention.bytes`

* **Описание**: Максимальный объём данных в топике, после чего старые сообщения удаляются

* **Пример**: `retention.bytes=10737418240` (10 GB)

* `segment.bytes`

* **Описание**: Размер сегмента логов топика

* **Пример**: `segment.bytes=1073741824` (1 GB)

* `cleanup.policy`

* **Описание**: Как Kafka обрабатывает старые сообщения

* **Значения**: `delete`, `compact`

* **Пример**: `cleanup.policy=delete`

* `num.partitions`

* **Описание**: Количество партиций в топике

* **Пример**: `num.partitions=3`

[к оглавлению](#apache-kafka)

* **У каждой партиции свой лидер** — в Kafka для каждой партиции в топике назначается лидер-брокер, который отвечает

за запись и чтение данных

* **Сообщения пишутся в лидера** — производители отправляют сообщения напрямую в брокер-лидер партиции

* **Данные реплицируются между брокерами** — для обеспечения отказоустойчивости Kafka реплицирует данные партиций на

другие брокеры, которые становятся репликами

* **Автоматический фейловер лидера** — в случае сбоя брокера-лидера Kafka автоматически назначает новый лидер из числа

реплик, обеспечивая бесшовную работу системы

* `min.insync.replicas`

* **Описание**: Минимальное количество синхронизированных реплик для подтверждения записи

* **Пример**: `min.insync.replicas=2`

* `unclean.leader.election.enable`

* **Описание**: Разрешает выбор лидера из неактуальных реплик, если нет синхронизированных реплик

* **Пример**: `unclean.leader.election.enable=false`

* `log.dirs`

* **Описание**: Директория на диске, где хранятся логи партиций

* **Пример**: `log.dirs=/var/lib/kafka/logs`

* `log.retention.hours`

* **Описание**: Максимальное время хранения данных в логах

* **Пример**: `log.retention.hours=168` (7 дней)

* `log.segment.bytes`

* **Описание**: Максимальный размер сегмента лога, после чего создаётся новый

* **Пример**: `log.segment.bytes=1073741824` (1 GB)

* `num.network.threads`

* **Описание**: Количество потоков для обработки сетевых запросов

* **Пример**: `num.network.threads=3`

* `num.io.threads`

* **Описание**: Количество потоков для ввода-вывода

* **Пример**: `num.io.threads=8`

* `socket.send.buffer.bytes`

* **Описание**: Размер буфера для отправки данных по сети

* **Пример**: `socket.send.buffer.bytes=102400`

* `message.max.bytes`

* **Описание**: Максимальный размер сообщения, которое брокер может принять

* **Пример**: `message.max.bytes=1048576` (1 MB)

* `replica.fetch.max.bytes`

* **Описание**: Максимальный размер данных для запроса реплики

* **Пример**: `replica.fetch.max.bytes=1048576` (1 MB)

* `ssl.keystore.location`

* **Описание**: Путь к хранилищу ключей SSL

* **Пример**: `ssl.keystore.location=/var/private/ssl/kafka.keystore.jks`

* `ssl.truststore.location`

* **Описание**: Путь к хранилищу доверенных сертификатов

* **Пример**: `ssl.truststore.location=/var/private/ssl/kafka.truststore.jks`

[к оглавлению](#apache-kafka)

* **Создание сообщения (Record)**: Продюсер формирует сообщение, содержащее ключ (необязательный), значение и метаданные,

такие как время отправки. Сообщение отправляется в топик (Topic), который состоит из одной или нескольких партиций

* **Выбор партиции**: Если ключ сообщения указан, Kafka использует его для хеширования и определения, в какую партицию

записать сообщение (сообщения с одинаковым ключом попадают в одну и ту же партицию). Если ключа нет, Kafka распределяет

сообщения по партициям с помощью round-robin или по другим правилам

* **Отправка сообщений в буфер (Batching)**: Для повышения производительности продюсер Kafka не отправляет каждое сообщение

по отдельности, а группирует несколько сообщений в пакеты (batching), прежде чем отправить их брокеру. Это снижает

сетевые задержки и нагрузку на брокера

* **Сжатие (Compression)**: Для уменьшения объёма передаваемых данных продюсер может сжимать сообщения с использованием

таких алгоритмов, как GZIP, Snappy или LZ4. Сжатие снижает нагрузку на сеть и хранение, но добавляет небольшие накладные

расходы на процессор

* **Асинхронная отправка**: Продюсер отправляет пакеты сообщений асинхронно. Это означает, что сообщения записываются в

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

* **Подтверждения (Acknowledgments)**: Kafka позволяет настраивать уровень подтверждений от брокеров

* **Ретрай и идемпотентность**: Если отправка сообщения не удалась, продюсер может повторить попытку отправки (ретрай).

Также можно включить идемпотентный режим продюсера, что предотвращает повторную отправку одного и того же сообщения в

случае сбоя, обеспечивая отправку уникального сообщения один раз

* **Error handling**: Продюсер обрабатывает ошибки при отправке сообщений. В зависимости от настроек продюсер может

попытаться переотправить сообщение или сообщить о проблеме через callback

* **Описание**: Указывает адреса брокеров Kafka, к которым продюсер должен подключаться для отправки сообщений

* **Пример**: `bootstrap.servers: localhost:9092,localhost:9093`

* **Зачем это нужно**: Kafka продюсер использует эти брокеры для получения метаданных о кластере (например, информация о топиках и партициях). Эти брокеры служат точками входа в кластер Kafka.

Продюсер должен преобразовывать (сериализовать) данные в байтовый формат перед отправкой в Kafka

* **Ключевая настройка для сериализации ключа:**

* `key.serializer`

* Пример: `key.serializer: org.apache.kafka.common.serialization.StringSerializer`

* **Ключевая настройка для сериализации значения:**

* `value.serializer`

* Пример: `value.serializer: org.apache.kafka.common.serialization.StringSerializer`

**Варианты сериализаторов:**

* `StringSerializer` для строк

* `ByteArraySerializer` для массива байтов

* `LongSerializer` для чисел

* Также можно реализовать свои собственные сериализаторы

Продюсер Kafka отправляет сообщения асинхронно, и для этого используется буферизация сообщений

* **batch.size**: Размер одного пакета (batch), который продюсер отправляет брокеру

* **Описание**: Определяет количество байтов сообщений, которые могут быть буферизованы в одном пакете перед отправкой брокеру

* **Пример**: `"batch.size": 16384` (16 KB)

* **Зачем это нужно**: Большие пакеты могут повысить производительность, но могут увеличить задержки

* **linger.ms**: Максимальное время ожидания перед отправкой пакета

* **Описание**: Продюсер может немного подождать, пока буфер накопит сообщения, чтобы отправить больше данных за один раз

* **Пример**: `linger.ms: 5` (время ожидания 5 мс)

* **Зачем это нужно**: Позволяет продюсеру собирать больше сообщений в пакете перед отправкой, что может улучшить эффективность использования сети

* **buffer.memory**: Размер выделенной памяти для буферизации сообщений

* **Описание**: Общий объем памяти, который продюсер может использовать для хранения сообщений, ожидающих отправки

* **Пример**: `buffer.memory: 33554432` (32 MB)

* **Зачем это нужно**: Если буфер заполняется, продюсер приостанавливает отправку сообщений, пока буфер не освободится

Продюсер может сжимать сообщения для уменьшения объема передаваемых данных

* **compression.type**

* **Описание**: Указывает тип сжатия для сообщений

* **Пример**: `compression.type: gzip` (варианты: none, gzip, snappy, lz4, zstd)

* **Зачем это нужно**: Сжатие уменьшает объем данных, передаваемых по сети, что может снизить нагрузку на сеть и хранилище,

особенно при больших объемах сообщений. Однако это может потребовать дополнительных ресурсов на сжатие/разжатие

Настройка определяет, как много брокеров должны подтвердить получение сообщения перед тем, как продюсер будет считать его

успешно отправленным

* **Описание**: Определяет количество подтверждений от брокеров

* **Значения**:

* `0`: Продюсер не ждёт подтверждений (самая быстрая отправка, но высокий риск потери сообщений)

* `1`: Продюсер ждёт подтверждения от лидера партиции

* `all` (или `-1`): Продюсер ждёт подтверждений от всех реплик (наибольшая надежность, но увеличенные задержки)

* **Пример**: `acks: all`

* **Зачем это нужно**: Позволяет выбрать баланс между скоростью и надежностью отправки данных.

* **Количество повторных попыток (retries):**

* **Описание**: Определяет, сколько раз продюсер должен попытаться отправить сообщение при неудаче

* **Пример**: `retries: 3`

* **Зачем это нужно**: Если произошёл временный сбой, продюсер может попытаться повторить отправку сообщений, что

увеличивает шанс доставки

* **Идемпотентность продюсера (enable.idempotence):**

* **Описание**: Включение идемпотентного режима, что предотвращает дублирование сообщений при сбоях

* **Пример**: `enable.idempotence: true`

* **Зачем это нужно**: Гарантирует, что каждое сообщение будет доставлено ровно один раз

* **Максимальный размер сообщения (max.request.size):**

* **Описание**: Максимальный размер сообщения, которое продюсер может отправить брокеру

* **Пример**: `max.request.size: 1048576` (1 MB)

* **Зачем это нужно**: Ограничивает размер сообщений, которые могут быть отправлены, чтобы избежать перегрузки сети и брокеров.

* **Таймаут ожидания подтверждений (request.timeout.ms):**

* **Описание**: Максимальное время ожидания подтверждения от брокера

* **Пример**: `request.timeout.ms: 30000` (30 секунд)

* **Зачем это нужно**: Помогает избежать бесконечного ожидания ответа от брокера в случае его сбоя