Атомарная фиксация - Atomic commit

В области Информатика, атомный совершить - это операция, которая применяет набор отдельных изменений как одну операцию. Если изменения применяются, то считается, что атомарная фиксация прошла успешно. Если происходит сбой до того, как атомарная фиксация может быть завершена, все изменения, выполненные в атомарной фиксации, отменяются. Это гарантирует, что система всегда остается в согласованном состоянии. Другое ключевое свойство изоляции проистекает из их природы: атомный операции. Изоляция гарантирует, что одновременно обрабатывается только одна атомарная фиксация. Чаще всего атомарные коммиты используются в системы баз данных и системы контроля версий.

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

использование

Атомарные фиксации необходимы для многоэтапного обновления данных. Это можно ясно продемонстрировать на простом примере перевода денег между двумя текущими счетами.[3]

Этот пример усложняется транзакцией по проверке баланса счета Y во время транзакции по переводу 100 долларов со счета X на Y. Для начала первые 100 долларов удаляются со счета X. Во-вторых, 100 долларов добавляются к счету Y. Если вся операция не завершается как одна атомарная фиксация, тогда может возникнуть несколько проблем. Если система дает сбой в середине операции, после удаления денег из X и до добавления в Y, то 100 долларов просто исчезли. Другая проблема заключается в том, что если баланс Y проверяется до добавления 100 долларов, будет сообщено о неправильном балансе для Y.

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

Системы баз данных

Атомарные коммиты в системах баз данных выполняют два ключевых свойства: КИСЛОТА,[4] атомарность и последовательность. Согласованность достигается только в том случае, если каждое изменение атомарной фиксации согласовано.

Как показано в примере, атомарные коммиты критически важны для многоступенчатых операций в базах данных. Благодаря современной аппаратной конструкции физический диск на котором находится база данных, истинные атомарные коммиты существовать не могут. Наименьшая область, в которую может быть записана запись на диске, называется сектором. Одна запись в базе данных может охватывать несколько разных секторов. Одновременно можно записать только один сектор. Этот предел записи является причиной того, что настоящие атомарные коммиты невозможны. После записей в базе данных в объем памяти были изменены, они поставлены в очередь для записи на диск. Это означает, что проблемы, указанные в примере, повторились. Любое алгоритмическое решение этой проблемы все равно столкнется с проблемой двух генералов. В протокол двухфазной фиксации и протокол трехфазной фиксации попытаться решить эту и некоторые другие проблемы, связанные с атомарными коммитами.

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

Вовремя голосование На этапе каждый узел записывает изменения в атомарной фиксации на свой диск. Затем узлы сообщают о своем статусе координатору. Если какой-либо узел не сообщает координатору или его сообщение о состоянии потеряно, координатор предполагает, что запись узла не удалась. Когда все узлы сообщат координатору, начинается вторая фаза.

Вовремя совершить На этапе координатор отправляет сообщение фиксации каждому из узлов для записи в их отдельные журналы. Пока это сообщение не будет добавлено в журнал узла, любые сделанные изменения будут регистрироваться как незавершенные. Если какой-либо из узлов сообщил об ошибке, координатор вместо этого отправит сообщение отката. Это удалит все изменения, записанные узлами на диск.[5][6]

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

в голосование Фаза, аналогичная двухфазной фиксации, координатор запрашивает, чтобы каждый узел был готов к фиксации. Если какой-либо узел выйдет из строя, координатор будет тайм-аут, ожидая отказавший узел. Если это происходит, координатор отправляет каждому узлу сообщение об отмене. То же действие будет предпринято, если какой-либо из узлов вернет сообщение об ошибке.

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

После того, как все узлы ответят на сообщение о подготовке, совершить фаза начинается. На этом этапе координатор отправляет сообщение подтверждения каждому узлу. Когда каждый узел получает это сообщение, он выполняет фактическую фиксацию. Если сообщение фиксации не достигает узла из-за потери сообщения или сбоя координатора, они выполнят фиксацию, если истечет время ожидания. Если координатор отказывает при восстановлении, он отправит сообщение фиксации на каждый узел.[7]

Контроль версий

Атомарные коммиты - общая черта программное обеспечение для контроля версий, и имеет решающее значение для поддержания согласованного состояния в репозитории.[8] Большинство программ для управления версиями не будут применять ни одну часть неудачной фиксации. Заметными исключениями являются CVS, VSS и IBM Rational ClearCase (в режиме UCM).[9]

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

Это предотвращает переход всего проекта в состояние неработоспособности из-за частично примененного набора изменений, когда один файл из фиксации успешно фиксируется, а другой файл с зависимыми изменениями не выполняется.[10]

Атомарные коммиты также могут относиться к возможности одновременно вносить изменения в несколько проектов с использованием программного обеспечения для управления версиями за одну операцию, используя стратегию разработки программного обеспечения для управления версиями, известную как монорепо.[8]

Соглашение об атомарной фиксации

При использовании систем контроля версий общепринято использовать небольшие коммиты. Их иногда называют атомарными фиксациями, поскольку они (в идеале) влияют только на один аспект системы. Эти атомарные коммиты обеспечивают большую понятность, меньше усилий для отката изменений и упрощают идентификацию ошибок.[11]

Лучшая понятность достигается за счет небольшого размера и целенаправленного характера коммита. Намного легче понять, что изменилось, и объяснить причины изменений, если вы ищете только один вид изменений. Это становится особенно важным при изменении формата исходного кода. Если объединить форматные и функциональные изменения, становится очень трудно определить полезные изменения. Представьте, что если интервал в файле изменится с использования табуляции на три пробела, каждая табуляция в файле будет отображаться как измененная. Это становится критическим, если также вносятся некоторые функциональные изменения, поскольку рецензент может просто не видеть функциональные изменения.[12][13]

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

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

Смотрите также

Рекомендации

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