Журнал фильтра правок

'@@ -1,14 +1,14 @@ [[Шаблон проектирования|Шаблон проектирования программного обеспечения]] "'''реактор"''' - стратегия [[Событие (объектно-ориентированное программирование)|обработки событий]], которая может [[Параллелизм (информатика)|одновременно]] реагировать на множество потенциальных запросов на обслуживание. Ключевым компонентом шаблона является [[цикл событий]], работающий в ''одном'' [[Поток выполнения|потоке]] или [[Процесс (информатика)|процессе]], который [[Мультиплексирование|демультиплексирует]] входящие запросы и отправляет их нужному обработчику запросов. <ref name="Schmidt 1995">{{Cite book|автор=Schmidt|first=Douglas C.|author-link=Douglas C. Schmidt|ответственный=Coplien|часть=Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events|ссылка часть=https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf|заглавие=Pattern Languages of Program Design|издание=1st|издательство=Addison-Wesley|date=1995|volume=1|isbn=9780201607345|editor1-link=Jim Coplien}}</ref> -Полагаясь на механизмы, основанные на событиях, а не [[Асинхронный ввод-вывод|на блокирующий ввод-вывод]] или многопоточность, реактор может обрабатывать множество конкурентных запросов, граничащих с вводом-выводом, с минимальной задержкой. <ref name="Devresse 2014">{{Cite web|url=https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf|title=Efficient parallel I/O on multi-core architectures|author=Devresse|first=Adrien|website=2nd Thematic CERN School of Computing|date=20 June 2014|publisher=CERN|archive-url=https://web.archive.org/web/20220808062914/https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf|archive-date=8 August 2022|access-date=14 September 2023|url-status=live}}</ref> Реактор также позволяет легко изменять или расширять отдельные процедуры обработки запросов, хотя этот шаблон имеет некоторые недостатки и ограничения. <ref name="Schmidt 1995">{{Cite book|автор=Schmidt|first=Douglas C.|author-link=Douglas C. Schmidt|ответственный=Coplien|часть=Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events|ссылка часть=https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf|заглавие=Pattern Languages of Program Design|издание=1st|издательство=Addison-Wesley|date=1995|volume=1|isbn=9780201607345|editor1-link=Jim Coplien}}<cite class="citation book cs1" data-ve-ignore="true" id="CITEREFSchmidt1995">[[Дуглас К. Шмидт|Schmidt, Douglas C.]] (1995). [https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf "Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events"] <span class="cs1-format">(PDF)</span>. In [[Джим Коплиен|Coplien, James O.]] (ed.). ''Pattern Languages of Program Design''. Vol.&nbsp;1 (1st&nbsp;ed.). Addison-Wesley. [[Международный стандартный книжный номер|ISBN]]&nbsp;[[Special:BookSources/9780201607345|<bdi>9780201607345</bdi>]].</cite></ref> +Полагаясь на механизмы, основанные на событиях, а не [[Асинхронный ввод-вывод|на блокирующий ввод-вывод]] или многопоточность, реактор может обрабатывать множество конкурентных запросов, граничащих с вводом-выводом, с минимальной задержкой. <ref name="Devresse 2014">{{Cite web|url=https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf|title=Efficient parallel I/O on multi-core architectures|author=Devresse|first=Adrien|website=2nd Thematic CERN School of Computing|date=20 June 2014|publisher=CERN|archive-url=https://web.archive.org/web/20220808062914/https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf|archive-date=8 August 2022|access-date=14 September 2023|url-status=live}}</ref> Реактор также позволяет легко изменять или расширять отдельные процедуры обработки запросов, хотя этот шаблон имеет некоторые недостатки и ограничения. <ref name="Schmidt 1995" /> -Благодаря балансу простоты и [[Масштабируемость|масштабируемости]] реактор стал центральным архитектурным элементом в нескольких [[Сервер (аппаратное обеспечение)|серверных]] приложениях и [[Фреймворк|фреймворков]] для [[Вычислительная сеть|работы в сети]] . Для особых случаев, когда необходима еще большая пропускная способность, производительность или сложность запроса, существуют производные - '''мультиреактор''' и проактор. <ref name="Schmidt 1995">{{Cite book|автор=Schmidt|first=Douglas C.|author-link=Douglas C. Schmidt|ответственный=Coplien|часть=Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events|ссылка часть=https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf|заглавие=Pattern Languages of Program Design|издание=1st|издательство=Addison-Wesley|date=1995|volume=1|isbn=9780201607345|editor1-link=Jim Coplien}}<cite class="citation book cs1" data-ve-ignore="true" id="CITEREFSchmidt1995">[[Дуглас К. Шмидт|Schmidt, Douglas C.]] (1995). [https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf "Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events"] <span class="cs1-format">(PDF)</span>. In [[Джим Коплиен|Coplien, James O.]] (ed.). ''Pattern Languages of Program Design''. Vol.&nbsp;1 (1st&nbsp;ed.). Addison-Wesley. [[Международный стандартный книжный номер|ISBN]]&nbsp;[[Special:BookSources/9780201607345|<bdi>9780201607345</bdi>]].</cite></ref> <ref name="Devresse 2014">{{Cite web|url=https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf|title=Efficient parallel I/O on multi-core architectures|author=Devresse|first=Adrien|website=2nd Thematic CERN School of Computing|date=20 June 2014|publisher=CERN|archive-url=https://web.archive.org/web/20220808062914/https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf|archive-date=8 August 2022|access-date=14 September 2023|url-status=live}}<cite class="citation web cs1" data-ve-ignore="true" id="CITEREFDevresse2014">Devresse, Adrien (20 June 2014). [https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf "Efficient parallel I/O on multi-core architectures"] <span class="cs1-format">(PDF)</span>. ''2nd Thematic CERN School of Computing''. CERN. [https://web.archive.org/web/20220808062914/https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf Archived] <span class="cs1-format">(PDF)</span> from the original on 8 August 2022<span class="reference-accessdate">. Retrieved <span class="nowrap">14 September</span> 2023</span>.</cite></ref> <ref name="Escoffier 2021">{{Cite book|автор=Escoffier|first=Clement|author2=Finnegan|first2=Ken|часть=Chapter 4. Design Principles of Reactive Systems|ссылка часть=https://www.oreilly.com/library/view/reactive-systems-in/9781492091714/ch04.html|заглавие=Reactive Systems in Java|издательство=O'Reilly Media|date=November 2021|isbn=9781492091721}}</ref> <ref name="Garrett 2015">{{Cite web|url=https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/|title=Inside NGINX: How We Designed for Performance & Scale|author=Garrett|first=Owen|website=NGINX|date=10 June 2015|publisher=F5, Inc.|archive-url=https://web.archive.org/web/20230820232851/https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/|archive-date=20 August 2023|access-date=10 September 2023|url-status=live}}</ref> +Благодаря балансу простоты и [[Масштабируемость|масштабируемости]] реактор стал центральным архитектурным элементом в нескольких [[Сервер (аппаратное обеспечение)|серверных]] приложениях и [[Фреймворк|фреймворков]] для [[Вычислительная сеть|работы в сети]] . Для особых случаев, когда необходима еще большая пропускная способность, производительность или сложность запроса, существуют производные - '''мультиреактор''' и проактор. <ref name="Schmidt 1995"/><ref name="Devresse 2014" /><ref name="Escoffier 2021">{{Cite book|автор=Escoffier|first=Clement|author2=Finnegan|first2=Ken|часть=Chapter 4. Design Principles of Reactive Systems|ссылка часть=https://www.oreilly.com/library/view/reactive-systems-in/9781492091714/ch04.html|заглавие=Reactive Systems in Java|издательство=O'Reilly Media|date=November 2021|isbn=9781492091721}}</ref> <ref name="Garrett 2015">{{Cite web|url=https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/|title=Inside NGINX: How We Designed for Performance & Scale|author=Garrett|first=Owen|website=NGINX|date=10 June 2015|publisher=F5, Inc.|archive-url=https://web.archive.org/web/20230820232851/https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/|archive-date=20 August 2023|access-date=10 September 2023|url-status=live}}</ref> == Обзор == Первоначальной мотивацией для шаблона реактора были практические соображения по [[Клиент — сервер|модели клиент-сервер]] в больших сетях, такие как [[C10k|проблема C10k]] для [[Веб-сервер|веб-серверов]].<ref name="Kegel 2014">{{Cite web|url=http://www.kegel.com/c10k.html|title=The C10k problem|author=Kegel|first=Dan|website=Dan Kegel's Web Hostel|date=5 February 2014|archive-url=https://web.archive.org/web/20230906022635/http://www.kegel.com/c10k.html|archive-date=6 September 2023|access-date=10 September 2023|url-status=live}}</ref> -Наивный подход к обработке запросов на обслуживание от многих потенциальных конечных точек, таких как [[Сокет (программный интерфейс)|сетевые сокеты]] или [[Файловый дескриптор|файловые дескрипторы]], заключается в прослушивании новых запросов из цикла событий, и немедленном чтении самого раннего запроса. Как только весь запрос будет прочитан, его можно обработать и переслать, напрямую вызвав соответствующий обработчик. Подобный полностью «итеративный» сервер, обрабатывающий один запрос от начала до конца за цикл событий, логически правилен. Однако он отстанет, если получит несколько запросов подряд. Итеративный подход не может масштабироваться, поскольку чтение запроса блокирует единственный поток сервера до тех пор, пока не будет получен полный запрос. А операции ввода-вывода обычно выполняются намного медленнее, чем другие вычисления. <ref name="Devresse 2014">{{Cite web|url=https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf|title=Efficient parallel I/O on multi-core architectures|author=Devresse|first=Adrien|website=2nd Thematic CERN School of Computing|date=20 June 2014|publisher=CERN|archive-url=https://web.archive.org/web/20220808062914/https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf|archive-date=8 August 2022|access-date=14 September 2023|url-status=live}}<cite class="citation web cs1" data-ve-ignore="true" id="CITEREFDevresse2014">Devresse, Adrien (20 June 2014). [https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf "Efficient parallel I/O on multi-core architectures"] <span class="cs1-format">(PDF)</span>. ''2nd Thematic CERN School of Computing''. CERN. [https://web.archive.org/web/20220808062914/https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf Archived] <span class="cs1-format">(PDF)</span> from the original on 8 August 2022<span class="reference-accessdate">. Retrieved <span class="nowrap">14 September</span> 2023</span>.</cite></ref> +Наивный подход к обработке запросов на обслуживание от многих потенциальных конечных точек, таких как [[Сокет (программный интерфейс)|сетевые сокеты]] или [[Файловый дескриптор|файловые дескрипторы]], заключается в прослушивании новых запросов из цикла событий, и немедленном чтении самого раннего запроса. Как только весь запрос будет прочитан, его можно обработать и переслать, напрямую вызвав соответствующий обработчик. Подобный полностью «итеративный» сервер, обрабатывающий один запрос от начала до конца за цикл событий, логически правилен. Однако он отстанет, если получит несколько запросов подряд. Итеративный подход не может масштабироваться, поскольку чтение запроса блокирует единственный поток сервера до тех пор, пока не будет получен полный запрос. А операции ввода-вывода обычно выполняются намного медленнее, чем другие вычисления. <ref name="Devresse 2014" /> -Одной из стратегий преодоления этого ограничения является многопоточность: за счет немедленного отделения каждого нового запроса в отдельный рабочий поток, первый запрос больше не будет блокировать цикл событий, который может немедленно завершить итерацию и обработать другой запрос. Такая конструкция «поток на соединение» масштабируется лучше, чем чисто итеративная, но она содержит свои ограничения. С точки зрения базовых системных ресурсов каждый новый поток или процесс требует дополнительных затрат [[Компьютерная память|памяти]] и времени обработки (из-за [[Переключение контекста|переключения контекста]] ). Фундаментальная неэффективность каждого потока, ожидающего завершения ввода-вывода, также не решена. <ref name="Schmidt 1995">{{Cite book|автор=Schmidt|first=Douglas C.|author-link=Douglas C. Schmidt|ответственный=Coplien|часть=Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events|ссылка часть=https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf|заглавие=Pattern Languages of Program Design|издание=1st|издательство=Addison-Wesley|date=1995|volume=1|isbn=9780201607345|editor1-link=Jim Coplien}}<cite class="citation book cs1" data-ve-ignore="true" id="CITEREFSchmidt1995">[[Дуглас К. Шмидт|Schmidt, Douglas C.]] (1995). [https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf "Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events"] <span class="cs1-format">(PDF)</span>. In [[Джим Коплиен|Coplien, James O.]] (ed.). ''Pattern Languages of Program Design''. Vol.&nbsp;1 (1st&nbsp;ed.). Addison-Wesley. [[Международный стандартный книжный номер|ISBN]]&nbsp;[[Special:BookSources/9780201607345|<bdi>9780201607345</bdi>]].</cite></ref> <ref name="Devresse 2014">{{Cite web|url=https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf|title=Efficient parallel I/O on multi-core architectures|author=Devresse|first=Adrien|website=2nd Thematic CERN School of Computing|date=20 June 2014|publisher=CERN|archive-url=https://web.archive.org/web/20220808062914/https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf|archive-date=8 August 2022|access-date=14 September 2023|url-status=live}}<cite class="citation web cs1" data-ve-ignore="true" id="CITEREFDevresse2014">Devresse, Adrien (20 June 2014). [https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf "Efficient parallel I/O on multi-core architectures"] <span class="cs1-format">(PDF)</span>. ''2nd Thematic CERN School of Computing''. CERN. [https://web.archive.org/web/20220808062914/https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf Archived] <span class="cs1-format">(PDF)</span> from the original on 8 August 2022<span class="reference-accessdate">. Retrieved <span class="nowrap">14 September</span> 2023</span>.</cite></ref> +Одной из стратегий преодоления этого ограничения является многопоточность: за счет немедленного отделения каждого нового запроса в отдельный рабочий поток, первый запрос больше не будет блокировать цикл событий, который может немедленно завершить итерацию и обработать другой запрос. Такая конструкция «поток на соединение» масштабируется лучше, чем чисто итеративная, но она содержит свои ограничения. С точки зрения базовых системных ресурсов каждый новый поток или процесс требует дополнительных затрат [[Компьютерная память|памяти]] и времени обработки (из-за [[Переключение контекста|переключения контекста]] ). Фундаментальная неэффективность каждого потока, ожидающего завершения ввода-вывода, также не решена. <ref name="Schmidt 1995" /><ref name="Devresse 2014"/> С точки зрения проектирования, оба подхода тесно связывают общий демультиплексор с конкретными обработчиками запросов, что делает серверный код хрупким и утомительным для модификации. Эти соображения подсказывают несколько основных проектных подходов: @@ -18,12 +18,11 @@ # Зарегистрировать обработчики запросов как [[Callback (программирование)|обратные вызовы]] с обработчиком событий для лучшего [[Разделение ответственности|разделения задач.]] -Объединение этих идей ведет шаблону реактора, который сочетает в себе преимущества однопоточной обработки с высокой пропускной способностью и масштабируемостью. <ref name="Schmidt 1995">{{Cite book|автор=Schmidt|first=Douglas C.|author-link=Douglas C. Schmidt|ответственный=Coplien|часть=Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events|ссылка часть=https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf|заглавие=Pattern Languages of Program Design|издание=1st|издательство=Addison-Wesley|date=1995|volume=1|isbn=9780201607345|editor1-link=Jim Coplien}}<cite class="citation book cs1" data-ve-ignore="true" id="CITEREFSchmidt1995">[[Дуглас К. Шмидт|Schmidt, Douglas C.]] (1995). [https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf "Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events"] <span class="cs1-format">(PDF)</span>. In [[Джим Коплиен|Coplien, James O.]] (ed.). ''Pattern Languages of Program Design''. Vol.&nbsp;1 (1st&nbsp;ed.). Addison-Wesley. [[Международный стандартный книжный номер|ISBN]]&nbsp;[[Special:BookSources/9780201607345|<bdi>9780201607345</bdi>]].</cite></ref> <ref name="Devresse 2014">{{Cite web|url=https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf|title=Efficient parallel I/O on multi-core architectures|author=Devresse|first=Adrien|website=2nd Thematic CERN School of Computing|date=20 June 2014|publisher=CERN|archive-url=https://web.archive.org/web/20220808062914/https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf|archive-date=8 August 2022|access-date=14 September 2023|url-status=live}}<cite class="citation web cs1" data-ve-ignore="true" id="CITEREFDevresse2014">Devresse, Adrien (20 June 2014). [https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf "Efficient parallel I/O on multi-core architectures"] <span class="cs1-format">(PDF)</span>. ''2nd Thematic CERN School of Computing''. CERN. [https://web.archive.org/web/20220808062914/https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf Archived] <span class="cs1-format">(PDF)</span> from the original on 8 August 2022<span class="reference-accessdate">. Retrieved <span class="nowrap">14 September</span> 2023</span>.</cite></ref> - +Объединение этих идей ведет шаблону реактора, который сочетает в себе преимущества однопоточной обработки с высокой пропускной способностью и масштабируемостью. <ref name="Schmidt 1995"/> <ref name="Devresse 2014" /> == Применение == Шаблон реактора может стать хорошей отправной точкой для решения любой параллельной проблемы обработки событий. Этот шаблон также не ограничивается сетевыми сокетами; аппаратный ввод-вывод, доступ к [[Файловая система|файловой системе]] или [[База данных|базе данных]], [[Межпроцессное взаимодействие|меж-процессное взаимодействие]] и даже абстрактные системы [[Обмен сообщениями|передачи сообщений]] — все это возможные варианты использования. </link><sup class="noprint Inline-Template Template-Fact" style="white-space:nowrap;">&#x5B; ''[[Википедия:О пользе ссылок|<span title="Seems straight-forward, but most sources emphasize network applications. (September 2023)">нужна цитата</span>]]'' &#x5D;</sup> -Однако у шаблона реактора есть ограничения, главным из которых является использование обратных вызовов, которые усложняют анализ и [[Отладка программы|отладку]] программы — проблема, характерная для проектов с [[Инверсия управления|инвертированным управлением]] . <ref name="Schmidt 1995">{{Cite book|автор=Schmidt|first=Douglas C.|author-link=Douglas C. Schmidt|ответственный=Coplien|часть=Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events|ссылка часть=https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf|заглавие=Pattern Languages of Program Design|издание=1st|издательство=Addison-Wesley|date=1995|volume=1|isbn=9780201607345|editor1-link=Jim Coplien}}<cite class="citation book cs1" data-ve-ignore="true" id="CITEREFSchmidt1995">[[Дуглас К. Шмидт|Schmidt, Douglas C.]] (1995). [https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf "Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events"] <span class="cs1-format">(PDF)</span>. In [[Джим Коплиен|Coplien, James O.]] (ed.). ''Pattern Languages of Program Design''. Vol.&nbsp;1 (1st&nbsp;ed.). Addison-Wesley. [[Международный стандартный книжный номер|ISBN]]&nbsp;[[Special:BookSources/9780201607345|<bdi>9780201607345</bdi>]].</cite></ref> Более простые подходы: «поток на соединение» и полностью итеративный подход, позволяют избежать этого и могут быть приемлемыми решениями, если не требуется масштабируемость или высокая пропускная способность. {{Efn|That said, a rule-of-thumb in software design is that if application demands can potentially increase past an assumed limit, one should expect that someday they will.}} </link> +Однако у шаблона реактора есть ограничения, главным из которых является использование обратных вызовов, которые усложняют анализ и [[Отладка программы|отладку]] программы — проблема, характерная для проектов с [[Инверсия управления|инвертированным управлением]] . <ref name="Schmidt 1995" /> Более простые подходы: «поток на соединение» и полностью итеративный подход, позволяют избежать этого и могут быть приемлемыми решениями, если не требуется масштабируемость или высокая пропускная способность. {{Efn| Практическое правило софто-строения говорит что если требования к приложению потенциально могут увеличить существующие и предполагаемые лимиты, можно ожидать что однажды так и будет.}} </link> -Однопоточность может стать недостатком в случаях требующих максимальной пропускной способности или когда запросы требуют значительной обработки. Преодолеть эти ограничения могут различные многопоточные конструкции. И фактически некоторые из них до сих пор используют шаблон реактора в качестве подкомпонента для обработки событий и ввода-вывода. <ref name="Schmidt 1995">{{Cite book|автор=Schmidt|first=Douglas C.|author-link=Douglas C. Schmidt|ответственный=Coplien|часть=Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events|ссылка часть=https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf|заглавие=Pattern Languages of Program Design|издание=1st|издательство=Addison-Wesley|date=1995|volume=1|isbn=9780201607345|editor1-link=Jim Coplien}}<cite class="citation book cs1" data-ve-ignore="true" id="CITEREFSchmidt1995">[[Дуглас К. Шмидт|Schmidt, Douglas C.]] (1995). [https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf "Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events"] <span class="cs1-format">(PDF)</span>. In [[Джим Коплиен|Coplien, James O.]] (ed.). ''Pattern Languages of Program Design''. Vol.&nbsp;1 (1st&nbsp;ed.). Addison-Wesley. [[Международный стандартный книжный номер|ISBN]]&nbsp;[[Special:BookSources/9780201607345|<bdi>9780201607345</bdi>]].</cite></ref> +Однопоточность может стать недостатком в случаях требующих максимальной пропускной способности или когда запросы требуют значительной обработки. Преодолеть эти ограничения могут различные многопоточные конструкции. И фактически некоторые из них до сих пор используют шаблон реактора в качестве подкомпонента для обработки событий и ввода-вывода. <ref name="Schmidt 1995" /> === Приложения === @@ -42,5 +41,11 @@ == Состав == -Реактивное приложение состоит из нескольких активных частей и опирается на некоторые механизмы поддержки: <ref name="Schmidt 1995">{{Cite book|автор=Schmidt|first=Douglas C.|author-link=Douglas C. Schmidt|ответственный=Coplien|часть=Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events|ссылка часть=https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf|заглавие=Pattern Languages of Program Design|издание=1st|издательство=Addison-Wesley|date=1995|volume=1|isbn=9780201607345|editor1-link=Jim Coplien}}<cite class="citation book cs1" data-ve-ignore="true" id="CITEREFSchmidt1995">[[Дуглас К. Шмидт|Schmidt, Douglas C.]] (1995). [https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf "Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events"] <span class="cs1-format">(PDF)</span>. In [[Джим Коплиен|Coplien, James O.]] (ed.). ''Pattern Languages of Program Design''. Vol.&nbsp;1 (1st&nbsp;ed.). Addison-Wesley. [[Международный стандартный книжный номер|ISBN]]&nbsp;[[Special:BookSources/9780201607345|<bdi>9780201607345</bdi>]].</cite></ref>{{Глосс}} +==Structure== +<gallery> +Reactor Pattern - UML 2 Component Diagram.svg|alt=A reactor typically consists of 2 subsystems. Sockets (a.k.a. handles) and a demultiplexer (like select or epoll) are typically provided by the system. The reactive application will provide a dispatcher / event-loop that reacts to handle events by invoking handlers, which are registered as callbacks.|UML 2 component diagram of a reactive application.<ref name="Schmidt 1995" /> +ReactorPattern - UML 2 Sequence Diagram.svg|alt=Before starting the event loop, a reactive application will typically register handles & handlers for specific requests. The event loop will then respond to request-based events by invoking a handler, passing the handle for processing.|UML 2 sequence diagram of a reactive server.<ref name="Schmidt 1995" /> +</gallery> + +Реактивное приложение состоит из нескольких активных частей и опирается на некоторые механизмы поддержки: <ref name="Schmidt 1995" /> {{Глосс}} {{Терм|Handle}} {{Опр|Идентификатор и интерфейс к экземпляра запроса с IO и данными. Обычно представлен в форме сокета, файлового дескриптора, или похожего механизма предоставляемого большинством современных ОС.}} @@ -59,11 +64,11 @@ Стандартной модели реактора достаточно для многих приложений, но для особенно требовательных случаев можно обеспечить еще большую мощность за счет дополнительной сложности. -Одна из основных модификаций — вызывать обработчики событий в их собственных потоках для большей параллелизма. Запуск обработчиков в пуле потоков вместо запуска новых потоков по мере необходимости еще больше упростит многопоточность и минимизирует накладные расходы. Т. о. пул потоков - естественное дополнение шаблона реактора во многих случаях использования. <ref name="Devresse 2014">{{Cite web|url=https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf|title=Efficient parallel I/O on multi-core architectures|author=Devresse|first=Adrien|website=2nd Thematic CERN School of Computing|date=20 June 2014|publisher=CERN|archive-url=https://web.archive.org/web/20220808062914/https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf|archive-date=8 August 2022|access-date=14 September 2023|url-status=live}}<cite class="citation web cs1" data-ve-ignore="true" id="CITEREFDevresse2014">Devresse, Adrien (20 June 2014). [https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf "Efficient parallel I/O on multi-core architectures"] <span class="cs1-format">(PDF)</span>. ''2nd Thematic CERN School of Computing''. CERN. [https://web.archive.org/web/20220808062914/https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf Archived] <span class="cs1-format">(PDF)</span> from the original on 8 August 2022<span class="reference-accessdate">. Retrieved <span class="nowrap">14 September</span> 2023</span>.</cite></ref> +Одна из основных модификаций — вызывать обработчики событий в их собственных потоках для большей параллелизма. Запуск обработчиков в пуле потоков вместо запуска новых потоков по мере необходимости еще больше упростит многопоточность и минимизирует накладные расходы. Т. о. пул потоков - естественное дополнение шаблона реактора во многих случаях использования. <ref name="Devresse 2014"/> Другой способ максимизировать пропускную способность — частично воспроизвести подход сервера «поток на соединение» с размножаемыми параллельными диспетчерами/циклами событий. Однако вместо количества соединений можно настроить количество диспетчеров, чтобы оно соответствовало доступным [[Многоядерный процессор|ядрам ЦП]] базового оборудования. -Этот вариант известен как мультиреактор. Он гарантирует, что выделенный сервер полностью использует вычислительную мощность оборудования. Поскольку отдельные потоки представляют собой долгоживущие циклы событий, накладные расходы на создание и уничтожение потоков ограничиваются запуском и завершением работы сервера. Поскольку запросы распределяются между независимыми диспетчерами, мультиреактор также обеспечивает лучшую доступность и надежность; в случае возникновения ошибки и сбоя одного диспетчера он будет прерывать только запросы, выделенные этому циклу событий. <ref name="Escoffier 2021">{{Cite book|автор=Escoffier|first=Clement|author2=Finnegan|first2=Ken|часть=Chapter 4. Design Principles of Reactive Systems|ссылка часть=https://www.oreilly.com/library/view/reactive-systems-in/9781492091714/ch04.html|заглавие=Reactive Systems in Java|издательство=O'Reilly Media|date=November 2021|isbn=9781492091721}}<cite class="citation book cs1" data-ve-ignore="true" id="CITEREFEscoffierFinnegan2021">Escoffier, Clement; Finnegan, Ken (November 2021). <span class="cs1-lock-registration" title="Free registration required">[https://www.oreilly.com/library/view/reactive-systems-in/9781492091714/ch04.html "Chapter 4. Design Principles of Reactive Systems"]</span>. ''Reactive Systems in Java''. O'Reilly Media. [[Международный стандартный книжный номер|ISBN]]&nbsp;[[Special:BookSources/9781492091721|<bdi>9781492091721</bdi>]].</cite></ref> <ref name="Garrett 2015">{{Cite web|url=https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/|title=Inside NGINX: How We Designed for Performance & Scale|author=Garrett|first=Owen|website=NGINX|date=10 June 2015|publisher=F5, Inc.|archive-url=https://web.archive.org/web/20230820232851/https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/|archive-date=20 August 2023|access-date=10 September 2023|url-status=live}}<cite class="citation web cs1" data-ve-ignore="true" id="CITEREFGarrett2015">Garrett, Owen (10 June 2015). [https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/ "Inside NGINX: How We Designed for Performance & Scale"]. ''NGINX''. F5, Inc. [https://web.archive.org/web/20230820232851/https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/ Archived] from the original on 20 August 2023<span class="reference-accessdate">. Retrieved <span class="nowrap">10 September</span> 2023</span>.</cite></ref> +Этот вариант известен как мультиреактор. Он гарантирует, что выделенный сервер полностью использует вычислительную мощность оборудования. Поскольку отдельные потоки представляют собой долгоживущие циклы событий, накладные расходы на создание и уничтожение потоков ограничиваются запуском и завершением работы сервера. Поскольку запросы распределяются между независимыми диспетчерами, мультиреактор также обеспечивает лучшую доступность и надежность; в случае возникновения ошибки и сбоя одного диспетчера он будет прерывать только запросы, выделенные этому циклу событий. <ref name="Escoffier 2021"/> <ref name="Garrett 2015"/> -Для особенно сложных сервисов, одновременно требующих синхронности и асинхронности, еще одной альтернативой является шаблон проактора. Этот шаблон более сложен, чем реактор, со своими инженерными деталями, но он по-прежнему использует подкомпонент реактора для решения проблемы блокировки ввода-вывода. <ref name="Escoffier 2021">{{Cite book|автор=Escoffier|first=Clement|author2=Finnegan|first2=Ken|часть=Chapter 4. Design Principles of Reactive Systems|ссылка часть=https://www.oreilly.com/library/view/reactive-systems-in/9781492091714/ch04.html|заглавие=Reactive Systems in Java|издательство=O'Reilly Media|date=November 2021|isbn=9781492091721}}<cite class="citation book cs1" data-ve-ignore="true" id="CITEREFEscoffierFinnegan2021">Escoffier, Clement; Finnegan, Ken (November 2021). <span class="cs1-lock-registration" title="Free registration required">[https://www.oreilly.com/library/view/reactive-systems-in/9781492091714/ch04.html "Chapter 4. Design Principles of Reactive Systems"]</span>. ''Reactive Systems in Java''. O'Reilly Media. [[Международный стандартный книжный номер|ISBN]]&nbsp;[[Special:BookSources/9781492091721|<bdi>9781492091721</bdi>]].</cite></ref> +Для особенно сложных сервисов, одновременно требующих синхронности и асинхронности, еще одной альтернативой является шаблон проактора. Этот шаблон более сложен, чем реактор, со своими инженерными деталями, но он по-прежнему использует подкомпонент реактора для решения проблемы блокировки ввода-вывода. <ref name="Escoffier 2021"/> == Смотрите также == @@ -99,3 +104,6 @@ [[Категория:Шаблоны проектирования]] [[Категория:Параллельные вычисления]] -[[Категория:Страницы с непроверенными переводами]]</nowiki> +[[Категория:Страницы с непроверенными переводами]] +[[Category:Concurrent computing]] +[[Category:Software design patterns]] +</nowiki> '