Ответ
Redis поддерживает как вертикальное, так и горизонтальное масштабирование. Основные подходы к горизонтальному масштабированию (увеличению количества серверов) включают:
-
Репликация (Primary-Replica)
- Что это: Создание копий (реплик) основного узла (primary). Все операции записи идут на primary, а затем асинхронно копируются на реплики.
- Зачем: Масштабирование операций чтения (read scaling) и обеспечение высокой доступности (high availability). Если primary узел падает, одна из реплик может быть повышена до нового primary.
- Ограничение: Не решает проблему масштабирования записи или нехватки памяти для хранения всего набора данных.
-
Redis Sentinel
- Что это: Система мониторинга и автоматического аварийного переключения (failover) для конфигураций с репликацией.
- Зачем: Обеспечивает высокую доступность. Sentinel следит за состоянием primary узла и, в случае его отказа, автоматически выбирает и повышает реплику до нового primary, перенаправляя клиентов.
-
Redis Cluster (Шардирование)
- Что это: Встроенное решение для горизонтального распределения данных по нескольким узлам (шардам). Набор данных делится на 16384 хеш-слота, которые распределяются между узлами кластера.
- Зачем: Масштабирование операций записи (write scaling) и объема хранимых данных. Позволяет хранить датасет, который не помещается в память одного сервера.
- Пример создания кластера:
# Создать кластер из 6 узлов (3 мастера и 3 реплики) redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1
-
Шардирование на стороне клиента
- Что это: Логика распределения ключей по разным инстансам Redis реализуется в коде приложения.
- Зачем: Дает полный контроль над распределением данных, но усложняет приложение и требует ручного управления при добавлении/удалении узлов.
Ответ 18+ 🔞
А, вот ты про масштабирование Redis спрашиваешь? Ну, это, блядь, целая опера, как выкрутиться, когда один сервер уже на пределе и орет "мама, не могу!".
Смотри, вариантов-то, внатуре, несколько, и каждый со своей, блядь, изюминкой и подвохом.
1. Репликация (Primary-Replica) Ну, это классика, ёпта. Берешь один главный узел (primary) и делаешь ему клонов — реплик. Вся запись идет только в primary, а оттуда данные, как шлюхи с зарплаты, разбегаются по репликам.
- Нахуя это надо? Чтоб читать могли все, а писал один. И если primary, сука, накроется — можно одну из реплик сделать новой главной. Высокая доступность, называется.
- Подвох: Запись всё равно одна, и если данных дохуя — они все равно на всех узлах, память не экономится. Масштабирование записи — ноль.
2. Redis Sentinel Это такая система, которая сидит, курит и смотрит на твой primary. Как только он, мудак, откинулся — Sentinel берет реплику, тычет в нее пальцем: "Ты теперь главный, блядь!", и всем клиентам кричит: "Идите сюда, новый босс!".
- Нахуя это надо? Чтобы не бегать ночью с криками "ой, всё пропало!". Автоматический failover, ебать его в сраку.
3. Redis Cluster (Шардирование) Вот это уже серьёзная движуха, когда данные раскидываются по куче серверов. Всё делится на 16384 хеш-слота (да, вот такая, блядь, магическая цифра), и эти слоты раскидываются по узлам.
- Нахуя это надо? Чтобы и писать могли все, и памяти хватало. Один сервер не тянет? Заведем три! Каждый хранит свою часть данных.
- Как это выглядит:
# Создаем кластер из 6 узлов (3 мастера и 3 реплики) redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1И понеслась, блядь. Данные сами распределятся, кластер будет рулить.
4. Шардирование на стороне клиента А это, сука, для мазохистов и гиков. Ты сам, в своем коде, решаешь, какой ключ на какой сервер Redis летит.
- Нахуя это надо? Полный контроль, можно выебистику какую-нибудь придумать. Но, бля, это ж твоя головная боль: добавь новый узел — пересчитывай всё, выкинь узел — опять пиздец. Сам себе злой буратино.
Короче, выбор зависит от того, что у тебя болит: читают много, пишут много или просто данных овердохуища. А может, всё сразу — тогда welcome в кластер, дружок.