Есть ли потеря функциональности, если я использую балансировщик нагрузки, который не взаимодействует с zookeeper в solrcloud?

В настройке облака solr есть 8 узлов solr и 3 узла zookeeper. Существует один балансировщик нагрузки, который получает все запросы индексации и поиска и распределяет их по этим 8 узлам solr в облаке solr. Перед отправкой запроса solr конкретному узлу solr он сначала проверяет, активна ли конечная точка службы. Только если он активен, он отправляет запрос на этот конкретный узел solr. Zookeeper занимается выборами лидеров в шарде. В этой настройке zookeeper не обрабатывает распределение запросов. Это плохо для распределенных запросов? Какие еще функции, предлагаемые solrcloud, упускаются из-за того, что балансировщик нагрузки выполняет работу по распределению запросов.

Обратите внимание, что балансировщик нагрузки необходим, потому что есть разные клиенты (Java, Ruby, JavaScript), обращающиеся к службе solr. Только SolrJ имеет возможность общаться с zookeeper с помощью класса CloudSolrServer). Кроме того, это помогает масштабировать узлы zookeeper без изменения каких-либо настроек со стороны клиента.


load-balancing solr solrcloud
person genonymous    schedule 08.02.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

SolrJ CloudSolrClient имеет несколько преимуществ:

  1. Автообнаружение узлов: он всегда знает, какие узлы находятся в кластере, используя тот же механизм ZK, который использует сам кластер SolrCloud.

  2. Маршрутизация, зависящая от запроса: хотя любой запрос может перейти к любому узлу в кластере SolrCloud, многие из них приведут к простому прокси-серверу для фактического узла, который должен обрабатывать запрос.

    2a: Запросы на индексирование направляются непосредственно лидеру шарда, обрабатывающего этот идентификатор документа. Для запроса массовой вставки это может означать несколько подзапросов, передающих пакеты документов непосредственно каждому соответствующему сегменту.

    2b: запросы к коллекции направляются на узел, который имеет сегмент из этой коллекции.

    CloudSolrClient уже знает об этом и выполняет маршрутизацию напрямую, избегая запросов прокси в кластере.

При этом запросы внутренней маршрутизации довольно легкие. Вы добавите некоторую задержку к запросам, увеличите внутреннюю пропускную способность сети и добавите минимальную нагрузку на ЦП кластеру SolrCloud.

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

person randomstatistic    schedule 23.05.2017