Транзакции в распределённых системах — различия между версиями
Yeputons (обсуждение | вклад) (→Согласованность и изоляция) |
м (rollbackEdits.php mass rollback) |
||
| (не показаны 4 промежуточные версии 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 | + | Классическое решение в базах данных — [[2 Phase Commit|алгоритм двухфазного коммита]] (не имеет никакого отношения к двухфазной блокировке). |
Текущая версия на 19:24, 4 сентября 2022
Зачем
Пусть у нас есть несколько узлов (процессов), которых хранят какие-то непересекающиеся данные. Например, на одном узле хранятся банковские счета пользователей на "А", на другом — на "Б", и так далее.
Тогда мы можем хотеть транзакционно изменять данные на разных узлах (см. BEGIN TRANSACTION и COMMIT TRANSACTION в SQL).
| Определение: |
Транзакция — это единица работы над множеством элементов из базы данных, которую можно в процессе работы целиком отменить (либо сама база данных, либо пользователь, см. ROLLBACK TRANSACTION), либо подтвердить (база данных может иногда не справиться, тогда транзакция отменяется). |
У транзакции обычно выделяют свойства по аббревиатуре ACID:
- Atomicity (атомарность) — транзакция либо полностью применила все свои изменения, либо полностью откатилась (отменилась)
- Consitency (согласованность) — в конце транзакции система находится в согласованном состоянии
- Isolation (изолированность) — параллельные транзакции не должны влиять друг на друга (например, при помощи phantom reads и non-repeatable reads), а должны выполняться как будто последовательно
- Durability (надёжность) — завершённые (commited) транзакции сохраняются даже в случае сбоев и перезапуска системы
Атомарность и надёжность
Предположим, что нам нужны только атомарность и надёжность. Самое сложное — откатывать транзакцию, если что-то пошло не так. Есть два основных способа этого добиться.
Undo log
Каждый узел сначала записывает предыдущие значения в надёжный журнал (лог, обычно append-only и сохраняется на диск), а только потом изменяет состояние в памяти. Когда транзакция подтверждается, надо записать произведённые изменения в надёжное место и можно стереть кусок журнала. Если транзакцию надо откатить (например, после перезапуска системы в журнале нет записи "транзакция успешна"), то мы идём с конца журнала и восстанавливаем старые значения.
Redo log
Мы вообще не делаем изменения в данных до подтверждения транзакции, а просто пишем в журнал все операции, которые надо произвести с данными. Когда транзакция успешно завершается, у нас две опции:
- Изменить данные прямо на диске.
- Записать об этом в журнал на диск (append-only), а состояние просто каждый раз восстанавливать из этого журнала. Иногда делать checkpoint'ы для сохранения состояния. Это сейчас на практике популярнее.
Согласованность и изоляция
В базах данных различают разные уровни изоляции (isolation level), максимальный уровень — сериализуемость (serializability). Это когда все транзакции можно упорядочить и получить согласованную историю, как если бы они выполнялись последовательно.
Можно брать блокировку сразу на все узлы, но это не очень эффективно и распределённая блокировка — это сложно, поэтому обычно дают блокировки разным данным в пределах одного узла. Чтобы сделать транзакцию, надо взять нужные блокировки (даже на чтение) и отпустить их, но при этом не вляпаться во взаимные блокировки или несогласованность (по-факту то транзакция не мгновенная). Для этого используется алгоритм двухфазной блокировки.
Более сложная штука — MVCC (MultiVersion Concurrency Control), это когда мы для каждой транзакции создаём "снимок" базы данных (наверняка при помощи персистентных структур данных) и дальше транзакция работает с ним. Например, в транзакциях только на чтение это позволяет экономить блокировки. А если появились записи, то надо как-то пробовать решать конфликты или даже просто откатывать транзакцию, если данные, которые она читала, уже кем-то были изменены.
Подтверждение транзакции в распределённой системе
Блокировки у нас локальны и берутся просто, но нам надо, чтобы все участники атомарно пришли к решению завершать транзакцию. Можно использовать алгоритмы распределённого консенсуса, но они сложные. Классическое решение в базах данных — алгоритм двухфазного коммита (не имеет никакого отношения к двухфазной блокировке).
