В области компьютерных наук атомарная фиксация — это операция, которая применяет набор отдельных изменений как одну операцию. Если изменения применены, то говорят, что атомарная фиксация выполнена успешно. Если происходит сбой до того, как атомарная фиксация может быть завершена, то все изменения, завершенные в атомарной фиксации, отменяются. Это гарантирует, что система всегда остается в согласованном состоянии. Другое ключевое свойство изоляции вытекает из их природы как атомарных операций. Изоляция гарантирует, что только одна атомарная фиксация обрабатывается за раз. Наиболее распространенные применения атомарных фиксаций — в системах баз данных и системах контроля версий .
Проблема с атомарными коммитами заключается в том, что они требуют координации между несколькими системами. [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]
Если выполняются только атомарные коммиты, то коммиты, которые вносят ошибки, гораздо проще идентифицировать. Не нужно просматривать каждый коммит, чтобы выяснить, был ли он причиной ошибки, нужно проверять только коммиты, связанные с этой функциональностью. Если ошибку нужно откатить, атомарные коммиты снова значительно упрощают задачу. Вместо того, чтобы возвращаться к проблемной ревизии и вручную удалять изменения перед интеграцией любых последующих изменений, разработчик может просто отменить любые изменения в идентифицированном коммите. Это также снижает риск того, что разработчик случайно удалит несвязанные изменения, которые оказались в том же коммите.
Атомарные коммиты также позволяют легко просматривать исправления ошибок, если за раз фиксируется только одно исправление ошибки. Вместо проверки нескольких потенциально не связанных файлов рецензент должен проверять только файлы и изменения, которые напрямую влияют на исправляемую ошибку. Это также означает, что исправления ошибок можно легко упаковать для тестирования, поскольку в коммите содержатся только те изменения, которые исправляют ошибку.
{{cite web}}: CS1 maint: несколько имен: список авторов ( ссылка )Функция, которой нет в CVS, и которая нравится многим командам, — это атомарные коммиты. Эта функция гарантирует, что пока один человек фиксирует изменения в репозитории, никто другой этого сделать не сможет. Таким образом, каждый коммит — это отдельный процесс, и репозиторий никогда не находится в состоянии, когда в нем есть несоответствующие файлы.