Ссылки на предыдущие части в закрепе. В этой части речь идет о понятиях «истины» и «лжи» в распределенных системах.
Распределенные системы состоят из нескольких узлов. Каждый отдельный узел может отказать в любой момент, поэтому система не может всецело полагаться на один узел. Вместо этого многие распределенные алгоритмы основаны на кворуме, то есть решении большинства узлов.
Обычно кворум представляет собой большинство от более чем половины узлов (хотя есть и другие разновидности). Он позволяет системе работать в случае сбоев отдельных узлов: при 3-х узлах допустим отказ 1-го, при 5 — отказ 2-х.
Отдельные узлы обязаны подчиняться решениям кворума.
Подробнее кворумы будут рассмотрены в следующей главе при обсуждении алгоритмов консенсуса.
🟢 Ограждающие маркеры
Допустим у нас есть система с сервисом хранения и приложениями-клиентами. Согласно бизнес-логике в один момент времени обратиться к файлу может только один клиент, иначе возможна порча файла. Такую логику можно реализовать это с помощью механизма договоров аренды (lease). Это некое подобие блокировки с заданным временем ожидания. Быть владельцем аренды и делать запись одновременно может только один клиент.
Если в работе арендующего клиента возникнет долгая пауза, то срок его договора аренды может истечь. Другой клиент может получить договор аренды и начать запись в тот же файл. После возобновления работы приостановленный клиент ошибочно считает, что у него все еще есть действующий договор аренды, и тоже пишет в файл. В результате файл портится.
Для решения этой проблемы добавим к договору аренды ограждающий маркер (fencing token). Маркер представляет собой номер, наращиваемый при каждом предоставлении блокировки (например, его может наращивать сервис блокировок). А клиенты при отправке запроса на запись теперь будут включать в запрос такой маркер.
Сервис хранения проверяет маркер у каждой операции: если в запросе маркер более старый, чем уже обработанный, то запрос отклоняется. Подробнее на картинке к посту.
💥 Византийские сбои
Ограждающие маркеры способны блокировать узел, непреднамеренно выполняющий ошибочные действия. Однако узел, умышленно желающий навредить, может легко это сделать, отправив сообщение с поддельным маркером.
Проблемы распределенных систем значительно усугубляются при наличии риска, что узлы могут «лгать», то есть отправлять поддельные сообщения. Это поведение носит название
византийского сбоя, и задача достижения консенсуса в такой среде известна как задача византийских генералов.
Задача византийских генералов
Имеется n генералов, которым нужно согласовать между собой план, и их действиям мешает наличие среди них предателей. Большинство из генералов верны и посылают правдивые сообщения, но предатели могут попытаться обмануть и запутать остальных с помощью отправки поддельных или ложных сообщений (пытаясь при этом остаться нераскрытыми). Заранее неизвестно, кто предатели.
В книге рассматриваются системы без византийских сбоев. То есть считаем, что узлы ненадежны, но «добропорядочны»: они
могут работать медленно или не отвечать вообще вследствие сбоя, их состояние может быть устаревшим (из-за паузы на сборку мусора или сетевых задержек), но если узел вообще отвечает, то он «говорит правду» в рамках имеющейся у него информации.
В то же время часть системы, которая находится под контролем пользователя (браузер) не считается доверенной. Поэтому нужно защищаться SQL-инъекций, XSS и др.
Также имеет смысл добавить механизмы защиты от слабых форм «лжи» — некорректных сообщений из-за ошибок ПО, неправильных настоек или аппаратных проблем.
Это могут быть:
🟠 контрольные суммы в сообщениях
🔴 проверка корректности вводимых пользователем данных, в том числе ограничение длины строк
🔴 синхронизация времени по нескольким серверам точного времени
В следующей главе будут рассмотрены решения и алгоритмы, разработанные специально для устранения проблем распределенных систем.
#кабанчик #сисдиз