Минимальная конфигурация Redis Cluster

На самом деле я использую конфигурацию Redis Master-Slave с HAProxy для Wordpress, чтобы иметь высокую доступность. Эта конфигурация хороша и работает идеально (я могу удалить любой сервер для обслуживания без простоев). Проблема этой конфигурации заключается в том, что только один сервер Redis получает весь трафик, а остальные просто ждут, если этот сервер умрет, поэтому на веб-странице с очень высокой нагрузкой может возникнуть проблема, и добавление дополнительных серверов не является решением, потому что всегда только один будет хозяином.

Имея это в виду, я думаю, могу ли я просто использовать Redis Cluster, чтобы разрешить чтение/запись на всех узлах, но я не совсем уверен, будет ли он работать в моей настройке.

Моя настройка в большинстве случаев ограничена тремя узлами, и я читал в некоторых местах, что минимальная настройка кластера Redis — это три узла, но рекомендуется шесть. Это рационально, потому что эта установка позволяет иметь узлы Slaves, которые станут Masters, если ее Master умрет, и тогда все данные будут сохранены, но что произойдет, если данные не заботятся? Я имею в виду, что в моих настройках данные представляют собой просто кэшированные объекты, поэтому, если они не существуют, просто создайте их снова, поэтому:

  • Данные будут потеряны (неважно), а другие узлы снова получат объекты от клиентов, чтобы обслуживать их в более поздних запросах (например, при сбросе данных).
  • Узлы ответят, что данных не существует, и откажутся от кэширования, потому что объект должен находиться на другом узле, который мертв.

Кто-то это знает?

Спасибо!!


person Daniel Carrasco    schedule 22.06.2018    source источник


Ответы (1)


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

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

Это указано в спецификации:

Ключевое пространство разделено на 16384 слота... один хэш-слот будет обслуживаться одним узлом...

Базовый алгоритм, используемый для сопоставления ключей с хеш-слотами, следующий:

HASH_SLOT = CRC16 (ключ) мод 16384

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

person neuront    schedule 03.08.2018
comment
Здравствуйте, спасибо за ответ, но я его уже читал и знаю. Вот почему существуют рабы. Я спрашиваю, может ли информация о мертвом узле быть перезаписана на живых узлах (кэш, если он не существует, создается), или команда не будет выполнена. Например: node1: A-D, node2: E-H, node3: I-L. Node2 умирает, и данные между E и H не работают (как и ожидалось). Клиент пытается прочитать F и терпит неудачу, затем он снова пытается создать F. F будет создан на другом живом узле или команда записи тоже не удастся, потому что предполагается, что она будет на узле2. В любом случае попробую протестировать. - person Daniel Carrasco; 22.08.2018