Распределенные транзакции

Участвует несколько узлов. Транзакция должна быть либо зафиксирована на всех узлах, либо на всех откачена. Бывают сбои как самих участников, так и каналов коммуникаций между ними.

Задача двух генералов

На двух холмах по войску, между ними враг. Одновременная атака ведет к победе. Одиночная атака ведет к поражению.
Посылают гонцов для обмена сообщениями. Гонца может перехватить враг и убить.

Вероятностное решение

Послать гонца, засечь время и ждать подтверждения. Если по истечению времени гонец не вернулся, посылаем следующего.

Доказательство отсутствия гарантированного решения

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

Протокол двухфазной фиксации

Описание алгоритма

200px|right Один из узлов выбирается координатором, обычно узел, к которому пришел исходный запрос.
В реальности в системе могут исполняться параллельно несколько транзакций, у которых разные координаторы.

Первая фаза

• Координатор всем участникам посылает сообщение приготовиться к коммиту;
  
• Узлы, участвующие в транзакции, присылают информацию что они готовы зафиксировать данные, что нет несогласованности в данных, ничего не сломалось;
  
• Когда координатор подтверждение от всех, он принимает решение;
  
• Если от всех узлов было положительное решение, то он примет решение выполнить.
  

Вторая фаза

• Координатор всем участникам пришлет свое положительное решение, а они ему присылают информацию в ответ, что запрос был выполнен.
  

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

У реплики есть момент неопределенности: между моментом, как была послана информация, что данные готовы быть зафиксированы, но ответ от координатора, что делать с транзакцией, еще не пришел.

Обработка сбоев координатора

• До принятия решения — транзакция должна быть откачана.
  
• При принятии решении координатор сразу же записывает его в transaction log и при восстановении он вспомнит о принятом решении и исполнит его.
  

Обработка сбоев участников

• До отправки готовности координатору — откат после восстановления;
  
• До получения решения — запрашивает у координатора;
  
• При получении решения — записывает в transaction log;
  
• После получения решение — выполняет решение, отправляет подверждение, записывает в transaction log.
  

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

Улучшение протокола

Координатору требуется помнить решение между принятием и подтверждениями исполнения.

Протокол предполагаемой фиксации

• При решении «фиксировать» — «забыть» транзакцию.
  
• Неизвестная транзакция — фиксировать.
  

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

б) Может произойти ложная фиксация.

в) Сбой на первой фазе.

• Происходит «потеря» транзакции, а информация не была записана в лог, то участникам придет ответ «фиксировать»
  

Протокол предполагаемого отката

• При решении «откатить» — «забыть» транзакцию.
  
• Неизвестная транзакция — откатить.
  

а) Не можем случайно зафиксировать транзакцию — надежнее.

б) Тратим гораздо больше памяти, но не всегда это критично.