ACID разбирает четыре свойства транзакций. CAP рассматривает конфликт формальной доступности и атомарной согласованности при разделении сети. Одинаковая буква C не делает это одной проверкой: корректность данных заказа и допустимый порядок сетевых операций проверяют отдельно.
Практический смысл
Почему это важно
Для одного заказа эти свойства дают четыре разные проверки. Запись заказа и резерв должны завершиться вместе; данные должны соблюдать правила продажи; две продажи не должны совместно нарушить эти правила; подтверждённый результат должен пережить оговорённый сбой. Название СУБД или более быстрый сервер ни одну из этих проверок не заменяют.
Доказательная часть
Что подтверждено
ACID объединяет атомарность, согласованность, изоляцию и долговечность. Атомарность связывает общий исход изменений; согласованность — допустимость состояния; изоляция — взаимодействие параллельных транзакций; долговечность — сохранение зафиксированного результата при предусмотренных отказах.
Граница применимости: Классическая модель транзакций; конкретные уровни изоляции и ослабленные режимы подтверждения требуют отдельного описания.
Заявление об ACID у локальной базы не доказывает атомарность внешней оплаты, согласование реплик большинством или возможность восстановиться до ошибочного удаления. Для этих задач нужны собственные участники, протоколы и материалы восстановления.
Граница применимости: Граница локальной транзакции, распределённой координации и восстановления истории; вывод из сопоставления моделей.
Для заказа атомарность проверяют на связанных изменениях одной транзакции: при полном откате одновременно отменяются создание заказа и резерв. Успешное завершение каждой команды по отдельности не доказывает общий исход всей операции.
Граница применимости: Редакторский пример свойства A для двух транзакционно управляемых изменений; цена, остаток и внешний платёж не считаются автоматически включёнными.
Свойство C предполагает заданные правила допустимого состояния и корректную логику перехода. База может отклонить нарушение объявленного ограничения, но не распознаёт неописанное правило скидки, кредитного лимита или адресата платежа.
Граница применимости: Согласованность ACID и граница ограничений данных; деловые примеры иллюстрируют необходимость явно заданных правил.
Проверка одного заказа без конкурентов не проверяет изоляцию. Две транзакции могут читать только зафиксированные данные и всё же совместно дать результат, который нельзя получить при их последовательном выполнении; PostgreSQL 18 допускает такие аномалии ниже Serializable.
Граница применимости: Свойство I; аномалия сериализации в модели и уровнях PostgreSQL 18. Не утверждение, что каждая пара конкурентных операций ошибочна.
Для свойства D требуется назвать, какое событие считается подтверждением и какой отказ результат должен пережить. В PostgreSQL 18 ожидание устойчивой локальной записи WAL и ожидание синхронной реплики определяются настройками; сохранность локального носителя не доказывает сохранность после его полной утраты.
Граница применимости: Модель долговечности и условия подтверждения PostgreSQL 18; отказ носителя рассматривается при отсутствии другой пригодной копии.
Буква C обозначает разные условия в ACID и CAP. В ACID речь о сохранении правил допустимых данных. В формализации CAP — об атомарной согласованности операций, то есть их порядке, совместимом с реальным временем. Доказательство одного условия не доказывает второе.
Граница применимости: Редакторское сопоставление модели транзакций и формального условия согласованности Gilbert–Lynch; не перечень свойств конкретного продукта.
Граница терминов
Не путать
Долговечность сохраняет принятый результат при оговорённом отказе. Проверенное восстановление устанавливает, можно ли получить нужное состояние из сохранённых материалов. Ошибочное удаление может быть надёжно зафиксировано, поэтому требуется история, предшествующая ошибке.
Перед спецификацией
Что проверить
- Запишите для заказа конкретные требования A, C, I и D четырьмя отдельными проверяемыми предложениями.
- Для A остановите выполнение посередине и убедитесь, что полный откат убирает все изменения внутри заявленной границы.
- Для C отправьте неверный остаток, повторный номер и недопустимую скидку; установите, какое ограничение или участок кода отклоняет каждый случай.
- Для I одновременно выполните две продажи последнего доступного товара и проверьте совместный результат.
- Для D зафиксируйте настройки подтверждения и испытайте предусмотренный сбой на отдельном тестовом контуре.
- Проверьте обработку отказа транзакции: приложение должно корректно сообщать результат и повторять только разрешённую операцию.
- Отдельно подтвердите план внешней оплаты, сохранённую историю и успешную проверку восстановления до ошибки.
Открытые основания
Первоисточники
The Transaction Model — Turing Award Lecture
Microsoft Research / ACM · Jim Gray, FCRC 1999 lecture slides
Первичный обзор transaction model, ACID, concurrency anomalies, logs и two-phase commit.
Открыть первоисточникPostgreSQL 18 Documentation: PREPARE TRANSACTION
PostgreSQL Global Development Group · PostgreSQL 18 SQL command reference
Описывает prepared transaction, external transaction manager и operational risk forgotten prepared state.
Открыть первоисточникIn Search of an Understandable Consensus Algorithm (Extended Version)
Stanford University / USENIX · Ongaro and Ousterhout, USENIX ATC 2014 extended paper
Первичное описание Raft: leader election, replicated log, commit majority и safety.
Открыть первоисточникPostgreSQL 18 Documentation: Continuous Archiving and Point-in-Time Recovery
PostgreSQL Global Development Group · PostgreSQL 18, Chapter 25.3
Связывает base backup, непрерывный WAL archive и проверяемый recovery target.
Открыть первоисточникPostgreSQL 18 Documentation: Transactions
PostgreSQL Global Development Group · документация PostgreSQL 18, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Проверить границы BEGIN/COMMIT/ROLLBACK, отдельные транзакции без BEGIN, точки сохранения и оговорку о поведении клиентских библиотек.
Открыть первоисточникPostgreSQL 18 Documentation: Constraints
PostgreSQL Global Development Group · документация PostgreSQL 18, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Проверить CHECK и NULL, NOT NULL, UNIQUE и границу проверок одной строки; пример заказа — редакторское применение этих правил.
Открыть первоисточникPostgreSQL 18 Documentation: Transaction Isolation
PostgreSQL Global Development Group · PostgreSQL 18, Chapter 13.2
Определяет isolation phenomena и фактическое поведение PostgreSQL levels, включая Serializable.
Открыть первоисточникPostgreSQL 18 Documentation: Write-Ahead Logging
PostgreSQL Global Development Group · PostgreSQL 18, Chapter 28.3
Определяет write-ahead rule, REDO crash recovery и роль checkpoint.
Открыть первоисточникPostgreSQL 18 Documentation: Log-Shipping Standby Servers
PostgreSQL Global Development Group · PostgreSQL 18, Chapter 26.2
Фиксирует async default, synchronous commit wait points и связь replication delay с data loss.
Открыть первоисточникBrewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services
MIT Laboratory for Computer Science · Gilbert and Lynch, SIGACT News 33(2), 2002
Формализует CAP impossibility для atomic consistency и availability в asynchronous network model.
Открыть первоисточник