День 1035. Асинхронный Обмен Сообщениями. Продолжение 1. Основы распределённой архитектуры 2. Перманентные очереди Перманентная очередь должна как минимум записывать новый элемент на диск, когда он помещается в очередь. Это минимально приемлемое поведение: сообщения должны сохраняться после отключения сервиса. Этого достаточно для многих (большинства?) приложений. Более перманентной (или более надёжной) будет очередь, которая записывает на несколько дисков. Это позволяет сообщениям также пережить сбой одного диска. Ещё более надёжная очередь использует диски на нескольких серверах, а самые параноидальные очереди записывают на несколько серверов в разных географических точках. Для большинства приложений такой уровень отказоустойчивости не требуется. Но важно отметить, что минимально приемлемая надежность - это запись на диск. Очереди в памяти недостаточно надежны. Проблема с очередями в памяти Что же значит фраза «асинхронные сообщения должны выдерживать отключения сервиса»? Легче всего понять это, обдумывая вопрос: «Когда безопасно отключить HTTP-сервис?» Протокол HTTP используется всеми видами API и веб-сервисов. Однако иногда забывается одна важная деталь: это протокол запроса/ответа. Т.е. на каждый запрос есть ровно один ответ. С точки зрения HTTP-сервиса, поступает запрос, а затем через некоторое время отправляется ответ и этот запрос завершается. Так когда безопасно отключить HTTP-сервис? Самый простой ответ - когда был отправлен ответ на каждый запрос, т.е. когда больше нет невыполненных запросов. Это настолько естественный ответ, что каждый HTTP-сервер подразумевает его по умолчанию. ASP.NET, Node.js, Ruby on Rails… - каждая среда отслеживает, сколько невыполненных запросов у неё есть, и считает себя «безопасной для завершения», когда это число достигает нуля. Это также верно для балансировщиков нагрузки и прокси-серверов. Вот почему внешний запрос опасен: всё это поведение по умолчанию внезапно оказывается неправильным. Служба HTTP сообщает, что завершение работы безопасно, когда это не так (в очереди ещё есть сообщения). Отключения - это нормально Часто разработчики неверно трактуют эту проблему, пытаясь изменить поведение HTTP-серверов на "Безопасно завершать работу только тогда, когда я говорю, что это безопасно". Но тогда придётся также поменять логику всех прокси-серверов и балансировщиков. Даже если это сработает, существует бесконечная проблема обслуживания: теперь ваша ферма серверов обрабатывает отключения совершенно иначе, чем все другие фермы. Таким образом разработчик хочет, чтобы их HTTP-приложение работало «бесконечно». И это серьёзное непонимание принципов работы: на самом деле системы более устойчивы, если серверы не работают бесконечно. Отключения - это нормально, и мы должны принимать отключения как нормальную часть жизни. Один из примеров - обновления. Когда разрабатывается новая версия приложения, она должна заменить старые версии. Обычный способ сделать это - скользящие обновления: для каждого сервера вышестоящий прокси прекращает отправку новых запросов, дожидается, пока у сервиса не останется невыполненных запросов, выключает его, устанавливает обновление, снова запускает и начинает отправку новых запросов. Завершение работы необходимо для выполнения скользящих обновлений. Другими примерами могут быть обновления ОС или плановые перезапуски веб-сервера. Резонный вывод - отключения - это нормально. Все HTTP-приложения должны работать правильно при завершении работы. Следствие: всё ПО, которое предполагает, что оно никогда не завершится, по своей сути содержит ошибки. Наконец, вернёмся к тому, что означает «перманентный». Очереди в памяти не выдерживают отключений. Следовательно, «минимально приемлемая надежность» означает, что очередь сообщений выдерживает отключения, которые являются нормальным и обычным явлением. Продолжение следует… Источник: blog.stephencleary.com/2021/01…ues.html