Проміжне програмне забезпечення повідомлень — це проміжне програмне забезпечення, що складається з механізму передачі повідомлень або режиму черги повідомлень, який використовує ефективний і надійний механізм обміну повідомленнями для незалежного від платформи та інтегрує розподілені системи на основі передачі даних. Наразі в індустрії існує багато продуктів MQ, таких як RabbitMQ, ActiveMQ, ZeroMQ тощо, які є чудовим посереднім програмним забезпеченням для повідомлень, але який із них варто обрати в проєкті? У цій статті оцінюється та порівнюється такі продукти черги повідомлень: RabbitMQ, ZeroMQ, ActiveMQ, MSMQ, Redis та memcacheQ
Відступ: Тут ми спершу можемо подумати над невеликим питанням: «Навіщо нам потрібні послуги черги повідомлень у веб-додатках?» ”
Наприклад, велика кількість запитів на вставку, оновлення та інших одночасно надходить у MySQL, що безпосередньо призводить до численних блокувань рядків і таблиць, а в кінцевому підсумку навіть надто багато запитів, що призводить до надмірної кількості помилок з'єднань. Використовуючи черги повідомлень, ми можемо обробляти запити асинхронно, знімаючи навантаження на систему.
RabbitMQ
Це відкрита черга повідомлень, написана на Erlang, яка підтримує багато протоколів: AMQP, XMPP, SMTP, STOMP, що робить її дуже важкою та більш придатною для розробки на корпоративному рівні. Це провідна реалізація протоколу AMQP, який реалізує архітектуру брокера, тобто повідомлення можна ставити в чергу на центральному вузлі перед відправкою клієнту. Є хороша підтримка маршрутизації, балансування навантаження або збереження даних. Ця функція робить RabbitMQ простим у використанні та розгортанні, підходить для багатьох сценаріїв, таких як маршрутизація, балансування навантаження або збереження повідомлень, і може бути реалізована лише кількома рядками коду з чергами повідомлень. Однак це робить його менш масштабованим і повільнішим, оскільки центральний вузол збільшує затримку і стає більшим після інкапсуляції повідомлення. Щоб налаштувати RabbitMQ, потрібно встановити середовище Erlang на цільовій машині.
Натисніть, щоб переглянути це зображення у новому вікні
? MQ(ZeroMQ)
Вона відома як найшвидша система черги повідомлень, особливо для сценаріїв із високопродуктивним попитом. Це дуже легка система обміну повідомленнями, розроблена спеціально для ситуацій з високою пропускною здатністю та низькою затримкою, яка часто використовується у фінансових застосунках. Порівняно з RabbitMQ, ZeroMQ підтримує багато складних сценаріїв повідомлень, але потрібно реалізувати окремі блоки у фреймворку ZeroMQ (наприклад, сокети, пристрої тощо).
? MQ (ZeroMQ) може реалізовувати складні/складні черги, у яких RabbitMQ не дуже сильний, але розробникам потрібно самостійно поєднувати кілька технічних фреймворків, і технічна складність є викликом для успішного застосування цього MQ. ZeroMQ має унікальну модель без проміжного програмного забезпечення, де не потрібно встановлювати та запускати сервер повідомлень або проміжне програмне забезпечення, бо ваш додаток виконує цю роль сервісу. Все, що потрібно — це звернутися до бібліотеки ZeroMQ, яку можна встановити за допомогою NuGet, і ви зможете спокійно надсилати повідомлення між додатками. Однак ZeroMQ надає лише непостійні черги, що означає, що якщо машина вийде з ладу, дані будуть втрачені. Серед них Twitter Storm використовує ZeroMQ для передачі потоків даних. ZeroMQ дуже гнучкий, але вам потрібно вивчити його 80-сторінковий посібник (якщо ви пишете про розподілену систему, обов'язково прочитайте його).
ZeroMQ не має проміжної архітектури і не потребує сервісних процесів та виконується. Насправді, вашу додаткову кінцеву точку виконує цю роль сервісу. Це дуже спрощує розгортання, але проблема в тому, що вам нема де стежити, якщо щось піде не так. Наскільки нам відомо, ZeroMQ пропонує лише непостійні черги. Ви можете реалізувати власні можливості аудиту та відновлення даних там, де вони потрібні.
Натисніть, щоб переглянути це зображення у новому вікні
MSMQ
Це єдина річ у продукті Microsoft, яка вважається цінною. Якщо MSMQ зможе довести, що може впоратися з такими завданнями, вони оберуть його використати. Суть у тому, що ця річ не складна, нічого, крім отримання і відправлення; Він має деякі жорсткі обмеження, наприклад, максимальний розмір повідомлення 4 МБ. Однак він може вирішити ці проблеми, підключившись до програмного забезпечення, такого як MassTransit або NServiceBus.
Натисніть, щоб переглянути це зображення у новому вікні
Яфка/Кафка
Kafka (яка розповсюджує повідомлення між різними вузлами) — це розподілена система MQ, розроблена та відкрита компанією LinkedIn у грудні 2010 року, яка зараз є інкубаційним проєктом Apache — високопродуктивної міжмовної розподіленої системи черги Publish/Subscribe повідомлень, а Jafka інкубується поверх Kafka, яка є оновленою версією Kafka. Він має такі характеристики: швидка збереження, що дозволяє зберігати повідомлення під системними накладними витратами O(1); Висока пропускна здатність, яка може досягати пропускної здатності 10 Вт/с на звичайному сервері; Повністю розподілена система, брокер, виробник і споживач усі нативно підтримують розподілений контент і автоматично досягають складної рівноваги. Підтримує паралельне завантаження даних Hadoop, що є життєздатним рішенням для лог-даних та офлайн-систем аналізу, таких як Hadoop, але з обмеженнями обробки в реальному часі. Kafka об'єднує обробку повідомлень онлайн і офлайн через паралельний механізм завантаження Hadoop, що також важливо для системи, що вивчається в цій темі. Apache Kafka — це дуже легка система обміну повідомленнями порівняно з ActiveMQ, і окрім дуже хорошої продуктивності, це також розподілена система, яка добре працює.
Натисніть, щоб переглянути це зображення у новому вікні
Apache ActiveMQ
ActiveMQ знаходиться десь посередині між ними (RabbitMQ і ZeroMQ), подібно до ZemoMQ, і може розгортатися як у проксі, так і в P2P режимах. Подібно до RabbitMQ, тут легко реалізовувати складні сценарії, і він потребує низького споживання.
ActiveMQ відомий як основа світу Java. Він має довгу історію і широко використовується. Він також кросплатформенний, забезпечуючи природну точку доступу до інтеграції для продуктів, які не є на платформі Microsoft. Однак його можна розглянути лише якщо він пройшов MSMQ. Щоб налаштувати ActiveMQ, потрібно встановити Java-середовище на цільовій машині.
Натисніть, щоб переглянути це зображення у новому вікні
Варто зазначити, що продукт наступного покоління ActiveMQ — це Apollo, який базується на прототипі ActiveMQ і є швидшим, надійнішим і простішим у підтримці інструментом брокера повідомлень. Apache називає Apollo найшвидшим і найнадійнішим сервером STOMP (Streaming Text Oriented Message Protocol).
Особливості Аполлона такі:
Підтримуються протоколи Stomp 1.0 та Stomp 1.1
Теми та черги
Браузер черги
Тематичні постійні підписки
Дзеркальна черга
Надійні повідомлення
Термін дії та обмін повідомленнями
Вибірка повідомлень
JAAS підтверджено
Авторизація на основі ACL
Підтримка SSL/TLS та перевірки сертифікатів
API управління REST
Натисніть, щоб переглянути це зображення у новому вікні
Редіс
Це база даних Key-Value NoSQL, яка активно розробляється та підтримується, хоча це система зберігання бази даних Key-Value, але вона підтримує функції MQ, тому її можна використовувати як легкий сервіс черги. Для операцій введення та виходу в чергу RabbitMQ і Redis — по 1 мільйону разів кожна, а час виконання фіксується кожні 100 000 разів. Тестові дані поділяються на чотири різні розміри: 128 байт, 512 байт, 1K і 10K. Експерименти показують, що при приєднанні до команди продуктивність Redis вища, ніж у RabbitMQ, коли порівняння даних невелике, а якщо обсяг даних перевищує 10K, Redis стає нестерпно повільним. Виходячи з команди, Redis демонстрував дуже хороші результати незалежно від обсягу даних, тоді як RabbitMQ був значно нижчим, ніж у Redis.
MemcacheQ
Постійна черга повідомлень Memcacheq (скорочено MCQ) — це легка черга повідомлень, MemcacheQ функціонує:
1 Проста та легка у використанні
2 Швидка обробка
3 Кілька черг
4 Хороша конкурентність
5 Сумісний із протоколом Memcache. Це означає, що потрібно просто встановити розширення memcache, додаткові плагіни не потрібні.
6 Також зручно використовувати його у фреймворку zend.
Зрештою, ці продукти:
1. Обидва мають власні клієнтські API або підтримують кілька мов програмування;
2. Є багато документації;
3. Було надано позитивну підтримку.
4. ActiveMQ, RabbitMQ, MSMQ, Redis мають запускати сервісні процеси, які можна контролювати та налаштовувати, а інші є проблемними
5. Всі вони забезпечують відносно хорошу надійність (послідовність), масштабованість і балансування навантаження, а також, звісно, продуктивність
Я не буду говорити нісенітниці, нижче додано набір результатів тестів, перехоплених в Інтернеті. Відображається кількість надісланих і отриманих повідомлень за секунду. Весь процес генерував загалом 1 мільйон 1K повідомлень. Тест проводився на автономній машині Windows Vista.
Як бачите, ZeroMQ — це не рівень, подібний до будь-якого іншого. Його продуктивність дивовижно висока. Незважаючи на це, цей продукт не забезпечує збереження повідомлень, не може легко зберігати та контролювати проміжні процеси, потребує самоаудиту та відновлення даних, тому він не є задовільним з точки зору простоти використання та HA. Висновок очевидний: якщо ви хочете, щоб додаток надсилав повідомлення якомога швидше, ви обираєте ZeroMQ. Вона цінніша, коли не надто переймаєшся втратою певних повідомлень випадково.
Блогер у цій статті сподівається (і не дуже сподівається) використовувати Rabbit, у Rabbitmq є вбудований ха, якщо ви сформуєте кластер, немає потреби турбуватися про такі проблеми, як балансування навантаження, і можна налаштувати дзеркало черги. Але це означає, що має бути більше тестування, і в результаті отримуєш улюблену гру, і все, що я чув і читав про Rabbit, змушує мене думати, що це має бути найкращий вибір.
|
Опубліковано 15.12.2016 10:52:40
|
|
|
|
