Вышла новая версия Apache Kafka

Apache Kafka — это распределенная система передачи сообщений, рассчитанная на высокую пропускную способность.

Я правильно понимаю, что это, грубо говоря, п2п аська?

Apache Kafka — это распределенная система передачи сообщений, рассчитанная на высокую пропускную способность.

Надеюсь, он не передает сообщения также, как Варнава.(намек на название)

Это очередная вариация на тему MQ?

Чем это лучше/хуже Apache Active MQ?

Возможно ошибаюсь, но насколько я понял это что то вроде WebSphereMQ. для передачи сообщении между приложениями.

Apache Kafka — это распределенная система передачи сообщений, рассчитанная на высокую пропускную способность.

Я правильно понимаю, что это, грубо говоря, п2п аська?

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

PS http://en.wikipedia.org/wiki/Message_queue

распределенная - один пакет собеседнику, другой в АНБ распределяется (как с тор)

Варнава-то вроде в романе усердно трудился, хоть и был несколько туповат. Не?

Атмосфера безысходности при разворачивании системы прилагается? :)

Posted at 11:34 PM on March 12, 2014

so slow...

Это distributed MQ. А Active MQ- это брокер.

Нет. Это вообще не про чатики, это про интеграцию приложений.

Понятно, спасибо.

Варнава-то вроде в романе усердно трудился, хоть и был несколько туповат. Не?

\begin{offtopic}
Нууу... он (Варнава) утверждал, что он упорно трудился, а как оно было на самом деле - не указано.
В любом случае результата от его работы было чуть больше, чем ничего.
\end{offtopic}

Надо будет глянуть на досуге, что это за Kafka такая.

А как оно в сравнении с RabbitMQ?

Я её использую с момента отделения бранча 0.8.1 в гите. Оф анонс пропустил :)

Kafka реализует персистентную очередь сообщений. Читатель может прийти за своей порцией данных через неделю и при этом всё прочитает.

Kafka

Grefnevaya?

Это очередь сообщений. Куча писателей отправляют сообщения в кластер, куча читателей читают. При этом ноды кластера могут выпадать и при этом данные не потеряются. Читатели тоже могут выпадать и дочитать свой кусок данных потом.

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

1) Эта штука устроена совсем не как WebSphere MS, ActiveMQ, RabbitMQ

2) Kafka - sharded queue. Тоесть очереди разделены по партициям, которые не знают о друг друге и распределены по независимым узлам

3) Они координируются через сервер Apache Zookeeper, который Highly Available. Таким образом если не считать Zookeeper - point of failure, но Kafka не содержит Single Point Of Failure.

4) Когда вы пишете сообщение, то Kafka просто сохраняет его в файл с помощью append

5) Когда вы читаете из Kafka, то вы указываете откуда и по какое сообщение читать из файла, тоесть используете pull model вместо push, как принято в остальных очередях. Это может быть знакомо некоторым из Amazon SQS

6) Понятие «получить сообщение» неизвестно Kafka. Вы можете прочитать любое сообщение в истории сколько угодно раз, пока его не удалили согласно устареванию на основе вами указаной конфигурации. Например можно держать все сообщения. Можно только последнюю неделю. Таким образом клиент решает, получил ли он сообщение

7) Для удобства пользователей в качестве надстройки доступен High Level Consumer, который используя Zookeeper вводит понятие «получить сообщение» и позволяет отличать семантику topic/queue. Для того чтобы различать эту сематику множественные conumerам тоже нужна координация.

С 0.8 вся координация между узлами осуществляется через контроллер (самостоятельная сущность внутри кафки, работает на одном из узлов). Зоокипер нужен для публикации метаданных и для стартапа узлов.

Что это дает если Zookeeper все равно есть?

Нагрузка на него нулевая.

А для, High Level Consumer? Но если координатор на _одном_ узле, это не одно и то же? Тем более как этот узел реплицирует свои метаданные о полученых сообщениях в consumer groups?

Правильно понимаю, что к JMS оно никакого отношения не имеет?

А для, High Level Consumer?

High Level Consumer — нерабочий кусок говна. В кафке в качестве consumer'а в продакшене можно использовать одну из двух сущностей — SimpleConsumer, AbstractFetcherThread. Причем вторая сущность построена на первой :)

Тем более как этот узел реплицирует свои метаданные о полученых сообщениях в consumer groups?

Зачем ему это делать? Consumer это клиентская часть. Каждый клиент сам решает где хранить свои метаданные.

Благодарю за развёрнутый ответ. Так сказать, расширил свой кругозор.

Атмосфера безысходности при разворачивании системы прилагается? :)

К MQ Series«Web Sphere MQ»(ТМ) раньше прилагалась, еще как. Шестизначне пароли, ограничение на длину имени юзера, никакого автокомплита в шелле... И документация «чтобы А см. B, С, D»... «чтобы B, см... X, Y, Z...» (далее - везде)

вся координация между узлами осуществляется через контроллер

Чем от брокира отл.?

Тем, что занимается другими задачами. Но работает это всё в рамках одного процесса. Узлы кафки договариваются кто будет контроллером. При падении контроллера происходят перевыборы.

Кстати, в этой версии в клиентской части появилось то, чего я «джва года ждал», а именно неблокирующий продюсер на колбеках. Но есть одна засада — под нагрузкой у него ломается внутреннее состояние и он встает колом :(

Для поклонников Ф.Кафки, Ein Apachekünstler.

А как оно в сравнении с RabbitMQ?

РаббитМQ - кластерный брокер, лишняя точка отказа в кластере. Жрёт оперативку пропорционально длине очереди, т.е. если что-то где-то нарушилось, и какая-то очередь начала быстро расти, то жди беды, которая парализует весь кластер.

чо?

это потому что рабитмк процессит каждое сообщение.

распределенная - один пакет собеседнику, другой в АНБ

и не только в АНБ, но в местечковые организации: ФСБ, КГБ и т.д.

Почитал, репу почесал - пригодится ли в моем проекте? Оно только для жабы?

У нас используется и в жабе и в плюсах и в перле ... правда имеется свой слой http-абстракции над кафочным протоколом.

Усердство не мешало ему плохо выполнять свою работу.

Узлы кафки договариваются кто будет контроллером

«Посоны, я создал!» (с)

High Level Consumer — нерабочий кусок говна

Двачую вас сер обеими конечностями. Пилю свой. Тоже на базе зукипера, с небольшим частным нюансом

За основу взял что-то уже имеющееся или начал с нуля пилить на основе протокола?

Это очередной «убийца RabbitMQ»?

Сферы применения немного разные.

На основе simple consumer + zookeeper играюсь. В отличии от High Level нету понятия сообщения получено или нет, но есть распределение работы чтобы два consumer не получили одно и то же сообщение. Zookeeper таким образом тоже простаивает, а понятие получения может перекладываться на наличие данных по сообщению в какой-то шарданутой базе например

Усердно, но абсолютно бесполезно. Что бы оправдать название, Apache Kafka следует делать так же, а настройки сделать в общем стиле Кафки. По форме верно, а по сути - сюр.

Следующая версия - Apache Orwell