В области вычислительной техники , атомная фиксация представляет собой операция , которая применяет множество различных изменений , как одну операции. Если изменения применяются, то считается, что атомарная фиксация прошла успешно. Если происходит сбой до того, как атомарная фиксация может быть завершена, все изменения, выполненные в атомарной фиксации, отменяются. Это гарантирует, что система всегда остается в согласованном состоянии. Другое ключевое свойство изоляции проистекает из их природы атомарных операций. Изоляция гарантирует, что одновременно обрабатывается только одна атомарная фиксация. Чаще всего атомарные коммиты используются в системах баз данных и системах контроля версий .
Проблема с атомарными коммитами в том, что они требуют координации между несколькими системами. [1] Поскольку компьютерные сети являются ненадежными услугами, это означает, что ни один алгоритм не может координировать свои действия со всеми системами, как это было доказано в задаче двух генералов . По мере того, как базы данных становятся все более и более распределенными, такая координация усложняет выполнение действительно атомарных коммитов. [2]
Применение
Атомарные коммиты необходимы для многоэтапного обновления данных. Это можно ясно продемонстрировать на простом примере перевода денег между двумя текущими счетами. [3]
Этот пример усложняется транзакцией по проверке баланса счета Y во время транзакции по переводу 100 долларов со счета X на Y. Для начала первые 100 долларов удаляются со счета X. Во-вторых, 100 долларов добавляются к счету Y. Если вся операция не завершается как одна атомарная фиксация, тогда может возникнуть несколько проблем. Если система дает сбой в середине операции, после удаления денег из 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]
Если выполняются только атомарные коммиты, тогда становится намного проще идентифицировать коммиты, которые вносят ошибки. Необязательно просматривать каждую фиксацию, чтобы увидеть, была ли она причиной ошибки, нужно проверять только те коммиты, которые имеют дело с этой функциональностью. Если необходимо откатить ошибку, атомарные коммиты снова значительно упростят работу. Вместо того, чтобы возвращаться к проблемной версии и удалять изменения вручную перед интеграцией любых последующих изменений; разработчик может просто отменить любые изменения в идентифицированной фиксации. Это также снижает риск случайного удаления разработчиками несвязанных изменений, которые оказались в одной фиксации.
Атомарные фиксации также позволяют легко просматривать исправления ошибок, если за раз фиксируется только одно исправление ошибки. Вместо проверки нескольких потенциально несвязанных файлов рецензент должен проверять только файлы и изменения, которые напрямую влияют на исправляемую ошибку. Это также означает, что исправления ошибок можно легко упаковать для тестирования, поскольку в фиксации содержатся только те изменения, которые исправляют ошибку.
Смотрите также
Рекомендации
- ^ Бокки, Wischik (2004). Расчет процесса атомарной фиксации .
- ^ Гарсия-Молина, Гектор; Ульман, Джефф; Видом, Дженнифер (2009). Системы баз данных Полная книга . Прентис Холл. стр. 1008 -1009.
- ^ Гарсия-Молина, Гектор; Ульман, Джефф; Видом, Дженнифер (2009). Системы баз данных Полная книга . Прентис Холл. п. 299 .
- ^ Эльмасри, Рамез (2006). Основы систем баз данных 5-е издание . Эддисон Уэсли. п. 620.
- ^ Эльмасри, Рамез (2006). Основы систем баз данных 5-е издание . Эддисон Уэсли. п. 688.
- ^ Бернштейн, Филип А .; Хадзилакос, Вассос; Гудман, Натан (1987). «Глава 7». Управление параллелизмом и восстановление в системах баз данных . Издательство Эддисон Уэсли.
- ^ Гаддам, Шринивас Р. Протокол трехфазной фиксации .
- ^ а б Левенберг, Рэйчел Потвин, Джош (июль 2016 г.). «Почему Google хранит миллиарды строк кода в одном репозитории» . Коммуникации ACM . Проверено 20 июля 2018 года .
- ^ Умный, Джон Фергюсон (2008). Java Power Tools . «О'Рейли Медиа, Инк.». п. 301. ISBN. 9781491954546. Проверено 26 июля 2018 года .
- ^ Весперман, Дженнифер (2009). Essential CVS (2-е изд.). Севастополь: O'Reilly Media, Inc., стр. 7. ISBN 9780596551407.
Функция, которой нет в CVS и которая нравится многим командам, - это атомарные коммиты. Эта функция гарантирует, что пока один человек фиксирует изменения в репозитории, никто другой не сможет. Таким образом, каждая фиксация - это отдельный процесс, и репозиторий никогда не находится в состоянии, в котором есть несовпадающие файлы.
- ^ «Лучшие практики Subversion» . Apache.
- ^ Барни, Бойсверт. Атомарная фиксация в системе контроля версий .
- ^ «Преимущества малых коммитов» . Хвойные системы.