Черга повідомлень (Message Queue, MQ)

Зараз серед вимог за багатьма бекенд-вакансіями можна побачити терміни RabbitMQ, ActiveMQ, Kafka. Можливо, ви вже знаєте, що це назва черги повідомлень (Message Queue). Але що таке “черга повідомлень”? Чому це така важлива вимога, що на неї обов’язково потрібно звертати увагу? Розібратися в цьому нам допоможе невелика аналогія.

Уявіть, що ви вирішили з друзями організувати книжковий клуб. Ви розподілилися за жанрами: хтось читає фантастику, хтось детективи, хтось історичні романи, а хтось поетичні збірки. Як тільки один з учасників клубу дізнається про нову книгу, він надсилає її своєму другу для прочитання, щоб кожен міг дізнатися його думку про книгу. Так книгу не потрібно читати кожному, її один раз читає один з ваших друзів і всі вже знають, про що вона. Це і є ваш додаток, де кожен елемент (учасник клубу) відповідає за обробку книг свого жанру.

А тепер уявіть, що в учасників клубу немає ніяких способів комунікації, крім особистого спілкування. Вони змушені жити в одній квартирі, оскільки у них немає інших способів координувати свої дії та не губитися. Якщо в клуб вступають нові учасники, у квартирі стає тісно та вони змушені переїздити в нову квартиру — і так поки учасників знову не стане надто багато. Якщо хтось з учасників клубу почне ремонт, то читати спокійно не зможе ніхто і весь клуб закриється до завершення ремонту. Будь-які сварки та напруженість у колективі також будуть впливати на всіх. Що вже говорити про ситуацію, коли кількість нових книг стане надто великою — книжковий клуб просто не впорається з цим.

Такий приклад — це типовий монолітний додаток. Монолітну архітектуру простіше використовувати, вона добре підходить для невеликих проєктів, особливо навчальних, pet-проєктів, з невеликою командою та невеликими навантаженнями. Якщо ви натрапили на розробника без досвіду роботи з чергами повідомлень, то він працював або тільки над невеликими проєктами, або над доісторичними проєктами-монолітами (з чимось середнім між пірамідою Хеопса та гігантським гуртожитком).

Як же розв’язати проблему нашого книжкового клубу? Очевидно, що потрібно покращити спосіб комунікації, дати можливість спілкуватися на великих відстанях. Всі ми знаємо таке рішення.

Необхідно додати в клуб мобільного оператора з телефонами. Кожен з учасників купує телефон та отримує свій мобільний номер, неначе реєструючись в системі. Ви обмінюєтеся цими номерами, заносячи їх собі в записник. Тепер можна просто натиснути «надіслати Васі повідомлення» і це повідомлення отримає той член клубу, якого звати «Вася». Просто і зручно.

Потрібно зазначити, що сам мобільний оператор та телефони — це не частина вашого клубу, а чужий проєкт, яким ви користуєтеся, не думаючи про те, як він працює (і, в цілому, вам це і не потрібно). Ваш «додаток» використовує стороннє рішення для комунікації між учасниками. Цей сторонній додаток і є Message Queue.

Ви запитаєте: «Чому власне черга повідомлень? Де тут черга?». Річ у тому, що тепер вам не потрібно вислуховувати кожного, хто вирішив порекомендувати книгу, та читати ці книги одночасно. Ви можете залишати повідомлення непрочитаними та читати їх одне за іншим відповідно до того, як ви завершуєте книгу з попереднього повідомлення. Так у вас формується черга книг до прочитання.

Що нам дає такий підхід? Кожен учасник клубу може бути сам по собі: ви можете жити і в одній квартирі, і в різних квартирах одного будинку, а можете і в різних містах. Хтось з клубу навіть може переїхати в іншу країну й у вас нічого не зміниться, крім роумінгу.

Тепер ваш клуб може бути розкиданим по всьому світу та працювати так само добре, як і якби ви всі сиділи поруч і спілкувалися особисто. Так формується розподілена архітектура. Переваг у цього підходу багато — тепер ніхто не свариться через тісноту, кожен, хто вирішив почати ремонт, не заважає іншим. Ви можете набрати скільки завгодно нових учасників і не мати проблем з масштабуванням вашого клубу. Ви можете навіть набрати учасників, які говорять різними мовами, головне домовитися спілкуватися один з одним однією мовою.

Ба більше, хтось з учасників клубу може схитрувати та зібрати цілу команду, яка буде допомагати йому читати книги — кожному по окремому повідомленню з книгою. При цьому ніхто з інших учасників клубу не зрозуміє різницю, адже формат роботи залишиться тим самим.

Впровадження черги повідомлень робить додаток легким до масштабування, розподіленим, пристосованим до багатопотоковості. Окремі його частини можна оновлювати, не зачіпаючи його повністю. Не важливо, яка у вас кількість учасників та команд, які мови ви використовуєте — робота буде такою ж ефективною. Такий додаток набагато простіше підлаштувати під великі навантаження. Потрібно тільки навчити всіх користуватися мобільними телефонами. 🙂

Приватний випадок описаної нами системи — це мікросервісна архітектура (microservices), тому мікросервіси частіше за все йдуть пліч-о-пліч з чергами повідомлень.

Message Queue — доказ серйозного продукту, над яким працює багато команд та який націлений на велику авдиторію. Черга повідомлень в резюме — це показник досвідченого програміста, який не з розмов знайомий з серйозною розробкою.

Хоча, звісно, ніхто не забороняє запхати чергу повідомлень в умовний «калькулятор» для солідності: там вона як п’яте колесо, зате круто виглядає в резюме. Тож будьте уважними та розглядайте резюме комплексно.