Что такое реплицирование?

Что такое реплицирование

Реплицирование (replication) — это процесс создания и поддержания копий данных на нескольких узлах системы с целью обеспечения отказоустойчивости, высокой доступности и улучшения производительности. В контексте распределённых систем это критическая концепция.

Основные цели реплицирования

1. Отказоустойчивость Если один узел выходит из строя, данные остаются доступными на других узлах.

2. Высокая доступность Система продолжает работать даже при сбое части инфраструктуры.

3. Производительность Данные расположены ближе к пользователям, снижая задержку.

4. Масштабируемость Распределение нагрузки между несколькими серверами.

Типы реплицирования

1. Синхронное реплицирование

// Главный узел ждёт подтверждения от реплик перед ответом
type Database struct {
    primary   *DBNode
    replicas  []*DBNode
}

func (db *Database) Write(key string, value interface{}) error {
    // Записываем на primary
    err := db.primary.Write(key, value)
    if err != nil {
        return err
    }
    
    // Ждём, пока ВСЕ реплики подтвердят
    for _, replica := range db.replicas {
        err := replica.Write(key, value)
        if err != nil {
            return err  // Откатываем, если хоть одна реплика упала
        }
    }
    
    return nil
}

Преимущества: строгая консистентность данных Недостатки: медленнее, зависит от самого медленного узла

2. Асинхронное реплицирование

// Primary отвечает сразу, репликация идёт в фоне
func (db *Database) Write(key string, value interface{}) error {
    err := db.primary.Write(key, value)
    if err != nil {
        return err
    }
    
    // Отвечаем клиенту сразу
    // Репликация в фоне
    go func() {
        for _, replica := range db.replicas {
            replica.Write(key, value)
        }
    }()
    
    return nil
}

Преимущества: быстрее, высокая доступность Недостатки: возможна временная несогласованность данных

Архитектуры реплицирования

1. Master-Slave (Primary-Replica) Один главный узел получает все записи, реплики только читают и получают обновления.

┌─────────────┐
│   Master    │  ← Все writes идут сюда
└──────┬──────┘
       │
       ├─→ Replication Stream
       │
       ▼
┌─────────────┐  ┌─────────────┐
│  Slave 1    │  │  Slave 2    │  ← Reads идут сюда
└─────────────┘  └─────────────┘

2. Master-Master (Multi-Master) Несколько узлов могут принимать записи с разрешением конфликтов.

┌─────────────┐       ┌─────────────┐
│  Master 1   │←─────→│  Master 2   │
└─────────────┘       └─────────────┘
      ↓                      ↓
   Replication           Replication

3. Quorum-Based Запись подтверждается большинством узлов (не все).

const QUORUM = 2  // Нужны подтверждения от 2 из 3 узлов

func (db *Database) Write(key string, value interface{}) error {
    confirmations := 0
    
    for _, node := range db.nodes {
        err := node.Write(key, value)
        if err == nil {
            confirmations++
        }
    }
    
    if confirmations < QUORUM {
        return errors.New("failed to reach quorum")
    }
    
    return nil
}

CAP теорема в контексте реплицирования

Distributed CAP теорема гласит, что при сетевом разделении невозможно одновременно иметь:

• Consistency (консистентность)
• Availability (доступность)
• Partition tolerance (устойчивость к разделению)

При сетевом разделении между узлами:

Выбираем CP (Consistency + Partition):
  → Отказываем в операции, пока система не восстановится
  → PostgreSQL с синхронной репликацией

Выбираем AP (Availability + Partition):
  → Отвечаем, может быть несогласованность
  → Eventual consistency
  → DynamoDB, Cassandra

Реальные примеры

PostgreSQL

-- Синхронная репликация
ALTER SYSTEM SET synchronous_commit = 'remote_apply';
SELECT pg_ctl_reload_conf();

Redis

# Redis использует асинхронную репликацию по умолчанию
./redis-server --slaveof 127.0.0.1 6379

Raft Algorithm (используется в etcd, Consul)

// Raft обеспечивает согласованную репликацию
// - Leader выбирается
// - Логи реплицируются перед коммитом
// - Гарантирует безопасность и прогресс

Практические рекомендации

1. Для критических данных: используй синхронную репликацию (CP)
2. Для высокой доступности: используй асинхронную репликацию (AP)
3. Для масштабируемости: рассмотри sharding + реплицирование
4. Мониторь lag: отслеживай задержку между мастером и репликами
5. Failover: автоматизируй переход на реплику при сбое

Реплицирование — это баланс между консистентностью, доступностью и сложностью системы.