Атомная фиксация
В области информатики атомарная фиксация — это операция, которая применяет набор отдельных изменений как одну операцию. Если изменения применяются, то считается, что атомарная фиксация прошла успешно. Если до завершения атомарной фиксации произойдет сбой, то все изменения, выполненные в атомарной фиксации, будут отменены. Это гарантирует, что система всегда останется в согласованном состоянии. Другое ключевое свойство изоляции вытекает из их природы как атомарных операций. Изоляция гарантирует, что одновременно обрабатывается только одна атомарная фиксация. Наиболее распространенное использование атомарных коммитов — в системах баз данных и системах контроля версий .
Проблема с атомарными коммитами заключается в том, что они требуют координации между несколькими системами. [1] Поскольку компьютерные сети являются ненадежными службами, это означает, что ни один алгоритм не может координировать свои действия со всеми системами, как это доказано в задаче двух генералов . Поскольку базы данных становятся все более и более распределенными, такая координация будет увеличивать сложность выполнения действительно атомарных коммитов. [2]
Использование [ править ]
Атомарные фиксации необходимы для многоэтапного обновления данных. Это можно наглядно продемонстрировать на простом примере денежного перевода между двумя текущими счетами. [3]
Этот пример усложняется транзакцией проверки баланса счета Y во время транзакции по переводу 100 долларов со счета X на Y. Для начала со счета X снимаются 100 долларов. Во-вторых, на счет Y добавляются 100 долларов. Если вся операция не завершается как одна атомарная фиксация, тогда может возникнуть несколько проблем. Если система дает сбой в середине операции, после удаления денег из X и перед добавлением в Y, то 100 долларов просто исчезли. Другая проблема заключается в том, что если баланс Y проверяется до добавления 100 долларов, будет сообщен неправильный баланс для Y.
При атомарных коммитах ни один из этих случаев произойти не может, в первом случае сбоя системы атомный коммит будет отменён и деньги вернутся в X. Во втором случае запрос баланса Y не может произойти до тех пор, пока не будет выполнен атомарный коммит. коммит полностью завершен.
Системы данных баз
Атомарные коммиты в системах баз данных выполняют два ключевых свойства ACID : [4] атомарность и последовательность . Согласованность достигается только в том случае, если каждое изменение в атомарном коммите является последовательным.
Как показано в примере, атомарные фиксации имеют решающее значение для многошаговых операций в базах данных. Из-за современной аппаратной конструкции физического диска , на котором находится база данных, настоящие атомарные фиксации не могут существовать. Наименьшая область, в которую можно записать данные на диске, называется сектором. Одна запись базы данных может охватывать несколько разных секторов. Одновременно можно записать только один сектор. Из-за этого ограничения записи настоящие атомарные фиксации невозможны. записей базы данных в памяти После изменения они ставятся в очередь для записи на диск. Это означает, что те же проблемы, указанные в примере, повторились. Любое алгоритмическое решение этой проблемы все равно столкнется с проблемой двух генералов. Протокол двухфазной фиксации и протокол трехфазной фиксации пытаются решить эту и некоторые другие проблемы, связанные с атомарными фиксациями.
Протокол двухфазной фиксации требует, чтобы координатор сохранял всю информацию, необходимую для восстановления исходного состояния базы данных, если что-то пойдет не так. Как следует из названия, существует две фазы: голосование и фиксация .
На этапе голосования каждый узел записывает изменения в атомарном коммите на свой диск. Затем узлы сообщают о своем статусе координатору. Если какой-либо узел не сообщает координатору или его сообщение о состоянии потеряно, координатор предполагает, что запись узла не удалась. Как только все узлы отчитаются перед координатором, начинается второй этап.
На этапе фиксации координатор отправляет сообщение о фиксации каждому из узлов для записи в их отдельные журналы. Пока это сообщение не будет добавлено в журнал узла, любые внесенные изменения будут записываться как незавершенные. Если какой-либо из узлов сообщил об ошибке, координатор вместо этого отправит сообщение об откате. Это удалит все изменения, записанные узлами на диск. [5] [6]
Протокол трехфазной фиксации направлен на устранение основной проблемы протокола двухфазной фиксации, которая возникает, если координатор и другой узел выходят из строя одновременно во время фазы фиксации и не могут сказать, какое действие должно произойти. Для решения этой проблемы в протокол добавлен третий этап. Фаза подготовки к фиксации происходит после фазы голосования и перед фазой фиксации .
На этапе голосования , аналогично двухфазному фиксации, координатор запрашивает готовность каждого узла к фиксации. В случае сбоя какого-либо узла координатор истечет по тайм-ауту во время ожидания отказавшего узла. Если это произойдет, координатор отправляет сообщение об отмене каждому узлу. То же действие будет предпринято, если какой-либо из узлов вернет сообщение об ошибке.
После получения сообщений об успехе от каждого узла на этапе голосования начинается этап подготовки к фиксации . На этом этапе координатор отправляет сообщение о подготовке каждому узлу. Каждый узел должен подтвердить сообщение подготовки и ответить. Если какой-либо ответ пропущен или какой-либо узел сообщает, что они не готовы, координатор отправляет сообщение об отмене. Любой узел, который не получает сообщение о подготовке до истечения таймаута, прерывает фиксацию.
После того, как все узлы ответили на сообщение подготовки, начинается фаза фиксации . На этом этапе координатор отправляетпередать сообщение каждому узлу. Когда каждый узел получает это сообщение, он выполняет фактическую фиксацию. Если сообщение фиксации не доходит до узла из-за потери сообщения или сбоя координатора, они выполнят фиксацию по истечении тайм-аута. Если координатор выйдет из строя после восстановления, он отправит сообщение о фиксации каждому узлу. [7]
Контроль версий [ править ]
Атомарные коммиты — это обычная функция программного обеспечения для контроля версий , которая имеет решающее значение для поддержания согласованного состояния в репозитории. [8] Большинство программ контроля версий не будут применять какую-либо часть неудачного коммита. Заметными исключениями являются CVS , VSS и IBM Rational ClearCase (в режиме UCM). [9]
Например, если программное обеспечение для контроля версий сталкивается с конфликтом слияния , который невозможно разрешить автоматически, никакая часть набора изменений не объединяется. Вместо этого разработчику предоставляется возможность либо отменить свои изменения, либо разрешить конфликт вручную.
Это предотвращает переход всего проекта в нерабочее состояние из-за частично примененного набора изменений, когда один файл из фиксации успешно фиксируется, а другой файл с зависимыми изменениями завершается сбоем. [10]
Атомарные коммиты также могут относиться к способности одновременно вносить изменения в несколько проектов с помощью программного обеспечения для контроля версий за одну операцию, используя стратегию разработки программного обеспечения для контроля версий, известную как монорепо . [8]
Соглашение об атомарных коммитах [ править ]
При использовании систем контроля версий общепринятым является использование небольших коммитов. Их иногда называют атомарными коммитами, поскольку они (в идеале) влияют только на один аспект системы. Эти атомарные коммиты обеспечивают большую понятность, меньшие усилия по откату изменений и более простую идентификацию ошибок. [11]
Большая понятность достигается за счет небольшого размера и целенаправленного характера коммита. Гораздо легче понять, что изменилось, и причину этих изменений, если искать только один тип изменений. Это становится особенно важным при внесении изменений в формат исходного кода. Если форматные и функциональные изменения сочетаются, становится очень сложно выявить полезные изменения. Представьте себе, что если интервал в файле изменен с использования табуляции на три пробела, каждая табуляция в файле будет отображаться как измененная. Это становится критически важным, если также вносятся некоторые функциональные изменения, поскольку рецензент может просто не увидеть функциональные изменения. [12] [13]
Если выполняются только атомарные коммиты, то коммиты, вносящие ошибки, гораздо проще идентифицировать. Не нужно просматривать каждый коммит, чтобы определить, является ли он причиной ошибки, необходимо проверить только коммиты, связанные с этой функциональностью. Если необходимо откатить ошибку, атомарные фиксации снова значительно упрощают работу. Вместо того, чтобы возвращаться к проблемной версии и удалять изменения вручную перед интеграцией последующих изменений; разработчик может просто отменить любые изменения в указанном коммите. Это также снижает риск того, что разработчик случайно удалит несвязанные изменения, которые оказались в одном коммите.
Атомарные фиксации также позволяют легко просматривать исправления ошибок, если одновременно фиксируется только одно исправление ошибки. Вместо проверки нескольких потенциально несвязанных файлов рецензент должен проверять только те файлы и изменения, которые напрямую влияют на исправляемую ошибку. Это также означает, что исправления ошибок можно легко упаковать для тестирования, поскольку в коммите содержатся только те изменения, которые исправляют ошибку.
См. также [ править ]
- Протокол двухфазной фиксации
- Протокол трехфазной фиксации
- Фиксация (управление данными)
- Атомная операция
Ссылки [ править ]
- ^ Бокки, Вищик (2004). Расчет процесса атомарной фиксации .
- ^ Гарсиа-Молина, Гектор; Уллман, Джефф; Видом, Дженнифер (2009). Системы баз данных. Полная книга . Прентис Холл. стр. 1008 –1009. ISBN 9780131873254 .
- ^ Гарсиа-Молина, Гектор; Уллман, Джефф; Видом, Дженнифер (2009). Системы баз данных. Полная книга . Прентис Холл. п. 299 . ISBN 9780131873254 .
- ^ Эльмасри, Рамез (2006). Основы систем баз данных, 5-е издание . Эддисон Уэсли. п. 620.
- ^ Эльмасри, Рамез (2006). Основы систем баз данных, 5-е издание . Эддисон Уэсли. п. 688.
- ^ Бернштейн, Филип А.; Хадзилакос, Вассос; Гудман, Натан (1987). «Глава 7». Параллельное управление и восстановление в системах баз данных . Издательство Аддисон Уэсли.
- ^ Гаддам, Шринивас Р. Протокол трехфазного обязательства .
- ^ Перейти обратно: а б Левенберг, Рэйчел Потвин, Джош (июль 2016 г.). «Почему Google хранит миллиарды строк кода в одном репозитории» . Коммуникации АКМ . Проверено 20 июля 2018 г.
{{cite web}}: CS1 maint: несколько имен: список авторов ( ссылка ) - ^ Смарт, Джон Фергюсон (2008). Электроинструменты Java . «О'Рейли Медиа, Инк.». п. 301. ИСБН 9781491954546 . Проверено 26 июля 2018 г.
- ^ Весперман, Дженнифер (2009). Essential CVS (2-е изд.). Севастополь: O'Reilly Media, Inc., с. 7. ISBN 9780596551407 .
Функция, которой нет в CVS и которая нравится многим командам, — это атомарные коммиты. Эта функция гарантирует, что пока один человек вносит изменения в репозиторий, никто другой не может. Таким образом, каждый коммит представляет собой отдельный процесс, и репозиторий никогда не находится в состоянии, когда в нем есть несовпадающие файлы.
- ^ «Лучшие практики Subversion» . Апач.
- ^ Барни, Буасверт. Atomic берет на себя обязательства по контролю версий .
- ^ «Преимущества небольших коммитов» . Хвойные системы. Архивировано из оригинала 5 октября 2011 г. Проверено 28 июля 2010 г.