Как Raft реплицирует log entry и решает, что его безопасно коммитить

Клиент отправляет SET x = 42 Raft-кластеру. Лидер дописывает это в свой лог. Но только лидер не может коммитить эту запись — ему нужно подтверждение от достаточного числа follower-ов, что они тоже её получили. Если лидер упадёт сразу после дописи, но до того как хоть один follower ответит, что происходит с записью?

Лог и AppendEntries

Лидер Raft хранит упорядоченный лог из entry. Каждый entry — тройка: (term, index, command). Когда клиент отправляет запись:

1. Лидер дописывает entry в свой лог и выполняет fsync на диск.
2. Лидер шлёт RPC AppendEntries каждому follower, передавая: новый entry, плюс prevIndex и prevTerm — index и term entry, предшествующего новому.
3. Каждый follower проверяет: есть ли в моём логе entry на prevIndex с prevTerm? Если да — дописывает и делает fsync. Если нет — отвечает mismatch.
4. Как только лидер получает подтверждение от большинства (включая себя), он помечает entry закоммиченным.
5. Лидер пристёгивает свой commit index к следующему heartbeat. Follower-ы применяют entry до этого index к своим state machine.

Проверка целостности: Log Matching

Проверка prevIndex/prevTerm — не бюрократия, это механизм, удерживающий лог каждого follower идентичным логу лидера. Если лог follower-а расходится (потому что предыдущий лидер записал другие entry перед падением), ответ mismatch сигнализирует лидеру откатиться и повторить с более ранним prevIndex. Лидер продолжает уменьшать до нахождения последней точки согласия, затем перезаписывает расходящийся хвост follower-а своим.

Это приводит к идентичным логам, потому что: каждое закоммиченное entry в предыдущем term было сохранено большинством нод. Лог нового лидера (избранного большинством) пересекается с этим предыдущим большинством, поэтому новый лидер имеет закоммиченные entry. Незакоммиченные entry на диске старого лидера перезаписываются — они никогда не были подтверждены клиенту, поэтому потери данных нет.

Паттерн replicated state machine

Raft не интересует, что означают команды. Твоё приложение определяет state machine — key-value-маппу, дерево конфига, отношение — и команды, мутирующие её. Raft гарантирует: каждая нода применяет каждое закоммиченное entry в одном и том же порядке. Поскольку команды детерминированы, каждая state machine заканчивает в одном состоянии. Это паттерн replicated state machine: упорядоченный реплицированный лог + детерминированная state machine = консистентный распределённый сервис.

Важные следствия:

• Не используй NOW(), random() или внешние API-вызовы внутри обработчиков команд — они нарушают детерминизм между репликами.
• State machine специфична приложению; Raft агностичен к ней.
• Чтения для линеаризуемости должны идти через лидера (ReadIndex/lease, разбираются в следующем уроке); чтения с follower-ов могут вернуть stale-данные.