Тюнинг: параметры брокеров (num.partitions, min.insync.replicas, log.retention.hours), GC tuning для Java 21

Тюнинг оптимизирует под нагрузку.

- Параметры брокеров:
- num.partitions: Количество разделов по умолчанию для новых топиков (default 1). Больше — выше parallelism, но overhead на метаданные (каждый раздел — ~1 МБ RAM на брокере).
- min.insync.replicas: Минимальное количество синхронизированных реплик для acks=all (default 1). Установите 2 для durability, но снижает availability при сбоях.
- log.retention.hours: Время хранения логов (default 168 часов). Баланс: дольше — больше диск, короче — риск потери для replay.

- GC tuning для Java 21: Kafka работает на JVM, GC (сборка мусора) влияет на latency. Используйте Shenandoah или ZGC для low-pause (sub-ms).
Параметры: -XX:+UseZGC -XX:ZCollectionInterval=10 (интервал 10 сек), -XX:MaxGCPauseMillis=5.
В памяти: ZGC использует colored pointers для concurrent marking, снижая паузы. Нюанс: для heap >64GB добавьте -XX:+ZGenerational для generational mode. Тестируйте с GC logs (-Xlog:gc*).

Компромиссы: агрессивный тюнинг снижает latency, но требует benchmark (k6 или Kafka's perf tools).


Восстановление после катастроф: MirrorMaker 2, репликация между регионами

Disaster recovery обеспечивает continuity.

- MirrorMaker 2 (MM2): Инструмент для зеркалирования тем между кластерами (active-passive или active-active). Работает как consumer-producer: читает из source, пишет в target. Поддерживает offset translation, topic renaming. В памяти: MM2 использует Connect framework, с tasks для parallelism.

- Репликация между регионами: Настройте MM2 с remote clusters, используя topics like mm2-offset-syncs для синхронизации offset'ов. Для cross-DC: настройте replication.factor>1, с geo-aware rack.aware.mode. Нюанс: latency добавляет 100-500 мс, мониторьте replication lag.

Стратегия: регулярные drills, с failover скриптами (изменение bootstrap.servers в клиентах).


Пример конфигурации безопасности (ZooKeeper и KRaft)

Вот пример конфигурации брокера для SASL_SSL с SCRAM (работает как с ZooKeeper, так и KRaft):

# Прослушиватели
listeners=SASL_SSL://:9092
advertised.listeners=SASL_SSL://broker-host:9092

# SSL настройки
ssl.keystore.location=/etc/kafka/secrets/kafka.keystore.jks
ssl.keystore.password=keystore-pass
ssl.truststore.location=/etc/kafka/secrets/kafka.truststore.jks
ssl.truststore.password=truststore-pass
ssl.client.auth=required  # Требовать клиентские сертификаты

# SASL
sasl.enabled.mechanisms=SCRAM-SHA-512
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512

# Для KRaft добавьте:
process.roles=broker,controller
controller.listener.names=CONTROLLER
listener.security.protocol.map=CONTROLLER:PLAINTEXT,SASL_SSL:SASL_SSL

# ACL
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
super.users=User:admin
allow.everyone.if.no.acl.found=false

В production: генерируйте сертификаты с CA (Let's Encrypt или self-signed), храните секреты в Vault.


#Java #middle #Kafka #Kafka_securiy

Нюансы

- Планирование ёмкости по количеству разделов: Разделы — единица parallelism, но лимит ~4K на брокер (из-за открытых файлов, RAM ~10 КБ на раздел). Планируйте: throughput / partition-throughput (например, 10 МБ/с на раздел). Для 100K TPS — 100 разделов. Нюанс: слишком много (>1M в кластере) замедляет контроллер (leader election до минут); используйте формулу: num_partitions = (desired_throughput / partition_throughput) * replication_factor.

- Оповещения по недореплицированным разделам: Метрика kafka.server:ReplicaManager:UnderReplicatedPartitions >0 сигнализирует о проблемах (сбой фолловера). Alerting в Prometheus: alert если >0 >5 мин, с playbook (проверить network, restart брокер). Нюанс: chronic under-replication приводит к data loss при unclean election.

- Типичные антипаттерны:
- Слишком много разделов: Приводит к overhead (метаданные, ZK load в старых версиях). Решение: consolidate темы, используйте compaction.
- Unclean election (unclean.leader.election.enable=true): Позволяет non-ISR лидеру, рискуя потерей данных. Держите false, жертвуйте availability.
- Отключенный мониторинг: Без alerting на lag или CPU>80% сбои незаметны. Всегда интегрируйте с ELK/Prometheus, с on-call ротацией.


#Java #middle #Kafka #Kafka_securiy