Двухфазный коммит (2 Phase Commit)

Продолжим разбирать девятую главу кабанчика? Сегодня кратко про двухфазный коммит.

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

В 2PC используется новый компонент, которого нет в обычных одноузловых транзакциях: координатор (или менеджер транзакций).

🔽🔼Алгоритм двухфазного коммита:

1️⃣ Приложение запрашивает
у координатора ID распределенной транзакции.

2️⃣ Приложение выполняет нужные операции (чтение, запись) в нескольких узлах БД.

3️⃣ Когда приложение готово к фиксации, координатор отправляет каждому узлу запрос готовности коммита, помеченный глобальным ID транзакции. Это начало фазы 1.

4️⃣ Узлы-участники отвечают, готовы ли они коммитить транзакцию (да/нет). Координатор отслеживает ответ.

5️⃣ 🙂 Если все узлы-участники ответили «да», то координатор записывает решение в журнал и отправляет участникам запрос коммита. Это начало фазы 2.

☹️ Если один из участников ответил «нет», то в фазе 2 координатор отправляет всем узлам запрос на роллбэк.

6️⃣ Узлы-участники выполняют коммит или роллбэк.
‰
Клепманн пишет, что процесс двухфазного коммита похож на церемонию бракосочетания: регистратор сначала спрашивает отдельно невесту и жениха, хочет ли каждый из них вступить в брак, и обычно получает от обоих ответ «да». Получив подтверждения от обоих, он объявляет их мужем и женой: транзакция зафиксирована. Если же невеста или жених не скажет «да», то церемония прерывается.

☄️ Отказы в фазе 1 и 2

✅Если один из запросов готовности к коммиту не сработает или же его время истечет, то координатор прервет транзакцию.

✅Если не сработает один из запросов коммита или роллбэка транзакции, то координатор будет повторять их в течение неопределенного времени.

💥 Отказ координатора

Если сбой координатора случится перед отправкой запроса готовности, то участники могут отменить транзакцию.

Но как только участник получил запрос готовности и ответил «да», он больше не может отменить транз­акцию сам — ему нужно дождаться ответа координатора о том, была ли транзакция подтверждена или прервана. Если в этот момент координатор выйдет из строя или случится сбой в сети, то участнику остается только ждать.

Транзакция узла-участника в таком состоянии называется сомнительной или неопределенной.

В принципе, узлы-участники могли бы пообщаться между собой и прийти к какому-то соглашению, но это не является частью протокола 2PC.

Единственный способ, предусмотренный протоколом 2PC — ожидать восстановления координатора.

Поэтому координатор должен записывать свое решение о фиксации или отмене транзакции в журнал транзакций на диске, прежде чем отправлять соотвествующие запросы участникам. Когда координатор восстановится, он определит статус всех сомнительных транзакций, прочитав свой журнал.

Если координатор не реплицируется, а работает на одной машине, то он является точкой отказа всей системы.

🤔 На практике

Распределенные транзакции, особенно реализованные с двухфазным коммитом, имеют смешанную репутацию.
С одной стороны, таких гарантий атомарности трудно добиться другими средствами.
С другой стороны, они сильно замедляют работу.

Поэтому многие сервисы предпочитают обойтись без распределенных транзакций.

Из моего опыта: насколько я знаю, раньше двухфазный комит использовали при необходимости в больших энтерпрайзных системах, но на проектах, где я работала, его не встречала.

#кабанчик #сисдиз