tgoop.com/java_fillthegaps/612
Last Update:
Почему однопоточный 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. На конференциях особо не светились, громких кейсов внедрения пока нет.
Энтерпрайз мир тяжело принимает новые технологии. Плюс не всегда нужно лучшее решение, иногда достаточно хорошего😊
BY Java: fill the gaps
Share with your friend now:
tgoop.com/java_fillthegaps/612