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

Материал из Викиконспекты
Перейти к: навигация, поиск
(Новая страница: «'''Replicated State Machine''' — система, которая хранит некий автомат (state machine) распределённо, а польз…»)
 
 
(не показаны 2 промежуточные версии этого же участника)
Строка 1: Строка 1:
 +
[[Категория:Параллельное программирование]]
 
'''Replicated State Machine''' — система, которая хранит некий автомат (state machine) распределённо, а пользователи могут применять к этому автомату операции.
 
'''Replicated State Machine''' — система, которая хранит некий автомат (state machine) распределённо, а пользователи могут применять к этому автомату операции.
 
После этого RSM обязана эту операцию либо атомарно применить, либо откатить, и сообщить об этом пользователю.
 
После этого RSM обязана эту операцию либо атомарно применить, либо откатить, и сообщить об этом пользователю.
Строка 13: Строка 14:
 
Нам обязательно нужна защита от отказов (иначе непонятно, зачем клонировать автомат),
 
Нам обязательно нужна защита от отказов (иначе непонятно, зачем клонировать автомат),
 
рандом из [[Алгоритм Бен-Ора|алгоритма Бен-Ора]] "не сильно спасает" (как говорилось на лекции; вероятно, тут подразумевается его тормознутость),
 
рандом из [[Алгоритм Бен-Ора|алгоритма Бен-Ора]] "не сильно спасает" (как говорилось на лекции; вероятно, тут подразумевается его тормознутость),
а надеяться на синхронность системы на практике не хочется ("вдруг сообщение придёт не скоро?" с лекции).
+
а надеяться на синхронность системы на практике не хочется ("вдруг сообщение придёт не скоро? или в swap кто-то ушёл" с лекции).
 
По этому поводу мы обычно жертвуем завершением за конечное время: алгоритм [[Paxos]].
 
По этому поводу мы обычно жертвуем завершением за конечное время: алгоритм [[Paxos]].
  
Однако на практике могут возникать дополнительные сложности с тем, что узлы у нас не падают навсегда, а временно уходят и поднимаются обратно (т.е. [[Иерархия ошибок в распределённых системах|с точки зрения теории]] у нас ненадёжная доставка сообщений), а нам надо консенсус запускать несколько раз и ещё как-то доносить старые решения до вернувшихся узлов (чтобы на них тоже получилось корректное состояние).
+
Однако на практике могут возникать дополнительные сложности с тем, что узлы у нас не падают навсегда, а временно уходят и поднимаются обратно (т.е. [[Иерархия ошибок в распределённых системах|с точки зрения теории]] у нас, строго говоря, ненадёжная доставка сообщений), а нам надо консенсус запускать несколько раз и ещё как-то доносить старые решения до вернувшихся узлов (чтобы на них тоже получилось корректное состояние).
 
В алгоритме [[Raft]] это отдельно разбирается.
 
В алгоритме [[Raft]] это отдельно разбирается.
 +
 +
По факту применяются и [[Paxos]], и [[Raft]] и все живут.

Текущая версия на 09:17, 4 июня 2019

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

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

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

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

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

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

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