Черга повідомлень
Черга повідомлень (англ. Message queue) в програмуванні — механізм операційної системи, що використовується для організації взаємодії між процесами або взаємодії між потоками програми. Такі компоненти використовують чергу для впорядкування повідомлень.
Огляд[ред. | ред. код]
Черги повідомлень надають асинхронний протокол передавання даних, означаючи, що відправник і одержувач повідомлення не зобов'язані взаємодіяти з чергою повідомлень одночасно. Розміщені в черзі повідомлення зберігаються доти, поки не отримують їх.
Черги повідомлень мають неявні або явні обмеження на розмір даних, які можуть передаватися в одному повідомленні, і кількість повідомлень, які можуть залишатися в черзі.
Багато реалізацій черг повідомлень функціонують внутрішньо: всередині операційної системи або всередині застосунка. Такі черги існують тільки для цілей цієї системи.
Інші реалізації дозволяють передавати повідомлення між різними комп'ютерними системами, потенційно підключаючи кілька застосунків і кілька операційних систем. Ці системи черг повідомлень зазвичай забезпечують розширену функціональність для забезпечення стійкості, щоб гарантувати, що повідомлення не будуть «втрачені» в разі збою системи.
Застосування[ред. | ред. код]
Для реалізації черги повідомлень системний адміністратор встановлює і налаштовує програмне забезпечення для організації черг повідомлень (диспетчер черги або брокер) і визначає іменовану чергу повідомлень. Або вони реєструються в службі черг повідомлень.
Потім застосунок реєструє програмну процедуру, яка «слухає» повідомлення, поміщені в чергу.
Друге і наступні застосунки можуть підключатися до черги і передавати на неї повідомлення.
Програмне забезпечення менеджера черг зберігає повідомлення доти, поки що приймаюча програма не підключиться, а потім викличе зареєстровану програмну процедуру. Потім застосунок-одержувач обробляє повідомлення відповідним чином.
Існує безліч варіантів точної семантики передачі повідомлень, в тому числі:
- Довговічність — повідомлення можуть зберігатися в пам'яті, записуватися на диск або навіть передаватися в СУБД, якщо необхідність в надійності вказує на більш ресурсоємних рішення.
- Політика безпеки — які програми повинні мати доступ до цих повідомлень?
- Політика очищення повідомлень — черги або повідомлення можуть мати «час життя».
- Фільтрація повідомлень — деякі системи підтримують фільтрацію даних, так що абонент може бачити тільки повідомлення, відповідні заздалегідь певним критеріям.
- Політика доставки — чи повинні ми гарантувати доставку повідомлення хоча б один раз або не більше одного разу?
- Політика маршрутизації — в системі з багатьма серверами черзі: які сервери повинні отримувати повідомлення або повідомлення черзі?
- Політика дозування — чи повинні повідомлення доставлятися негайно? Або система повинна трохи почекати і спробувати доставити багато повідомлень одночасно?
- Критерії черговості — коли повідомлення має вважатися «вміщеним в чергу»? Коли в одній черзі? Або коли бути перенаправленим, принаймні, в одну віддалену чергу? Або до всіх черг?
- Повідомлення про одержання — видавцеві може знадобитися дізнатися, коли деякі або всі передплатники отримали повідомлення.
Всі ці фактори можуть істотно вплинути на семантику транзакцій, надійність і ефективність системи.
Стандарти і протоколи[ред. | ред. код]
Історично чергу повідомлень використовувала власні закриті протоколи, які обмежували здатність різних операційних систем або мов програмування взаємодіяти в гетерогенном безлічі середовищ.
З'явилися три стандарти, які використовуються в реалізаціях черги повідомлень з відкритим вихідним кодом:
- Advanced Message Queuing Protocol (AMQP) — багатофункціональний протокол черги повідомлень.
- STOMP (STOMP) — простий текстовий протокол повідомлень.
- MQTT (раніше MQ Telemetry Transport) — протокол полегшеної черги повідомлень, особливо для вбудованих пристроїв.
Ці протоколи знаходяться на різних стадіях стандартизації та реалізації. Перші два працюють на тому ж рівні, що і HTTP, MQTT на рівні TCP/IP.
Синхронний або асинхронний[ред. | ред. код]
Багато з широко відомих протоколів зв'язку використовуються синхронно. Протокол HTTP, який використовується у Всесвітній павутині і в вебсервісах, пропонує наочний приклад, коли користувач відправляє запит на вебсторінку, а потім чекає відповіді.
Однак існують сценарії, в яких синхронна поведінка не підходить. Наприклад, AJAX (асинхронний JavaScript і XML) можна використовувати для асинхронної відправки текстових, JSON- або XML-повідомлень для поновлення частини вебсторінки з більш релевантною інформацією.
Реалізація в UNIX[ред. | ред. код]
В 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.] (англ.)
Це незавершена стаття про інформаційні технології. Ви можете допомогти проєкту, виправивши або дописавши її. |