Redis sentinel vs кластеризация


Я понимаю, что Redis sentinel-это способ настройки HA (высокой доступности) среди нескольких экземпляров redis. Как я вижу, есть один экземпляр redis, который активно обслуживает запросы клиентов в любой момент времени. Есть два дополнительных сервера в режиме ожидания (ожидание сбоя, так что один из них может быть в действии снова).

  • это пустая трата ресурсов?
  • есть ли лучший способ использования полного использования имеющихся ресурсов?
  • Это Редис кластеризация альтернативы Redis sentinel?

Я уже искал документацию redis для страж и кластеризации, может кто-нибудь, имеющий опыт объясните пожалуйста.

обновление

ОК. В моем реальном сценарии развертывания у меня есть два сервера, выделенные для redis. У меня есть еще один сервер, на котором работает мой сервер Jboss. Приложение работает в JBoss настроено подключение к главному серверу redis (M).

сценарий отработки отказа

В идеале, я думаю, что при сбое главного сервера кэша (либо процесс Redis идет вниз, либо сбой машины) приложение в Jboss должно подключиться к ведомому серверу кэша. Как я могу настроить серверы redis для достижения этой цели?

+--------+          +--------+
| Master  |---------| Slave  |
|         |         |        |
+--------+          +--------+

Configuration: quorum = 1
4 63

4 ответа:

во-первых, давайте поговорим sentinel.

Sentinel управляет отказоустойчивостью, он не настраивает Redis для HA. Это важное различие. Во - вторых, схема, которую вы опубликовали, на самом деле является плохой настройкой-вы не хотите запускать Sentinel на том же узле, что и узлы Redis, которыми он управляет. Когда вы теряете этого хозяина, вы теряете и то, и другое.

Как "это пустая трата ресурсов?"это зависит от вашего варианта использования. Вам не нужно три узла Redis в этой настройке, вам нужно только два. Три увеличивает ваш избыточность, но не требуется. Если вам нужна дополнительная избыточность, то это не пустая трата ресурсов. Если вам не нужна избыточность, вы просто запускаете один экземпляр Redis и называете его хорошим - поскольку запуск большего количества будет "потрачен впустую".

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

Что касается "Есть ли лучший способ использования полного использования доступных ресурсов?"мы не можем ответить на этот вопрос, поскольку он слишком зависим по вашему конкретному сценарию и коду. Тем не менее, если объем данных для хранения "мал", а скорость команд не слишком высока, то помните, что вам не нужно выделять хост для Redis.

теперь для " Является ли кластеризация Redis альтернативой Redis sentinel?". Это действительно полностью зависит от вашего варианта использования. Redis Cluster не является решением HA - это решение с несколькими записывающими устройствами/больше, чем ОЗУ. Если ваша цель просто ха, то это, вероятно, не будет подходящим для вас. Redis Cluster поставляется с ограничения, особенно вокруг операций с несколькими ключами, поэтому это не обязательно простая операция "просто использовать кластер".

Если вы считаете, что наличие трех хостов, работающих под управлением Redis (и трех работающих sentinel), является расточительным, вы, вероятно, будете удерживать кластер еще больше, поскольку он требует больше ресурсов.

вопросы, которые вы задали, наверное, слишком широкой и, чтобы выжить, как написано. Если у вас есть конкретный случай / проблема, которую вы разрабатываете, пожалуйста, обновите поэтому мы можем предоставить конкретную помощь и информацию.

обновление для конкретики:

для правильного управления отказоустойчивостью в вашем сценарии я бы пошел с 3 sentinels, один из которых работает на вашем сервере JBoss. Если у вас есть 3 узла JBoss, то идите с одним на каждом. У меня был бы модуль Redis (master+slave) на отдельных узлах, и пусть sentinel управляет отказоустойчивостью.

оттуда это вопрос подключения JBoss/Jedis для использования Sentinel для его информации и подключения управление. Поскольку я не использую их, быстрый поиск показывает, что у Jedis есть поддержка для него, вам просто нужно правильно настроить его. Некоторые примеры, которые я нашел, находятся в Ищу пример джедаев с Sentinel и https://github.com/xetorthio/jedis/issues/725 о которых говорят JedisSentinelPool находясь на маршруте для использования в бассейне.

когда Sentinel выполняет отказоустойчивость, клиенты будут отключены, а Jedis (должен?) обработайте переподключение, спросив стражи, кто сейчас хозяин.

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

во-первых, сказать, что Sentinel обеспечивает отказоустойчивость без HA, неверно. При отработке отказа у вас есть HA с дополнительным преимуществом репликации состояния приложения. Различие заключается в том, что вы можете иметь HA в системе без репликации (это HA, но это не отказоустойчиво).

Это не прямой ответ на ваш вопрос, но думаю, что это полезная информация для новичков Redis, таких как я. Также этот вопрос появляется в качестве первой ссылки в google при поиске "Redis cluster vs sentinel".

Redis Sentinel-это имя решения Redis high availability... Он не имеет ничего общего с кластером Redis и предназначен для использования люди, которым не нужен Redis Cluster, а просто способ выполнения автоматический выход из строя, когда мастер экземпляр не работает правильно.

взято с Redis Sentinel design draft 1.3

Это не очевидно, когда вы новичок в Redis и реализуете решение для отработки отказа. Официальная документация о страж и кластеризации doens не сравнивают друг с другом, поэтому трудно выбрать правильный путь, не читая тонны документации.

Это мое понимание после того, как я ударил головой по документации.

Sentinel-это своего рода горячее резервное решение, в котором ведомые устройства реплицируются и готовы к продвижению в любое время. Однако он не будет поддерживать любые записи нескольких узлов. Ведомые устройства могут быть настроены для операций чтения. Это не правда, что Sentinel не будет предоставлять HA, он имеет все функции типичного активно-пассивного кластера ( хотя это не правильный термин для использования здесь ).

кластер Redis для более или менее распределенное решение, работающее поверх осколков. Каждый фрагмент данных распределяется между ведущими и ведомыми узлами. Минимальный коэффициент репликации 2 гарантирует, что у вас есть два активных фрагмента, доступных через master и slaves. Если вы знаете осколки в Mongo или Elasticsearch, это будет легко догнать.