У меня есть то, что у меня есть 3 экземпляра memcached, работающих на 3 разных серверах. В настоящее время мое приложение имеет те же 3 разных узла. Все серверы приложений знают обо всех серверах memcached, но если один из них опускается, я не могу заметить. Идея состоит в том, чтобы переместить сервер memcached на собственные узлы.Знакомство с Couchbase с использованием memcached buckets
Я начал рассматривать CouchBase как альтернативу решения этого вопроса, но не уверен, что он будет работать.
Будет ли он работать так, чтобы у меня был кластер CouchBase, на каждом узле приложения, а затем подключался к другим серверам memcached, а CouchBase будет отслеживать и знать, какие из них являются живыми?
В этом случае, как приложение, которое в настоящее время связано с экземплярами memcached, знает, как получить данные, если один из экземпляров memcached не работает? Или это CouchBase, который будет средним человеком, заботящимся о том, где его хранить?
Спасибо, один вопрос относительно сбора информации для всех узлов. Означает ли это, что если у меня есть кластер с серверами e.x 2 couchbase, которые, просто подключившись к одному из них, проинформируют объект об этих двух узлах? И если один из них опустится, попытается ли он получить его с других узлов? Просто интересно, что произойдет, когда сервер couchbase опустится, а не только хранилище memcached. – Nitro
Итак, первоначальное сообщение получает список vbuckets, но он проверяет, где он обновляет эту информацию vbucket. Как правило, хорошей идеей является настройка своего рода виртуального IP-интерфейса или прокси-сервера, такого как nginx, который позволяет выполнять балансировку нагрузки по кругу на всех узлах. Таким образом, если один из узлов опустится, вы все равно сможете подключиться и получить эти обновления vbucket без необходимости внесения изменений кода для поддержки отказа. Кроме этого, да. Как только он разговаривает с начальным узлом с SDK Couchbase, он знает обо всех других серверах и соответственно распределяет трафик. – Drahkar