Курсы распределённых систем: сравнение подходов

Список тем мало говорит о глубине курса. Обсудить Raft, реализовать его и проверить сервис поверх etcd — три разных учебных результата. Поэтому сравниваем тип практики и способ проверки, а не число упоминаний алгоритма.

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

Практикум Fly.io на Maelstrom предлагает шесть групп задач: эхо, уникальные идентификаторы, рассылку, счётчик, журнал в стиле Kafka и транзакции. Это самостоятельный набор упражнений, а не университетский семестр. Примеры написаны на Go; протокол ввода-вывода позволяет использовать другие языки.

Узлы работают как локальные процессы, обменивающиеся JSON через стандартные потоки. Сеть симулируется: можно задавать задержки и разделения, записывать историю и проверять её свойства. У нас лабораторная 3 и лабораторная 4 исследуют настоящие etcd и NATS. Эти способы проверки дополняют друг друга: первый помогает искать ошибки протокола, второй — видеть поведение интеграции.

Для короткого дополнительного задания подойдёт отказоустойчивая рассылка: сначала добиться доставки после восстановления связи, затем измерить число сообщений. Проверяющий истории не становится исчерпывающим доказательством корректности, а задача на счётчик сама по себе не означает обязательной реализации CRDT.

В нашей программе 10 лекций и 4 лабораторные соединены одним сервисом задач. API принимает запрос, etcd хранит состояние, NATS передаёт работу обработчику. Студент дописывает две ключевые операции — создание и завершение задачи; API, доставка и запуск экспериментов предоставлены в заготовке.

• —Неизвестный результат запроса. В лабораторной 1 ответ теряется после успешной записи. Нужно повторить запрос и сохранить единственный логический результат.
• —Смена лидера и разделение сети. Лабораторная 2 показывает поведение трёх настоящих узлов etcd. Студент исследует готовый консенсус и объясняет его границы.
• —Запись, доставка и эффект. В лабораторной 3 задача и запись для последующей отправки сохраняются атомарно. После повторной доставки обработчик не должен второй раз изменить локальный счётчик; подтверждение сообщения следует за фиксацией результата.

Что проверено и что остаётся за пределами. Стенд содержит 12 заданных сценариев отказа, а не общий проверяющий линейризуемость. Все процессы работают на одном физическом узле; брокер один, его диск сохраняется. Уникальность эффекта относится к счётчику в etcd при сохранённых записях защиты от повторов, а не к внешнему платежу. Собственный Raft, реальная миграция между шардами и потеря диска брокера в базовую практику не входят.

Это делает курс прикладным: главная работа — сформулировать гарантию всей операции и проверить, где она нарушается. У MIT и UW глубже самостоятельная реализация алгоритмов; наш сквозной пример выделяет границы между HTTP, хранилищем и очередью.

Ниже — авторские предложения для следующей редакции. Эти задания ещё не добавлены в текущие лабораторные.

1. Описание протокола до кода. По примеру UW: состояния, сообщения, таймеры, инвариант и граница атомарной операции. После эксперимента — короткий разбор причины сбоя. Это можно применить ко всем четырём лабораторным без смены проекта.
2. Рассылка и слияние изменений. Добавить к лекциям 2, 4 и 8 связку «порядок сообщений → репликация», а затем небольшое упражнение на CRDT. Cambridge и ШАД дают ориентиры для теории, Gossip Glomers — для практики рассылки.
3. Проверка историй и поиск контрпримеров. Дополнить заданные отказы случайными последовательностями событий и проверкой истории операций. Для маленького протокола отдельно исследовать ограниченную модель, как в DSLabs. Реальные интеграционные эксперименты сохранить.
4. Углублённая практика по выбору. Начать с согласованного хеширования или репликации с ведущим и резервным узлом. Миграцию разделов и полный Raft вынести в отдельный большой блок с дополнительной нагрузкой, ориентируясь на MIT и ITMO-MPP.

Статьи связывают программы между собой

В чтении MIT встречаются MapReduce, GFS, Paxos, Raft, Linearizability и Spanner; у UW — Lamport, Paxos, Bigtable, MapReduce и Dynamo. У нас эти работы связаны с лекциями и самостоятельными деками Research Insights Made Simple. Например, чтение к лекции 2 ведёт к времени и причинности, к лекции 5 — к консенсусу, к лекции 7 — к транзакциям.

Полезное дополнение по примеру MIT — один короткий ответ до обсуждения: «На какое допущение опирается система и что сломается, если его убрать?» Дека помогает объяснить статью; ответ и эксперимент показывают, понял ли студент её границы.