Клиенты должны читать от лидера. Если узел знает, что это не лидер, он должен перенаправить клиента на лидера. Если узел не знает, кто является лидером, он должен выбросить ошибку, и клиент должен выбрать другой узел наугад, пока ему не будет рассказано или не найдет лидера. Если узел считает, что это лидер, опасно возвращать чтение из локального состояния, поскольку оно может просто потерять связь с остальной частью кластера сразу же, когда он получает массивный ларек (загрузка процессора, io stall, vm overload, большой gc , некоторая фоновая задача, работа по обслуживанию сервера, ...), так что она фактически лишается руководства во время ответа клиенту и выдает устаревшее чтение. Этого можно избежать, выполнив раунд (multi) Paxos для чтения.
Часы Lamport и векторные часы говорят, что вы должны передавать сообщения для назначения этой операции. A происходит до операции B, когда они запускаются на разных машинах. Если они не работают одновременно. Это дает теоретическое обоснование того, почему мы не можем сказать, что чтение от лидера не устарело, не обмениваясь сообщениями с большинством кластера. Обмен сообщениями устанавливает взаимосвязь «произошла до» от чтения до следующей записи (что может случиться с новым лидером из-за перехода на другой ресурс).
Сам лидер может быть акцептором, и поэтому в кластере из трех узлов ему просто нужен один ответ от другого узла, чтобы завершить раунд (несколько) Paxos. Он может отправлять сообщения параллельно и отвечать клиенту, когда он получает первый ответ. Сеть между узлами должна быть посвящена внутрикластерному трафику (и лучшему, что вы можете получить), так что это не добавляет много задержки для клиента.
Существует ответ, в котором описывается, как Paoxs можно использовать для службы блокировки, которая не может терпеть устаревшие чтения или переупорядоченные записи, где сценарий сбоя обсуждается в some questions about paxos Очевидно, что служба блокировки не может читать и записывать блокировки, выполняемые одновременно, поэтому он делает раунд (multi) Paxos для каждого сообщения клиента, чтобы строго упорядочить чтение и запись по кластеру.
Если клиент читает с нескольких узлов, он должен иметь дело с тем, что сообщения могут быть потеряны, дублированы, отложены, переупорядочены. предположите, что кластер просто копировал хранилище значений ключа (map), и вы спросили три узла 'getKey (1)', и вы получили три ответа в три раза, указав «null», «10», «4» из-за задержек репликации между узлами и задержками сообщений от клиента к узлам кластера. поэтому вы * должны * читать форму лидера в paxos и для того, чтобы знать, что он по-прежнему является хозяином, в тот момент, когда он отвечает, ему нужно обмениваться сообщениями с большинством кластера. – simbo1905