Как называется набор требований к транзакциям?

Требования к транзакциям: ACID

Набор требований к транзакциям в контексте баз данных и распределённых систем называется ACID. Это акроним, образованный от четырёх ключевых свойств, которые гарантируют надёжность и предсказуемость обработки транзакций, даже в условиях сбоев или параллельного выполнения. В мире Go-разработки, особенно при работе с базами данных (PostgreSQL, MySQL) или построении распределённых сервисов, понимание ACID является фундаментальным.

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

ACID состоит из следующих свойств:

1. Atomicity (Атомарность)

    Транзакция выполняется как единое, неделимое целое. Она либо выполняется **полностью**, либо не выполняется **совсем**. Не допускаются промежуточные состояния. В случае любой ошибки (сбой системы, логическая ошибка в коде) все уже выполненные в рамках транзакции изменения должны быть отменены (*откатаны*, **rollback**).

    **Пример на Go с `database/sql`:**

```go
tx, err := db.Begin() // Начало транзакции
if err != nil {
    log.Fatal(err)
}
defer tx.Rollback() // Гарантированный откат при выходе из функции, если не был commit

_, err = tx.Exec("UPDATE accounts SET balance = balance - $1 WHERE id = $2", 100, 1)
if err != nil {
    return err // Транзакция будет откатана из-DE defer
}

_, err = tx.Exec("UPDATE accounts SET balance = balance + $1 WHERE id = $2", 100, 2)
if err != nil {
    return err // Первое UPDATE также будет откатано! Это и есть атомарность.
}

err = tx.Commit() // Фиксация изменений только здесь.
if err != nil {
    return err
}
// Теперь оба изменения сохранены необратимо.
```

2. Consistency (Согласованность)

    Транзакция переводит базу данных из одного **корректного состояния** в другое. Это означает, что все бизнес-правила, ограничения (**constraints**), уникальные индексы, каскадные операции и триггеры должны быть соблюдены. Если транзакция нарушает эти правила, она будет откатана. Это свойство обеспечивается совместно приложением (которое формирует корректные запросы) и СУБД (которая проверяет ограничения).

1. Isolation (Изолированность)

    Параллельно выполняемые транзакции не должны влиять друг на друга. Результат одновременного выполнения нескольких транзакций должен быть эквивалентен их **последовательному** выполнению. Уровни изоляции (Read Uncommitted, Read Committed, Repeatable Read, Serializable) определяют степень этой "невидимости" изменений из других транзакций, являясь компромиссом между строгой изоляцией и производительностью.

    **Проблемы при слабой изоляции:** **"Грязное" чтение (dirty read)**, **неповторяющееся чтение (non-repeatable read)**, **фантомное чтение (phantom read)**.

1. Durability (Долговечность)

    После успешного завершения транзакции (**commit**) её результаты должны быть **навсегда** сохранены в системе, даже в случае последующего аппаратного или программного сбоя. Обычно это достигается записью в постоянное хранилище (жёсткий диск, SSD) и использованием **WAL (Write-Ahead Logging)**.

Значение ACID для Go-разработчика

• Надёжность: Позволяет строить системы, где критические операции (финансовые переводы, изменения статуса заказа) выполняются безопасно.
• Упрощение модели: Разработчик может мыслить в терминах целых бизнес-операций, а не отдельных запросов.
• Работа с конкурентностью: Уровни изоляции помогают управлять параллельным доступом к данным без явных низкоуровневых блокировок в коде.
• Выбор инструментов: Понимание ACID помогает выбрать подходящую СУБД (например, PostgreSQL для строгого ACID) или, наоборот, осознанно отказаться от некоторых свойств в пользу масштабируемости, выбрав NoSQL решение, которое часто следует модели BASE (Basically Available, Soft state, Eventual consistency) — противоположному подходу.

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