интервьюер:Давайте поговорим о сегментированном кластере Redis. Давайте сначала поговорим о Redis Cluster?
интервьюер:Redis Cluser — это официальное кластерное решение, доступное только в Redis 3.x. Что вы знаете об этом?
Кандидат: Ну, почему бы нам не начать с основ?
Кандидат: Говоря о Redis ранее, упомянутый Redis является «единым экземпляром» для хранения всех данных.
Кандидат: 1. Архитектура разделения чтения-записи в режиме master-slave позволяет нескольким подчиненным серверам нести «трафик чтения», но перед лицом «трафика записи» всегда сопротивляется только главный сервер.
Кандидат: 2. «Вертикальное расширение» повышает аппаратные возможности сервера Redis, но обновление до определенного уровня нерентабельно.
Кандидат: Вертикальное расширение означает «большой объем памяти», и «стоимость» сохраняемости Redis будет увеличиваться (Redis обеспечивает сохраняемость RDB, она заполнена, а дочерний процесс форка может использовать слишком много памяти, что приводит к слишком долгой блокировке основного потока. длинная)
Кандидат: Таким образом, "единственный экземпляр" является узким местом
Кандидат: "Вертикальное расширение" не работает, только "горизонтальное расширение".
Кандидат: используйте несколько экземпляров Redis для формирования кластера и «распределяйте» данные по разным экземплярам Redis в соответствии с определенными правилами. Когда данные всех экземпляров Redis в кластере суммируются, данные завершены.
Кандидат: На самом деле, это понятие "распределенный" (: Однако в Redis, кажется, есть еще люди, называемые "шардированный кластер"?
Кандидат: Как мы знаем из первых уст, если вы хотите «распределенное хранилище», вы не можете избежать «распределения» данных (также смысл маршрутизации)
Кандидат: Начнем с Redis Cluster, его «роутинг» делается на стороне клиента (в SDK интегрирована функция роутинг-форвардинга)
Кандидат: Логика распределения данных Redis Cluster включает концепцию «Hash Solt».
Кандидат: Кластер Redis по умолчанию представляет собой кластер с 16384 хеш-слотами, которые выделены для разных экземпляров Redis.
Кандидат: Что касается того, как «разделить», вы можете напрямую поделиться им или вы можете «вручную» установить хэш-слот каждого экземпляра Redis, все зависит от нас.
Кандидат: Важно то, что мы должны разделить все эти 16384, и у нас не может быть остатков!
Кандидат: Когда у клиента есть данные для записи, он сначала вычисляет 16-битное значение ключа по алгоритму CRC16 (что можно понимать как хеширование), а затем по модулю 16384 для полученного значения.
Кандидат: После взятия по модулю естественным образом получается один из хеш-слотов, после чего данные можно вставить в экземпляр Redis, выделенный для хеш-слота.
интервьюер:Тогда возникает вопрос: теперь, когда клиент вычисляет местоположение хеш-слота с помощью хэш-алгоритма, как он узнает, на каком экземпляре Redis находится хэш-слот?
Кандидат: в этом случае каждый экземпляр Redis в кластере будет «распространяться» на другие экземпляры, за которые он отвечает. Таким образом, каждый экземпляр Redis может записывать отношения между «всеми хеш-слотами и экземплярами» (:
Кандидат: с этим отношением сопоставления клиент также будет «кэшировать» копию в своем собственном локальном хранилище, поэтому, естественно, клиент будет знать, с каким экземпляром Redis работать.
интервьюер:Тогда у меня другая проблема.Я также могу добавлять или удалять экземпляры Redis в кластере.Как я могу это исправить?
Кандидат: когда кластер удаляет или добавляет экземпляр Redis, всегда будет происходить изменение отношения хеш-слота, за которое отвечает экземпляр Redis.
Кандидат: измененная информация будет отправлена всему кластеру через сообщения, все экземпляры Redis узнают об изменении, а затем обновят свои сохраненные сопоставления.
Кандидат: Но в это время клиент фактически не в курсе (:
Кандидат: Следовательно, когда клиент запрашивает определенный ключ, он все равно будет запрашивать «исходный» экземпляр Redis. Исходный экземпляр Redis вернет команду «перемещено», сообщая клиенту, что он должен перейти к новому экземпляру Redis, чтобы запросить его.
Кандидат: после того, как клиент получает команду «перемещено», он знает, что нужно запросить новый экземпляр Redis, и обновляет «отношение сопоставления между хэш-слотами кэша и экземплярами».
Кандидат: Подводя итог: После завершения переноса данных клиент получит команду "перемещено" и обновит локальный кеш.
интервьюер:Данные еще не полностью перенесены?
Кандидат: если данные не были полностью перенесены, в это время будет возвращена команда «спросить» клиента. Он также просит клиента запросить новый экземпляр Redis, но в это время клиент не будет обновлять локальный кеш.
интервьюер:понял
интервьюер: Проще говоря, если в экземпляре кластера Redis произойдет изменение, между экземплярами Redis будет «связь».
интервьюер: Таким образом, когда клиент запрашивает, экземпляр Redis всегда будет знать, на каком экземпляре Redis находятся данные, которые клиент хочет запросить.
интервьюер: если миграция была завершена, верните команду «переместить», чтобы сообщить клиенту, в каком экземпляре Redis искать данные, и клиент должен обновить свой кеш (отношение сопоставления).
интервьюер: если он мигрирует, верните команду «ack», чтобы сообщить клиенту, какой экземпляр Redis нужно найти для данных.
Кандидат: Как и ожидалось от тебя...
интервьюер:Итак, вы знаете, почему существует 16384 хеш-слота?
Кандидат: Ну, этот. В этом случае «связь» между экземплярами Redis будет обмениваться «информацией о слотах» друг с другом.Если слотов слишком много (это означает, что сетевой пакет станет больше), и сетевой пакет станет больше, означает ли это «чрезмерная занятость»? пропускная способность сети
Кандидат: Другая часть заключается в том, что автор Redis считает, что кластер не будет превышать 1000 экземпляров при нормальных обстоятельствах.
Кандидат: Тогда берите 16384, то есть данные можно разумно разбросать по разным инстансам в кластере Redis, и пропускная способность не будет лишней при обмене данными
интервьюер:понял
интервьюер:Знаете ли вы, почему «хеш-слот» используется в Redis для разделения данных? вместо последовательного хеширования
Кандидат: Насколько я понимаю, последовательный алгоритм хеширования имеет "хеш-кольцо". Когда клиент запрашивает, он хеширует ключ, чтобы определить его позицию в хэш-кольце, а затем оглядывается назад по часовой стрелке, чтобы найти первый реальный узел.
Кандидат: Преимущество согласованного алгоритма хеширования по сравнению с «традиционным фиксированным модулем» заключается в том, что если экземпляр необходимо добавить или удалить в кластере, будет затронута только небольшая часть данных.
Кандидат: Но если экземпляр добавляется или удаляется в кластере, в соответствии с алгоритмом последовательного хеширования необходимо знать, какая часть данных затронута, и затронутые данные необходимо перенести.
интервьюер:В порядке…
Кандидат: Что касается метода хэш-слота, мы уже можем узнать из вышеизложенного: каждый экземпляр в кластере может получить информацию, относящуюся к слоту.
Кандидат: после того, как клиент выполнит хэш-операцию с ключом, если он обнаружит, что запрошенный экземпляр не имеет соответствующих данных, экземпляр вернет команду «перенаправления», чтобы сообщить клиенту, где запрашивать запрос.
Кандидат: Расширение и сжатие кластера основано на «хеш-слоте» в качестве базовой единицы.В целом «реализация» будет более простой (краткой, эффективной и гибкой). Процесс, вероятно, заключается в перераспределении некоторых слотов, а затем переносе данных в слотах, не затрагивая все данные экземпляра в кластере.
интервьюер:Итак, вы понимаете общий принцип «маршрутизации на стороне сервера»?
Кандидат: Ну, маршрутизация на стороне сервера обычно означает, что существует прокси-уровень, который специально подключается к запросу клиента, а затем перенаправляет его в кластер Redis для обработки.
Кандидат: В прошлом интервью я также упомянул, что Codis сейчас более популярен.
Кандидат: Самая большая разница между ним и Redis Cluster заключается в том, что Redis Cluster напрямую подключается к экземплярам Redis, тогда как клиенты Codis напрямую подключаются к прокси-серверу, который затем распределяется по разным экземплярам Redis для обработки.
Кандидат: Схема маршрутизации ключей в Codis очень похожа на схему Redis Cluster.Codis инициализирует 1024 хеш-слота и распределяет их между разными серверами Redis.
Кандидат: отношения сопоставления между хэш-слотами и экземплярами Redis хранятся и управляются Zookeeper.Прокси-сервер получает последние отношения сопоставления через Codis DashBoard и кэширует их локально.
интервьюер:Итак, каков процесс, если я хочу масштабировать экземпляр Codis Redis?
Кандидат: Проще говоря: добавьте новый экземпляр Redis в кластер, а затем перенесите некоторые данные в новый экземпляр.
Кандидат: Примерный процесс такой: 1. Часть данных определенного Solt в "исходном экземпляре" отправляется в "целевой экземпляр". 2. После того, как «целевой экземпляр» получает данные, он возвращает подтверждение «исходному экземпляру». 3. После того, как «исходный экземпляр» получит подтверждение, он локально удаляет данные, переданные «целевому экземпляру». 4. Повторяйте шаги 1, 2 и 3, пока весь раствор не будет перенесен.
Кандидат: Codis также поддерживает "асинхронную миграцию". На шаге 2 выше, после отправки данных "исходным экземпляром", он продолжает получать клиентские запросы, не дожидаясь, пока "целевой экземпляр" вернет подтверждение.
Кандидат: данные, которые не были перенесены, помечаются как «только для чтения», что не повлияет на согласованность данных. Если есть «операция записи» для переносимых данных, это заставит клиента «повторить попытку» и, наконец, записать в «целевой экземпляр».
Кандидат: Кроме того, для bigkey асинхронная миграция использует метод «разделения инструкций» для миграции. Например, если имеется 10 000 элементов набора, «исходный экземпляр» может отправить 10 000 команд «целевому экземпляру» вместо однократной миграции. всего большого ключа (поскольку большие объекты склонны к блокировке)
интервьюер:понял.
Резюме этой статьи:
-
Причина рождения шардированных кластеров: производительность записи будет сталкиваться с узкими местами при высоком уровне параллелизма && не может масштабироваться бесконечно (нерентабельно).
-
Разделенный кластер: Необходимо решить проблемы "маршрутизации данных" и "миграции данных"
-
Маршрутизация данных кластера Redis:
- Кластер Redis по умолчанию представляет собой кластер с 16384 хеш-слотами, которые выделены для экземпляров в кластере Redis.
- Экземпляры кластера Redis будут «общаться» друг с другом и обмениваться информацией о хеш-слоте, за который они несут ответственность (в конце концов, каждый экземпляр имеет полное отношение сопоставления).
- Когда клиент запрашивает, используйте алгоритм CRC16 для вычисления значения хэша и по модулю 16384, и, естественно, получите хэш-слот, а затем получите соответствующее местоположение экземпляра Redis.
-
Почему 16384 хеш-слота: 16384 может не только сделать данные, выделяемые экземплярами Redis, относительно однородными, но также не повлияет на информацию о слотах взаимодействия между экземплярами Redis и не вызовет серьезных проблем с производительностью сети.
-
Почему Redis Cluster использует хеш-слоты вместо последовательного хеширования?: Реализация хеш-слотов относительно проста и эффективна.При каждом расширении и сжатии необходимо перемещать только данные, соответствующие Solt (слоту), и, как правило, весь экземпляр Redis не перемещается.
-
Маршрутизация данных Codis: по умолчанию выделяется 1024 хеш-слота, и информация, связанная с отображением, будет сохранена в кластере Zookeeper. Прокси кэширует копию локально. При изменении экземпляра кластера Redis DashBoard обновляет информацию о сопоставлении между Zookeeper и Proxy.
-
Миграция данных Redis Cluster и Codis: Redis Cluster поддерживает синхронную миграцию, Codis поддерживает синхронную миграцию и асинхронную миграцию.
- Добавьте новый экземпляр Redis в кластер, а затем перенесите некоторые данные в новый экземпляр (онлайн)
Добро пожаловать в мой публичный аккаунт WeChat【Java3y] Давайте поговорим о Java-интервью, серия онлайн-интервьюеров постоянно обновляется!
Серия [Онлайн-интервьюер-Мобильный терминал]Продолжаем обновлять два раза в неделю!
【Онлайн-интервьюер-компьютер】СерияПродолжаем обновлять два раза в неделю!
Оригинал это не просто! ! Проси три! !