Отчет о тестировании производительности
Проверьте отчет о тестировании производительности Ali Redis следующим образом, который может достигать сотен тысяч и миллионов запросов в секунду (на данный момент игнорируя оптимизацию Ali Redis), давайте проанализируем, как Redis делает это, исходя из дизайна и реализации Redis.
Дизайн и реализация Redis
На самом деле, Redis в основном отвечает требованиям производительности такой эффективной пропускной способности по трем аспектам.
- эффективные структуры данных
- Мультиплексная модель ввода-вывода
- механизм события
эффективные структуры данных
Несколько эффективных структур данных, поддерживаемых Redis: string (строка), hash (хэш), list (список), set (коллекция), zset (упорядоченная коллекция).
Базовые методы кодирования вышеупомянутых открытых структур данных оптимизированы по-разному, я не буду вдаваться в подробности, это не тема этой статьи.
Мультиплексная модель ввода-вывода
Предполагая, что в определенное время с сервером Redis установлено 10 000 длинных соединений, метод блокировки ввода-вывода состоит в том, чтобы установить поток для каждого соединения для обработки, тогда требуется 10 000 потоков, и, согласно нашему опыту, интенсивный ввод-вывод Мы обычно устанавливаем количество потоков = 2 * количество процессоров + 1 для операций с интенсивным использованием процессора.Для операций с интенсивным использованием процессора мы обычно устанавливаем количество потоков = количество процессоров + 1. Конечно, в различных книги или онлайн, которые могут быть рассчитаны более подходящим и точным.Количество потоков, но результат часто является относительно небольшой величиной, например, блокировка ввода-вывода, которая также создает тысячи потоков, система не может выдержать такую нагрузку, и это труднее достичь эффективной пропускной способности и обслуживания.
Способ мультиплексирования модели ввода-вывода состоит в том, чтобы использовать поток для помещения этих 10 000 успешно установленных ссылок в event_poll одну за другой, и event_poll зарегистрирует функцию обратного вызова для этих 10 000 долгосрочных соединений. Установление прошло успешно, чтение данных завершено и т.д.), оно будет записано в готовую очередь rdlist event_poll через callback-функцию, чтобы этот единственный поток мог получить требуемые данные, прочитав rdlist
Следует отметить, что в дополнение к асинхронному вводу-выводу, другие модели ввода-вывода фактически могут быть классифицированы как блокирующие модели ввода-вывода.Разница в том, что когда блокирующая модель ввода-вывода считывает данные на первом этапе, если в это время данные не готовы и должны быть заблокированы.После готовности данных на втором этапе данные необходимо скопировать из состояния ядра в состояние пользователя.Этот шаг также блокируется. Модель мультиплексирования ввода-вывода не блокируется на первом этапе, а только блокируется на втором этапе.
Таким образом, один или несколько потоков могут использоваться для обработки большого количества соединений, что значительно увеличивает пропускную способность.
механизм события
Клиент redis устанавливает соединение с сервером redis, отправляет команды, а сервер redis отвечает на команды через механизм событий, как показано на следующем рисунке (откуда-то в Интернете...)
- Во-первых, работает сервер Redis, и событие AE_READABLE прослушивающего сокета находится в состоянии прослушивания.обработчик ответа соединенияРабота,
- Клиент устанавливает соединение с сервером redis, а прослушивающий сокет генерирует событие AE_READABLE.Когда мультиплексор ввода-вывода отслеживает его готовность, он помещает событие в очередь, а диспетчер файловых событий получает доставку события в очереди. Вобработчик ответа соединенияОбработка работы, подтверждает, что клиент успешно установил соединение, и в то же время помещает событие AE_READABLE клиентского сокета в очередь, а диспетчер файловых событий получает события в очереди для доставки.ассоциация обработчика запроса команды
- Клиент отправляет запрос установки значения ключа, событие AE_READABLE клиентского сокета, когда мультиплексор ввода-вывода прослушивает его готовность, он помещает событие в очередь, а диспетчер файловых событий получает события в очереди и доставляет их вассоциация обработчика запроса командыиметь дело с
- ассоциация обработчика запроса командыПосле завершения обработки необходимо отреагировать на завершение операции клиента, в это время событие AE_WRITEABLE сокета будет запушено в очередь, а событие в очереди будет получено файловым диспетчером событий .процессор восстановления командОбработать, вернуть результат операции и выпустить событие AE_WRITEABLE ипроцессор восстановления командассоциация
режим реактора
В целом можно сказать, что рабочий режим Redis заключается в том, что режим реактора взаимодействует с очередью, использует поток serverAccept для обработки соединения запроса на установление и использует модель мультиплексирования ввода-вывода, чтобы позволить ядру прослушивать эти сокеты. После того, как некоторые сокеты прочитаны и записаны После того, как событие готово, соответствующее событие помещается в очередь, после чего работает worker, а файловый диспетчер событий получает от него событие и передает его соответствующему процессору для выполнения. выполнение события завершено, файловый диспетчер событий будет удален из очереди Получить следующее событие для обработки
По аналогии в netty мы вообще ставим bossGroup и workerGroup.По умолчанию bossGroup равен 1, а workerGroup=2*количество процессоров, чтобы несколько потоков могли обрабатывать события read и write ready, но более трудоемких операций быть не может .Если есть, его нужно поместить в пул потоков, иначе его пропускная способность будет снижена. В Redis мы видим, что значение обоих равно 1