Redis против RabbitMQ в качестве брокера данных / системы обмена сообщениями между Logstash и elasticsearch

92

Мы определяем архитектуру для сбора информации журналов поставщиками Logstash, которые установлены на различных машинах, и централизованно индексируют данные на одном сервере elasticsearch и используют Kibana в качестве графического слоя. Нам нужна надежная система обмена сообщениями между грузоотправителями Logstash и elasticsearch, чтобы гарантировать доставку. Какие факторы следует учитывать при выборе Redis вместо RabbitMQ в качестве брокера данных / системы обмена сообщениями между поставщиками Logstash и elasticsearch или наоборот?

elasticsearch redis rabbitmq logstash Салиндо
источник

Ответы:

95

После оценки Redis и RabbitMQ я выбрал RabbitMQ в качестве нашего брокера по следующим причинам:

  1. RabbitMQ позволяет использовать встроенный уровень безопасности с помощью сертификатов SSL для шифрования данных, которые вы отправляете брокеру, а это означает, что никто не будет прослушивать ваши данные и иметь доступ к вашим жизненно важным данным организации.
  2. RabbitMQ - очень стабильный продукт, который может обрабатывать большое количество событий в секунду и множество соединений, не будучи узким местом.
  3. В нашей организации мы уже использовали RabbitMQ и имели хорошие внутренние знания о его использовании и уже подготовленную интеграцию с chef.

Что касается масштабирования, RabbitMQ имеет встроенную реализацию кластера, которую вы можете использовать в дополнение к балансировщику нагрузки для реализации среды резервного брокера.

Мой кластер RabbitMQ Active Active или Active Passive?

Теперь о более слабом моменте использования RabbitMQ:

  1. большинство поставщиков Logstash не поддерживают RabbitMQ, но, с другой стороны, лучший из них, названный Beaver, имеет реализацию, которая без проблем отправляет данные в RabbitMQ.
  2. Реализация Beaver с RabbitMQ в его текущей версии немного медленна по производительности (для моих целей) и не могла обрабатывать скорость 3000 событий в секунду с одного сервера и время от времени сбой службы.
  3. Прямо сейчас я работаю над исправлением, которое решит проблему с производительностью RabbitMQ и сделает грузоотправителя Beaver более стабильным. Первое решение - добавить больше процессов, которые могут выполняться одновременно, что даст грузоотправителю больше возможностей. Второе решение - изменить Beaver для асинхронной отправки данных в RabbitMQ, что теоретически должно быть намного быстрее. Надеюсь, что к концу недели я завершу реализацию обоих решений.

Вы можете следить за проблемой здесь: https://github.com/josegonzalez/python-beaver/issues/323

И проверьте запрос на перенос здесь: https://github.com/josegonzalez/python-beaver/pull/324

Если у вас есть еще вопросы, не стесняйтесь оставлять комментарии.

Том Крегенбильд
источник
3
Есть ли у Redis более сильные стороны по сравнению с RabbitMQ? Redis кажется более простым в настройке. И если вам не нужна огромная пропускная способность, а безопасность обеспечивается другими средствами, RabbitMQ может не понадобиться. Пожалуйста, поправьте меня, если я ошибаюсь.
Ricardo MS
Вы правы, но для уверенности вам нужно сравнить производительность двух продуктов
Tom Kregenbild
4
«RabbitMQ - очень стабильный продукт, который может обрабатывать большое количество событий в секунду и множество подключений, не будучи узким местом». - Я почти уверен, что это правда и Reddis. Так что это НЕ преимущество rabbitmq над Reddit
Мартин Тома
«RabbitMQ позволяет использовать встроенный уровень безопасности с помощью SSL» - разве Reddis не поддерживает шифрование транспортного уровня?
Мартин Тома
2
2019 по-прежнему не имеет встроенного TLS в
Redis
55

Redis создан как хранилище данных «ключ-значение», несмотря на наличие некоторых базовых возможностей брокера сообщений.

RabbitMQ создан как брокер сообщений. Естественно, он имеет множество возможностей брокера сообщений.

Ферхат
источник
1
Ваше утверждение о Redis не более точно с введением Stream в Redis 5. RabbitMQ определенно является лучшим выбором для крупномасштабных сценариев. Redis - надежная, быстрая и простая в настройке альтернатива для сценария малого и среднего масштаба (каковым является большинство проектов в мире).
Reza
Спасибо за приверженность, было бы хорошо, если бы кто-нибудь напишет здесь свой опыт о новых возможностях Redis.
Ferhat
44

Я провел некоторое исследование по этой теме. Если производительность важна, а настойчивость - нет, RabbitMQ - идеальный выбор. Redis - это технология, разработанная с другой целью.

Ниже приводится список преимуществ использования RabbitMQ поверх Redis:

  • RabbitMQ использует протокол расширенной очереди сообщений (AMQP), который можно настроить для использования SSL, дополнительного уровня безопасности.
  • RabbitMQ занимает примерно 75% времени, затрачиваемого Redis на прием сообщений.
  • RabbitMQ поддерживает приоритеты для сообщений, которые могут использоваться рабочими для использования первоочередных сообщений с высоким приоритетом.
  • Нет никакого шанса потерять сообщение, если какой-либо воркер выйдет из строя после использования сообщения, чего нет в Redis.
  • RabbitMQ имеет хорошую систему маршрутизации для направления сообщений в разные очереди.

Несколько минусов использования RabbitMQ:

  • RabbitMQ может быть немного сложно поддерживать, сложно отлаживать сбои.
  • Колебания имени узла или IP-адреса узла могут вызвать потерю данных, но при правильном управлении долговременные сообщения могут решить проблему.
Арун Редди
источник
4
В Redis есть функции, Sorted Setsкоторые разрешают приоритетные взаимодействия, подобные очереди. Redis также можно кластеризовать / сегментировать, чтобы отправлять разные сообщения даже в разные очереди на разных серверах. Не уверен в использовании SSL непосредственно для Redis, но я смотрю на AWS Elasticache, и их Redis 3.2.6 позволяет шифрование в состоянии покоя и при передаче. Примечание: я вовсе не говорю, что Redis лучше для этого случая; просто отметив, что это не может быть причиной выбора RabbitMQ вместо Redis.
dwanderson
1
Также не забывайте, что Redis является однопоточным, поэтому, если у вас много издателей / потребителей, это может быть проблемой.
Kedare
5

Мне было интересно то же самое. Более ранние рекомендации разработчиков Logstash рекомендуют Redis вместо RabbitMQ ( http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized ), однако этот раздел примечаний больше не существует в текущей документации, хотя есть общие примечания по использованию брокера для борьбы с пиками здесь https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html .

Хотя я также довольно успешно использую RabbitMQ, в настоящее время я изучаю брокера Redis, поскольку протокол AMQP, вероятно, излишен для моего варианта использования журналирования.

opennomad
источник
2

Быстрые вопросы:

  1. зачем вам брокер? Если вы используете logstash или logstash-forwarder для чтения файлов с этих серверов, они оба будут замедляться, если конвейер будет перегружен.
  2. у вас есть опыт применения rabbit или redis? При прочих равных, инструмент, которым вы умеете пользоваться, - лучший инструмент.

Что касается мнений, я запустил Redis в качестве брокера и возненавидел его. Конечно, это могло быть связано с моим отсутствием опыта работы с Redis (не проблема с самим продуктом), но это было самое слабое звено в конвейере, и оно всегда давало сбой, когда мы больше всего в этом нуждались.

Ален Коллинз
источник