Как называеться свойство когда все или не все во время транзации?

Ответ: ACID-свойства транзакций

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

ACID: Основные свойства транзакций

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

1. Atomicity (Атомарность) — Это именно то свойство, которое вы имеете в виду, говоря "все или не все". Атомарность гарантирует, что транзакция выполняется полностью (со всеми своими операциями) или не выполняется вовсе. Нет промежуточных состояний. Если на любом этапе выполнения транзакции произойдёт ошибка (сбой приложения, отключение питания, логическая ошибка), все уже выполненные изменения в рамках этой транзакции будут откатаны (rollback). Система вернётся в состояние, которое было до начала транзакции, как будто её и не было.

    *   **Пример**: Перевод денег между счетами (`UPDATE` баланса счёта A, `UPDATE` баланса счёта B). Атомарность гарантирует, что либо оба `UPDATE` успешно завершатся (деньги спишутся с одного счёта и зачислятся на другой), либо оба откатятся (балансы останутся прежними). Ситуация, когда деньги списались, но не зачислились, невозможна.

1. Consistency (Согласованность) — Это свойство гарантирует, что каждая успешная транзакция переводит базу данных из одного согласованного состояния в другое. Данные должны удовлетворять всем заданным правилам, ограничениям (constraints), триггерам и каскадным операциям. Если транзакция нарушает эти правила, она будет откачена.

    *   **Пример**: Ограничение `CHECK (balance >= 0)` на столбец `balance`. Транзакция, которая пытается установить отрицательный баланс, будет прервана, а изменения не применятся.

1. Isolation (Изолированность) — Гарантирует, что параллельно выполняющиеся транзакции не влияют друг на друга. Результат выполнения изолированной транзакции должен быть таким, как если бы она выполнялась в системе одна. Уровни изоляции (Read Uncommitted, Read Committed, Repeatable Read, Serializable) определяют степень этой изоляции и баланс между строгостью и производительностью.

2. Durability (Долговечность/Устойчивость) — Гарантирует, что если транзакция была зафиксирована (committed), то её результаты будут сохранены постоянно, даже в случае сбоя системы (например, после восстановления питания). Обычно это достигается через запись в журнал транзакций (WAL — Write-Ahead Logging) перед подтверждением commit'а пользователю.

Атомарность в Go: Пример реализации

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

package main

import (
    "context"
    "database/sql"
    "fmt"
    "log"
)

func transferMoney(ctx context.Context, db *sql.DB, fromID, toID int, amount float64) error {
    // 1. Начинаем транзакцию. С этого момента все операции будут частью одной единицы работы.
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return fmt.Errorf("failed to begin transaction: %w", err)
    }

    // Флаг для отката в случае ошибки. По умолчанию откатываем.
    shouldRollback := true
    defer func() {
        if shouldRollback {
            // Если мы здесь и shouldRollback == true, значит, произошла ошибка.
            // Пытаемся откатить изменения. Ошибка отката важна для логирования.
            if rbErr := tx.Rollback(); rbErr != nil {
                log.Printf("WARNING: failed to rollback transaction: %v", rbErr)
            }
        }
    }()

    // 2. Выполняем операции внутри транзакции.
    // Списание средств
    _, err = tx.ExecContext(ctx,
        "UPDATE accounts SET balance = balance - $1 WHERE id = $2 AND balance >= $1",
        amount, fromID,
    )
    if err != nil {
        return fmt.Errorf("failed to withdraw: %w", err)
    }

    // Зачисление средств
    _, err = tx.ExecContext(ctx,
        "UPDATE accounts SET balance = balance + $1 WHERE id = $2",
        amount, toID,
    )
    if err != nil {
        return fmt.Errorf("failed to deposit: %w", err)
    }

    // 3. Если все операции успешны, фиксируем транзакцию.
    // После Commit все изменения становятся постоянными.
    if err = tx.Commit(); err != nil {
        return fmt.Errorf("failed to commit transaction: %w", err)
    }

    // 4. Отмечаем, что откат больше не нужен.
    shouldRollback = false
    fmt.Println("Transfer completed successfully")
    return nil
}

func main() {
    // db := sql.Open(...) - инициализация базы данных
    // err := transferMoney(context.Background(), db, 1, 2, 100.0)
}

Как это работает с точки зрения "всё или ничего":

• Если ошибка произойдёт на этапе списания (UPDATE ... WHERE id = $1), выполнение функции прервётся, defer вызовет tx.Rollback(), и первое UPDATE не сохранится.
• Если ошибка произойдёт на этапе зачисления (UPDATE ... WHERE id = $2), сработает тот же механизм отката, и первое UPDATE также будет отменено.
• Только если оба UPDATE и вызов tx.Commit() завершатся успешно, изменения будут применены к базе данных как единое целое.

Важность в распределённых системах (микросервисы)

В современной архитектуре (микросервисы) обеспечить классическую ACID-транзакцию между несколькими сервисами и их базами данных очень сложно. Здесь на первый план выходят паттерны Saga (длительные транзакции с компенсирующими действиями) и принципы Eventual Consistency (Конечная согласованность), которые жертвуют немедленной атомарностью и изоляцией в пользу доступности и масштабируемости.

Итак, прямо отвечая на ваш вопрос: свойство, гарантирующее, что транзакция выполнится полностью или не выполнится вовсе, называется Атомарность (Atomicity). Это краеугольный камень модели ACID, обеспечивающий целостность данных в критических операциях.