День 1036. Асинхронный Обмен Сообщениями. Продолжение 1. Основы распределённой архитектуры 2. Перманентные очереди Примеры перманентных очередей Наиболее предпочтительным вариантом будут облачные очереди, когда это возможно, потому что облачный провайдер управляет ими, они очень хорошо масштабируются и дают вам настройки, позволяющие контролировать, насколько параноидально надёжной должна быть ваша очередь. Примерами могут быть Azure Storage Queue, Amazon Simple Queue Service (SQS) и Google Cloud Tasks. Все облачные системы очередей предоставляют перманентные очереди, которые можно масштабировать автоматически. Какими бы прекрасными ни были облачные решения, локальные системы очередей вполне жизнеспособны. Невозможно получить те же возможности масштабирования, что и в облачном решении, но вы можете снизить задержки. Самыми распространёнными локальными перманентными очередями в наши дни являются RabbitMQ и Kafka. Для старых систем Windows обычно использовалась очередь сообщений Microsoft (MSMQ), хотя в наши дни это больше не рекомендуется. Обратите внимание, что некоторые локальные решения для очередей (например, RabbitMQ) не используют постоянные хранилища по умолчанию, поэтому необходима некоторая настройка, чтобы сделать очередь действительно перманентной. Есть и другие решения как для облачных, так и для локальных сетей. База данных как перманентная очередь Ещё одно решение, которое иногда используется, - база данных. Обычно это должна быть база данных, которая гарантирует ACID. Некоторые базы данных NoSql также можно использовать в качестве перманентных очередей, если они действительно имеют перманентную запись. Но имейте в виду, что некоторые базы данных NoSql могут терять записи, и в этом случае они не считаются перманентными очередями. Большинство баз данных, используемых в качестве перманентных очередей, полностью ACID (т.е. транзакционные). Использование базы данных ACID в качестве перманентной очереди позволяет использовать паттерн исходящих сообщений (Outbox). Когда сервис хочет опубликовать сообщение оно считается успешно записанным тогда и только тогда, когда определённая транзакция базы данных завершается успешно и сообщение записывается в базу данных как часть этой транзакции. Сервис не может сообщить об успехе до обновления базы данных, потому что обновление базы данных может завершиться ошибкой. Также сервер не может сообщить об успехе, пока не завершится обновление базы данных, потому что, если возникнет проблема с попаданием сообщения в постоянную очередь, сообщение будет потеряно. Таким образом, используя непосредственно базу данных в качестве постоянной очереди, сервис гарантирует, что сообщение об успехе будет возвращено тогда и только тогда, когда произойдёт обновление базы данных. Паттерн исходящих сообщений получил свое название, потому что обычно существует специальная таблица "outbox", в которой хранятся только опубликованные сообщения. Можно сделать так, чтобы потребитель очереди читал таблицу исходящих сообщений напрямую, но более распространённым решением является использование таблицы исходящих сообщений в качестве временного хранилища для сообщений на пути к другой перманентной очереди - обычно той, которая используется остальной частью приложения (например, облачная очередь или локальная постоянная очередь). В этом случае сервис публикации (или другой отдельный сервис) считывает сообщения из таблицы исходящих сообщений, отправляет их в постоянную очередь, а затем удаляет эти сообщения из таблицы исходящих сообщений. Продолжение следует… Источник: blog.stephencleary.com/2021/01…ues.html