Схема реактора

Шаблон реактора проектирования программного обеспечения представляет собой стратегию обработки событий реагировать на множество потенциальных запросов на обслуживание , которая может одновременно . Ключевым компонентом шаблона является цикл событий , работающий в одном потоке или процессе , который демультиплексирует входящие запросы и отправляет их нужному обработчику запросов. ^[1]

Полагаясь на механизмы, основанные на событиях, а не на блокировку ввода-вывода или многопоточность, реактор может обрабатывать множество одновременных запросов, связанных с вводом-выводом , с минимальной задержкой. ^[2]Реактор также позволяет легко изменять или расширять определенные процедуры обработки запросов, хотя этот шаблон имеет некоторые недостатки и ограничения. ^[1]

Благодаря сочетанию простоты и масштабируемости реактор стал центральным архитектурным элементом в нескольких серверных приложениях и программных средах для работы в сети . Такие производные, как мультиреактор и проактор, также существуют для особых случаев, когда необходима еще большая пропускная способность, производительность или сложность запроса. ^[1]^[2]^[3]^[4]

Обзор

Практические соображения по модели клиент-сервер в больших сетях, такие как проблема C10k для веб-серверов , были первоначальной мотивацией для шаблона реактора. ^[5]

Наивный подход к обработке запросов на обслуживание от многих потенциальных конечных точек, таких как сетевые сокеты или файловые дескрипторы , заключается в прослушивании новых запросов внутри цикла событий, а затем немедленном чтении самого раннего запроса. Как только весь запрос будет прочитан, его можно обработать и переслать, напрямую вызвав соответствующий обработчик. Полностью «итеративный» сервер, подобный этому, который обрабатывает один запрос от начала до конца за итерацию цикла событий, логически действителен. Однако он отстанет, если получит несколько запросов подряд. Итеративный подход не может масштабироваться, поскольку чтение запроса блокирует единственный поток сервера до тех пор, пока не будет получен полный запрос, а операции ввода-вывода обычно выполняются намного медленнее, чем другие вычисления. ^[2]

Одной из стратегий преодоления этого ограничения является многопоточность: за счет немедленного разделения каждого нового запроса на отдельный рабочий поток первый запрос больше не будет блокировать цикл событий, который может немедленно выполнить итерацию и обработать другой запрос. Такая конструкция «поток на соединение» масштабируется лучше, чем чисто итеративная, но она по-прежнему содержит множество недостатков и будет с трудом преодолевать определенный момент. С точки зрения базовых системных ресурсов каждый новый поток или процесс требует дополнительных затрат памяти и времени обработки (из-за переключения контекста ). Фундаментальная неэффективность каждого потока, ожидающего завершения ввода-вывода, также не решена. ^[1]^[2]

С точки зрения проектирования оба подхода тесно связывают общий демультиплексор с конкретными обработчиками запросов, что делает серверный код хрупким и утомительным для модификации. Эти соображения подсказывают несколько основных проектных решений:

Сохраните однопоточный обработчик событий; многопоточность приводит к накладным расходам и сложности, не решая реальную проблему блокировки ввода-вывода.
Используйте механизм уведомления о событиях для демультиплексирования запросов только после завершения ввода-вывода (чтобы ввод-вывод фактически не блокировался).
Зарегистрируйте обработчики запросов как обратные вызовы с обработчиком событий для лучшего разделения задач.

Объединение этих идей приводит к созданию шаблона реактора, который уравновешивает преимущества однопоточной обработки с высокой пропускной способностью и масштабируемостью. ^[1]^[2]

Использование

Шаблон реактора может стать хорошей отправной точкой для решения любой параллельной проблемы обработки событий. Этот шаблон также не ограничивается сетевыми сокетами; аппаратный ввод-вывод, доступ к файловой системе или базе данных , межпроцессное взаимодействие и даже абстрактные системы передачи сообщений — все это возможные варианты использования. ^{[ нужна ссылка ]}

Однако у шаблона реактора есть ограничения, главным из которых является использование обратных вызовов, которые усложняют программы анализ и отладку — проблема, характерная для проектов с инвертированным управлением . ^[1] Более простые подходы «поток на соединение» и полностью итеративный подход позволяют избежать этого и могут быть приемлемыми решениями, если не требуется масштабируемость или высокая пропускная способность. ^[а]^{[ нужна ссылка ]}

Однопоточность также может стать недостатком в случаях использования, требующих максимальной пропускной способности или когда запросы требуют значительной обработки. Различные многопоточные конструкции могут преодолеть эти ограничения, и фактически некоторые из них до сих пор используют шаблон реактора в качестве подкомпонента для обработки событий и ввода-вывода. ^[1]

Приложения

Шаблон реактора (или его вариант) нашел место во многих веб-серверах, серверах приложений и сетевых платформах:

Адаптивная среда общения ^[1]
EventMachine ^{[ нужна ссылка ]}
Нетти ^[3]
Нгинкс ^[4]
Node.js ^[2]^[6]
Объектная среда Perl ^{[ нужна ссылка ]}
МАЛЕНЬКИЕ библиотеки C++ ^[7]
Spring Framework (версия 5 и новее) ^[8]
витой ^[9]
Верт.x ^[3]

Структура

Диаграмма компонентов UML 2 реактивного приложения. ^[1]
Диаграмма последовательности UML 2 реактивного сервера. ^[1]

Реактивное приложение состоит из нескольких движущихся частей и будет опираться на некоторые механизмы поддержки: ^[1]

Ручка: Идентификатор и интерфейс для конкретного запроса с вводом-выводом и данными. Часто это принимает форму сокета, файлового дескриптора или аналогичного механизма, который должен предоставляться большинством современных операционных систем.
Демультиплексор: Уведомитель событий, который может эффективно отслеживать состояние дескриптора, а затем уведомлять другие подсистемы о соответствующем изменении статуса (обычно дескриптор ввода-вывода становится «готовым к чтению»). Традиционно эту роль выполнял системный вызов select() , но более современные примеры включают epoll , kqueue и IOCP .
Диспетчер: Фактический цикл событий реактивного приложения. Этот компонент поддерживает реестр допустимых обработчиков событий, а затем вызывает соответствующий обработчик при возникновении события.
Обработчик событий: Также известный как обработчик запросов, это особая логика для обработки одного типа запроса на обслуживание. Шаблон реактора предлагает динамически регистрировать их с помощью диспетчера как обратные вызовы для большей гибкости. По умолчанию реактор не использует многопоточность, а вызывает обработчик запроса в том же потоке, что и диспетчер.
Интерфейс обработчика событий: Абстрактный класс интерфейса, представляющий общие свойства и методы обработчика событий. Каждый конкретный обработчик должен реализовать этот интерфейс, в то время как диспетчер будет работать с обработчиками событий через этот интерфейс.

Варианты

Стандартной модели реактора достаточно для многих приложений, но для особо требовательных приложений можно использовать дополнительные настройки, которые могут обеспечить еще большую мощность за счет дополнительной сложности.

Одним из основных изменений является вызов обработчиков событий в их собственных потоках для большей параллелизма. Запуск обработчиков в пуле потоков вместо запуска новых потоков по мере необходимости еще больше упростит многопоточность и минимизирует накладные расходы. Это делает пул потоков естественным дополнением шаблона реактора во многих случаях использования. ^[2]

Другой способ максимизировать пропускную способность — частично повторно ввести подход сервера «поток на соединение» с параллельными реплицируемыми диспетчерами/циклами событий. Однако вместо количества соединений можно настроить количество диспетчеров, чтобы оно соответствовало доступным ядрам ЦП базового оборудования.

Этот вариант, известный как мультиреактор, гарантирует, что выделенный сервер полностью использует вычислительную мощность оборудования. Поскольку отдельные потоки представляют собой длительные циклы событий, накладные расходы на создание и уничтожение потоков ограничиваются запуском и завершением работы сервера. Поскольку запросы распределяются между независимыми диспетчерами, мультиреактор также обеспечивает лучшую доступность и надежность; в случае возникновения ошибки и сбоя одного диспетчера он будет прерывать только запросы, выделенные для этого цикла событий. ^[3]^[4]

Для особенно сложных сервисов, где необходимо объединить синхронные и асинхронные требования, еще одной альтернативой является шаблон проактора. Этот шаблон более сложен, чем реактор, со своими инженерными деталями, но он по-прежнему использует подкомпонент реактора для решения проблемы блокировки ввода-вывода. ^[3]

См. также

Связанные шаблоны:

Активный объект
Шаблон наблюдателя
Шаблон Proactor , который позволяет смешивать синхронную и асинхронную обработку событий.

Примечания

^ Тем не менее, практическое правило разработки программного обеспечения заключается в том, что если требования приложения потенциально могут превысить предполагаемый предел, следует ожидать, что когда-нибудь так и будет.

Ссылки

^ Jump up to: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж ^к Шмидт, Дуглас К. (1995). «Глава 29: Reactor: шаблон поведения объекта для демультиплексирования и диспетчеризации дескрипторов синхронных событий» (PDF) . В Коплиене, Джеймс О. (ред.). Языки шаблонов проектирования программ . Том. 1 (1-е изд.). Аддисон-Уэсли. ISBN 9780201607345 .
^ Jump up to: ^а ^б ^с ^д ^и ^ж ^г Девресс, Адриен (20 июня 2014 г.). «Эффективный параллельный ввод-вывод в многоядерных архитектурах» (PDF) . 2-я Тематическая школа вычислительной техники ЦЕРН . ЦЕРН. Архивировано (PDF) из оригинала 8 августа 2022 года . Проверено 14 сентября 2023 г.
^ Jump up to: ^а ^б ^с ^д ^и Эскофье, Клеман; Финнеган, Кен (ноябрь 2021 г.). «Глава 4. Принципы проектирования реактивных систем» . Реактивные системы в Java . О'Рейли Медиа. ISBN 9781492091721 .
^ Jump up to: ^а ^б ^с Гаррет, Оуэн (10 июня 2015 г.). «Внутри NGINX: как мы создавали производительность и масштабируемость» . НГИНКС . F5, Inc. Архивировано из оригинала 20 августа 2023 года . Проверено 10 сентября 2023 г.
^ Кегель, Дэн (5 февраля 2014 г.). «Проблема C10k» . Веб-хостел Дэна Кегеля . Архивировано из оригинала 6 сентября 2023 года . Проверено 10 сентября 2023 г.
^ Бонер, Йонас (15 июня 2022 г.). «Реактивные паттерны: 3. Изолировать мутации» . Реактивные принципы . Проверено 20 сентября 2023 г.
^ «Сетевое программирование: написание сетевых и интернет-приложений» (PDF) . ПОКО-проект . Прикладная информатика Software Engineering GmbH. 2010. С. 21–22 . Проверено 20 сентября 2023 г.
^ Стоянчев, Россен (9 февраля 2016 г.). «Реактивная весна» . Весна.io . Проверено 20 сентября 2023 г.
^ «Обзор реактора» . www.wisted.org . Проверено 28 июля 2024 г.

Внешние ссылки

Конкретные приложения:

Алексеев, Андрей (30 марта 2012 г.). «Глава 14: nginx» . В Брауне, Эми; Уилсон, Грег (ред.). Архитектура приложений с открытым исходным кодом . Том. 2. Лулу.com. ISBN 9781105571817 .

Примеры реализации:

[6] Тем не менее, практическое правило разработки программного обеспечения заключается в том, что если требования приложения потенциально могут превысить предполагаемый предел, следует ожидать, что когда-нибудь так и будет.

[Schmidt_1995-1] Jump up to: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж ^к Шмидт, Дуглас К. (1995). «Глава 29: Reactor: шаблон поведения объекта для демультиплексирования и диспетчеризации дескрипторов синхронных событий» (PDF) . В Коплиене, Джеймс О. (ред.). Языки шаблонов проектирования программ . Том. 1 (1-е изд.). Аддисон-Уэсли. ISBN 9780201607345 .

[Devresse_2014-2] Jump up to: ^а ^б ^с ^д ^и ^ж ^г Девресс, Адриен (20 июня 2014 г.). «Эффективный параллельный ввод-вывод в многоядерных архитектурах» (PDF) . 2-я Тематическая школа вычислительной техники ЦЕРН . ЦЕРН. Архивировано (PDF) из оригинала 8 августа 2022 года . Проверено 14 сентября 2023 г.

[Escoffier_2021-3] Jump up to: ^а ^б ^с ^д ^и Эскофье, Клеман; Финнеган, Кен (ноябрь 2021 г.). «Глава 4. Принципы проектирования реактивных систем» . Реактивные системы в Java . О'Рейли Медиа. ISBN 9781492091721 .

[Garrett_2015-4] Jump up to: ^а ^б ^с Гаррет, Оуэн (10 июня 2015 г.). «Внутри NGINX: как мы создавали производительность и масштабируемость» . НГИНКС . F5, Inc. Архивировано из оригинала 20 августа 2023 года . Проверено 10 сентября 2023 г.

[Kegel_2014-5] Кегель, Дэн (5 февраля 2014 г.). «Проблема C10k» . Веб-хостел Дэна Кегеля . Архивировано из оригинала 6 сентября 2023 года . Проверено 10 сентября 2023 г.

[Bonér_2022-7] Бонер, Йонас (15 июня 2022 г.). «Реактивные паттерны: 3. Изолировать мутации» . Реактивные принципы . Проверено 20 сентября 2023 г.

[POCO_Network_Programming-8] «Сетевое программирование: написание сетевых и интернет-приложений» (PDF) . ПОКО-проект . Прикладная информатика Software Engineering GmbH. 2010. С. 21–22 . Проверено 20 сентября 2023 г.

[Stoyanchev_2016-9] Стоянчев, Россен (9 февраля 2016 г.). «Реактивная весна» . Весна.io . Проверено 20 сентября 2023 г.

[Twisted_2024-10] «Обзор реактора» . www.wisted.org . Проверено 28 июля 2024 г.

[1]

[2]

[3]

[4]

[5]

[а]

[6]

[7]

[8]

[9]