Разные версии, разные ситуации
Версий Redis 3.x, 4.x и 6.x много, и архитектуры разных версий тоже разные, не очень строго спрашивать однопоточная версия или нет.
- Версия 3.x, самая ранняя версия, то есть редис, который все передавали из уст в уста, однопоточный
- простая структура данных
- Избегайте накладных расходов на блокировки и переключения контекста
- Может иметь очень высокий QPS
- Версия 4.х, строго говоря, не однопоточная, а поток, отвечающий за обработку клиентских запросов, однопоточный, но начинает добавлять какие-то многопоточные вещи (асинхронное удаление) .
- Из-за проблемы блокировки одного потока первичный ключ вводит многопоточность.
- После последней версии 6.0.x распрощайтесь с единой нитью во всех впечатлениях и используйте новую многопоточность для решения проблемы.
Как понять единый поток Redis
- Сетевой ввод-вывод Redis и чтение и запись пары ключ-значение выполняются одним потоком. Когда Redis обрабатывает клиентские запросы, он включает получение (чтение сокета), синтаксический анализ, выполнение, возврат содержимого (запись сокета) и т. д. Обработка основного потока, это так называемая «единая нить». Это также основной процесс Redis для предоставления служб хранения ключей и значений извне.
- Но другие функции Redis, такие как сохранение, асинхронное удаление, синхронизация данных кластера и т. д., фактически выполняются дополнительными потоками.
Рабочий поток Redis является однопоточным, но, что касается Redis, он многопоточный;
Основная причина, по которой производительность по-прежнему высока в однопоточную эпоху Redis3.x
- Операции в памяти: все данные Redis хранятся в памяти, поэтому все операции выполняются на уровне памяти, поэтому его производительность относительно высока;
- Простая структура данных: структура данных Redis специально разработана, и в большинстве случаев сложность поиска и работы с этими простыми структурами данных составляет O (1), поэтому производительность относительно высока;
- Мультиплексирование и неблокирующий ввод-вывод: Redis использует функцию мультиплексирования ввода-вывода для мониторинга нескольких клиентов, подключенных к сокету, так что одно потоковое соединение может использоваться для обработки нескольких запросов, уменьшая накладные расходы, вызванные переключением потоков, а также избегая операций ввода-вывода. О блокировка операций
- Избегайте переключения контекста: поскольку это однопоточная модель, избегаются ненужное переключение контекста и многопоточная конкуренция, что экономит время и потребление производительности, вызванное многопоточным переключением, а однопоточность не вызывает взаимоблокировки возникновения проблем.
Первоначальный замысел автора принять один поток
- Его общий смысл заключается в том, что Redis основан на операциях с памятью, поэтому его узким местом может быть память машины или пропускная способность сети, а не ЦП.Поскольку ЦП не является узким местом, то естественно использовать однопоточное решение, а использовать проблемы с многопоточным сравнением. Но в Redis 4.0 стала поддерживаться многопоточность, например удаление фона и другие функции.
- Есть три основные причины, по которым Redis использовал один поток до версии 4.0.
- Использование однопоточной модели упрощает разработку и обслуживание Redis, поскольку однопоточная модель удобна для разработки и отладки;
- Даже если используется однопоточная модель, несколько клиентских запросов обрабатываются одновременно, в основном с использованием мультиплексирования и неблокирующего ввода-вывода;
- Для систем Redis основным узким местом производительности является память или пропускная способность сети, а не ЦП .
Поскольку однопоточность так хороша, зачем постепенно добавлять многопоточность?
проблема с одним потоком
- В обычных условиях команду del можно использовать для быстрого удаления данных, но когда удаленный ключ представляет собой очень большой объект, например набор хэшей, содержащий тысячи элементов, команда del приведет к зависанию основного потока Redis.
- Это самая классическая ошибка эпохи однопоточности redis3.x, головная боль удаления больших ключей, потому что redis однопоточный, del bigKey...
- Поток будет освобожден после долгого ожидания Это похоже на добавление синхронизированной блокировки.Вы представляете, как программа будет заблокирована при высоком параллелизме?
Как решить
-
Использование отложенного удаления может эффективно избежать проблемы зависания Redis.
- Например, когда мне (Redis) нужно удалить большой объем данных, поскольку это однопоточная синхронная операция, это приведет к зависанию службы Redis, поэтому в Redis 4.0 был добавлен новый многопоточный модуль. Конечно, в этой версии многопоточность в основном решает проблему низкой эффективности удаления данных.
Поскольку Redis обрабатывается одним основным потоком, антирез, отец Redis, всегда подчеркивал, что « Ленивый Redis лучше Redis». cpu time slice), отделить от основного потока redis и позволить подпотоку bio обрабатывать его, что значительно сокращает время блокировки основной строки. Таким образом, уменьшается количество удалений, вызывающих проблемы с производительностью и стабильностью.
-
В Redis 4.0 было введено несколько потоков для реализации таких функций, как асинхронное отложенное удаление данных, но по-прежнему существует только один поток для обработки запросов на чтение и запись, поэтому в узком смысле это все еще один поток.
Введение в многопоточность и мультиплексирование ввода-вывода в redis6
- Основным узким местом производительности Redis является пропускная способность памяти или сети, а не ЦП.
- Наконец, узкое место Redis можно изначально определить как: сетевой ввод-вывод
- Пять моделей ввода-вывода в сетевом программировании Unix
- Блокировка ввода-вывода - Блокировка ввода-вывода
- NoneBlocking IO - неблокирующий ввод-вывод
- Мультиплексирование ввода-вывода - мультиплексирование ввода-вывода
- Это своего рода модель ввода-вывода, то есть классический режим проектирования Reactor, мультиплексирование ввода-вывода, проще говоря, путем отслеживания событий чтения и записи файла, а затем уведомления потока о выполнении связанных операций, чтобы убедиться, что неблокирующие механизмы ввода-вывода Redis могут обеспечить плавное завершение выполнения.
- Multi-way относится к множественным соединениям сокетов.
- Мультиплексирование относится к мультиплексированию потока. Существует три основных технологии мультиплексирования: select, poll, epoll.
- epoll — это новейшая и лучшая технология мультиплексирования. Использование технологии множественного мультиплексирования ввода-вывода позволяет одному потоку эффективно обрабатывать несколько запросов на подключение (минимизируя затраты времени на сетевой ввод-вывод) , а Redis очень быстро оперирует данными в памяти (операции в памяти не станут здесь узким местом производительности), в основном два вышеупомянутых момента делают Redis высокой пропускной способностью.
- ввод-вывод, управляемый сигналом - ввод-вывод, управляемый сигналом
- асинхронный ввод-вывод - асинхронный ввод-вывод
- краткое описание
- Рабочий поток Redis является однопоточным, но, что касается Redis, он многопоточный;
- Чтение и запись самого ввода-вывода блокируется, например, когда в сокете есть данные, Redis сначала скопирует данные из пространства режима ядра в пространство пользовательского режима, вызвав, а затем передаст их Redis для Процесс копирования блокируется Да, чем больше объем данных, тем больше времени требуется для копирования, и все эти операции основаны на одном потоке.
- В Redis 6.0 добавлена новая многопоточная функция для повышения производительности операций ввода-вывода при чтении и записи. Ее основная идея реализации состоит в том, чтобы разделить задачи чтения и записи ввода-вывода основного потока на группу независимых потоков для выполнение, так что Чтение и запись нескольких сокетов могут быть распараллелены.Использование технологии множественного мультиплексирования ввода-вывода позволяет одному потоку эффективно обрабатывать несколько запросов на подключение (минимизировать время, затрачиваемое на сетевой ввод-вывод), и максимальное время- потребление Socket read , анализ запроса и запись передаются на аутсорсинг отдельно, а выполнение оставшейся команды по-прежнему выполняется последовательно основным потоком и взаимодействует с данными в памяти.
- Объединяя приведенный выше рисунок, мы видим, что операция сетевого ввода-вывода становится многопоточной, а другие основные части по-прежнему ориентированы на многопотоковое исполнение, что является хорошим компромиссом.
Включает ли Redis 6.0 многопоточность по умолчанию?
- Redis помещает все данные в память, а время отклика памяти составляет около 100 наносекунд.Для небольших пакетов данных сервер Redis может обрабатывать QPS от 8 Вт до 10 Вт, что также является пределом обработки Redis.Для 80% компаний, однопоточного Redis достаточно.
- В Redis6.0 механизм многопоточности по умолчанию отключен, если вам нужно использовать функцию многопоточности, вам нужно выполнить две настройки в redis.conf
- Установите для элемента конфигурации io-thread-do-reads значение yes, чтобы запустить многопоточность.
- Установите количество потоков. Что касается настройки количества потоков, официальное предложение состоит в том, что если это 4-ядерный процессор, рекомендуется установить количество потоков на 2 или 3. Если это 8-ядерный процессор, рекомендуется установите количество потоков равным 6. Количество потоков должно быть меньше, чем количество ядер машины.Больше не всегда лучше.
Подведем итог
- Redis превосходен в своем дебюте, основываясь на таких функциях, как работа с памятью, простая структура данных, мультиплексирование и неблокирующий ввод-вывод, а также избегая ненужного переключения контекста потока, он по-прежнему быстр в однопоточной среде;
- Однако удаление ключа больших данных по-прежнему происходит с большой задержкой, поэтому в Redis 4.0 представлены такие команды, как многопоточная асинхронная отвязка ключа/очистки, которые в основном используются для асинхронного удаления данных Redis;
- В Redis 6.0 введено многопоточное чтение и запись ввода-вывода, чтобы можно было обрабатывать больше задач более эффективно.Redis просто превращает чтение и запись ввода-вывода в многопоточность, а выполнение команд по-прежнему выполняется основной поток выполняется последовательно, поэтому работа Redis в многопоточном режиме не вызовет проблем с безопасностью потоков.
- Будь то первоначальный однопоточный дизайн Redis или многопоточный дизайн, противоречащий исходному дизайну, есть только одна цель: сделать Redis все быстрее и быстрее.
- Так что Редис все еще не изменился, он все тот же мальчик, каким был раньше, O(∩_∩)О, ха-ха~