Нормальные операции алгоритма Raft

Я прочитал статью об алгоритме Raft и получил вопрос, связанный с последовательностью операций, выполняемых Raft при получении запроса клиента:

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

  1. Клиентский запрос получен в конечном автомате лидера, лидер добавляет команду в свой журнал.
  2. Лидер отправляет RPC AppendEntries своим последователям, чтобы клонировать команду в их локальных журналах, и ожидает подтверждения от большинства последователей, что запись была успешно добавлена ​​в их локальный файл журнала.
  3. Как только было получено подтверждение того, что запрос был успешно зарегистрирован в большинстве журналов последователей, запрос фиксируется в конечном автомате лидера, вызывая переход, возвращая результат этого перехода клиенту.
  4. В конечном итоге лидер уведомляет последователей о зафиксированных записях в последующих AppendEntries RPC.

Если вышеизложенное понимание верно, то я могу утверждать, что клиентский запрос задерживается в течение некоторого времени для завершения процесса репликации, а также могу утверждать, что успех клиентского запроса во многом зависит от успеха репликации. процесс (поскольку клиентская команда / запрос не выполняется на машине лидера до тех пор, пока не будет получено подтверждение большинства). Вопрос в том, сколько времени в среднем потребуется, чтобы клиентский запрос получил ответ после завершения процедуры репликации, также эффективно ли это работает для систем реального времени?


algorithm real-time consistency raft consensus
person CSGuy    schedule 29.02.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed предполагает, что системы, такие как Raft, запрашивающие части согласованности и доступности троицы теоремы CAP, будут иметь ограничения производительности. Вам также может быть интересен https://pdfs.semanticscholar.org/7c45/54d064128043897ea a> (Обзор опыта надежной многоадресной рассылки, Бирман), в котором описывается опыт работы с надежными группами многоадресной рассылки в системах с высокой степенью надежности, таких как управление воздушным движением.

Мой вывод из этого заключается в том, что настоящая система может быть очень осторожна с тем, какую информацию она охраняет с Raft, Paxos и друзьями, а что она может охранять менее тщательно. Другая точка зрения - использовать очень сложную реализацию Paxos, такую ​​как Google Spanner, чтобы программистам не приходилось беспокоиться о проблемах систем без ACID.

person mcdowella    schedule 01.03.2016

arrow_upward
0
arrow_downward

Если вышеизложенное понимание верно, то я могу заявить, что клиентский запрос задерживается в течение некоторого времени для завершения процесса репликации.

Верно, лидер текущего термина подтвердит запрос клиента только после того, как команда будет реплицирована на большинство узлов в кластере.

Я также могу утверждать, что успех клиентского запроса во многом зависит от успеха процесса репликации.

Это тоже правильно. По крайней мере, большинство узлов в кластере (включая лидера) должны быть доступны и реагировать, чтобы команда могла быть успешно реплицирована и лидер подтвердил запрос.

как долго в среднем ожидается получение ответа на запрос клиента после завершения процедуры репликации

Это зависит от топологии вашей сети. Задержка ответа на запрос клиента будет состоять из следующих частей (при условии отсутствия сбоев лидера): * время ожидания, необходимое для передачи запроса клиента между клиентом и лидером. * задержка AppendEntries запроса от лидера к последователям на репликацию записи (отправляемого параллельно всем последователям. * время ожидания ответа AppendEntries от последователей лидеру. * время, необходимое ведущему для применения команды в свой конечный автомат (т.е. запись на диск в лучшем случае) * задержка ответа клиента, который должен быть передан от ведущего к клиенту

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

также эффективно ли это работает для систем реального времени?

Это зависит от ваших требований для вашего конкретного случая. Но в целом системы реального времени требуют задержек менее нескольких миллисекунд, поэтому ответ, скорее всего, отрицательный. Также имейте в виду, что в периоды сбоев и нестабильности, когда происходят выборы нового лидера, задержка может значительно увеличиваться.

person Dimos    schedule 13.09.2019