Как ведет себя Потребитель Кафки, если Продюсер выходит из строя. Что происходит с данными в интервале, когда производитель выходит из строя - PullRequest
0 голосов
/ 21 мая 2019

Я просто хочу знать, как Потребитель может использовать данные, когда производитель не работает. Допустим, производитель продолжает отправлять журналы потребителю с постоянной скоростью, а затем производитель снижается с 8:00 до 18:00. Как потребитель работает в таком случае, и есть ли способ, чтобы потребитель мог получить данные, которые были бы отправлены в 8:00 - 18:00, если бы производитель был на месте.

Ответы [ 2 ]

1 голос
/ 21 мая 2019

В Apache Kafka нет никакой связи между поведением производителя и потребителя.Выступая в качестве системы обмена сообщениями, Kafka позволяет отделить производителя от потребителя, предоставляя асинхронный канал связи.Производитель может отправлять сообщения в своем собственном темпе, а потребитель может читать эти сообщения в режиме реального времени или позже в своем собственном темпе (отличном от темпа производителя).Сообщения сохраняются в теме, расположенной в кластере Kafka, и каждое сообщение имеет позицию в разделе темы (смещение).Конечно, можно настроить удаление сообщений из темы, если пользователь не находится в сети в течение длительного времени, читая сообщения.Вы можете хранить сообщения в течение очень долгого времени (дни, недели, месяцы), после чего они будут удалены;или вы можете настроить хранение сообщений в зависимости от времени (удаляя сообщения старше определенного времени).Кроме того, потребитель также может перематывать поток сообщений в теме, фактически перечитывая сообщения при необходимости.Наконец, потребитель может также искать конкретную позицию в тематическом разделе на основе смещения или указания времени.

0 голосов
/ 21 мая 2019

У документа Кафки есть хорошая схема, которую я скопировал ниже.Это показывает новизну Кафки в сжатой форме.enter image description here

Без Кафки ситуация примерно такая.У нас есть несколько серверов, например, серверы Frontend, серверы БД, серверы чата и т. Д. С другой стороны, у нас, вероятно, есть разные метрики и инструменты мониторинга (например, монитор БД, монитор пользовательского интерфейса и т. Д.).Прямая связь один-к-одному между различными серверами и сборщиками может сработать для небольших систем, но она выходит из строя довольно быстро после того, как система превысила определенный порог с точки зрения масштабируемости.Кафка решает эту проблему, отделяя отправителей и получателей.Они оба общаются через брокеров Kafka вместо того, чтобы разговаривать друг с другом.

Итак, в вашем случае потребитель просто спросит брокера, есть ли какие-либо новые данные по теме, на которую он подписывается.Поскольку производитель не работает и, предположив, что в очереди нет данных, брокер ответит: ничего не нужно использовать. .Таким образом, потребитель будет постоянно опрашивать через фиксированный интервал, в бесконечном цикле и ничего не делать.Всякий раз, когда производитель подходит и начинает выкачивать данные, потребитель начинает получать (и обрабатывать) их.Существуют более сложные случаи использования, когда вы можете потерять данные, если срок хранения по определенной теме истек, а потребитель не обработал отставание.Но я не думаю, что это беспокоит вас в этот момент вашего путешествия.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...