Черга повідомлень
Черга повідомлень (англ. Message queue) в програмуванні — механізм операційної системи, що використовується для організації взаємодії між процесами або взаємодії між потоками програми. Такі компоненти використовують чергу для впорядкування повідомлень.
Черги повідомлень надають асинхронний протокол передавання даних, означаючи, що відправник і одержувач повідомлення не зобов'язані взаємодіяти з чергою повідомлень одночасно. Розміщені в черзі повідомлення зберігаються доти, поки не отримують їх.
Черги повідомлень мають неявні або явні обмеження на розмір даних, які можуть передаватися в одному повідомленні, і кількість повідомлень, які можуть залишатися в черзі.
Багато реалізацій черг повідомлень функціонують внутрішньо: всередині операційної системи або всередині застосунка. Такі черги існують тільки для цілей цієї системи.
Інші реалізації дозволяють передавати повідомлення між різними комп'ютерними системами, потенційно підключаючи кілька застосунків і кілька операційних систем. Ці системи черг повідомлень зазвичай забезпечують розширену функціональність для забезпечення стійкості, щоб гарантувати, що повідомлення не будуть «втрачені» в разі збою системи.
Для реалізації черги повідомлень системний адміністратор встановлює і налаштовує програмне забезпечення для організації черг повідомлень (диспетчер черги або брокер) і визначає іменовану чергу повідомлень. Або вони реєструються в службі черг повідомлень.
Потім застосунок реєструє програмну процедуру, яка «слухає» повідомлення, поміщені в чергу.
Друге і наступні застосунки можуть підключатися до черги і передавати на неї повідомлення.
Програмне забезпечення менеджера черг зберігає повідомлення доти, поки що приймаюча програма не підключиться, а потім викличе зареєстровану програмну процедуру. Потім застосунок-одержувач обробляє повідомлення відповідним чином.
Існує безліч варіантів точної семантики передачі повідомлень, в тому числі:
- Довговічність — повідомлення можуть зберігатися в пам'яті, записуватися на диск або навіть передаватися в СУБД, якщо необхідність в надійності вказує на більш ресурсоємних рішення.
- Політика безпеки — які програми повинні мати доступ до цих повідомлень?
- Політика очищення повідомлень — черги або повідомлення можуть мати «час життя».
- Фільтрація повідомлень — деякі системи підтримують фільтрацію даних, так що абонент може бачити тільки повідомлення, відповідні заздалегідь певним критеріям.
- Політика доставки — чи повинні ми гарантувати доставку повідомлення хоча б один раз або не більше одного разу?
- Політика маршрутизації — в системі з багатьма серверами черзі: які сервери повинні отримувати повідомлення або повідомлення черзі?
- Політика дозування — чи повинні повідомлення доставлятися негайно? Або система повинна трохи почекати і спробувати доставити багато повідомлень одночасно?
- Критерії черговості — коли повідомлення має вважатися «вміщеним в чергу»? Коли в одній черзі? Або коли бути перенаправленим, принаймні, в одну віддалену чергу? Або до всіх черг?
- Повідомлення про одержання — видавцеві може знадобитися дізнатися, коли деякі або всі передплатники отримали повідомлення.
Всі ці фактори можуть істотно вплинути на семантику транзакцій, надійність і ефективність системи.
Історично чергу повідомлень використовувала власні закриті протоколи, які обмежували здатність різних операційних систем або мов програмування взаємодіяти в гетерогенном безлічі середовищ.
З'явилися три стандарти, які використовуються в реалізаціях черги повідомлень з відкритим вихідним кодом:
- Advanced Message Queuing Protocol (AMQP) — багатофункціональний протокол черги повідомлень.
- STOMP (STOMP) — простий текстовий протокол повідомлень.
- MQTT (раніше MQ Telemetry Transport) — протокол полегшеної черги повідомлень, особливо для вбудованих пристроїв.
Ці протоколи знаходяться на різних стадіях стандартизації та реалізації. Перші два працюють на тому ж рівні, що і HTTP, MQTT на рівні TCP/IP.
Багато з широко відомих протоколів зв'язку використовуються синхронно. Протокол HTTP, який використовується у Всесвітній павутині і в вебсервісах, пропонує наочний приклад, коли користувач відправляє запит на вебсторінку, а потім чекає відповіді.
Однак існують сценарії, в яких синхронна поведінка не підходить. Наприклад, AJAX (асинхронний JavaScript і XML) можна використовувати для асинхронної відправки текстових, JSON- або XML-повідомлень для поновлення частини вебсторінки з більш релевантною інформацією.
В UNIX є 2 поширені реалізації черг. Одна є частиною SYS V API, а інша — частина POSIX.
- AMQP
- Amazon SQS
- Apache ActiveMQ
- Apache Qpid
- IBM WebSphere MQ[ru]
- Java Message Service
- MQTT
- RabbitMQ
- MSMQ
- Bach, M.J. The Design of the UNIX Operating System. ISBN 9780132017992.
- Message Queuing (MSMQ) [Архівовано 9 травня 2015 у Wayback Machine.] (англ.)
|
Це незавершена стаття про інформаційні технології. Ви можете допомогти проєкту, виправивши або дописавши її. |