Replicated State Machine

НЕТ ВОЙНЕ

24 февраля 2022 года российское руководство во главе с Владимиром Путиным развязало агрессивную войну против Украины. В глазах всего мира это военное преступление совершено от лица всей страны, всех россиян. Будучи гражданами Российской Федерации, мы против своей воли оказались ответственными за нарушение международного права, военное вторжение и массовую гибель людей. Чудовищность совершенного преступления не оставляет возможности промолчать или ограничиться пассивным несогласием. Мы убеждены в абсолютной ценности человеческой жизни, в незыблемости прав и свобод личности. Режим Путина — угроза этим ценностям. Наша задача — обьединить все силы для сопротивления ей. Эту войну начали не россияне, а обезумевший диктатор. И наш гражданский долг — сделать всё, чтобы её остановить. Антивоенный комитет России

Распространяйте правду о текущих событиях, оберегайте от пропаганды своих друзей и близких. Изменение общественного восприятия войны - ключ к её завершению.

meduza.io, Популярная политика, Новая газета, zona.media, Майкл Наки.

Replicated State Machine — система, которая хранит некий автомат (state machine) распределённо, а пользователи могут применять к этому автомату операции. После этого RSM обязана эту операцию либо атомарно применить, либо откатить, и сообщить об этом пользователю. Подтверждённые пользователю транзакции теряться не должны.

Это может быть полезно, когда у нас есть очень важные данные, которые надо:

1. Защитить от сбоев любого конкретного узла (т.е. надо хранить на нескольких узлах и нельзя иметь центрального координатора)
2. Быстро обновлять (т.е. нельзя просто записывать на диск каждый раз)

Если операции, применяемые к состоянию, детерминированы, то можно не клонировать состояние между машинами, а просто применять операции повторно на разных узлах. Но операции обычно не коммутируют, поэтому всем узлам надо приходить к консенсусу: какие операции в каком порядке применять.

Теоретически эта задача считается эквивалентной задаче консенсуса, поэтому действуют ограничения FLP. Нам обязательно нужна защита от отказов (иначе непонятно, зачем клонировать автомат), рандом из алгоритма Бен-Ора "не сильно спасает" (как говорилось на лекции; вероятно, тут подразумевается его тормознутость), а надеяться на синхронность системы на практике не хочется ("вдруг сообщение придёт не скоро? или в swap кто-то ушёл" с лекции). По этому поводу мы обычно жертвуем завершением за конечное время: алгоритм Paxos.

Однако на практике могут возникать дополнительные сложности с тем, что узлы у нас не падают навсегда, а временно уходят и поднимаются обратно (т.е. с точки зрения теории у нас, строго говоря, ненадёжная доставка сообщений), а нам надо консенсус запускать несколько раз и ещё как-то доносить старые решения до вернувшихся узлов (чтобы на них тоже получилось корректное состояние). В алгоритме Raft это отдельно разбирается.

По факту применяются и Paxos, и Raft и все живут.