Что такое Apache Kafka
Официальное определение для Apache Kafka — распределённая стриминговая платформа. Это одно из тех прекрасных определений, которые не имеют никакого смысла до тех пор, пока не посидишь хорошенько с документацией. На самом деле идея Кафки очень простая. В большой распределенной системе обычно много сервисов, которые генерируют разные события: логи, данные мониторинга, замеченные попытки доступа к секретным ресурсам, и т. п. С другой стороны, есть сервисы, которым эти данные очень нужны. И тут появляется Kafka: он сидит между продюсерами и консьюмерами данных (producer & consumer): собирает данные у первых, хранит у себя в распределенном хранилище по топикам и раздаёт вторым по подписке. Другими словами, Kafka — это гибрид распределенной базы данных и очереди сообщений.
В такой подаче многое становится понятным, но не всё. Например, переносить сообщения из одного места в другое через паттерн «издатель-подписчик» может любая очередь сообщений, зачем еще и Kafka? Они хоть чем-нибудь отличаются?
Отличаются.
Чем Kafka отличается от очередей сообщений
- Kafka умеет передавать данные только одним способом — через паттерн издатель-подписчик. Любая очередь сообщений, тот же RabbitMQ, умеет больше.
- В отличие от очередей, которые удаляют сообщения сразу же после успешной доставки, Kafka хранит их столько, сколько скажут. По-умолчанию — неделю. Это удобно, потому что подписываясь на топик в Kafka можно получить и те сообщения, которые публиковались позавчера.
- Цифры попадаются разные, но Kafka рвёт по производительности популярные очереди сообщений вроде ActiveMQ и RabbitMQ. Некоторые даже приводят цифры пропускной способности: 100K сообщений в секунду у Кафки против «всего» 20K у RabbitMQ. И, если документация не врёт, Кафке не сильно любопытно, пропускают через него килобайты или терабайты данных.
- Кластеризация. Тут всё очень просто: даже один Kafka-брокер — это кластер. Для того, чтобы добавить ему второй, никаких особых настроек делать не надо. В тех очередях, которые поддерживают кластеризацию, особые настройки обычно нужны.
- Kafka всегда сохраняет сообщения на диск. Очереди сообщений, которые это умеют, обычно требуют сохранение явно включать (те же MSMQ, RabbitMQ).
- Доступность. Топики с сообщениями можно разбить на разделы (partition) и распределить внутри кластера, а затем еще включить и репликацию. На выходе вырастет пропускная способность, ведь один топик теперь хранится и обслуживается несколькими брокерами, и даже если один из брокеров умрёт, где-то останется реплика его данных, и всё обойдётся без потерь. Хотя некоторые очереди сообщений тоже умеют делать репликацию, я не могу вспомнить ни одной, которая умеет дробить свои очереди на части и распределять по кластеру.
Для чего его можно использовать
В некоторых сценариях Кафку можно использовать вместо очереди сообщений. Отправлять сообщения он умеет, сохранение на диск делает автоматически, очень производителен, так что почему бы и нет.
LinkedIn, который и изобрёл Кафку, использовал его для сбора и агрегации пользовательской активности на сайте: где кликнул, что искал, какие страницы открывал. Эти данные собирались по топикам в одном месте — в Кафке — а уже оттуда их забирали другие сервисы: аналитики, обработки, постоянного хранения, и т.п.
Часто Kafka используется для агрегации логов. Вместо того, чтобы иметь дело с физическими файлами, раскиданными по разным машинам, эти самые машины выступают как продюсеры логов, публикуя их в Кафку. После такой нехитрой манипуляции от файлов мы переходим к потоку данных-событий, который можно перенаправлять, анализировать и хранить.
Кроме логов можно собирать и события мониторинга (кто и где сколько памяти жрёт, сколько в системе активных потоков), служебные события (перезагрузка или апгрэйд машины), или даже ошибки.
Наконец, кроме перемещения данных из точки А в точку Б Кафка может их и обработать. Для этого у него есть Streams API, с которым можно создать обработчики потоков: подписываемся на одну тему, фильтруем и обрабатываем данные, публикуем результат в другой теме. Например, подписавшись на поток логов, можно отслеживать потенциальные ошибки и потом публиковать их в новый топик — «ошибки».
Заключение
Apache Kafka очень производительный инструмент, который нужен для перенаправления потоков данных из одного места в другое, с обработкой и без. Проект достаточно зрелый, и среди тех, кто его активно использует, полно гигантов нашей индустрии: LinkedIn, Netflix, Yahoo, Twitter, Pinterest, много их. Но, конечно, просто читать какую прекрасную штуку LiinkedIn изобрёл — скучно, так что в следующий раз мы раздобудем кафкианский инсталлер (pun intended) и пообрабатываем какой-нибудь поток данных.
Спасибо, Просто и понятно 🙂
Кратко и содержательно.
Большое спасибо!
Коротко и ясно, но
1. Давно существует промышленное решение Sonic ESB. В составе котороко есть MQ со всеми плюшками новоиспеченной Kafka и даже больше
2. Производительность надо сравнивать на одном железе, т.к. Очень много факторов влиянт. Например, мерили производительность
кластера Sonic MQ. У него у каждого брокера локальная БД (по умолчанию) соотвественно разложив файлы db и recovery логи грамотно на SSD диски можно получить очерь приличные показатели (я думаю Kafkу) переплюнет
3. Если кому необходим надежный, производительный, с достойной поддежкой messeging посмотрите в сторону Aurea CX Messenger (Sonic ESB)
Наконец то нашел что то доступное для понимание по Кафке) Спасибо за шеринг своего опыта)
(а где у вас тут реклама на сайте — хочу перейти по ней 🙂
Нету пока рекламы 🙂
Шикарно, теперь все понятно:) Спасибо)
Спасибо!