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

Каково это, все чиновники, пожалуйста, спуститесь с Сяо Лаем:

Легенда: интеллект-карта

Реакторный режим

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

1. Традиционная блокирующая модель ввода-вывода

Прежде чем говорить о модели реактора, необходимо упомянуть метод обработки традиционной блокирующей модели ИО.

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

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

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

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

2. Модель псевдоасинхронного ввода-вывода

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

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

Это решение позволяет избежать проблемы исчерпания ресурсов потока, вызванной созданием потока для каждого запроса. Но нижний уровень по-прежнему является моделью синхронной блокировки. Если все потоки в пуле потоков заблокированы, он не сможет отвечать на дополнительные запросы. Поэтому этот режим будет ограничивать максимальное количество подключений и не сможет кардинально решить проблему.

Давайте продолжим использовать ресторан выше в качестве примера.После того, как владелец ресторана работал в течение определенного периода времени, количество клиентов увеличилось, и первоначальные пять официантов в магазине не могут справиться с этим один на один. один. Таким образом, босс использует пул потоков из 5 человек. Официанты обслуживают одного клиента сразу после обслуживания другого.

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

Итак, как решить эту проблему? Не волнуйтесь, скоро появится режим Reactor.

3. Шаблоны проектирования реакторов

Основная идея дизайна режима Reactor основана на модели мультиплексирования ввода-вывода.

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

Что это обозначает? Владелец ресторана также заметил проблему медленных заказов клиентов, поэтому проявил смелый подход и оставил только одного официанта. Когда клиент заказывает, официант идет развлекать других гостей, а после того, как клиент заказывает еду, он напрямую вызывает официанта для обслуживания. Здесь клиенты и серверы можно рассматривать как несколько соединений и один поток соответственно. Официант остановился у одного клиента, а когда другой клиент сделал заказ, она сразу же пошла обслуживать других клиентов.

Поняв идею конструкции реактора, давайте посмотрим на реализацию сегодняшнего главного героя с одним потоком одного реактора:

Reactor отслеживает события клиентских запросов через программу мультиплексирования ввода-вывода и распределяет их через диспетчер задач после получения события.

Для события запроса на установление соединения оно обрабатывается через акцептор, и устанавливается соответствующий обработчик, ответственный за последующую бизнес-обработку.

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

Весь процесс выполняется в одном потоке.

эра одного потока

После понимания паттерна Reactor у вас может возникнуть вопрос, какое это имеет отношение к нашей сегодняшней теме. Возможно, вы не знаете, что Redis реализован на основе однопоточного режима Reactor.

После того, как мультиплексор ввода/вывода получает запрос пользователя, он помещает его в очередь и передает файловому диспетчеру. Для последующих операций, как видно из однопоточной реализации реактора, весь процесс завершается в одном потоке, поэтому Redis называется однопоточной операцией.

Для однопоточного Redis он основан на памяти, а сложность времени выполнения команды невелика, поэтому скорость чтения и записи очень высока.

эра многопоточности

Многопоточность была представлена в версии Redis6. Выше упоминалось, что однопоточная обработка Redis имеет очень высокую скорость, так зачем вводить многопоточность? Где находится узкое место одиночного потока?

Давайте сначала рассмотрим второй вопрос: в Redis узкое место производительности одного потока в основном связано с сетевыми операциями ввода-вывода. То есть большая часть процессорного времени потребляется во время выполнения системных вызовов чтения/записи в сети чтения/записи. Если вы хотите удалить несколько больших пар ключ-значение, вы не можете удалить их за короткое время, тогда для одного потока последующие операции будут заблокированы.

Вспомним упомянутый выше однопоточный метод обработки в режиме Reactor. Для событий, не связанных с подключением, Reactor вызовет соответствующий обработчик для завершения процесса чтения->обработки бизнеса->записи, что означает, что этот шаг вызовет узкие места в производительности.

Redis предназначен для обработки чтения и записи сетевых данных и анализа протоколов с помощью многопоточности.Для выполнения команд по-прежнему используются однопоточные операции.

Суммировать

Реакторный режим

Традиционная модель блокирующего ввода-вывода распределяет клиентские и серверные потоки 1:1, что не способствует расширению.
Псевдоасинхронная модель ввода-вывода использует метод пула потоков, но нижний уровень по-прежнему использует метод синхронной блокировки, который ограничивает максимальное количество подключений.
Reactor отслеживает события клиентских запросов через мультиплексоры ввода-вывода и распределяет их через диспетчеры задач.

эра одного потока

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

эра многопоточности

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

Об авторе

Автор: Всем привет, меня зовут Лайу, я занимаюсь перемещением кирпичей BAT. На пути от небольшой компании к большому заводу я многое приобрел. Я хочу поделиться этим опытом с теми, кто в этом нуждается, поэтому я создал публичный аккаунт».Трудовые мигранты в ИТ-секторе". Регулярные обновления, надеемся помочь вам.