Replicated State Machine

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

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

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

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

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

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

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