Replicated State Machine — различия между версиями

Материал из Викиконспекты
Перейти к: навигация, поиск
Строка 1: Строка 1:
 +
[[Категория:Параллельное программирование]]
 
'''Replicated State Machine''' — система, которая хранит некий автомат (state machine) распределённо, а пользователи могут применять к этому автомату операции.
 
'''Replicated State Machine''' — система, которая хранит некий автомат (state machine) распределённо, а пользователи могут применять к этому автомату операции.
 
После этого RSM обязана эту операцию либо атомарно применить, либо откатить, и сообщить об этом пользователю.
 
После этого RSM обязана эту операцию либо атомарно применить, либо откатить, и сообщить об этом пользователю.

Версия 09:08, 4 июня 2019

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

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

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

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

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

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

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