Изменения

Участвует несколько узлов. Транзакция должна быть либо зафиксирована на всех узлах, либо на всех откачена. Бывают сбои как самих участников, так и каналов коммуникаций между ними.<br> ==Задача двух генералов = Набор требований = На двух холмах по войску, между ними враг. Одновременная атака ведет к победе. Одиночная атака ведет к распределенным базам данныхпоражению.<br>Посылают гонцов для обмена сообщениями. Гонца может перехватить враг и убить.<br> === Вероятностное решение === Послать гонца, засечь время и ждать подтверждения. Если по истечению времени гонец не вернулся, посылаем следующего.<br> === Доказательство отсутствия гарантированного решения ===Пусть существует конечный протокол, тогда существует минимальное по включению множество сообщений. Пусть последнее сообщение не доставлено, которых хотят достигнуть тогда принять решение нельзя.<br>  == Протокол двухфазной фиксации == === Требования по децентрализации Описание алгоритма ===*Локальная независимость - Один из узлов выбирается координатором, обычно узел должен функционировать даже в изоляции, к которому пришел исходный запрос.<br>(имеется В реальности в виду отвечать как на запросы на чтениесистеме могут исполняться параллельно несколько транзакций, так и на изменение)у которых разные координаторы.<br> 1 Фаза: координатор всем участникам посылает сообщение приготовиться к коммиту.<br>* Отсутствие центрального узлаЕму узлы, участвующие в транзакции, присылают информацию что они готовы зафиксировать данные, что нет несогласованности в данных, так как при его наличии и отключении ничего не выполнится локальная независимостьсломалось.<br>* Непрерывное функционирование;Когда координатор подтверждение от всех, он принимает решение.<br>** Надежность;Если от всех узлов было положительное решение, то он примет решение выполнить.<br>** ДоступностьНачнется 2 Фаза, в которой координатор всем участникам пришлет свое положительное решение, а они ему присылают информацию в ответ, что запрос был выполнен.<br>=== Требования по прозрачности ===* Независимость После завершения второй фазы, когда было получен положительный ответ от расположения;всех участников, координатор говорит, что транзакцию была завершена и шлет это в ответ на исходный запрос.<br>** Программы могут работать на любом узле (У реплики есть момент неопределенности: между моментом, как была послана информация, что данные действительно хранятся распределенно в отличие готовы быть зафиксированы, но ответ от репликации);координатора, что делать с транзакцией, еще не пришел.<br> === Обработка сбоев координатора ===** Удаленный доступ к данным (должны уметь сделать любой запрос на любом узле);До принятия решения {{---}} транзакция должна быть откачана.<br>Распределенная БД должна логически себя вести как одна большая БД* При принятии решении координатор сразу же записывает его в transaction log и при восстановении он вспомнит о принятом решении и исполнит его.<br> === Независимость от фрагментации Обработка сбоев участников ===* Программы не знают на каком узле находятся данные.До отправки готовности координатору {{---}} откат после восстановления;<br>* До получения решения {{---}} запрашивает у координатора;<br>* Унифицированный доступ к данным.При получении решения {{---}} записывает в transaction log;<br>* Географическое секционированиеПосле получения решение {{---}} выполняет решение, отправляет подверждение, записывает в transaction log.<br> Данные обработки все работает при краткосрочных сбоях, однако, так как в общем случае задача неразрешима, существуют вырожденные случаи последовательных сбоев в коммуникации, которые не позволят ни координатору, ни участнику продвинуться. === Независимость от репликации Улучшение протокола ===* Автоматическая поддержка репликацииКоординатору требуется помнить решение между принятием и подтверждениями исполнения.<br>* Выбор узла для обновления.<br>=== Распределенные транзакции =Протокол предполагаемой фиксации====* Поддержка распределенных запросовПри решении «фиксировать» {{---}} «забыть» транзакцию.<br>** Один запрос получает данные с разных узлов;Неизвестная транзакция {{---}} фиксировать.<br>** Несколько узлов могут участвовать в одной транзакции;а) Работает, когда количество фиксированных транзакций сильно превышает количество откаченных, экономим таким образом память.<br>** Должна быть согласованность фиксаций и откатаб) Может произойти ложная фиксация.<br>* Независимость от окруженияв) Сбой на первой фазе.<br> ** От аппаратурыПроисходит «потеря» транзакции, а информация не была записана в лог, то есть должны быть унифицированное представление данных;участникам придет ответ «фиксировать»<br> ====Протокол предполагаемого отката====** От ОС, то есть должна быть конвертация данных и поддержка разных ОС;При решении «откатить» {{---}} «забыть» транзакцию.<br>** От сети, например, в дата центрах будет быстрая локальная связь;Неизвестная транзакция {{---}} откатить.<br>** От типа СУБД, хотелось бы уметь делать распределенную БД, которая обслуживается разными системами управления БД (Oracle, Postgres, etcа)Не можем случайно зафиксировать транзакцию {{---}} надежнее. Но в реальности все очень печально<br> б) Тратим гораздо больше памяти, но не всегда это критично.<br>