Теория отказоустойчивых распределенных систем — различия между версиями
M8hew (обсуждение | вклад) |
M8hew (обсуждение | вклад) |
||
| Строка 20: | Строка 20: | ||
== Домашние задания == | == Домашние задания == | ||
| − | |||
| − | |||
| − | |||
'''Задание 1''' | '''Задание 1''' | ||
| − | + | Напишите систему, вычисляющую интеграл от некоторой функции. | |
| − | Напишите | + | |
| − | + | Мастер (клиент) находит рабочие узлы (сервера) через IP broadcast — рассылает стартовое сообщение по всем адресам подсети, на которое рабочие узлы, слушающие на своих TCP портах, отвечают. Затем каждому рабочему узлу даётся отрезок, он вычисляет на нём интеграл и отправляет ответ мастеру. Мастер складывает ответы серверов и получает итоговый результат. | |
| + | Требования: | ||
| + | * если после раздачи заданий сервера становятся недоступны (выключаются / происходит разрыв сети), но хотя бы один сервер доступен, программа это детектирует, раздаёт работу доступным серверам вместо отключившихся и даёт верный ответ | ||
| + | * если недоступный сервер снова появляется в сети и пытается послать ответ, это не приводит к ошибке, в частности, результат по соотв. отрезку не будет учтён дважды | ||
| + | * если недоступный сервер появился в сети, мастер должен уметь присылать на него новые задачи (например, отключился какой-то ещё сервер) | ||
| − | + | Задачу прошу сделать на чистом С, пользуясь API сетевых сокетов. Лучше всего на UNIX-like системе, хотя на Windows в общем сокеты похожие. | |
| − | + | Обязательно показать работу программы с полной / частичной потерей пакетов, дублированием, задержками. Рекомендую утилиту tc или iptables. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | '' | + | ''Литература:'' |
| + | * Стивенс У. Р. "Разработка сетевых приложений", гл. 2, 3, 4, 5, 7 | ||
| − | ''' | + | '''Deadline: 17 ноября''' |
| − | |||
| − | |||
| − | |||
| − | '' | + | '''Задание 2''' |
| − | + | Вы имитируете базу данных с репликами. Клиент отправляет данные на master сервера, с мастера данные реплицируются на другие узлы. Чтение распределяется равномерно по всем репликам (т. е. запрос клиента на чтение обслуживается не мастером, а какой-то репликой). При потере мастера реплики должны проголосовать и выбрать нового мастера среди живых узлов, используя протокол консенсуса (Raft). | |
| − | + | Если мастер оживает и на нём есть какие-то несинхронизованные данные, то они должны обработаться разумным образом, а бывший мастер — стать одной из реплик.<br> | |
| − | + | Отдельным пунктом — реализация линеаризуемого атомарный CAS | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | # Система должна выполнять CRUD операции — create/read/update/delete | |
| + | # При чтениях не надо данные от реплики прокачивать через мастер, данные должны идти с реплики на клиента. Для этого мастер может отвечать, например, 302 Found и давать заголовок Location с адресом реплики | ||
| + | # Учитывайте семантику методов HTTP — PUT идемпотентный (и требует ID ресурса в запросе), POST — неидемпотентный, PATCH позволяет обновить ресурс частично и зависит от текущего состояния | ||
| + | # Максимальное количество реплик фиксированное. | ||
| − | ''' | + | '''Deadline: 1 декабря''' |
| − | |||
| − | + | '''Задание 3''' | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | '''Задание | + | |
| − | + | CRDT | |
| − | + | TBD | |
== Литература == | == Литература == | ||
Версия 02:03, 8 ноября 2024
Содержание
Теория отказоустойчивых распределенных систем
Обязательный осенний курс для студентов 4 курса специализации РС ПМИ ФКН ВШЭ.
Занятия проводятся онлайн по субботам c 9.30 в zoom
Лектор: Алексей Неганов aka @bokareis.
Записи пар: тут
Текущая ведомость: TBD
Формула оценки
Оценка за курс ставиться по следующей формуле (ОДз1 + ОДз2 + ОДз3 + ОЭкз)*4/3, где максимальная отметка
- за Дз1 1 балл
- за Дз2 3 балла
- за Дз3 2 балла
- за Экз 2 балла
Домашние задания
Задание 1
Напишите систему, вычисляющую интеграл от некоторой функции.
Мастер (клиент) находит рабочие узлы (сервера) через IP broadcast — рассылает стартовое сообщение по всем адресам подсети, на которое рабочие узлы, слушающие на своих TCP портах, отвечают. Затем каждому рабочему узлу даётся отрезок, он вычисляет на нём интеграл и отправляет ответ мастеру. Мастер складывает ответы серверов и получает итоговый результат.
Требования:
- если после раздачи заданий сервера становятся недоступны (выключаются / происходит разрыв сети), но хотя бы один сервер доступен, программа это детектирует, раздаёт работу доступным серверам вместо отключившихся и даёт верный ответ
- если недоступный сервер снова появляется в сети и пытается послать ответ, это не приводит к ошибке, в частности, результат по соотв. отрезку не будет учтён дважды
- если недоступный сервер появился в сети, мастер должен уметь присылать на него новые задачи (например, отключился какой-то ещё сервер)
Задачу прошу сделать на чистом С, пользуясь API сетевых сокетов. Лучше всего на UNIX-like системе, хотя на Windows в общем сокеты похожие.
Обязательно показать работу программы с полной / частичной потерей пакетов, дублированием, задержками. Рекомендую утилиту tc или iptables.
Литература:
- Стивенс У. Р. "Разработка сетевых приложений", гл. 2, 3, 4, 5, 7
Deadline: 17 ноября
Задание 2
Вы имитируете базу данных с репликами. Клиент отправляет данные на master сервера, с мастера данные реплицируются на другие узлы. Чтение распределяется равномерно по всем репликам (т. е. запрос клиента на чтение обслуживается не мастером, а какой-то репликой). При потере мастера реплики должны проголосовать и выбрать нового мастера среди живых узлов, используя протокол консенсуса (Raft).
Если мастер оживает и на нём есть какие-то несинхронизованные данные, то они должны обработаться разумным образом, а бывший мастер — стать одной из реплик.
Отдельным пунктом — реализация линеаризуемого атомарный CAS
- Система должна выполнять CRUD операции — create/read/update/delete
- При чтениях не надо данные от реплики прокачивать через мастер, данные должны идти с реплики на клиента. Для этого мастер может отвечать, например, 302 Found и давать заголовок Location с адресом реплики
- Учитывайте семантику методов HTTP — PUT идемпотентный (и требует ID ресурса в запросе), POST — неидемпотентный, PATCH позволяет обновить ресурс частично и зависит от текущего состояния
- Максимальное количество реплик фиксированное.
Deadline: 1 декабря
Задание 3
CRDT
TBD
Литература
- Petrov, A. (2019). Database Internals: A deep dive into how distributed data systems work.
- Luo, C., & Carey, M. J. (2020). LSM-based storage techniques: a survey.
- Schütze, H., Manning, C. D., & Raghavan, P. (2008). Introduction to information retrieval.
- Lemire, D., Ssi‐Yan‐Kai, G., & Kaser, O. (2016). Consistently faster and smaller compressed bitmaps with roaring.
- Grabowski, S., Raniszewski, M., & Deorowicz, S. (2017). FM-index for Dummies.
- Navarro, G., & Mäkinen, V. (2007). Compressed full-text indexes.