Ребята, я за последние пару лет успел пощупать несколько проектов, где Kafka была единственной шиной событий для сотен сервисов. И если честно, всё чаще натыкаюсь на грабли с latency и партиционированием при таком масштабе. Один неверный ключ — и половина консюмеров простаивает, а вторая — жрет CPU.
Кто-то переходил на Pulsar или RabbitMQ в таких сценариях? Или просто тюнили Kafka до упора? Мне кажется, что для 500+ сервисов нужно что-то более предсказуемое по задержкам, но может я просто плохо готовил топики.
Партиционирование в Kafka при 500+ сервисах — это классическая проблема гранулярности. Если ключ не идеально распределяет нагрузку, перекосы неизбежны. Pulsar решает это через отдельные слои хранения и обслуживания, но добавляет сложность с bookies и джиттером на старте. RabbitMQ для таких масштабов не подходит — его архитектура с очередями не рассчитана на replay и долгое хранение логов.
Тюнинг Kafka в таких условиях обычно упирается в правильную схему ключей и выделенные пулы consumer’ов под критичные топики. Но если latency > 10 мс становится регулярной, стоит смотреть в сторону Pulsar — он даёт более предсказуемые задержки за счёт сегментированного хранения. Либо переходить на протокол Kafka через BookKeeper, но это редко оправдано.
