ПРИМЕЧАНИЕ: это с точки зрения аспиранта с небольшим опытом работы с распределенными системами, поэтому это может не относиться к опытным исследователям и инженерам.

Эта статья основана на лекции по освещению, которую я сделал в своем курсе по распределенным системам CMPS232. Я выбираю эту тему по двум причинам

  • Большинство лекций по освещению в этом классе сосредоточено на теории, и, честно говоря, я думаю, что некоторые из них пересказывают то, что сказал автор.
  • Raft делает упор на понятность, и у MIT 6.824 есть лаборатория для Raft.

Работа в лаборатории Raft заняла у меня около недели. Хотя я много использовал golang, я почти не использую его асинхронные функции, горутины, каналы и т. Д., Которые необходимы при реализации конечного автомата. Кроме того, интерфейсы и утилита журнала, предоставляемые лабораторией, мне не очень удобны, поэтому я написал еще одну утилиту журнала, которая поддерживает запись в терминал и в файл.

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

Что касается уроков, которые я извлек

  • Спецификация очень важна. Знайте, что вы хотите сделать, прежде чем это делать. Думаю, это касается и проекта курса распределенных систем. Если вы слишком рано перейдете к деталям кодирования, вы потеряете контроль над проектом. Это правда, что иногда я не знаю, что пишу, пока не напишу и не удалю определенный объем кода, но наличие спецификации - действительно более эффективный способ.
  • Тест предотвратит множество проблем. Если вы посмотрите на эти популярные реализации рафта, вы увидите, что они охватывают все случаи, упомянутые в статье. И тестовые примеры похожи на проверку модели, с которой я впервые столкнулся при использовании облегченного моделирования для понимания бумаги с аккордами. Вы перечисляете те крайние случаи, которые могут привести к сбою программы или неправильному протоколу. И ваш протокол должен избегать этих сбоев и / или восстанавливаться после них. Что касается лаборатории, наличие этих тестовых примеров действительно помогает при написании реализации.
  • Начни с простого. Как и в случае с плотом, при первом написании реализации вам не нужно выполнять изменение членства и уплотнение журнала. Чем меньше целей, тем легче сосредоточиться и правильно их решать. Затем вы можете добавить больше функций, которые сделают его более близким к производственному использованию.
  • Не смотрите слишком рано на существующую реализацию. Приятно посмотреть на эти реализации, работающие в производственной среде, и поучиться у них. Но большая часть их кода сосредоточена на производительности, и хотя вы сначала реализуете протокол, правильность является главной целью. Также у них иногда есть грязные уловки, чтобы повысить производительность и / или написать меньше кода, что усложняет их понимание. Однако, когда у вас есть какой-то запущенный код, вы можете взглянуть на другие реализации и посмотреть, сможете ли вы настроить производительность, как они.

Ссылка