Как работает синхронная репликация?

Синхронная репликация: принцип работы и детали реализации

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

Основной принцип работы

В синхронной репликации каждая операция изменения данных проходит следующие этапы:

// Упрощенная модель синхронной репликации
type SynchronousReplicator struct {
    primary    *Node
    replicas   []*Node
    quorumSize int
}

func (r *SynchronousReplicator) Write(data []byte) error {
    // 1. Клиент отправляет запрос на первичную реплику
    primaryAck := make(chan error, 1)
    go func() { primaryAck <- r.primary.Prepare(data) }()
    
    // 2. Первичная реплика рассылает данные всем вторичным репликам
    replicaAcks := make([]chan error, len(r.replicas))
    for i, replica := range r.replicas {
        replicaAcks[i] = make(chan error, 1)
        go func(idx int, rep *Node) {
            replicaAcks[idx] <- rep.Replicate(data)
        }(i, replica)
    }
    
    // 3. Ожидание подтверждений от ВСЕХ реплик
    if err := <-primaryAck; err != nil {
        return fmt.Errorf("primary failed: %w", err)
    }
    
    for i, ackChan := range replicaAcks {
        if err := <-ackChan; err != nil {
            return fmt.Errorf("replica %d failed: %w", i, err)
        }
    }
    
    // 4. Только после всех подтверждений операция считается успешной
    return r.primary.Commit(data)
}

Ключевые характеристики

Требование кворума (Quorum Requirement):

• Для записи требуется подтверждение от N из N реплик
• Любой отказ реплики блокирует операцию записи
• Гарантирует, что все реплики содержат одинаковые данные в любой момент времени

Последовательность операций:

1. Подготовка (Prepare) — первичная реплика валидирует операцию
2. Рассылка (Broadcast) — данные отправляются всем репликам
3. Ожидание подтверждений (Acknowledge Wait) — ожидание ответов от всех узлов
4. Фиксация (Commit) — подтверждение успешной записи клиенту
5. Завершение (Finalize) — реплики применяют изменения

Преимущества и недостатки

Преимущества:

• Строгая согласованность — все реплики идентичны
• Нулевая потеря данных при сбоях
• Простота восстановления — любая реплика может стать первичной
• Гарантированная целостность транзакций

Недостатки:

• Высокая задержка — определяется самым медленным узлом
• Низкая доступность — один отказавший узел блокирует всю систему
• Ограничение масштабируемости — каждый новый узел увеличивает задержку
• Проблема с географическим распределением — задержки сети становятся критичными

Реализация в Go

В Go синхронную репликацию часто реализуют с использованием горутин и каналов для параллельного ожидания подтверждений:

package replication

import (
    "context"
    "errors"
    "sync"
    "time"
)

type SyncReplica struct {
    nodes []*DataNode
    mu    sync.RWMutex
}

func (sr *SyncReplica) SyncWrite(ctx context.Context, data []byte) error {
    sr.mu.Lock()
    defer sr.mu.Unlock()
    
    var wg sync.WaitGroup
    errCh := make(chan error, len(sr.nodes))
    
    // Отправка данных всем узлам параллельно
    for _, node := range sr.nodes {
        wg.Add(1)
        go func(n *DataNode) {
            defer wg.Done()
            select {
            case errCh <- n.WriteData(ctx, data):
            case <-ctx.Done():
                errCh <- ctx.Err()
            }
        }(node)
    }
    
    // Закрываем канал после завершения всех горутин
    go func() {
        wg.Wait()
        close(errCh)
    }()
    
    // Собираем все ошибки
    var errs []error
    for err := range errCh {
        if err != nil {
            errs = append(errs, err)
        }
    }
    
    // Если есть ошибки - откатываем операцию
    if len(errs) > 0 {
        sr.rollbackWrite(ctx, data)
        return errors.Join(errs...)
    }
    
    return nil
}

Практические аспекты и оптимизации

Таймауты и обработка ошибок:

• Настройка разумных таймаутов для каждой реплики
• Стратегии повторных попыток (retry policies)
• Механизмы компенсирующих транзакций для отката

Гибридные подходы:

• Полусинхронная репликация — ожидание подтверждения от большинства узлов
• Синхронная с деградацией — переход в асинхронный режим при проблемах
• Кворумные записи — подтверждение от N/2+1 узлов вместо всех

Применение в современных системах:

• Финансовые транзакции (банковские системы)
• Регистры медицинских записей
• Системы управления конфигурацией
• Критически важные метаданные

Заключение

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