Разница между Redis и Kafka [закрыто]

87

Redis можно использовать как паб-подписку в реальном времени, как и Kafka.

Я не понимаю, какой из них использовать и когда.

Любой вариант использования будет большим подспорьем.

redis apache-kafka publish-subscribe Света Шарма
источник
15
Я не уверен, почему этот вопрос был закрыт как «основанный на мнении»? Между ними есть объективные технические различия, и существующий ответ четко описывает эти различия.
Дэвид Андерсон

Ответы:

137

Redis pub-sub в основном похож на систему «запустил и забыл», где все созданные вами сообщения будут доставлены всем потребителям одновременно, а данные нигде не хранятся. У вас есть ограничение по памяти по отношению к Redis. Также количество производителей и потребителей может повлиять на производительность Redis.

Kafka, с другой стороны, представляет собой распределенный журнал с высокой пропускной способностью, который можно использовать в качестве очереди. Здесь любое количество пользователей может производить, а потребители могут потреблять в любое время, когда захотят. Он также обеспечивает постоянство сообщений, отправленных через очередь.

Заключительный дубль:

Используйте Redis:

  1. Если вы хотите, чтобы система «зажгла и забыла», все сообщения, которые вы создаете, мгновенно доставляются потребителям.
  2. Если скорость больше всего беспокоит.
  3. Если вы можете смириться с потерей данных.
  4. Если вы не хотите, чтобы ваша система удерживала отправленное сообщение.
  5. Объем данных, с которыми предстоит иметь дело, невелик.

Используйте кафку:

  1. Если хотите надежности.
  2. Если вы хотите, чтобы в вашей системе была копия сообщений, которые были отправлены даже после использования.
  3. Если вы не можете смириться с потерей данных.
  4. Если скорость не имеет большого значения.
  5. размер данных огромен
Картикеян Гопалл
источник
69
Одно из основных отличий заключается в том, что Redis Pub / Sub основан на push, а Kafka Pub / Sub - на pull. Это означает, что сообщения, опубликованные в Redis, будут автоматически доставляться подписчикам мгновенно, в то время как в Kafka данные / сообщения никогда не отправляются потребителям, потребитель будет запрашивать сообщения, когда потребитель будет готов обработать сообщение. cloudkarafka.com/blog/… kafka.apache.org/documentation.html#design_pull
Зени
Читая это: redis.io/topics/persistence, мне кажется возможным удерживать отправленные сообщения. Я ошибся?
Дэвид Д.
1
@DavidD: предоставленная вами ссылка объясняет, как вы можете настроить, redisчтобы сообщения, которые были отправлены, но еще не обработаны , не были потеряны после перезапуска redis. Хотя это возможно, redisне позволяет хранить (или продолжать повторно использовать слова @Karthikeyan) из коробки.
Younes
11

Версия Redis 5.0+ предоставляет структуру данных Stream . Это можно рассматривать как структуру данных журнала с гарантиями доставки. Он предлагает набор операций блокировки, позволяющих потребителям ждать новых данных, добавленных в поток производителями, и в дополнение к этому концепцию, называемую группами потребителей.

В основном структура Stream обеспечивает те же возможности, что и Kafka.

Вот документация https://redis.io/topics/streams-intro

Эту функцию поддерживают два самых популярных клиента Java: Redisson и Jedis.

Никита Кокшаров
источник
1
Сам Никита :) Шикарная библиотека! Только начал им пользоваться. Хорошо структурировано и продумано! Вы гений сэр!
ммм
@mmm Спасибо!
Никита Кокшаров
У меня есть вопросы относительно правильного использования и нет, и я боюсь сделать неправильные предположения? Возможно, вы могли бы рассмотреть два вопроса, которые я добавил сюда по SO. Также хотел бы добавить вас в Skype, чтобы иногда беспокоить вас, если это нормально. Я могу дать некоторое представление о том, как я хочу его использовать. Не полный нуб :)
ммм
Например, в настоящее время я создаю кэшируемую карту ... используя идентификатор времени выполнения в качестве ключа, а затем добавляю список вещей, которые система в настоящее время обрабатывает из двухсторонней очереди ... списка, я могу создать ArrayList для я думаю , я считаю, что redisson преобразует его для меня внутренне, но если я этого не сделаю и создам список повторного запуска, то я должен дать ему имя, правильно? Как бы вы тогда назвали этот список внутри компании? Случайный идентификатор? Должен ли ваш API также не предоставлять параметр без createList, createMap и т. Д., Поскольку для него есть вариант использования?
ммм
Конечно, я могу отправить randomUuid, но было бы неплохо узнать, что у Redisson есть хороший генератор имен. Я также пишу свой собственный Deque для обработки пакетных заданий, содержащий повторный вызов deque, подкрепленный картой, содержащей «взятые» элементы. Если у нас есть 10 систем с каждыми 8 потоками, обрабатывающими очередь, и произойдет ядерная бомба, все они будут потеряны и останутся необработанными, поскольку они были взяты, но не полностью обработаны.
ммм