Транзакции в распределённых системах

Зачем

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

Тогда мы можем хотеть транзакционно изменять данные на разных узлах (см. 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), это когда мы для каждой транзакции создаём "снимок" базы данных (наверняка при помощи персистентных структур данных) и дальше транзакция работает с ним. Например, в транзакциях только на чтение это позволяет экономить блокировки. А если появились записи, то надо как-то пробовать решать конфликты или даже просто откатывать транзакцию, если данные, которые она читала, уже кем-то были изменены.

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

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