Шукаєте систему черги? А може ви шукаєте кращого? Ось вся необхідна інформація!
Системи масового обслуговування — це найкраще збережена таємниця розробки серверних програм.
Не намагаючись написати вірш на хвалу системам масового обслуговування, я б сказав, що молодший бекенд-розробник стає бекенд-розробником середнього рівня після того, як навчиться інтегрувати черги в систему. Черги покращують взаємодію з клієнтами (ми побачимо, як), зменшують складність і підвищують надійність системи.
Звичайно, для дуже простих веб-програм із майже нульовим трафіком і веб-сайтів із брошурами черги можуть бути загальними (або навіть неможливими для встановлення, якщо ви перебуваєте у типовому середовищі загального хостингу), але нетривіальні програми всі виграють від черги системи, і великі програми неможливі без черги.
Перш ніж ми почнемо, застереження: якщо ви вже знайомі з системами масового обслуговування та хочете порівняти різні варіанти, наступні кілька вступних розділів призведуть до глибокого сну. 🙂 Тож сміливо стрибайте вперед. Вступні розділи призначені для тих, хто має лише туманне уявлення про системи масового обслуговування або лише побіжно почув цю назву.
Що таке система масового обслуговування?
Почнемо з розуміння того, що таке черга.
Черга — це структура даних в інформатиці, яка імітує реальні черги, які ми бачимо навколо себе. Наприклад, підійшовши до квиткової каси, ви помітите, що вам доведеться стояти в кінці черги, а той, хто стоїть на початку черги, отримає квиток першим. Це те, що ми також називаємо феноменом «першим прийшов, першим обслужений». В інформатиці можна писати програми, які зберігають свої завдання таким чином у черзі, обробляючи їх одне за одним у порядку черги.
Зауважте, що сама черга не обробляє. Це просто своєрідне тимчасове сховище, де завдання чекають, поки їх щось підхопить. Якщо все це звучить надто абстрактно, не хвилюйтеся. Це абстрактне поняття, але ми побачимо чіткі приклади в наступному розділі. 🙂
Навіщо потрібні системи масового обслуговування?
Не вдаючись у дуже розлогий опис, я б сказав, що основна потреба в системах масового обслуговування полягає у фоновій обробці, паралельному виконанні та відновленні після збою. Розглянемо це на прикладах:
Фонова обробка
Припустімо, що ви проводите маркетингову кампанію електронної комерції, де час має важливе значення, і ваша програма створена так, що вона надсилає електронний лист із підтвердженням безпосередньо перед тим, як клієнт завершить платіж і покаже сторінку «подяки». Якщо поштовий сервер, до якого ви підключаєтеся, не працює, веб-сторінка просто загине, що порушить роботу користувача.
Уявіть собі, яку кількість запитів на підтримку ви отримаєте! У цьому випадку краще відправити це завдання надсилання електронної пошти до черги завдань і показати клієнту сторінку успіху.
Паралельне виконання
Багато розробників, особливо ті, які здебільшого кодують прості програми з низьким трафіком, мають звичку використовувати завдання cron для фонової обробки. Це нормально, доки розмір вхідних даних не стане настільки великим, що їх неможливо очистити. Наприклад, припустімо, що у вас є завдання cron, яке збирає аналітичні звіти та надсилає їх користувачам електронною поштою, і ваша система може обробляти 100 звітів за хвилину.
Щойно ваша програма розростається й починає отримувати в середньому понад 100 запитів на хвилину, вона почне відставати все більше й більше й ніколи не зможе виконати всі завдання.
У системі масового обслуговування цієї ситуації можна уникнути, налаштувавши кілька працівників, кожен з яких може вибрати завдання (що містить 100 звітів, які потрібно виконати кожен) і працювати паралельно, щоб завершити завдання набагато, набагато швидше.
Відновлення після невдачі
Як веб-розробники, ми зазвичай не думаємо про невдачі. Ми сприймаємо як належне, що наші сервери та API, які ми використовуємо, завжди будуть онлайн. Але реальність інша: збої в мережі надто поширені, а чудові API, на які ви покладаєтеся, можуть не працювати через проблеми з інфраструктурою (перш ніж сказати «не я!», не забудьте масовий збій Amazon S3). Отже, повертаючись до прикладу зі звітами, якщо під час створення звіту вам потрібно підключитися до платіжного API, і це з’єднання не працює на 2 хвилини, що станеться з 200 звітами, які не вдалося виконати?
Однак системи масового обслуговування викликають значні накладні витрати. Крива навчання є досить стрімкою, коли ви переходите в абсолютно новий домен, складність вашої програми та розгортання зростає, а завдання в черзі не завжди можна контролювати зі 100% точністю. Однак бувають ситуації, коли створити додаток без черг просто неможливо.
Покінчивши з цим, давайте поглянемо на деякі з поширених варіантів серед серверних модулів/систем черг.
Redis
Redis відомий як сховище ключ-значення, яке просто зберігає, оновлює та отримує рядки даних без знання структури даних. Хоча це могло бути правдою раніше, сьогодні Redis має ефективні та дуже корисні структури даних, такі як списки, відсортовані набори та навіть систему Pub-Sub, що робить його дуже бажаним для впровадження черги.
Перевагами Redis є:
- База даних повністю в пам’яті, що забезпечує швидше читання/запис.
- Висока ефективність: може легко підтримувати понад 100 000 операцій читання/запису в секунду.
- Дуже гнучка схема збереження. Ви можете вибрати максимальну продуктивність ціною можливої втрати даних у разі збоїв або налаштувати повністю консервативний режим, щоб пожертвувати продуктивністю заради узгодженості.
- Кластери підтримуються з коробки
Будь ласка, зверніть увагу, що Redis не має абстракцій обміну повідомленнями/черги/відновлення, тому вам потрібно або використовувати пакет, або створити легку систему самостійно. Прикладом є те, що Redis є серверною частиною черги за замовчуванням для фреймворку Laravel PHP, де планувальник був реалізований авторами фреймворку.
Вивчення Redis легко.
RabbitMQ
Є кілька тонких відмінностей між Redis і RabbitMQтож давайте спочатку приберемо їх із шляху.
Перш за все, RabbitMQ має більш спеціалізовану, чітко визначену роль, і тому він створений, щоб відобразити це — обмін повідомленнями. Іншими словами, його перевага полягає в тому, щоб діяти як посередник між двома системами, чого не можна сказати про Redis, який діє як база даних. Як результат, RabbitMQ надає ще кілька можливостей, яких немає в Redis: маршрутизація повідомлень, повторні спроби, розподіл навантаження тощо.
Якщо ви подумаєте про це, черги завдань також можна розглядати як систему обміну повідомленнями, де планувальник, робочі та «подавачі» завдань можна вважати суб’єктами, які беруть участь у передачі повідомлень.
RabbitMQ має такі переваги:
- Кращі абстракції для передачі повідомлень, зменшення роботи на рівні програми, якщо передача повідомлень є тим, що вам потрібно.
- Більш стійкий до збоїв і відключень живлення (ніж Redis, принаймні за замовчуванням).
- Підтримка кластерів і об’єднань для розподілених розгортань.
- Корисні інструменти для керування та моніторингу розгортань.
- Підтримка практично всіх нетривіальних мов програмування.
- Розгортання за допомогою обраного вами інструменту (Docker, Chef, Puppet тощо).
Коли використовувати RabbitMQ? Я б сказав, що це чудовий вибір, якщо ви знаєте, що вам потрібно використовувати асинхронну передачу повідомлень, але не готові впоратися з надзвичайною складністю деяких інших варіантів черги в цьому списку (див. нижче).
ActiveMQ
Якщо вам подобається корпоративний простір (або створюєте розповсюджену та масштабну програму) і ви не хочете постійно винаходити колесо (і при цьому робити помилки), ActiveMQ варто подивитися.
Ось у чому перевага ActiveMQ:
- Він реалізований на Java, тому має дуже гарну інтеграцію з Java (дотримується стандарту JMS).
- Підтримується кілька протоколів: AMQP, MQTT, STOMP, OpenWire тощо.
- Керується безпекою, маршрутизацією, терміном дії повідомлень, аналітикою тощо.
- Вбудована підтримка популярних шаблонів розподілених повідомлень, що економить ваш час і дорогі помилки.
Це не означає, що ActiveMQ доступний лише для Java. У нього є клієнти для Python, C/C++, Node, .Net та інших екосистем, тому не повинно бути побоювань щодо можливого колапсу в майбутньому. Крім того, ActiveMQ побудовано на повністю відкритих стандартах, і створювати власні полегшені клієнти має бути легко.
Усе, що було сказано та зроблено, будь ласка, майте на увазі, що ActiveMQ є лише посередником і не містить серверної частини. Для зберігання повідомлень все одно потрібно використовувати один із підтримуваних серверних модулів. Я включив його сюди, оскільки він не прив’язаний до певної мови програмування (як інші популярні рішення, такі як Celery, Sidekiq тощо).
Amazon MQ
Amazon MQ заслуговує на швидку, але важливу згадку тут. Якщо ви вважаєте, що ActiveMQ є ідеальним рішенням для ваших потреб, але не хочете самостійно займатися створенням і обслуговуванням інфраструктури, Amazon MQ пропонує для цього керовану послугу. Він підтримує всі протоколи ActiveMQ — немає жодної різниці в функціях — оскільки він використовує сам ActiveMQ під поверхнею.
Перевагою є те, що це керована служба, тож вам не потрібно турбуватися ні про що, крім її використання. Це має ще більше сенсу для розгортань на AWS, оскільки ви можете використовувати інші послуги та пропозиції безпосередньо з вашого розгортання (наприклад, швидша передача даних).
Amazon SQS
Ми не можемо очікувати, що Amazon буде спокійно сидіти, коли справа доходить до критичних частин інфраструктури, чи не так? 🙂
Так і маємо Amazon SQS, яка є повністю розміщеною простою службою черги (дослівно) відомого гіганта AWS. Знову ж таки, тонкі відмінності важливі, тому зауважте, що SQS не має концепції передачі повідомлень. Як і Redis, це простий бекенд для прийняття та розподілу завдань у чергах.
Отже, коли ви захочете використовувати Amazon SQS? Ось кілька причин:
- Ви фанат AWS і більше нічого не торкатиметеся (чесно кажучи, таких людей багато, і я думаю, що в цьому немає нічого поганого).
- Вам потрібне розміщене рішення, тому переконайтеся, що рівень відмов дорівнює нулю і жодне з завдань не буде втрачено.
- Ви не хочете створювати кластер і контролювати його самостійно. Або ще гірше, доведеться створювати інструменти моніторингу, коли ви можете використовувати цей час для продуктивної розробки.
- Ви вже маєте значні інвестиції в платформу AWS, і залишатися заблокованим має бізнес-сенс.
- Вам потрібна цілеспрямована проста система черги без будь-яких дрібниць, пов’язаних із передачею повідомлень, протоколами тощо.
Загалом, Amazon SQS є надійним вибором для тих, хто бажає включити черги завдань у свою систему та не турбуватися про встановлення/контроль самостійно.
Beanstalkd
Beanstalkd існує вже давно і є перевіреним у боях, швидким і простим сервером для черги завдань. Є кілька характеристик Beanstalkd, які значно відрізняють його від Redis:
- Це суто система черги завдань і нічого більше. Ви підштовхуєте до нього завдання, які пізніше притягують працівники. Отже, якщо ваша програма потребує навіть невеликої передачі повідомлень, вам слід уникати Beanstalkd.
- Немає розширених структур даних, таких як набори, черги пріоритетів тощо.
- Beanstalkd — це те, що називається чергою «першим прийшов, першим вийшов» (FIFO). Немає можливості розставити роботу за пріоритетністю.
- Варіантів кластеризації немає.
Усе сказане Beanstalkd створює зручну та швидку систему черги для простих проектів, які живуть на одному сервері. Для багатьох він швидший і стабільніший, ніж Redis. Отже, якщо у вас є питань з Redis, який ви просто не можете вирішити незважаючи ні на що, і ваші потреби прості, Beanstalkd варто спробувати.
Висновок
Якщо ви дочитали до цього місця (або дійшли сюди до повного читання 😉), є досить хороший шанс, що ви зацікавлені в системах масового обслуговування або вам вони потрібні. Якщо так, то список на цій сторінці буде вам у пригоді, якщо ви не шукаєте систему черги для певної мови/фреймворку.
Я хотів би сказати вам, що черга проста і на 100% надійна, але це не так. Це безлад, оскільки все це відбувається у фоновому режимі та відбувається дуже швидко (помилки можуть залишитися непоміченими та коштувати дуже дорого). Тим не менш, черги дуже необхідні поза точкою, і ви побачите, що вони є потужною зброєю (можливо, навіть найпотужнішою) у вашому арсеналі. Удачі! 🙂