Исправление
vertexua,
(текущая версия)
:
Всем спасибо за занимательные версии, но теперь по порядку
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ам тоже нужна координация.
Исправление
vertexua,
:
Всем спасибо за занимательные версии, но теперь по порядку
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, как принято в остальных очередях
6) Понятие «получить сообщение» неизвестно Kafka. Вы можете прочитать любое сообщение в истории сколько угодно раз, пока его не удалили согласно устареванию на основе вами указаной конфигурации. Например можно держать все сообщения. Можно только последнюю неделю. Таким образом клиент решает, получил ли он сообщение
7) Для удобства пользователей в качестве надстройки доступен High Level Consumer, который используя Zookeeper вводит понятие «получить сообщение» и позволяет отличать семантику topic/queue. Для того чтобы различать эту сематику множественные conumerам тоже нужна координация.
Исходная версия
vertexua,
:
Всем спасибо за занимательные версии, но теперь по порядку
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) Когда вы читаете файл, то вы указываете откуда и по куда читать из этого файла, тоесть используете pull model вместо push, как принято в остальных очередях
6) Понятие «получить сообщение» неизвестно Kafka. Вы можете прочитать любое сообщение в истории сколько угодно раз, пока его не удалили согласно устареванию на основе вами указаной конфигурации. Например можно держать все сообщения. Можно только последнюю неделю. Таким образом клиент решает, получил ли он сообщение
7) Для удобства пользователей в качестве надстройки доступен High Level Consumer, который используя Zookeeper вводит понятие «получить сообщение» и позволяет отличать семантику topic/queue. Для того чтобы различать эту сематику множественные conumerам тоже нужна координация.