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

Ответ 1

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

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

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

Является ли мой кластер RabbitMQ активным активным или активным пассивом?

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

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

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

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

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

Ответ 2

Redis создается как хранилище данных ключевых значений, несмотря на наличие основных функций брокера сообщений.

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

Ответ 3

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

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

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

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

• RabbitMQ может быть немного сложен в обслуживании, труден для отладки сбоев.
• Колебания имени узла или узла-IP могут привести к потере данных, но при правильном управлении проблемы могут быть решены с помощью надежных сообщений.

Ответ 4

Мне было интересно то же самое. Предыдущие рекомендации пользователей 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, скорее всего, будет излишним для моего случая использования журнала.

Ответ 5

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

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

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