LINUX.ORG.RU

История изменений

Исправление ergo, (текущая версия) :

В том-то и дело, что я читал Рафт и даже загорелся идеей применить его, ведь он такой простой и логичный

это, кстати, большое заблуждение. спецификация выглядит простой поскольку там много упущений. у меня ушло полтора месяца на его разработку и проведение кучи тестов. При этом очень многое невозможно автоматизировать ибо тайминг. Например, когда стартует 25 нод с рафт процессами - там настолько рандомная событийная последовательность. Из 2600 строк кода этой реализации 1000 отвечает только за создание кворума, около 900 - за выбор лидера. Остальные - на append и get данных. Сделать кавер тест на все юзкейсы нереально, поэтому много проводилось кастомных тестов. например, тот же сбор кворума из 25 нод - запускал в цикле несколько тысяч раз на выявление корнер кейсов, когда кворум не мог собраться (а именно, при 25 нодах должен сформироваться кворум из 11 нод, остальные должны принять его и не запускать новых голосований). Там процесс очень интересный - в процессе «знакомства» процессов друг с другом они начинают формировать кворумы - 3 ноды начинают создавать свой, другие по мере «связывания» - свои кворумы (но они все должны придти к одному кворуму в кластере). Как только появляется у ноды пиров достаточное кол-во для создания бОльшего кворума (например из 5, 7, 9 или 11), он запускает новое голосование (но текущий кворму не бросает ибо не знает, чем закончится новое голосование). Или, например, как сплит отрабатывается - тоже весьма интересная задача.

В общем, там много интересных деталей. Попробуй, если любопытно будет.

ЗЫ в спецификации рафта нет кворумов. это улучшение было добавлено именно для усиления кластера в части устойчивости.

Исправление ergo, :

В том-то и дело, что я читал Рафт и даже загорелся идеей применить его, ведь он такой простой и логичный

это, кстати, большое заблуждение. спецификация выглядит простой поскольку там много упущений. у меня ушло полтора месяца на его разработку и проведение кучи тестов. При этом очень многое невозможно автоматизировать ибо тайминг. Например, когда стартует 25 нод с рафт процессами - там настолько рандомная событийная последовательность. Из 2600 строк кода этой реализации 1000 отвечает только за создание кворума, около 900 - за выбор лидера. Остальные - на append и get данных. Сделать кавер тест на все юзкейсы нереально, поэтому много проводилось кастомных тестов. например, тот же сбор кворума из 25 нод - запускал в цикле несколько тысяч раз на выявление корнер кейсов, когда кворум не мог собраться (а именно, при 25 нодах должен сформироваться кворум из 11 нод, остальные должны принять его и не запускать новых голосований). Там процесс очень интересный - в процессе «знакомства» процессов друг с другом они начинают формировать кворумы - 3 ноды начинают создавать свой, другие по мере «связывания» - свои кворумы (но они все должны придти к одному кворуму в кластере). Как только появляется у ноды пиров достаточное кол-во для создания бОльшего кворума (например из 5, 7, 9 или 11), он запускает новое голосование (но текущий кворму не бросает ибо не знает, чем закончится новое голосование). Или, например, как сплит отрабатывается - тоже весьма интересная задача.

В общем, там много интересных деталей. Попробуй, если любопытно будет.

Исправление ergo, :

В том-то и дело, что я читал Рафт и даже загорелся идеей применить его, ведь он такой простой и логичный

это, кстати, большое заблуждение. спецификация выглядит простой поскольку там много упущений. у меня ушло полтора месяца на его разработку и проведение кучи тестов. При этом очень многое невозможно автоматизировать ибо тайминг. Например, когда стартует 25 нод с рафт процессами - там настолько рандомная событийная последовательность. Из 2600 строк кода этой реализации 1000 отвечает только за создание кворума, около 900 - за выбор лидера. Остальные - на append и get данных. Сделать кавер тест на все юзкейсы нереально, поэтому много проводилось кастомных тестов. например, тот же сбор кворума из 25 нод - запускал в цикле несколько тысяч раз на выявление корнер кейсов, когда кворум не мог собраться (а именно, при 25 нодах должен сформироваться кворум из 11 нод, остальные должны принять его и не запускать новых голосований). Там процесс очень интересный - в процессе «знакомства» процессов друг с другом они начинают формировать кворумы - 3 ноды начинают создавать свой, другие по мере «связывания» - свои кворумы. Как только появляется у ноды пиров достаточное кол-во для создания бОльшего кворума (например из 5, 7, 9 или 11), он запускает новое голосование (но текущий кворму не бросает ибо не знает, чем закончится новое голосование). Или, например, как сплит отрабатывается - тоже весьма интересная задача.

В общем, там много интересных деталей. Попробуй, если любопытно будет.

Исходная версия ergo, :

В том-то и дело, что я читал Рафт и даже загорелся идеей применить его, ведь он такой простой и логичный

это, кстати, большое заблуждение. спецификация выглядит простой поскольку там много упущений. у меня ушло полтора месяца на его разработку и проведение кучи тестов. При этом очень многое невозможно автоматизировать ибо тайминг. Например, когда стартует 25 нод с рафт процессами - там настолько рандомная событийная последовательность. Например, из 2600 строк кода этой реализации 1000 отвечает только за создание кворума, около 900 - за выбор лидера. Остальные - на append и get данных. Сделать кавер тест на все юзкейсы нереально, поэтому много проводилось кастомных тестов. например, тот же сбор кворума из 25 нод - запускал в цикле несколько тысяч раз на выявление корнер кейсов, когда кворум не мог собраться (а именно, при 25 нодах должен сформироваться кворум из 11 нод, остальные должны принять его и не запускать новых голосований). Там процесс очень интересный - в процессе «знакомства» процессов друг с другом они начинают формировать кворумы - 3 ноды начинают создавать свой, другие по мере «связывания» - свои кворумы. Как только появляется у ноды пиров достаточное кол-во для создания бОльшего кворума (например из 5, 7, 9 или 11), он запускает новое голосование (но текущий кворму не бросает ибо не знает, чем закончится новое голосование). Или, например, как сплит отрабатывается - тоже весьма интересная задача.

В общем, там много интересных деталей. Попробуй, если любопытно будет.