Консенсус распределённых баз данных: 6 ключевых модулей Raft от теории до реализации

Распределённый консенсус — краеугольный камень распределённых баз данных—TiDB, CockroachDB, etcd и Consul все полагаются на протоколы консенсуса для обеспечения согласованности данных. Однако статья о Paxos печально известна своей непонятностью, а её инженерная реализация ещё более адова; проблемы split-brain заставляют бесчисленные команды тушить пожары глубокой ночью; нестабильность выборов лидера вызывает прерывистую недоступность сервиса; задержка репликации логов делает межрегиональные развёртывания практически бесполезными; а гарантии линеаризуемой согласованности доставляют разработчикам бесконечные головные боли. Протокол Raft, разработанный с «понятностью» как основной принцип, разбивает проблему консенсуса на три подзадачи—выбор лидера, репликацию логов и безопасность—став де-факто стандартным протоколом консенсуса для распределённых баз данных в 2026 году.

Ключевые концепции вкратце

Концепция	Описание
Raft	Понятный протокол распределённого консенсуса, разбивающий консенсус на выборы, репликацию и безопасность
Выбор лидера	Follower истекает по таймауту, становится Candidate, инициирует выборы, получает большинство голосов и становится Leader
Репликация логов	Leader реплицирует клиентские запросы как записи лога на все Follower
Таймаут Heartbeat	Leader отправляет периодические heartbeat; Follower инициируют выборы при таймауте
Терм	Логические часы Raft, увеличиваются на каждых выборах, используются для обнаружения устаревшей информации
Индекс коммита	Индекс лога, подтверждённый большинством узлов; записи до этого индекса закоммичены
Снимок	Сжимает закоммиченные логи в снимок состояния для предотвращения неограниченного роста лога
Изменение состава	Динамическое добавление/удаление узлов кластера без появления двух лидеров
Линеаризуемая согласованность	Чтения наблюдают самую последнюю запись; Raft реализует через ReadIndex или Lease Read

Пять ключевых вызовов

Продукционный консенсус Raft — это гораздо больше, чем «выбрать лидера и реплицировать логи». Вы должны решить эти 5 ключевых задач:

1. Стабильность выборов лидера — Сетевые колебания вызывают частые выборы, делая кластер недоступным во время переходов лидера. Как избежать штормов выборов? Как установить разумные параметры таймаута?

2. Согласованность репликации логов — После сетевых разделений логи могут расходиться. Как усекать конфликтующие логи после восстановления? Как позволить медленным узлам догнать без влияния на общую пропускную способность?

3. Обработка сетевых разделений — Миноритарный раздел продолжает терпеть неудачу на выборах, в то время как мажоритарный раздел обслуживает нормально. Как безопасно объединить после восстановления разделения?

4. Безопасность изменения состава — Добавление/удаление узлов за один шаг может создать окно, в котором сосуществуют два лидера. Как реализовать безопасные изменения состава?

5. Снимки и уплотнение логов — Неограниченный рост логов исчерпывает диск и память. Когда запускать снимки? Как передавать снимки без блокировки нормальной репликации?

Модуль 1: Конечный автомат Raft и выбор лидера

Узлы Raft имеют три состояния: Follower, Candidate и Leader. Follower, не получивший heartbeat в течение таймаута выборов, становится Candidate и инициирует выборы.

type NodeState int

const (
    Follower NodeState = iota
    Candidate
    Leader
)

type RaftNode struct {
    mu            sync.Mutex
    id            int
    state         NodeState
    currentTerm   int
    votedFor      int
    log           []LogEntry
    commitIndex   int
    lastApplied   int
    nextIndex     map[int]int
    matchIndex    map[int]int
    heartbeatCh   chan struct{}
    electionTimer *time.Timer
    peers         []string
}

func (rn *RaftNode) startElection() {
    rn.mu.Lock()
    rn.state = Candidate
    rn.currentTerm++
    rn.votedFor = rn.id
    term := rn.currentTerm
    lastLogIndex := len(rn.log) - 1
    lastLogTerm := 0
    if lastLogIndex >= 0 {
        lastLogTerm = rn.log[lastLogIndex].Term
    }
    rn.mu.Unlock()

    votesReceived := 1
    voteCh := make(chan bool, len(rn.peers))

    for i, peer := range rn.peers {
        if i == rn.id {
            continue
        }
        go func(peerAddr string) {
            resp := rn.requestVote(peerAddr, &RequestVoteArgs{
                Term:         term,
                CandidateID:  rn.id,
                LastLogIndex: lastLogIndex,
                LastLogTerm:  lastLogTerm,
            })
            voteCh <- resp.VoteGranted
        }(peer)
    }

    for i := 0; i < len(rn.peers)-1; i++ {
        if <-voteCh {
            votesReceived++
        }
    }

    rn.mu.Lock()
    defer rn.mu.Unlock()
    if votesReceived > len(rn.peers)/2 && rn.currentTerm == term {
        rn.state = Leader
        rn.nextIndex = make(map[int]int)
        rn.matchIndex = make(map[int]int)
        for i := range rn.peers {
            rn.nextIndex[i] = len(rn.log)
            rn.matchIndex[i] = 0
        }
        go rn.heartbeatLoop()
    }
}

Ключевой момент: Таймауты выборов должны быть рандомизированы (150-300мс), чтобы предотвратить одновременный таймаут всех узлов и расщепление голосов. Candidate должен набрать большинство голосов, чтобы стать Leader.

Модуль 2: Репликация логов и согласованность

Когда Leader получает клиентский запрос, он добавляет операцию в свой локальный лог, затем реплицирует её на все Follower. Как только большинство подтверждает, запись коммитится.

type LogEntry struct {
    Term    int
    Index   int
    Command interface{}
}

func (rn *RaftNode) appendEntries(args *AppendEntriesArgs) *AppendEntriesReply {
    rn.mu.Lock()
    defer rn.mu.Unlock()

    reply := &AppendEntriesReply{Term: rn.currentTerm}

    if args.Term < rn.currentTerm {
        reply.Success = false
        return reply
    }

    if args.PrevLogIndex >= 0 {
        if args.PrevLogIndex >= len(rn.log) {
            reply.Success = false
            return reply
        }
        if rn.log[args.PrevLogIndex].Term != args.PrevLogTerm {
            rn.log = rn.log[:args.PrevLogIndex]
            reply.Success = false
            return reply
        }
    }

    for i, entry := range args.Entries {
        idx := args.PrevLogIndex + 1 + i
        if idx < len(rn.log) {
            if rn.log[idx].Term != entry.Term {
                rn.log = rn.log[:idx]
                rn.log = append(rn.log, entry)
            }
        } else {
            rn.log = append(rn.log, entry)
        }
    }

    if args.LeaderCommit > rn.commitIndex {
        lastNewIdx := args.PrevLogIndex + len(args.Entries)
        if args.LeaderCommit < lastNewIdx {
            rn.commitIndex = args.LeaderCommit
        } else {
            rn.commitIndex = lastNewIdx
        }
    }

    rn.currentTerm = max(rn.currentTerm, args.Term)
    reply.Term = rn.currentTerm
    reply.Success = true
    return reply
}

func (rn *RaftNode) replicateLog() {
    rn.mu.Lock()
    defer rn.mu.Unlock()

    if rn.state != Leader {
        return
    }

    for i, peer := range rn.peers {
        if i == rn.id {
            continue
        }
        prevIdx := rn.nextIndex[i] - 1
        prevTerm := 0
        if prevIdx >= 0 && prevIdx < len(rn.log) {
            prevTerm = rn.log[prevIdx].Term
        }
        entries := rn.log[rn.nextIndex[i]:]

        go func(peerAddr string, peerID int) {
            resp := rn.sendAppendEntries(peerAddr, &AppendEntriesArgs{
                Term:         rn.currentTerm,
                LeaderID:     rn.id,
                PrevLogIndex: prevIdx,
                PrevLogTerm:  prevTerm,
                Entries:      entries,
                LeaderCommit: rn.commitIndex,
            })
            rn.mu.Lock()
            if resp.Success {
                rn.nextIndex[peerID] = prevIdx + len(entries) + 1
                rn.matchIndex[peerID] = rn.nextIndex[peerID] - 1
            } else {
                rn.nextIndex[peerID] = max(1, rn.nextIndex[peerID]-1)
            }
            rn.mu.Unlock()
        }(peer, i)
    }
}

Ключевой момент: Проверки согласованности логов используют PrevLogIndex и PrevLogTerm. Если лог Follower расходится с Leader, Leader пошагово уменьшает nextIndex, пока не найдёт точку совпадения.

Модуль 3: Механизм Heartbeat и таймаута

Heartbeat — ядро работы Raft—Leader поддерживает авторитет через heartbeat, а Follower обнаруживают доступность Leader через heartbeat.

func (rn *RaftNode) heartbeatLoop() {
    ticker := time.NewTicker(50 * time.Millisecond)
    defer ticker.Stop()

    for {
        <-ticker.C
        rn.mu.Lock()
        if rn.state != Leader {
            rn.mu.Unlock()
            return
        }
        rn.mu.Unlock()
        rn.replicateLog()
    }
}

func (rn *RaftNode) electionTimeoutLoop() {
    for {
        rn.resetElectionTimer()
        select {
        case <-rn.electionTimer.C:
            rn.mu.Lock()
            if rn.state != Leader {
                rn.mu.Unlock()
                rn.startElection()
                continue
            }
            rn.mu.Unlock()
        case <-rn.heartbeatCh:
            continue
        }
    }
}

func (rn *RaftNode) resetElectionTimer() {
    timeout := time.Duration(150+rand.Intn(150)) * time.Millisecond
    if rn.electionTimer != nil {
        rn.electionTimer.Stop()
    }
    rn.electionTimer = time.NewTimer(timeout)
}

Ключевой момент: Интервал heartbeat должен быть значительно меньше таймаута выборов (обычно 1/5–1/10), чтобы Follower не истекали по таймауту до прибытия heartbeat от Leader. Настраивайте таймауты на основе RTT для межрегиональных развёртываний.

Модуль 4: Снимки и уплотнение логов

Неограниченный рост логов исчерпывает ресурсы. Механизм снимков сжимает закоммиченные логи в снимок конечного автомата, сохраняя только логи после снимка.

type Snapshot struct {
    LastIncludedIndex int
    LastIncludedTerm  int
    Data              []byte
}

func (rn *RaftNode) takeSnapshot() {
    rn.mu.Lock()
    defer rn.mu.Unlock()

    if rn.commitIndex <= 0 {
        return
    }

    snapshotIdx := rn.commitIndex
    snapshotTerm := rn.log[snapshotIdx].Term

    stateData := rn.stateMachine.Serialize()

    snap := Snapshot{
        LastIncludedIndex: snapshotIdx,
        LastIncludedTerm:  snapshotTerm,
        Data:              stateData,
    }

    rn.log = rn.log[snapshotIdx+1:]
    rn.lastApplied = snapshotIdx
    rn.persistSnapshot(snap)
}

func (rn *RaftNode) installSnapshot(args *InstallSnapshotArgs) *InstallSnapshotReply {
    rn.mu.Lock()
    defer rn.mu.Unlock()

    reply := &InstallSnapshotReply{Term: rn.currentTerm}

    if args.Term < rn.currentTerm {
        return reply
    }

    if args.LastIncludedIndex > rn.commitIndex {
        rn.log = rn.log[args.LastIncludedIndex-rn.lastApplied:]
        rn.commitIndex = args.LastIncludedIndex
        rn.lastApplied = args.LastIncludedIndex
    }

    rn.stateMachine.Deserialize(args.Data)
    rn.currentTerm = max(rn.currentTerm, args.Term)
    reply.Term = rn.currentTerm
    return reply
}

Ключевой момент: Размер снимка следует контролировать в пределах 10–100МБ. Передача снимков не должна блокировать нормальную репликацию логов; используйте отдельный RPC-канал.

Модуль 5: Изменение состава и безопасность

Прямой переход от старой к новой конфигурации может вызвать split-brain. Raft реализует безопасные изменения через Joint Consensus.

type ConfigChange struct {
    Type    string // "add" or "remove"
    NodeID  int
    Address string
}

func (rn *RaftNode) proposeConfigChange(change ConfigChange) error {
    rn.mu.Lock()
    if rn.state != Leader {
        rn.mu.Unlock()
        return fmt.Errorf("not leader")
    }
    rn.mu.Unlock()

    entry := LogEntry{
        Term:    rn.currentTerm,
        Command: change,
    }

    rn.mu.Lock()
    rn.log = append(rn.log, entry)
    rn.mu.Unlock()

    rn.replicateLog()
    return nil
}

func (rn *RaftNode) applyConfigChange(change ConfigChange) {
    rn.mu.Lock()
    defer rn.mu.Unlock()

    switch change.Type {
    case "add":
        if !rn.containsPeer(change.NodeID) {
            rn.peers = append(rn.peers, change.Address)
            rn.nextIndex[change.NodeID] = len(rn.log)
            rn.matchIndex[change.NodeID] = 0
        }
    case "remove":
        newPeers := make([]string, 0)
        for i, p := range rn.peers {
            if i != change.NodeID {
                newPeers = append(newPeers, p)
            }
        }
        rn.peers = newPeers
        delete(rn.nextIndex, change.NodeID)
        delete(rn.matchIndex, change.NodeID)
    }
}

Ключевой момент: Продукционные среды рекомендуют поузловые изменения (добавление/удаление одного узла за раз), чтобы избежать сложности Joint Consensus. Убедитесь, что кластер всё ещё имеет большинство перед удалением узла.

Модуль 6: Чтение/запись клиента и линеаризуемая согласованность

Если чтения Raft обходят Leader, могут возвращаться устаревшие данные. Линеаризуемые чтения требуют ReadIndex или Lease Read.

func (rn *RaftNode) linearizableRead() (interface{}, error) {
    rn.mu.Lock()
    if rn.state != Leader {
        leaderID := rn.currentLeader
        rn.mu.Unlock()
        return nil, fmt.Errorf("not leader, redirect to %d", leaderID)
    }

    readIndex := rn.commitIndex
    term := rn.currentTerm
    rn.mu.Unlock()

    confirmCh := make(chan bool, len(rn.peers))
    confirmed := 1

    for i, peer := range rn.peers {
        if i == rn.id {
            continue
        }
        go func(addr string) {
            resp := rn.sendHeartbeat(addr, term)
            confirmCh <- resp.Success
        }(peer)
    }

    for i := 0; i < len(rn.peers)-1; i++ {
        if <-confirmCh {
            confirmed++
        }
    }

    if confirmed <= len(rn.peers)/2 {
        return nil, fmt.Errorf("lost leadership")
    }

    rn.mu.Lock()
    for rn.lastApplied < readIndex {
        rn.mu.Unlock()
        time.Sleep(time.Millisecond)
        rn.mu.Lock()
    }
    result := rn.stateMachine.Read()
    rn.mu.Unlock()

    return result, nil
}

func (rn *RaftNode) leaseRead() (interface{}, error) {
    rn.mu.Lock()
    defer rn.mu.Unlock()

    if rn.state != Leader {
        return nil, fmt.Errorf("not leader")
    }

    if time.Since(rn.leaseStart) > rn.leaseDuration {
        return nil, fmt.Errorf("lease expired, fallback to ReadIndex")
    }

    return rn.stateMachine.Read(), nil
}

Ключевой момент: ReadIndex гарантирует линеаризуемость, но требует одного RPC-раундтрипа. Lease Read опирается на предположения о часах—лучшая производительность, но с риском. В продакшене рекомендуется ReadIndex + оптимизация Lease на 1 секунду.

5 распространённых ошибок

#	Ошибка	Последствие	Правильный подход
1	❌ Фиксированный таймаут выборов	Несколько узлов истекают одновременно, расщепляя голоса	✅ Рандомизировать таймаут выборов (150-300мс) для предотвращения расщепления голосов
2	❌ Follower отвечают на чтения напрямую	Возвращают устаревшие данные, нарушая линеаризуемую согласованность	✅ Перенаправлять чтения на Leader, использовать ReadIndex для согласованности
3	❌ Одношаговое изменение состава	Два лидера могут сосуществовать во время изменения (split-brain)	✅ Поузловое изменение или двухфазное изменение через Joint Consensus
4	❌ Снимок блокирует репликацию логов	Запись в кластер останавливается во время медленной передачи снимка	✅ Отдельный RPC-канал для передачи снимков, не блокировать AppendEntries
5	❌ Не сохраняются currentTerm и votedFor	Узел может проголосовать дважды после перезапуска, нарушая безопасность выборов	✅ Синхронно сохранять Term/Vote в стабильное хранилище при каждом обновлении

10 устранение неполадок

#	Симптом ошибки	Возможная причина	Метод диагностики
1	Частые смены лидера	Таймаут выборов слишком короткий или высокая сетевая задержка	Увеличить таймаут выборов, убедиться что интервал heartbeat < таймаут выборов / 5
2	Высокая задержка репликации логов	Медленные узлы замедляют общий коммит	Включить асинхронную репликацию, установить лимит размера пакета maxInflight
3	`term mismatch`	Старый Leader всё ещё пытается писать после сетевого разделения	Проверить, имеет ли Leader последний Term; старый Leader автоматически понижается после восстановления разделения
4	OOM при передаче снимка	Снимок слишком большой, загружается в память целиком	Передавать снимок частями, 1-4МБ на часть
5	Кластер недоступен после изменения состава	Потеряно большинство после изменения	Убедиться что узлы всё ещё образуют большинство после изменения; развёртывать нечётное количество узлов
6	Чтение устаревших данных	Follower отвечает на чтения без участия Leader	Включить ReadIndex или Lease Read для линеаризуемых чтений
7	Логи потеряны после перезапуска узла	Логи не сохранены в стабильное хранилище	fsync после каждой записи лога; использовать WAL для долговечности
8	`commitIndex not advancing`	Меньшинство узлов недоступно, невозможно достичь большинства	Проверить, образуют ли живые узлы большинство; удалить неисправные узлы при необходимости
9	Штормы выборов	Дисбаланс соотношения интервала heartbeat и таймаута выборов	Установить интервал heartbeat равным 1/10 таймаута выборов; добавить фазу PreVote
10	Неконсистентное состояние после снимка	Проблема атомарности между записью снимка и усечением логов	Выполнить запись снимка и усечение логов в одной транзакции

Продвинутая оптимизация

1. Фаза PreVote предотвращает штормы выборов — Добавить фазу PreVote перед формальным RequestVote. Инициировать выборы только когда логи достаточно актуальны, предотвращая штормы выборов после восстановления сетевого разделения.

2. Пакетная репликация логов для пропускной способности — Leader объединяет несколько записей лога в один AppendEntries RPC, снижая количество сетевых раундтрипов. etcd по умолчанию использует лимит пакета в 1024 записи.

3. Асинхронная передача снимков — Использовать отдельный потоковый RPC для передачи снимков без блокировки обычного канала репликации логов. Применять ограничение скорости, чтобы передача снимков не потребляла всю пропускную способность.

4. Узлы Learner снижают риск изменений — Новые узлы сначала присоединяются как Learner, догоняют логи, затем конвертируются в Voters—предотвращая блокировку коммитов новыми узлами.

5. Оптимизация кэша ReadIndex — Leader кэширует последний ReadIndex после подтверждения heartbeat. Последующие чтения используют кэшированное значение, снижая частоту подтверждения heartbeat.

Сравнение: Raft vs Multi-Paxos vs EPaxos vs ZAB

Измерение	Raft	Multi-Paxos	EPaxos	ZAB
Понятность	✅ Разработан для ясности	❌ Непонятная статья, сложная реализация	⚠️ Средняя, основана на графах зависимостей	⚠️ Средняя, похож на Raft
Зависимость от лидера	✅ Модель сильного лидера	✅ Есть лидер, но оптимизируемо	❌ Без лидера, любая реплика может предлагать	✅ Модель сильного лидера
Межрегиональная задержка	❌ Записи требуют подтверждения лидера	⚠️ Оптимизируемо, но сложно	✅ Без лидера, запись на ближайшую реплику	❌ Записи требуют подтверждения лидера
Порядок логов	✅ Строгий порядок, легко рассуждать	⚠️ Допускает неупорядоченность, сложно	❌ Граф зависимостей определяет порядок	✅ Строгий порядок
Изменение состава	✅ Поузловое изменение простое	❌ Сложная реализация	⚠️ Среднее	⚠️ Среднее
Экосистема	✅ etcd/Consul/TiKV	⚠️ Chubby/Megastore	❌ Ограниченная экосистема	✅ ZooKeeper
Производительность	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐

Руководство по выбору: Однорегиональное развёртывание → Raft (зрелая экосистема, легко понять); межрегиональный active-active → EPaxos (низкая задержка с записью на ближайший); экосистема ZooKeeper → ZAB; Paxos только при унаследованных ограничениях.

Итоги и перспективы

Протокол Raft стал де-факто стандартом консенсуса распределённых баз данных в 2026 году—его модель сильного лидера упрощает управление логами, рандомизированные таймауты выборов предотвращают расщепление голосов, а механизм снимков решает проблему разрастания логов. Но продукционное развёртывание требует преодоления 5 ключевых вызовов: стабильность выборов лидера, согласованность репликации логов, обработка сетевых разделений, безопасность изменения состава и уплотнение логов/снимков. 6 ключевых модулей, представленных в этой статье—конечный автомат и выборы, репликация логов, heartbeat и таймаут, сжатие снимков, изменение состава и линеаризуемые чтения—охватывают полную цепочку от теории до продакшена. Помните: протокол консенсуса — это не просто выбор лидера—это полноценная инженерная система от безопасности выборов до линеаризуемой согласованности.