ACID

ACID — это набор из четырех свойств транзакций в системах управления базами данных: Atomicity, Consistency, Isolation и Durability. По-русски их обычно называют атомарностью, согласованностью, изоляцией и долговечностью.

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

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

Что такое ACID простыми словами

Представим банковский перевод 10 000 рублей с одного счета на другой. Операция состоит минимум из двух изменений: уменьшить баланс первого счета и увеличить баланс второго.

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

ACID описывает свойства, благодаря которым связанные изменения данных выполняются предсказуемо и не оставляют базу в некорректном промежуточном состоянии.

Расшифровка ACID

Что такое транзакция

Транзакция — это логическая группа операций с данными, которая рассматривается как единое действие.

Например, оформление заказа может включать создание заказа, запись позиций, изменение остатка и фиксацию платежного статуса.

Если эти действия должны быть выполнены вместе, их можно объединить в транзакцию.

BEGIN;
UPDATE accounts SET balance = balance - 10000 WHERE id = 1;
UPDATE accounts SET balance = balance + 10000 WHERE id = 2;
COMMIT;

Если возникает ошибка, система может выполнить ROLLBACK и отменить незавершенные изменения.

Atomicity — атомарность

Atomicity означает принцип все или ничего.

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

Атомарность защищает систему от частично выполненных действий.

Пример атомарности

Интернет-магазин оформляет заказ.

1. Создает запись orders.
2. Добавляет позиции order_items.
3. Уменьшает остаток товара.
4. Создает запись оплаты.

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

Иначе может появиться заказ без товаров или платеж без корректного заказа.

Atomicity и ROLLBACK

ROLLBACK используется для отмены изменений незавершенной транзакции.

Приложение начинает операцию, выполняет несколько запросов и либо подтверждает их через COMMIT, либо откатывает при ошибке.

Это один из основных механизмов реализации атомарных бизнес-действий.

Atomicity не означает мгновенность

Слово атомарность иногда ошибочно понимают как очень быстрое выполнение.

На самом деле речь идет о неделимости логического результата.

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

Consistency — согласованность

Consistency означает, что транзакция переводит базу из одного допустимого состояния в другое с учетом определенных правил целостности.

Например, Primary Key должен оставаться уникальным, обязательное поле не должно превращаться в NULL, а Foreign Key не должен ссылаться на отсутствующую запись, если ограничение этого не допускает.

Пример Consistency

В системе есть правило: количество товара на складе не может быть отрицательным.

Если заказ пытается списать десять единиц при остатке пять, операция должна быть отклонена или обработана согласно бизнес-правилам.

После завершения транзакции база не должна оказаться в состоянии, нарушающем установленные ограничения.

Что обеспечивает Consistency

Согласованность зависит не только от СУБД.

В ней участвуют несколько уровней.

• типы данных;
• Primary Key;
• Foreign Key;
• UNIQUE;
• NOT NULL;
• CHECK Constraints;
• триггеры;
• бизнес-логика приложения.

СУБД может обеспечить технические ограничения, но смысловые бизнес-правила часто реализует Backend.

Consistency и бизнес-логика

База не всегда знает, что именно считается корректным состоянием бизнеса.

Например, SQL-система может позволить записать скидку 90 процентов, если соответствующего ограничения нет.

Но бизнес может запрещать менеджерам предоставлять скидку выше 20 процентов.

Такое правило должно быть реализовано в подходящем слое приложения или базы.

Isolation — изоляция

Isolation описывает поведение параллельно выполняющихся транзакций.

В production сотни пользователей могут одновременно изменять одни и те же данные.

СУБД должна контролировать их взаимодействие так, чтобы параллельность не приводила к непредсказуемым результатам.

Пример проблемы без изоляции

На складе осталась одна единица товара.

Два покупателя одновременно открывают оформление заказа и оба видят остаток 1.

Если приложение без контроля параллельности разрешит обоим списать товар, склад получит некорректный остаток или будет создано два заказа на один экземпляр.

Механизмы транзакций и изоляции помогают решить такие конфликты.

Уровни изоляции

Реляционные СУБД обычно предоставляют несколько уровней Isolation.

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

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

Read Uncommitted

На слабом уровне изоляции транзакция потенциально может видеть изменения, которые другая транзакция еще не зафиксировала.

Такие данные могут впоследствии быть отменены.

Поэтому этот режим подходит далеко не для всех сценариев.

Dirty Read

Dirty Read — чтение незакоммиченных данных другой транзакции.

Например, транзакция A временно изменила баланс на 50 000, транзакция B прочитала это значение, после чего A выполнила ROLLBACK.

Транзакция B фактически работала с состоянием, которого никогда не существовало как подтвержденного.

Read Committed

Read Committed обычно предотвращает чтение незакоммиченных изменений.

Но между двумя запросами одной транзакции другая транзакция может изменить данные и зафиксировать результат.

Поэтому повторное чтение иногда возвращает другое значение.

Non-repeatable Read

Non-repeatable Read возникает, когда одна транзакция читает строку дважды и между чтениями другая транзакция успевает изменить и подтвердить ее.

В результате один и тот же запрос в рамках бизнес-операции возвращает разные данные.

Repeatable Read

Repeatable Read обеспечивает более строгие гарантии повторного чтения.

Транзакция получает более стабильное представление данных согласно механизму конкретной СУБД.

При этом особенности новых строк, удовлетворяющих условию запроса, зависят от реализации и уровня изоляции.

Phantom Read

Phantom Read связан не с изменением существующей строки, а с появлением или исчезновением строк, подходящих под условие запроса.

Например, первый запрос находит десять заказов со статусом NEW, другая транзакция добавляет еще один, после чего повторная выборка видит уже одиннадцать.

Serializable

Serializable — наиболее строгая классическая модель изоляции.

Результат параллельного выполнения должен соответствовать некоторому последовательному порядку выполнения транзакций.

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

Isolation и блокировки

Один из способов обеспечить изоляцию — использовать блокировки.

Когда транзакция изменяет данные, другие операции могут ожидать освобождения соответствующего ресурса.

Так предотвращаются некоторые конкурентные ошибки.

MVCC

Многие СУБД используют Multi-Version Concurrency Control.

MVCC позволяет хранить несколько логических версий данных, чтобы чтение не всегда блокировало запись и наоборот.

Это помогает поддерживать высокую конкурентность, сохраняя определенный уровень согласованности.

Deadlock

Deadlock возникает, когда две транзакции взаимно ожидают ресурсы, удерживаемые друг другом.

Например, транзакция A заблокировала строку 1 и ждет строку 2, а транзакция B заблокировала строку 2 и ждет строку 1.

СУБД должна обнаружить такую ситуацию и завершить одну из транзакций.

Приложение должно корректно обрабатывать подобные ошибки.

Durability — долговечность

Durability означает, что после успешного COMMIT подтвержденные изменения не должны просто исчезнуть при обычном сбое процесса или перезапуске системы.

СУБД использует журналы и механизмы хранения, позволяющие восстановить подтвержденное состояние.

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

Пример Durability

Пользователь оплачивает заказ. Система фиксирует платеж и возвращает статус успешно.

Через секунду сервер неожиданно перезагружается.

После восстановления подтвержденная операция должна остаться в базе согласно гарантиям выбранной конфигурации.

Write-Ahead Log

СУБД часто используют журналирование изменений перед окончательной записью страниц данных.

Общая идея Write-Ahead Logging состоит в том, чтобы сначала надежно зафиксировать информацию, необходимую для восстановления, а затем изменять основные структуры хранения.

После сбоя журнал помогает восстановить корректное состояние.

Durability и дисковая подсистема

Гарантии долговечности зависят не только от SQL-команд, но и от конфигурации СУБД, операционной системы и оборудования.

Если хранилище неправильно подтверждает запись данных, надежность всей цепочки снижается.

Поэтому критичные системы требуют надежных дисков, резервирования и корректных настроек синхронизации.

Durability и Backup

Durability не заменяет Backup.

Если пользователь выполнил DELETE и транзакция успешно закоммичена, долговечность как раз помогает надежно сохранить это удаление.

Для восстановления случайно удаленных данных нужна отдельная резервная копия или другой механизм восстановления.

ACID и COMMIT

COMMIT — команда подтверждения транзакции.

До COMMIT изменения обычно считаются незавершенными в рамках транзакционной модели.

После подтверждения начинают действовать требования Durability, а результат становится частью зафиксированного состояния согласно правилам конкретной СУБД.

ACID и ROLLBACK

ROLLBACK отменяет незакоммиченные изменения.

Он тесно связан с Atomicity, потому что позволяет вернуть систему к состоянию до неуспешной операции.

Важно понимать, что внешние действия не всегда автоматически откатываются вместе с Database Transaction.

Транзакция базы и внешние системы

Если внутри бизнес-процесса Backend изменяет SQL-базу и одновременно вызывает платежный API, обычная локальная транзакция базы не может автоматически отменить действие во внешнем сервисе.

Например, платеж уже прошел, а SQL COMMIT завершился ошибкой.

Для таких распределенных процессов нужны дополнительные архитектурные подходы: идемпотентность, компенсационные действия, Outbox и другие механизмы.

ACID и микросервисы

В монолите одна транзакция может охватывать несколько таблиц одной базы.

В микросервисной архитектуре каждый сервис часто владеет собственной Database.

Одна локальная ACID-транзакция уже не может просто охватить order-service, payment-service и inventory-service.

Поэтому распределенная согласованность проектируется отдельно.

Saga Pattern

Saga разбивает большой бизнес-процесс на последовательность локальных транзакций.

Если один этап завершается ошибкой, выполняются компенсационные действия.

Например, если оплата прошла, но резерв товара не удался, система может инициировать возврат платежа.

Такой подход не идентичен одной глобальной ACID-транзакции, но помогает управлять распределенным процессом.

Transactional Outbox

Transactional Outbox помогает согласовать изменение базы и публикацию события.

Вместо прямой отправки сообщения после COMMIT приложение в одной локальной транзакции записывает бизнес-изменение и событие в Outbox.

Отдельный Worker затем надежно публикует событие в Message Broker.

Так уменьшается риск ситуации, когда база обновилась, а событие потерялось.

ACID и Event-driven Architecture

В событийной архитектуре локальные базы сервисов могут сохранять ACID-гарантии, но обмен между сервисами остается распределенным.

Сообщения могут доставляться повторно, поэтому Consumers должны учитывать идемпотентность.

ACID решает надежность локальных изменений, но не все проблемы Event-driven системы.

ACID и идемпотентность

Идемпотентность означает, что повтор операции не создает нежелательный дополнительный результат.

Например, повторно доставленное событие PaymentSucceeded не должно дважды зачислить платеж.

ACID Transaction и уникальное ограничение могут использоваться вместе для защиты от подобных повторов.

ACID и SQL

ACID тесно ассоциируется с реляционными SQL-СУБД, поскольку транзакции являются одной из их ключевых возможностей.

PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database и другие системы предоставляют механизмы для построения ACID-транзакций.

Конкретные гарантии зависят от Storage Engine, настроек, уровня изоляции и характера операции.

ACID и PostgreSQL

PostgreSQL широко использует транзакционную модель и MVCC для конкурентной работы пользователей.

Разработчик может объединять связанные INSERT, UPDATE и DELETE в транзакцию и подтверждать их через COMMIT.

Для производительности и корректности важно выбирать подходящий уровень изоляции и обрабатывать конфликты.

ACID и MySQL

В MySQL транзакционность зависит в том числе от используемого Storage Engine.

Для современных бизнес-приложений обычно применяется транзакционный механизм, поддерживающий COMMIT, ROLLBACK и конкурентную работу с данными.

Поэтому при оценке ACID важно смотреть не только на название СУБД, но и на конкретную конфигурацию.

ACID и Microsoft SQL Server

SQL Server предоставляет транзакции, блокировки и механизмы управления изоляцией для корпоративных приложений.

T-SQL позволяет явно начинать, подтверждать и отменять транзакции.

При высокой конкурентной нагрузке важно контролировать блокировки, Deadlock и продолжительность транзакций.

ACID и Oracle Database

Oracle Database использует развитые механизмы транзакций и согласованного чтения.

PL/SQL и SQL могут работать внутри транзакционной модели, а COMMIT и ROLLBACK определяют границы фиксации изменений.

Для критичных систем эти механизмы являются важной частью надежности данных.

ACID и NoSQL

Распространенное заблуждение заключается в том, что NoSQL базы якобы не поддерживают ACID.

В действительности гарантии зависят от конкретного продукта.

Одни NoSQL-системы обеспечивают атомарность на уровне одного документа или ключа, другие поддерживают более широкие транзакции.

Поэтому сравнивать следует конкретные требования приложения и возможности конкретной СУБД.

ACID и MongoDB

MongoDB предоставляет атомарность операций над отдельным документом и может поддерживать транзакции, затрагивающие несколько документов.

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

ACID и Redis

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

Поэтому нельзя автоматически переносить ожидания от SQL ACID Transaction на любой сценарий Redis.

Для критичной логики необходимо проверять конкретные гарантии используемых команд, Persistence и архитектуры.

ACID и BASE

ACID иногда противопоставляют концепции BASE, которая чаще обсуждается применительно к распределенным системам.

На практике современные базы могут сочетать разные свойства, поэтому это не жесткое деление на два несовместимых мира.

ACID и CAP theorem

ACID и CAP theorem описывают разные аспекты систем.

ACID относится прежде всего к свойствам транзакций, а CAP рассматривает поведение распределенной системы при сетевом разделении.

Поэтому нельзя напрямую сказать, что база выбирает ACID вместо CAP.

ACID и Consistency в CAP

Слово Consistency присутствует и в ACID, и в CAP, но смысл различается.

В ACID Consistency означает сохранение правил корректности данных при транзакции.

В CAP Consistency относится к модели наблюдения данных в распределенной системе.

Эти понятия не следует смешивать.

ACID и OLTP

OLTP-системы обрабатывают большое количество коротких бизнес-транзакций.

Например, платежи, заказы, складские операции и изменение документов.

ACID особенно важен для таких систем, поскольку параллельная нагрузка высока, а ошибки в состоянии данных напрямую влияют на бизнес.

ACID и OLAP

OLAP ориентирован прежде всего на аналитическое чтение больших наборов данных.

Транзакционная модель там тоже может иметь значение, но профиль нагрузки отличается от OLTP.

Например, Data Warehouse чаще выполняет тяжелые SELECT и пакетные загрузки, а не тысячи небольших конкурентных платежных операций.

ACID и бухгалтерские системы

В учетных системах особенно важна неделимость связанных изменений.

Например, проведение документа может изменить несколько регистров и связанных записей.

Частично примененное изменение способно исказить отчеты и остатки.

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

ACID и интернет-магазин

Оформление заказа включает несколько связанных операций.

Необходимо создать заказ, зарезервировать товар и зафиксировать определенное состояние оплаты.

Часть действий может находиться в одной базе и выполняться как ACID Transaction, а взаимодействие с внешним платежным сервисом требует дополнительных механизмов согласованности.

ACID и банковские системы

Финансовые системы являются классическим примером важности транзакций.

Перевод, списание комиссии или изменение баланса не должны оставлять систему в неопределенном состоянии.

Однако реальная банковская архитектура значительно сложнее одной Database Transaction и включает журналы, интеграции, аудит и компенсационные процессы.

ACID и Backend

Backend определяет границы бизнес-операции и управляет транзакцией через драйвер или ORM.

Например, сервер начинает Transaction, выполняет несколько SQL-запросов и вызывает COMMIT только после прохождения всех проверок.

Если возникает Exception, приложение выполняет ROLLBACK.

ACID и ORM

ORM обычно предоставляет API для управления транзакциями.

Разработчик может выполнять изменения через объекты, а Framework отправляет соответствующий SQL.

Но ORM не освобождает от понимания ACID, поскольку необходимо правильно определить Transaction Boundary и уровень Isolation.

Transaction Boundary

Transaction Boundary — граница, определяющая, какие операции входят в одну транзакцию.

Слишком маленькая транзакция может не обеспечить необходимую атомарность.

Слишком большая — дольше удерживать ресурсы и повышать вероятность конфликтов.

Граница должна соответствовать одной логической бизнес-операции.

Почему транзакции должны быть короткими

Долгая транзакция удерживает ресурсы и может мешать другим операциям.

Если Backend начинает Transaction, затем несколько секунд ожидает внешний API и только после этого делает COMMIT, база может испытывать ненужные блокировки и рост нагрузки.

Внешние сетевые вызовы обычно стоит отделять от длительно открытой транзакции, если архитектура позволяет.

ACID и производительность

Транзакционные гарантии имеют стоимость.

СУБД должна вести журналы, координировать параллельные операции и обеспечивать необходимые уровни Durability и Isolation.

Но отключение надежности ради производительности без анализа последствий может привести к повреждению бизнес-данных.

Баланс надежности и скорости

Не все данные одинаково критичны.

Для платежа нужны сильные гарантии, а потеря нескольких временных счетчиков просмотров может быть допустима.

Поэтому архитектура должна выбирать уровень надежности в зависимости от бизнес-ценности данных.

ACID и High Availability

ACID не означает, что база всегда доступна.

Сервер может выйти из строя, даже если транзакции на нем корректны.

Для высокой доступности нужны Replication, Failover, кластеризация и другие инфраструктурные механизмы.

ACID и Backup

ACID также не защищает от всех видов потери данных.

Транзакция может корректно и надежно удалить важную запись после ошибки пользователя.

Поэтому Backup и Point-in-Time Recovery решают другую задачу и остаются необходимыми.

ACID и Disaster Recovery

Disaster Recovery обеспечивает восстановление после серьезного отказа инфраструктуры или площадки.

ACID поддерживает корректность транзакций внутри работающей СУБД, а DR определяет, как вернуть систему к работе после масштабного сбоя.

Эти механизмы дополняют друг друга.

ACID и репликация

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

Чем больше узлов должны подтвердить изменение, тем выше потенциальная устойчивость, но тем больше может быть latency.

Конкретные гарантии определяются архитектурой выбранной СУБД.

Типичные ошибки при работе с ACID

1. Считать, что ACID автоматически делает приложение полностью надежным.
2. Открывать транзакцию слишком надолго.
3. Выполнять внешние сетевые вызовы внутри долгой Database Transaction без необходимости.
4. Не обрабатывать Deadlock и конфликты сериализации.
5. Выбирать слабый уровень изоляции, не понимая последствий.
6. Пытаться объединить разные микросервисы обычной локальной транзакцией.
7. Считать Durability заменой Backup.
8. Смешивать Consistency в ACID и CAP.
9. Не определять четкую Transaction Boundary.
10. Не тестировать конкурентные сценарии.

Как правильно использовать ACID-транзакции

Шаг 1. Определить бизнес-инварианты

Нужно понять, какие состояния системы недопустимы.

Шаг 2. Выделить логическую операцию

Связанные изменения должны иметь понятную Transaction Boundary.

Шаг 3. Использовать ограничения базы

Primary Key, Foreign Key, UNIQUE и CHECK помогают защищать Consistency.

Шаг 4. Выбрать Isolation Level

Он должен соответствовать реальной конкурентной нагрузке и требованиям к данным.

Шаг 5. Делать транзакцию короткой

Не нужно удерживать Database Transaction во время длительных внешних операций без необходимости.

Шаг 6. Обрабатывать конфликты

Приложение должно быть готово к Deadlock, Timeout и необходимости безопасного Retry.

Шаг 7. Настроить Backup

Транзакционность не заменяет восстановление данных.

Шаг 8. Тестировать параллельную работу

Ошибки Isolation часто проявляются только при одновременном выполнении операций.

Практический пример

Интернет-магазин принимает заказ на последний экземпляр товара.

Два покупателя одновременно нажимают кнопку Купить.

Backend каждого пользователя начинает транзакцию и пытается уменьшить остаток.

Isolation и механизм конкурентного доступа предотвращают некорректное одновременное списание.

Один заказ успешно получает товар и выполняет COMMIT. Для второго приложение видит, что доступного остатка больше нет, и отменяет операцию.

Atomicity гарантирует, что у неуспешного заказа не останутся частично созданные связанные записи.

Consistency поддерживается ограничениями и бизнес-проверкой остатка.

Isolation контролирует конкурентное выполнение двух заказов.

Durability означает, что после успешного подтверждения результат не должен исчезнуть при обычном перезапуске базы.

При этом резервные копии и репликация используются отдельно, поскольку ACID не решает все задачи надежности инфраструктуры.

ACID для бизнеса

Для бизнеса ACID означает снижение риска некорректных данных в критичных операциях.

Ошибочный баланс, двойное списание товара или частично проведенный документ могут иметь прямые финансовые последствия.

Транзакционная модель помогает сделать такие операции предсказуемыми даже при параллельной нагрузке и технических сбоях.

При этом надежность зависит не только от СУБД. Приложение должно правильно определять границы транзакций, бизнес-инварианты и поведение при ошибках.

Когда ACID особенно важен

• финансовые операции;
• бухгалтерский учет;
• складские остатки;
• заказы и платежи;
• резервирование ограниченных ресурсов;
• изменение нескольких связанных сущностей;
• системы с высокой конкурентной нагрузкой;
• критичные корпоративные данные.

Когда строгая транзакция не всегда нужна

Не каждое значение требует максимальных гарантий.

Счетчик просмотров, временный Cache или телеметрия могут допускать потерю небольшой части последних данных.

В таких сценариях более мягкие гарантии могут уменьшить задержку и стоимость системы.

Важно принимать это решение осознанно, исходя из бизнес-последствий.

Связанные термины

Краткий итог

ACID — это набор четырех свойств транзакций: Atomicity, Consistency, Isolation и Durability. Они помогают базе выполнять связанные изменения как единое действие, сохранять правила целостности, корректно работать при параллельных запросах и не терять подтвержденные результаты.

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

При этом ACID не заменяет Backup, High Availability или Disaster Recovery и не решает автоматически согласованность между несколькими независимыми микросервисами. Надежная архитектура использует транзакции вместе с правильными ограничениями, идемпотентностью, мониторингом и процедурами восстановления.