(В этой статье эти две модели описываются с точки зрения Java, поэтому я говорю только о потоках). Прежде чем представить эти две модели, давайте представим понятия синхронизации, асинхронности, блокировки и неблокировки в сценарии ввода-вывода. Все мы знаем, что наша программа работает в операционной системе. Между нашей программой и серверным оборудованием находится операционная система. Как правило, наш сервер представляет собой систему Linux. По соображениям безопасности системы Linux делятся на:Пользовательский режим и режим ядра.
Операции ввода/вывода должны проходить через два процесса: 1, устройство хранения данных считывается в буфер ядра 2, читать данные из буфера ядра в пространство пользователя
Операция 1 намного медленнее операции 2, потому что такие операции, как адресация диска, выполняются медленнее.
Затем мы обычно ссылаемся на блокирующий ввод-вывод и неблокирующий ввод-вывод в сценариях ввода-вывода, имея в виду, заблокирована ли операция 1, то есть она немедленно вернет значение состояния или будет ждать устройства хранения. данные для чтения в кэш ядра После возврата требуемых данных.
А синхронный ввод-вывод и асинхронный ввод-вывод, о которых говорится в будние дни, относятся к тому, будет ли блокироваться операция 2.
Модель реактора
Это синхронная неблокирующая модель. Также известна как модель Dispatcher. Подумайте, если нам нужно построить поток для обработки этого соединения для каждого соединения, и соединение не должно быть заполнено несколькими потоками, тогда некоторые люди могут сказать, что пул потоков должен быть подключен к пулу потоков. Но это может решить только проблему количества потоков, но другая проблема это проблема использования ресурсов.Когда соединение не разрывается, когда соединение временно не запрашивается, ваш поток должен блокироваться в ожидании запроса? этот поток все еще занят другими, и этот поток не используется, когда у других соединений есть запросы, что является пустой тратой ресурсов и низкой производительностью.
Итак, как решить эту проблему?
Конечно, есть и другие связи при повторном запросе процесса накрутки. Эта вещь заключалась в том, чтобы найти «человека», который будет выполнять бизнес-операции обработки потоков, то есть должен иметь «человека» для управления всеми соединениями, он нашел запрос, который связан с выделением потоков для обработки бизнеса. .
Это называется моделью реактора. Упомянутого выше «человека» называют реактором, что в переводе с китайского означает реактор, то есть это человек, который осуществляет мониторинг, если возникнет ситуация, он ответит и распределит задачи по бизнес-потокам для обработки.
Может быть один поток Reactor, многопоточность с одним Reactor, многопоточность с несколькими Reactor ###Однопоточный реактор с одним потоком
select всегда будет отслеживать событие. После поступления события оно будет передано диспетчеру. Если запрошенное событие установлено, будет назначен акцептор, а акцептор создаст обработчик для обработки последующих операций. Если запрошенное событие не установлен, предыдущий соответствующий обработчик будет назначен для обработки последующих дел.
Преимущество этой ситуации в простоте. . . Нет проблем, вызванных многопоточным соперничеством за общие ресурсы. Недостаток в том, что он однопоточный, что тратит впустую несколько ЦП, и только один обработчик может обрабатывать его одновременно, а остальным приходится ждать.
Звучит бесполезно Да, большинство сценариев не подходят, но Redis используется именно так. Потому что он обрабатывает бизнес достаточно быстро. Так что это подходит для использования, когда бизнес-процессы выполняются очень быстро. ###Многопоточность с одним реактором
Этот режим и вышеупомянутые разницы состоят в том, что конкретная реализация услуг не обрабатывается обработчиком. Обработчик отвечает только за данные чтения, и данные даны бизнес-темы, а затем бизнес-поток завершен, и результат Дано обработчику, обработчик отправить клиенту. . Преимущество этого режима заключается в полном использовании ЦП, подходящей для несчастья обработки бизнеса. Недостатки - это проблема изменения ресурсов между многопоточными ресурсами, и только один реактор может контролировать и отвечать, когда запрос слишком велик, реактор может стать узким местом производительности. ### 多 реактор многопотативный Настолько более реактор многопоток.
Следовательно, это решение эквивалентно шунтированию основного Reactor, только новое соединение принимается основным Reactor, а старые соединения распределяются на подчиненный Reactor для ответа.
Модель проактора
Это асинхронная неблокирующая модель. Китайский перевод для фронтальной камеры. . Я не знаю, что это такое, это можно назвать активным устройством. То есть нам не нужно ждать, пока данные ввода-вывода будут готовы, то есть кэш ядра прочитал данные в пространство пользователя. Все это делает ядро, после того как данные готовы, Proactor уведомляется, а затем Proactor вызывает соответствующий обработчик для бизнес-обработки. По сравнению с Reactor стоимость обхода селектора очереди уведомлений о событиях устранена.
Поэтому теоретически проактором более эффективен, чем реактор, но Linux на самом деле не реализует модель Proactor, но EPOLL имитирует модель Proactor.
Пожалуйста, поправьте меня, если я ошибаюсь! Личный публичный аккаунт: стратегия прокачки да