Транзакции в распределённых системах — различия между версиями

Материал из Викиконспекты
Перейти к: навигация, поиск
(Согласованность и изоляция)
 
(не показаны 2 промежуточные версии этого же участника)
Строка 1: Строка 1:
 +
[[Категория: Параллельное программирование]]
 
== Зачем ==
 
== Зачем ==
  
Строка 12: Строка 13:
 
# '''A'''tomicity (атомарность) — транзакция либо полностью '''применила''' все свои изменения, либо полностью '''откатилась''' (отменилась)
 
# '''A'''tomicity (атомарность) — транзакция либо полностью '''применила''' все свои изменения, либо полностью '''откатилась''' (отменилась)
 
# '''C'''onsitency (согласованность) — в конце транзакции система находится в согласованном состоянии
 
# '''C'''onsitency (согласованность) — в конце транзакции система находится в согласованном состоянии
# '''I'''solation (изолированность) — параллельные транзакции не должны влиять друг на друга (например, при помощи phantom reads), а должны выполняться как будто последовательно
+
# '''I'''solation (изолированность) — параллельные транзакции не должны влиять друг на друга (например, при помощи phantom reads и non-repeatable reads), а должны выполняться как будто последовательно
 
# '''D'''urability (надёжность) — завершённые (commited) транзакции сохраняются даже в случае сбоев и перезапуска системы
 
# '''D'''urability (надёжность) — завершённые (commited) транзакции сохраняются даже в случае сбоев и перезапуска системы
  
Строка 47: Строка 48:
 
Блокировки у нас локальны и берутся просто, но нам надо, чтобы все участники атомарно пришли к решению завершать транзакцию.
 
Блокировки у нас локальны и берутся просто, но нам надо, чтобы все участники атомарно пришли к решению завершать транзакцию.
 
Можно использовать алгоритмы распределённого консенсуса, но они сложные.
 
Можно использовать алгоритмы распределённого консенсуса, но они сложные.
Классическое решение в базах данных — [[2 Phase Locking|алгоритм двухфазного коммита]] (не имеет никакого отношения к двухфазной блокировке).
+
Классическое решение в базах данных — [[2 Phase Commit|алгоритм двухфазного коммита]] (не имеет никакого отношения к двухфазной блокировке).

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

Зачем[править]

Пусть у нас есть несколько узлов (процессов), которых хранят какие-то непересекающиеся данные. Например, на одном узле хранятся банковские счета пользователей на "А", на другом — на "Б", и так далее.

Тогда мы можем хотеть транзакционно изменять данные на разных узлах (см. BEGIN TRANSACTION и COMMIT TRANSACTION в SQL).

Определение:
Транзакция — это единица работы над множеством элементов из базы данных, которую можно в процессе работы целиком отменить (либо сама база данных, либо пользователь, см. ROLLBACK TRANSACTION), либо подтвердить (база данных может иногда не справиться, тогда транзакция отменяется).

У транзакции обычно выделяют свойства по аббревиатуре ACID:

  1. Atomicity (атомарность) — транзакция либо полностью применила все свои изменения, либо полностью откатилась (отменилась)
  2. Consitency (согласованность) — в конце транзакции система находится в согласованном состоянии
  3. Isolation (изолированность) — параллельные транзакции не должны влиять друг на друга (например, при помощи phantom reads и non-repeatable reads), а должны выполняться как будто последовательно
  4. Durability (надёжность) — завершённые (commited) транзакции сохраняются даже в случае сбоев и перезапуска системы

Атомарность и надёжность[править]

Предположим, что нам нужны только атомарность и надёжность. Самое сложное — откатывать транзакцию, если что-то пошло не так. Есть два основных способа этого добиться.

Undo log[править]

Каждый узел сначала записывает предыдущие значения в надёжный журнал (лог, обычно append-only и сохраняется на диск), а только потом изменяет состояние в памяти. Когда транзакция подтверждается, надо записать произведённые изменения в надёжное место и можно стереть кусок журнала. Если транзакцию надо откатить (например, после перезапуска системы в журнале нет записи "транзакция успешна"), то мы идём с конца журнала и восстанавливаем старые значения.

Redo log[править]

Мы вообще не делаем изменения в данных до подтверждения транзакции, а просто пишем в журнал все операции, которые надо произвести с данными. Когда транзакция успешно завершается, у нас две опции:

  • Изменить данные прямо на диске.
  • Записать об этом в журнал на диск (append-only), а состояние просто каждый раз восстанавливать из этого журнала. Иногда делать checkpoint'ы для сохранения состояния. Это сейчас на практике популярнее.

Согласованность и изоляция[править]

В базах данных различают разные уровни изоляции (isolation level), максимальный уровень — сериализуемость (serializability). Это когда все транзакции можно упорядочить и получить согласованную историю, как если бы они выполнялись последовательно.

Можно брать блокировку сразу на все узлы, но это не очень эффективно и распределённая блокировка — это сложно, поэтому обычно дают блокировки разным данным в пределах одного узла. Чтобы сделать транзакцию, надо взять нужные блокировки (даже на чтение) и отпустить их, но при этом не вляпаться во взаимные блокировки или несогласованность (по-факту то транзакция не мгновенная). Для этого используется алгоритм двухфазной блокировки.

Более сложная штука — MVCC (MultiVersion Concurrency Control), это когда мы для каждой транзакции создаём "снимок" базы данных (наверняка при помощи персистентных структур данных) и дальше транзакция работает с ним. Например, в транзакциях только на чтение это позволяет экономить блокировки. А если появились записи, то надо как-то пробовать решать конфликты или даже просто откатывать транзакцию, если данные, которые она читала, уже кем-то были изменены.

Подтверждение транзакции в распределённой системе[править]

Блокировки у нас локальны и берутся просто, но нам надо, чтобы все участники атомарно пришли к решению завершать транзакцию. Можно использовать алгоритмы распределённого консенсуса, но они сложные. Классическое решение в базах данных — алгоритм двухфазного коммита (не имеет никакого отношения к двухфазной блокировке).