Выполнить чтение из распределенного кластера на основе Paxos
Может ли кто-нибудь помочь представить, как читать содержимое распределенного кластера?
Я имею в виду, что существует распределенный кластер, согласованность которого гарантируется алгоритмом Paxos.
В реальном приложении, как клиент читает содержимое, которое он записал в кластер?
Например, в кластере из 5 серверов, возможно, только 3 из них получают самые новые данные, а два других имеют старые данные из-за задержки в сети или чего-то подобного.
Означает ли это, что клиент должен прочитать хотя бы большинство всех узлов? В 5-ти серверах это означает чтение данных как минимум с 3-х серверов и проверка того, что у него самый новый номер версии?
Если так, это кажется довольно медленным, так как вам нужно прочитать 3 копии? Как реальный мир реализует это?
1 ответ
Клиенты должны читать от лидера. Если узел знает, что это не лидер, он должен перенаправить клиента к лидеру. Если узел не знает, кто является лидером, он должен выдать ошибку, и клиент должен выбрать другой узел случайным образом, пока ему не сообщат или не найдут лидера. Если узел считает себя лидером, опасно возвращать чтение из локального состояния, так как он может просто потерять связь с остальной частью кластера, когда получает массивный останов (загрузка процессора, остановка ввода-вывода, перегрузка виртуальной машины, большой gc). некоторая фоновая задача, работа по обслуживанию сервера, ...) такая, что она фактически теряет лидерство при ответе клиенту и выдает устаревшее чтение. Этого можно избежать, запустив раунд (мульти)Paxos для чтения.
Lamport Clock и Vector Clock говорят, что вы должны передать сообщения, чтобы назначить, что операция A происходит перед операцией B, когда они работают на разных машинах. Если нет, они работают одновременно. Это обеспечивает теоретическое обоснование того, почему мы не можем сказать, что чтение от лидера не устарело без обмена сообщениями с большинством кластера. Обмен сообщениями устанавливает отношение "произошло до" при чтении к следующей записи (что может произойти на новом лидере из-за аварийного переключения).
Сам лидер может быть акцептором, и поэтому в кластере с тремя узлами ему просто нужен один ответ от одного другого узла, чтобы завершить раунд (мульти)Paxos. Он может отправлять сообщения параллельно и отвечать клиенту, когда он получает первый ответ. Сеть между узлами должна быть выделена для внутрикластерного трафика (и наилучшего, который вы можете получить), чтобы это не увеличивало время ожидания клиента.
Существует ответ, который описывает, как Paoxs может использоваться для службы блокировки, которая не может допустить устаревшие чтения или переупорядоченные записи, где сценарий сбоя обсуждается на некоторых вопросах о paxos. Очевидно, что служба блокировки не может иметь операции чтения и записи в блокировки, работающие одновременно "следовательно, почему он делает раунд (мульти)Paxos для каждого клиентского сообщения, чтобы строго упорядочить операции чтения и записи по всему кластеру.