Разница между узлом координатора и точкой контакта драйвера C ++ в Cassandra?
При использовании драйвера C ++ для создания API-интерфейсов для взаимодействия с Cassandra программе C ++ необходимо предоставить список через запятую, содержащий IP-адреса узлов, которые драйвер может использовать в качестве точки контакта (cass_cluster_set_contact_points) с базой данных. Я хотел понять роль этой контактной точки, и если она играет иную роль, чем узел-координатор, то есть является ли точка контакта и узел-координатор одной и той же вещью.
Также, когда мы выполняем, скажем, многопоточную программу, для выполнения нескольких запросов, выбирается узел координатора / точка контакта для каждого запроса или он просто выбирается в начале, а затем этот узел фиксируется как узел координатора на протяжении всего процесса. выполнение программы.
Решение
Конечные точки контакта просто служат для вашего драйвера для обнаружения кластера. Вам действительно нужно предоставить только два или три, и водитель определит оставшиеся конечные точки с помощью сплетен.
При подключении рекомендуется использовать TokenAwareLoadBalancingPolicy, Это приведет к тому, что любая фильтрация запросов на ключе раздела будет обходить необходимость в узле-координаторе и направлять напрямую к узлу, который отвечает за требуемые данные.
Если запрос не фильтруется по ключу раздела или если это многоключевой запрос, то точный узел не может быть определен. На этом этапе ваша политика балансировки нагрузки резервного копирования ( TokenAwareLoadBalancingPolicy принимает политику резервного копирования в качестве аргумента) будет использоваться для определения узла-координатора. Если я правильно помню DCAwareRoundRobinLoadBalancingPolicy по умолчанию.
Таким образом, конечные точки соединения служат только для обнаружения кластера. Узел-координатор выбирается во время запроса на основе алгоритмов, используемых в вашей политике балансировки нагрузки.
Другие решения
Точки контакта, указанные в программе, используются при настройке соединения кластера. Сплетня получит все настройки подключения кластера на основе этих IP-адресов. Сплетня будет поддерживать IP-адреса и другие свойства узла и всегда будет проверять, есть ли изменения в настройке, и будет обновляться каждый раз, если изменяется конфигурация.
Если на ip1 происходит запрос на запись или чтение с кластером, подключенным к хостам как ip1, ip2 & ip3, тогда ip1 является координатором для этой конкретной операции. Он действует как прокси для обработки операции и перенаправляет операцию на соответствующий узел, например, ip4, который находится в кластере, но не в списке контактов, на основе различных свойств, настройки кластера и таких политик, как TokenAwareLoadBalancingPolicy. Вы можете взглянуть на эту статью по datastax: https://docs.datastax.com/en/archived/cassandra/1.2/cassandra/architecture/architectureClientRequestsAbout_c.html