Почему однопоточный Redis такой быстрый?

В прошлом посте предложила вам задачку: сравнить Redis и велосипедик на основе ConcurrentHashMap + Spring MVC.

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

Как однопоточный Redis справляется с нагрузкой?

Секрет в том, как он работает с запросами. Есть 2 основные модели:

🌊 Каждый запрос обрабатывается в своем потоке (thread per request).

Такая модель используется, когда мы подключаем Spring MVC. Наш велосипедик тоже на ней работает.

У каждого потока свой стэк, переменные изолированы. Код легко писать, читать и дебажить. Идеальный вариант для сложных энтерпрайзных задач!

Но есть недостаток - число запросов в работе ограничено числом потоков в ОС. Обычно это несколько тысяч.

Из-за этой модели наш велосипед и проигрывает:
😒 Миллионы запросов просто не дойдут до ConcurrentHashMap, максимум несколько тысяч.
😒 Прочитать и записать в мэп - простые операции. Отправлять таких малышей в отдельный поток - как забивать краном гвозди. Очень большие накладные расходы на каждый запрос.

Redis использует другую модель:

🏃 EventLoop - малое число потоков бешено переключаются между запросами. В работу можно взять миллионы запросов!

Такая схема используется в реактивных серверах типа Netty, поддерживает многопоточность в JS и питоне.

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

❓ Можно ли взять лучшее из двух миров? Использовать многопоточность вместе с EventLoop?

Можно! Один поток Redis не использует все доступные ядра процессора, поэтому добавить десяток потоков - вполне рабочая идея.

Такую схему используют KeyDB и DragonflyDB. На сайте публикуют бенчмарки, где они обходят Redis в 5-25 раз. 25 раз звучит слишком мощно, но про 5-10 раз можно верить.

❓ Почему чаще используется Redis, а не более быстрые альтернативы?

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

KeyDB и DragonflyDB - свежие БД пирожки. Один вышел в 19 году, другой в 22. На конференциях особо не светились, громких кейсов внедрения пока нет.

Энтерпрайз мир тяжело принимает новые технологии. Плюс не всегда нужно лучшее решение, иногда достаточно хорошего😊