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

Изоляция транзакций в распределённых системах

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

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

Изоляция (Isolation) — это одно из свойств ACID, которое гарантирует, что одновременные транзакции не влияют друг на друга. В традиционной базе данных это реализуется через блокировки и версионирование.

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

Level 1: READ UNCOMMITTED
  - Грязное чтение (dirty read)
  - Очень слабая изоляция
  - Редко используется

Level 2: READ COMMITTED
  - Нет грязного чтения
  - Возможны некоторые аномалии
  - Довольно распространён

Level 3: REPEATABLE READ
  - Нет грязного чтения
  - Нет non-repeatable read
  - Может быть phantom read

Level 4: SERIALIZABLE
  - Полная изоляция
  - Транзакции выполняются как последовательно
  - Самый строгий уровень

Проблемы в распределённых системах

В распределённых системах изоляция намного сложнее:

1. Множественные базы данных:

// Нужно обновить два сервиса
service1.transfer(-100);  // Убрать деньги
service2.transfer(+100);  // Добавить деньги

// Что если service2 упадёт?
// Money потеряны!

2. Сетевые задержки:

• Нет гарантии атомарности
• Может произойти partial failure
• Невозможно заблокировать ресурсы на другом сервере

3. Консистентность:

• Данные могут быть несогласованными на разных узлах
• Читаем старые данные
• Конфликты обновлений

Теорема CAP

Вы не можете иметь все три одновременно:

CAP Theorem:

Consistency (Консистентность)
  - Все узлы видят одни и те же данные
  - ТРЕБУЕТ синхронизации

Availability (Доступность)
  - Система всегда отвечает
  - НЕСОВМЕСТИМА с синхронной консистентностью

Partition Tolerance (Устойчивость к разделениям)
  - Система работает при сетевых сбоях
  - ТРЕБУЕТСЯ в распределённых системах

Выбираете: CA, CP, или AP

Практические подходы к изоляции

1. Двухфазный коммит (2PC)

// Фаза 1: Prepare
service1.prepare(); // Зарезервировать ресурсы
service2.prepare(); // Зарезервировать ресурсы

// Фаза 2: Commit или Rollback
if (allPrepared) {
    service1.commit();
    service2.commit();
} else {
    service1.rollback();
    service2.rollback();
}

// Проблема: Если coordinator упадёт после prepare?
// Ресурсы остаются заблокированными

2. Saga Pattern (рекомендуется)

// Saga = последовательность локальных транзакций

// Шаг 1: Убрать деньги со счёта A
@Transactional
public void step1() {
    accountService.debit(accountA, 100);
}

// Шаг 2: Добавить деньги на счёт B
@Transactional
public void step2() {
    accountService.credit(accountB, 100);
}

// Шаг 3 (компенсация): Если шаг 2 упал, вернуть деньги
@Transactional
public void compensate() {
    accountService.credit(accountA, 100);
}

// Выполнение Saga
if (step1()) {
    if (!step2()) {
        compensate();  // Откат
    }
}

3. Event Sourcing

// Вместо хранения состояния храним все события

public class AccountEvent {
    String accountId;
    BigDecimal amount;
    String type; // DEBIT, CREDIT
    LocalDateTime timestamp;
}

// История транзакций — источник истины
public class Account {
    public BigDecimal calculateBalance() {
        return events.stream()
            .filter(e -> e.type.equals("DEBIT"))
            .map(AccountEvent::getAmount)
            .reduce(BigDecimal.ZERO, BigDecimal::subtract);
    }
}

4. Конечная консистентность (Eventual Consistency)

// Не требуем синхронную консистентность
// Система будет консистентна со временем

// Сервис A сразу подтверждает операцию
response.setSuccess(true);

// Асинхронно отправляем сообщение Сервису B
messageQueue.send(new TransferEvent(
    fromAccount, toAccount, amount
));

// Сервис B обработает сообщение позже
// В какой-то момент система будет консистентна

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

@Service
public class TransferService {
    
    @Autowired
    private AccountService accountService;
    
    @Autowired
    private TransactionRepository txRepo;
    
    // Локальная транзакция — изолирована в одной БД
    @Transactional(isolation = Isolation.SERIALIZABLE)
    public void transferLocal(String from, String to, BigDecimal amount) {
        accountService.debit(from, amount);
        accountService.credit(to, amount);
    }
    
    // Распределённая транзакция через Saga
    public void transferDistributed(String from, String to, BigDecimal amount) {
        try {
            // Шаг 1: Локальная транзакция в сервисе A
            accountService.debit(from, amount);
            txRepo.save(new Transaction(
                from, to, amount, TransactionStatus.PENDING
            ));
            
            // Шаг 2: Отправляем событие сервису B
            eventPublisher.publishEvent(
                new MoneyTransferEvent(from, to, amount)
            );
            
        } catch (Exception e) {
            // Откат: компенсирующая транзакция
            accountService.credit(from, amount);
            txRepo.save(new Transaction(
                from, to, amount, TransactionStatus.FAILED
            ));
            throw new TransferException(e);
        }
    }
}

Уровни изоляции в распределённых системах

Strong Consistency (Строгая консистентность)

• Требует координации между узлами
• Медленно (высокие задержки)
• Сложно реализовать
• Примеры: Google Spanner, Cockroach DB

Eventual Consistency (Конечная консистентность)

• Быстро (низкие задержки)
• Асинхронная репликация
• Временная несогласованность
• Примеры: DynamoDB, Cassandra

Causal Consistency

• Причинно-следственная связь
• Быстрее строгой, медленнее конечной
• Хорошо для большинства приложений

Транзакции в распределённых БД

// PostgreSQL (традиционная ACID)
@Transactional(isolation = Isolation.SERIALIZABLE)
public void acidTransaction() {
    // Полная изоляция, но медленно
}

// MongoDB (документы, локальные транзакции)
@Transactional
public void mongoTransaction() {
    // Изолирована внутри одного документа или сессии
}

// Cassandra (конечная консистентность)
public void cassandraWrite() {
    // Нет транзакций
    // Только eventual consistency
}

Ответ на вопрос

Возможна ли изоляция в распределённых системах?

ДА, но с компромиссами:

1. Строгая изоляция — возможна, но очень дорога (низкая доступность, высокие задержки)

2. Слабая изоляция — легко реализуется (высокая доступность, низкие задержки)

3. Pragmatic approach — используем Saga, Event Sourcing, Eventual Consistency для большинства случаев

4. Выбор зависит от требований:

   • Нужна строгая консистентность? → используй 2PC или синхронные координацию
   • Нужна высокая доступность? → используй Saga и eventual consistency
   • Нужен баланс? → используй causal consistency

В современных микросервисных архитектурах предпочитают использовать Saga Pattern и Event Sourcing, так как они обеспечивают хороший баланс между консистентностью, доступностью и производительностью.