Redis Vs RabbitMQ як брокер даних / система обміну повідомленнями між Logstash та elasticsearch

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

Оцінивши Redis та RabbitMQ, я вибрав RabbitMQ нашим брокером з наступних причин:

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

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

Мій кластер RabbitMQ активний активний чи активний пасивний?

Тепер до слабшого місця використання 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

Якщо у вас є більше запитань, залиште коментар.

Redis створений як сховище даних ключових значень, незважаючи на наявність основних можливостей брокера повідомлень.

RabbitMQ створений як посередник повідомлень. Він має безліч можливостей посередника повідомлень, природно.

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

Нижче наведено список плюсів щодо використання RabbitMQ над Redis:

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

Кілька мінусів для використання RabbitMQ:

• RabbitMQ може бути трохи важким в обслуговуванні, важким для налагодження збоїв.
• коливання імені вузла або вузла-ip можуть спричинити втрату даних, але якщо вони добре керовані, надійні повідомлення можуть вирішити проблему.

Мені цікаво те саме. Раніше рекомендації людей 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, ймовірно, надмірний для мого випадку використання журналів.

Швидкі запитання:

1. навіщо потрібен брокер? Якщо ви використовуєте logstash або logstash-forwarder для читання файлів із цих серверів, вони обоє уповільняться, якщо конвеєр перевантажиться.
2. чи є у вас досвід керування кроликом або редісом? За інших рівних умов інструмент, яким ви вмієте користуватися, є кращим.

Що стосується думок, я працював на redis як брокер і ненавидів це. Звичайно, це могло бути моїм недосвідченим досвідом роботи з redis (не проблема з самим продуктом), але це було найслабше ланка в конвеєрі, і завжди виходило з ладу, коли нам це було найбільше потрібно.