11.4Распределённые системы: теория

Исходи из того, что сеть задерживает ответы, часы расходятся, а узлы падают между шагами. Применяй идемпотентность, deadline, jitter, bulkhead и fencing token, затем различай CAP выбор при partition и компромисс latency/consistency в обычной работе.

Сетевое разделение неотличимо от падения

Практический вопрос тут один: что делать, когда ответ не пришёл, а узнать причину невозможно? Из него вырастают CAP, кворумы, консенсус и векторные часы.

Главное: изнутри сетевое разделение неотличимо от падения. Узел A послал запрос узлу B и не получил ответа. Что случилось: B умер? B жив, но ответ потерялся по дороге? B жив, получил запрос, выполнил его и просто отвечает медленно? Различить эти три случая нельзя в принципе - не «инструмент пока не придумали», а математически невозможно: все три выглядят для A одинаково, как тишина. Всё дальнейшее сводится к тому, как с этой тишиной жить.

CAP: что теорема на самом деле утверждает

Когда сеть порвалась, узел на одной стороне разрыва обязан выбрать одно из двух - ответить клиенту возможно устаревшими данными или не ответить вовсе. Третьего варианта нет физически: свежие данные лежат по ту сторону разрыва, дотянуться до них нельзя, а притвориться, что дотянулся, значит соврать. Всё прочее в CAP лишь аккуратно формулирует этот выбор и доказывает, что он неизбежен.

Точная формулировка (Gilbert & Lynch в 2002 году доказали гипотезу Брюера): распределённая система не может одновременно гарантировать consistency, availability и partition tolerance. Дальше начинается место, где ошибаются почти все: каждое из трёх слов означает не то, что кажется.

• Consistency здесь означает линеаризуемость, а не букву C из ACID. Требование: система ведёт себя так, будто существует одна копия данных, и любое чтение возвращает результат последней завершённой записи по реальному времени. Свойство очень сильное - сильнее, чем «данные не противоречат ограничениям».
• Availability: каждый запрос к любому живому узлу получает непустой корректный ответ за конечное время. Не «99.99 % аптайма», а именно «ни один живой узел не имеет права ответить ошибкой или молчать».
• С partition tolerance система продолжает работать, когда сеть произвольно теряет сообщения между группами узлов.

Почему «CA-система» - некорректная категория

Отказаться от P означает утверждать, что сетевого разделения не бывает. В любой системе, где узлы общаются по сети, разделение не гипотеза, а наблюдаемый факт: кабель, свитч, перегруженный линк, GC-пауза на 30 секунд (снаружи неотличима от разрыва), неправильно применённая сетевая политика. Ты не выбираешь, случится ли partition; ты выбираешь только, как система себя поведёт.

Поэтому P не опция, а условие задачи, и реальный выбор всегда «C или A при P». Честной CA-системой остаётся только одноузловая: там нет сети между узлами, а значит, нет и разделения (но есть отказ, при котором система просто недоступна). Одиночный Postgres формально CA - и именно поэтому его аптайм ограничен аптаймом одной машины. Как только к нему добавили синхронную реплику, появился вопрос «что делать, если реплика недоступна: ждать (CP, встанет запись) или коммитить без неё (AP, риск потерять данные при failover)».

PACELC: то, чего не хватает в CAP

Формулировка Дэниела Абади: if P then A or C, else L or C. Читается так: «при разделении (P) выбирай между доступностью (A) и консистентностью (C), а в остальное время (Else) выбирай между латентностью (L) и консистентностью (C)».

Вторая половина важнее первой, потому что описывает 99.99 % времени жизни системы. Разделения случаются редко; а вот выбор «ждать подтверждения от кворума реплик (медленнее, но консистентно) или ответить сразу с локальной реплики (быстро, но возможно устарело)» делается на каждом запросе. Синхронная репликация через дата-центры стоит десятки миллисекунд на каждый коммит, всегда, независимо от аварий.

Практический смысл PACELC для собеса: он даёт язык, чтобы обсуждать реплики для чтения. За «читаем с асинхронной реплики» стоит осознанный выбор L над C в нормальном режиме, со всеми последствиями вроде «пользователь сохранил профиль и не увидел изменений».

Strict и eventual consistency, и что между ними

Между «всегда свежие данные» и «когда-нибудь сойдётся» лежит целая шкала моделей, и на практике почти всегда нужна её середина.

Три «клиентские» гарантии, за которые платят пользователи

Eventual consistency без дополнительных гарантий выдаёт аномалии, которые пользователь замечает. У каждой есть имя и лечение.

• Read-your-writes (read-after-write). Пользователь сменил аватарку, обновил страницу и видит старую - запись ушла на лидера, чтение попало на отстающую реплику. Лечения: (1) читать с лидера в течение N секунд после записи этого пользователя; (2) липкая сессия, когда все запросы сессии идут на одну реплику; (3) клиент запоминает версию/LSN своей записи и требует реплику не старее (read your writes через токен консистентности - так работает consistent read в некоторых БД).
• Monotonic reads. Пользователь видит комментарий, обновляет страницу - комментарий исчез: два чтения попали на реплики с разным лагом. Лечение: закрепить сессию за репликой (по user_id в consistent hashing, а не случайно), либо передавать наблюдённую версию и не читать более старую.
• Monotonic writes / causal. Классика: ответ на комментарий появился раньше самого комментария, потому что записи распространялись независимо. Лечение: причинная согласованность, то есть вместе с операцией передают её зависимости (версии тех записей, которые операция «видела») и не применяют операцию, пока не применены её причины.

Идемпотентность: главный инструмент выживания в ненадёжной сети

Определение: операция идемпотентна, если её повторное применение с теми же аргументами не меняет состояние системы по сравнению с однократным применением. Формально f(f(x)) = f(x). Важно, что речь про состояние, а не про ответ: повторный DELETE может вернуть 404 вместо 204 - состояние всё равно одинаковое, операция идемпотентна.

Смысл ровно в одном: в сети нельзя отличить «запрос не дошёл» от «ответ не вернулся», поэтому на неизвестность остаётся один безопасный ответ: повторить, а повторять можно только идемпотентное. Ретраи, at-least-once доставка, outbox, саги: всё это держится на идемпотентности.

Три способа сделать неидемпотентную операцию идемпотентной

1. Ключ идемпотентности. Клиент генерирует уникальный идентификатор намерения (не запроса!) и присылает его в заголовке. Сервер сохраняет ключ вместе с результатом; повторный запрос с тем же ключом возвращает сохранённый результат, не выполняя работу заново. Так устроены Stripe, платёжные шлюзы и любой нормальный финансовый API.

   CREATE TABLE idempotency (
       key          text PRIMARY KEY,          -- Idempotency-Key от клиента
       request_hash text        NOT NULL,      -- защита от «тот же ключ, другое тело»
       state        text        NOT NULL,      -- IN_PROGRESS | DONE
       response     jsonb,                     -- сохранённый ответ
       created_at   timestamptz NOT NULL DEFAULT now(),
       expires_at   timestamptz NOT NULL       -- ключи не хранят вечно: 24ч–7 суток
   );

   func (s *Service) Charge(ctx context.Context, key string, req ChargeReq) (Resp, error) {
       h := hashOf(req)
       // 1. Столбим ключ: тут и происходит сериализация.
       claimed, prev, err := s.claim(ctx, key, h) // INSERT ... ON CONFLICT DO NOTHING + SELECT
       if err != nil {
           return Resp{}, err
       }
       if !claimed {
           if prev.RequestHash != h {
               return Resp{}, ErrKeyReused        // 422: тот же ключ с другим телом
           }
           if prev.State == "IN_PROGRESS" {
               return Resp{}, ErrInFlight         // 409: клиент должен повторить позже
           }
           return prev.Response, nil              // 200 с сохранённым ответом
       }
       // 2. Делаем работу и сохраняем результат в одной транзакции с ключом.
       return s.doChargeAndStore(ctx, key, req)
   }

   Три детали, которые отличают знающего: (а) ключ придумывает клиент, и он обязан переиспользовать его при ретрае - иначе смысла нет; (б) хранится хеш запроса, чтобы поймать «тот же ключ, другое тело» и вернуть ошибку вместо чужого ответа; (в) есть состояние IN_PROGRESS, иначе два параллельных ретрая начнут работу одновременно.

2. Уникальное ограничение в БД (естественная дедупликация). Если у операции есть естественный уникальный ключ, СУБД сделает работу за тебя: UNIQUE (order_id, operation_type), и второй INSERT просто провалится или ничего не сделает. Самый дешёвый и самый надёжный вариант, потому что гарантию держит само хранилище, а не дисциплина кода. Работает и на потребителе брокера: INSERT INTO processed(message_id) ON CONFLICT DO NOTHING в одной транзакции с эффектом.
3. Условное изменение состояния (CAS / переход конечного автомата). Вместо «списать» писать «перевести из PENDING в PAID»: UPDATE orders SET status='PAID' WHERE id=$1 AND status='PENDING'. Повтор увидит 0 затронутых строк и поймёт, что работа уже сделана. Тем же приёмом работает оптимистическая блокировка по версии: ... WHERE id=$1 AND version=$2. Это превращает любое изменение в идемпотентное на уровне семантики домена и заодно защищает от конкурентных обновлений.

Таймауты, ретраи, jitter - и как не устроить retry storm

Таймаут: обязателен всегда

Запрос без таймаута оставляет утечку, которая ждёт своего часа: горутина, соединение из пула и память живут ровно столько, сколько решит удалённая сторона. Правила:

• Таймаут ставится на каждый внешний вызов и выбирается по перцентилю, а не наугад: обычно p99 нормального ответа × 1.5–2. Таймаут 30 секунд при p99 = 80 мс бесполезен - он не защищает, а только продлевает агонию.
• Бюджет таймаута. Дедлайн задаёт входящий запрос, и он уменьшается по цепочке: если клиенту обещано 2 секунды, а на первый хоп ушло 700 мс, второму хопу остаётся 1.3 с, а не снова 2. В Go это буквально context.WithTimeout, который пробрасывают вниз, а в gRPC он передаётся по сети автоматически. Без этого суммарное время ответа = сумма таймаутов, и клиент отваливается раньше, чем система успевает ему ответить.
• Отменять работу по дедлайну. Если клиент уже ушёл, считать дальше значит жечь ресурсы впустую. ctx.Done() должен реально доходить до запроса в БД.

Ретраи: только на то, что можно повторять

• Повторять можно таймауты, ошибки соединения, 502/503/504, gRPC UNAVAILABLE/DEADLINE_EXCEEDED - и только для идемпотентных операций.
• Повторять нельзя 400/401/403/404/422 (отказ детерминированный - повтор даст то же самое) и любые неидемпотентные операции без ключа идемпотентности.
• Уважать Retry-After, если сервер его прислал: он знает лучше.
• Ограничивать число попыток: 2–3 на уровень, не больше. И помнить про умножение по цепочке: 3 уровня по 3 попытки = 27 запросов на один клиентский, а по 3 повтора сверх первой попытки — уже 4³ = 64.

Экспоненциальная задержка и jitter

Просто «повторить через секунду» плохо тем, что тысяча клиентов, получивших ошибку одновременно, повторят тоже одновременно - и добьют сервис ровно в момент, когда он пытается встать. Экспонента разносит попытки во времени, jitter разносит клиентов между собой.

// Full jitter: задержка равномерно из [0, cap), где cap растёт экспоненциально.
// В замерах AWS он даёт наименьшую нагрузку и наименьшее время до успеха,
// лучше, чем «экспонента ± небольшой шум».
func backoff(attempt int) time.Duration {
    const base, max = 100 * time.Millisecond, 10 * time.Second
    exp := base << attempt          // 100ms, 200ms, 400ms, 800ms...
    if exp > max {
        exp = max
    }
    return time.Duration(rand.Int63n(int64(exp))) // [0, exp)
}

func doWithRetry(ctx context.Context, f func(context.Context) error) error {
    var err error
    for attempt := 0; attempt < 3; attempt++ {
        if attempt > 0 {
            select {
            case <-time.After(backoff(attempt)):
            case <-ctx.Done():                  // дедлайн важнее ретраев
                return ctx.Err()
            }
        }
        if err = f(ctx); err == nil || !retriable(err) {
            return err
        }
    }
    return err
}

Circuit breaker, bulkhead, backpressure, load shedding

Четыре разных ответа на вопрос «что делать, когда мощности не хватает». Их часто перечисляют списком, не различая, хотя различие простое: breaker защищает от чужого отказа, bulkhead ограничивает распространение своего, backpressure тормозит источник, load shedding выбрасывает лишнее.

Circuit breaker - не долби мёртвого

Конечный автомат из трёх состояний вокруг вызова к внешней зависимости.

• Closed: запросы идут, считаем долю ошибок и медленных ответов в скользящем окне.
• В состоянии Open порог уже превышен, и все вызовы мгновенно падают с ошибкой, не трогая зависимость. Главный выигрыш тут в том, что клиент получает быстрый отказ вместо таймаута в 3 секунды, освобождаются горутины и соединения, а упавший сервис получает шанс встать.
• Half-open пропускает несколько пробных запросов, когда пауза вышла. Успех возвращает в closed, неуспех отправляет обратно в open с увеличенной паузой.

Тонкости: считать надо долю ошибок при достаточном объёме (минимум N запросов в окне, иначе один неудачный запрос при низком трафике откроет breaker), считать таймауты как ошибки, а бизнес-ошибки (404, 422) не считать, и обязательно иметь осмысленный fallback: закэшированное значение, значение по умолчанию, деградированный ответ. Breaker без fallback просто меняет медленный отказ на быстрый - это полезно, но только половина ценности.

Bulkhead - переборка

Название из судостроения: корпус делят на отсеки, чтобы пробоина не затопила весь корабль. В сервисе это отдельные пулы ресурсов на каждую зависимость или класс трафика: свой пул соединений, свой семафор на число одновременных вызовов, отдельный пул воркеров. Без переборок один медленный внешний API съедает все горутины и соединения, и падает весь сервис, включая эндпоинты, которые к этому API вообще не обращаются.

// Простейший bulkhead в Go: буферизованный канал как семафор на зависимость.
type Bulkhead struct{ sem chan struct{} }

func NewBulkhead(n int) *Bulkhead { return &Bulkhead{sem: make(chan struct{}, n)} }

func (b *Bulkhead) Do(ctx context.Context, f func() error) error {
    select {
    case b.sem <- struct{}{}:            // взяли слот
        defer func() { <-b.sem }()
        return f()
    case <-ctx.Done():                   // слотов нет, бесконечно не ждём
        return ErrBulkheadFull           // быстрый отказ, а не медленная очередь
    }
}

Backpressure - обратное давление

Сигнал «мне плохо, притормози», который идёт вверх по потоку к источнику нагрузки. Это не отказ, а замедление: TCP-окно, небуферизованный канал в Go, ограниченная очередь, ответ 429 с Retry-After, остановка чтения из брокера, пока не разобрана текущая пачка. Очередь без границы не буфер, а отложенный отказ: неограниченный канал или неограниченная очередь превращают перегрузку в рост латентности и OOM вместо честного «не могу».

Load shedding - сбрасывание нагрузки

Когда притормозить источник невозможно (это внешние пользователи), остаётся отказывать части запросов, чтобы обслужить остальные. Отличие от rate limiting: rate limit задаёт политику («этому клиенту не больше 100 rps»), а shedding реагирует на состояние («у меня очередь длиннее 200, отвечаю 503»). Правильно делать это по приоритету: сначала отбрасывать фоновые задачи и повторные запросы, потом аналитику, в последнюю очередь платежи. И отбрасывать как можно раньше и дешевле: проверка на входе, до похода в БД.

Консистентное хеширование

«Консистентное» здесь не имеет отношения к консистентности данных из CAP. Английское consistent hashing в этом контексте значит «устойчивое»: такое распределение ключей по узлам, которое почти не меняется, когда узлов становится больше или меньше. Речь всё время идёт про шардирование: ключи раскладывают по нескольким узлам так, чтобы любой участник системы, зная только ключ, вычислил один и тот же адрес.

Какую проблему решает

Ключи по N узлам обычно размазывают так: node = hash(key) % N. Работает ровно до момента, когда N меняется. Пусть в кэше 100 узлов и 100 млн ключей. Добавили один узел: % 100 превратилось в % 101, и почти каждый ключ теперь отображается на другой узел - переезжает около 99 % ключей (точнее, доля N/(N+1) при добавлении). Для кэша это означает почти полный промах на всём кластере одновременно: кэш пустой, весь трафик ушёл в базу, база легла. Не «деградация», а инцидент - вызванный не аварией, а плановым добавлением мощности.

Консистентное хеширование делает так, что при изменении числа узлов переезжает только 1/N ключей. Те же 100 узлов, добавили 101-й: переехало примерно 1 % ключей, остальные 99 % остались на своих местах и продолжают попадать в кэш.

Кольцо

Пространство хешей (скажем, 0…2³²−1) замыкается в кольцо. На кольцо отображаются и узлы (по хешу их имени или адреса), и ключи (по хешу ключа). Правило владения одно: ключ принадлежит первому узлу, встреченному при движении по кольцу по часовой стрелке. Ищут бинарным поиском по отсортированному массиву позиций узлов, O(log N).

Виртуальные узлы: зачем они обязательны

У наивного кольца с N физическими точками две болезни. Первая в неравномерности: случайные позиции трёх узлов почти никогда не делят кольцо на три равные дуги, и разброс нагрузки в 2–3 раза считается нормой. Вторая: при удалении узла вся его нагрузка падает на одного соседа, который тут же ложится следом (каскад).

Решение: каждый физический узел кладут на кольцо V раз под разными метками (hash("nodeA#0"), hash("nodeA#1"), …). При V = 100–200 самый нагруженный узел обгоняет среднее уже не в разы, а на 10–25 %; до единиц процентов разброс падает ближе к V = 1000. При удалении узла его дуги расходятся между всеми остальными, а не сваливаются на одного. Платишь памятью под V×N точек (для 100 узлов по 150 реплик это 15 000 записей, копейки) и чуть более долгим поиском. Бонус: V можно делать пропорциональным мощности узла - тогда получается взвешенное распределение для разнородного железа.

type Ring struct {
    points []uint32          // отсортированные позиции виртуальных узлов
    owner  map[uint32]string // позиция -> имя физического узла
    vnodes int
}

// crc32 не годится: он линеен, и метки, отличающиеся одним байтом, дают позиции
// со сдвигом на одну и ту же константу — узлы ложатся параллельно, и разброс
// не падает даже при V = 1000. Обрезанный sha256 раскидывает ровно.
func hash(s string) uint32 {
    sum := sha256.Sum256([]byte(s))
    return binary.BigEndian.Uint32(sum[:4])
}

func (r *Ring) Add(node string) {
    for i := 0; i < r.vnodes; i++ {
        p := hash(node + "#" + strconv.Itoa(i))
        r.points = append(r.points, p)
        r.owner[p] = node
    }
    sort.Slice(r.points, func(i, j int) bool { return r.points[i] < r.points[j] })
}

func (r *Ring) Get(key string) string {
        h := hash(key)
    // первый узел по часовой стрелке; ушли за конец, замыкаем на начало
    i := sort.Search(len(r.points), func(i int) bool { return r.points[i] >= h })
    if i == len(r.points) {
        i = 0
    }
    return r.owner[r.points[i]]
}

Распределённые блокировки и fencing token

Задача: гарантировать, что критическую секцию (обработку файла, запуск джобы, изменение ресурса) в кластере выполняет ровно один процесс. Наивный вариант на Redis:

SET lock:job42 <random-uuid> NX PX 30000    # взять, только если свободен, TTL 30 c
# ... работа ...
# снять только свою блокировку: сравнить значение и удалить атомарно (Lua):
# if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) end

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

Фундаментальная проблема: TTL не останавливает процесс

Сценарий, который надо уметь рассказать: процесс P1 взял блокировку с TTL 30 секунд, начал работу и застрял - stop-the-world пауза GC, своп, вытеснение планировщиком, сетевая задержка. Прошло 40 секунд. Блокировка истекла, P2 её взял и начал работу. Тут P1 просыпается: с его точки зрения ничего не произошло, он уверен, что владеет блокировкой, и делает запись в хранилище. Два процесса одновременно в критической секции, и никакой TTL, никакой алгоритм согласования этого не предотвратит - потому что проблема не в блокировке, а в том, что нельзя остановить процесс, который считает себя владельцем.

// Токен ложится в условие записи: ресурс сам отсекает устаревшего владельца.
// UPDATE resource SET data = $1, fence = $2 WHERE id = $3 AND fence < $2
res, err := db.ExecContext(ctx,
    `UPDATE jobs SET result = $1, fence = $2 WHERE id = $3 AND fence < $2`,
    data, token, jobID)
if err != nil {
    return err
}
if n, err := res.RowsAffected(); err == nil && n == 0 {
    return ErrStaleLockHolder // нас уже вытеснили, тихо выходим без паники
}

Redlock и почему вокруг него спор

Redlock работает на N независимых Redis-мастерах: берём блокировку на большинстве за время, много меньшее TTL. Критика Мартина Клеппманна: алгоритм опирается на ограниченность задержек и на синхронность часов, а при паузе GC или скачке часов ломается ровно так же, как одиночный Redis - то есть даёт иллюзию строгости без фактической гарантии. Ответ на собесе, который закрывает вопрос: «Для эффективности (не запускать одну и ту же работу дважды без большой беды) хватит блокировки на одном Redis с TTL и уникальным значением. Для корректности (двойной запуск недопустим) нужен либо fencing token, либо перенос гарантии в сам ресурс - уникальный индекс, CAS по версии, условная запись».

Лидер, кворум, консенсус

Зачем вообще лидер

Лидер сводит распределённую задачу к локальной: если все записи проходят через один узел, порядок операций определён тривиально, конфликтов нет, а остальные узлы просто повторяют журнал. Лидер нужен далеко не одним БД: единственный запускающий cron, единственный владелец шарда, единственный компактор, единственный ребалансировщик. Цена известна: нового лидера при отказе надо надёжно выбрать и гарантировать, что он ровно один.

Кворум и почему N/2+1

Кворумом называют минимальное число узлов, которое должно согласиться, чтобы решение считалось принятым. Большинство (N/2+1) выбрано не из эстетики: любые два большинства из одного и того же множества обязательно пересекаются минимум в одном узле. Из этого следует главное свойство: два разных решения (два лидера, две записи одного индекса лога) невозможны, потому что узел из пересечения не проголосует дважды в одном терме. Если бы кворумом была половина, при разрыве 2/2 обе половины набрали бы кворум и выбрали бы разных лидеров - классический split brain.

Отсюда правило «нечётное число узлов»: чётность не добавляет живучести, но добавляет латентности и стоимости. И отсюда же понятно, почему кластер из 3 узлов, потерявший 2, перестаёт обслуживать запись, хотя один узел жив: он не может доказать, что он не в меньшинстве, а значит, не имеет права принимать решения. Это буквально CP-выбор в действии.

В системах с настраиваемым кворумом (Cassandra, Dynamo-подобные) то же самое выражается через W + R > N: если число узлов для подтверждения записи плюс число узлов для чтения больше общего числа реплик, множества гарантированно пересекаются и чтение увидит последнюю запись. Типовой выбор N=3, W=2, R=2; а W=1, R=1 даёт максимальную скорость и никаких гарантий.

Консенсус: договориться об одном значении и больше его не менять

В задаче о консенсусе группа узлов должна выбрать одно значение (кто теперь лидер; какая запись идёт под номером 42) так, чтобы выполнились три условия: выбрано ровно одно значение, выбранное больше никогда не меняется, и все живые узлы в итоге узнают одно и то же. Это умеют Paxos и Raft; на Raft стоят etcd, Consul и Kafka в режиме KRaft (Raft выбирает там контроллер, а лидеров партиций назначает уже он). ZooKeeper держится на своём протоколе ZAB, родственнике Paxos.

Разницу с кворумом полезно уметь проговорить: кворум задаёт правило подсчёта («больше половины»), а консенсус описывает протокол, который поверх этого правила решает, что делать с отказами, повторными голосованиями и вернувшимися после разрыва «зомби»-узлами. Кворум считает, консенсус договаривается.

Raft: термы, выборы, репликация лога

Raft придумали как «понятную альтернативу Paxos», и держится он на трёх идеях: сильный лидер, разделение времени на термы и репликация журнала.

• Терм задаёт номер эпохи, монотонно растущее целое. В каждом терме не более одного лидера. Он же служит логическими часами: узел, увидевший больший терм, немедленно становится follower. Так система сама вытесняет «зомби-лидера», вернувшегося после разрыва.
• Три роли: follower (пассивно принимает записи и heartbeat), candidate (пытается стать лидером), leader (единственный, кто принимает клиентские записи).
• Выборы. У каждого follower идёт случайный таймаут выборов (в статье авторов Raft для примера 150–300 мс, в etcd по умолчанию от 1 до 2 с). Heartbeat не пришёл - follower увеличивает терм, становится candidate, голосует за себя и рассылает RequestVote. Узел отдаёт голос, если ещё не голосовал в этом терме и лог кандидата не отстаёт от его собственного (это условие гарантирует, что лидером не станет узел, потерявший закоммиченные записи). Набрал большинство - стал лидером и сразу начинает слать heartbeat.
• Split vote случается, когда несколько кандидатов стартовали одновременно: голоса делятся, и никто не набирает большинство. Терм проходит впустую, таймауты истекают, начинается новый терм. Именно поэтому таймаут случайный: рандомизация делает одновременный старт маловероятным, и обычно достаточно одного лишнего раунда.
• Репликация лога. Клиентская запись попадает в лог лидера, лидер рассылает AppendEntries. Реплицировав запись своего терма на большинство, лидер считает её committed, применяет к машине состояний и сообщает индекс коммита followers. Записи прошлых термов так коммитить нельзя, даже если они лежат на большинстве: их новый лидер ещё может затереть, и они становятся закоммиченными заодно с первой записью текущего терма. Клиенту, соответственно, нельзя отвечать «ок» до коммита.
• Свойство безопасности: если запись закоммичена в терме T, она присутствует в логах всех будущих лидеров. Это обеспечивают правило голосования «не голосуй за отстающий лог» и пересечение кворумов.

Дедупликация и «exactly-once end-to-end»

• At-most-once. Отправили и забыли: потери возможны, дублей нет. Годится для метрик и телеметрии, где потеря одного значения безразлична.
• At-least-once. Повторяем до подтверждения: потерь нет, дубли гарантированы. Так и работает любая надёжная система доставки.
• Exactly-once, ровно один раз. Как свойство доставки по сети недостижимо: потерю запроса нельзя отличить от потери ответа (в теории это задача о двух генералах).

Как делают дедупликацию на практике

• Ключ дедупликации в сообщении. Продюсер кладёт event_id (детерминированный, а не uuid.New() на каждой попытке отправки), потребитель хранит виденные идентификаторы. Под хранилище идёт таблица inbox (транзакционно с эффектом) или Redis-множество с TTL, если допустимо «почти точно».
• Окно дедупликации конечно. Хранить все идентификаторы вечно нельзя. Окно выбирают (час, сутки, неделя) по максимально возможной задержке повтора; за пределами окна дубль пройдёт. Компромисс придётся назвать вслух: «у нас дедупликация на 24 часа, сообщение старше этого срока считается новым».
• Экономия памяти. Для больших потоков ставят Bloom-фильтр предфильтром: «точно не видел» он отвечает бесплатно, «возможно видел» отправляет в БД. Ложноположительные срабатывания не страшны, за ними идёт точная проверка.
• Лучше не дедуплицировать, а быть идемпотентным. UPSERT по естественному ключу, переход состояния с условием, запись в S3 по детерминированному имени. Тогда дубли безвредны by design и никакого хранилища идентификаторов не нужно.

Отдельно про то, в каком порядке потребитель брокера коммитит смещение: commit offset после обработки даёт at-least-once (упали между обработкой и коммитом - будет повтор), commit до обработки даёт at-most-once (упали после коммита - сообщение потеряно). Почти всегда выбирают первое плюс идемпотентную обработку.

Часы и порядок событий

Физические часы врут - и это архитектурная проблема

• Дрейф. Кварцевый генератор уходит на 10–100 ppm, то есть на секунды в сутки. NTP подтягивает часы обратно, и время в этот момент может прыгнуть назад. Два события, случившиеся друг за другом, получат метки в обратном порядке.
• Точность синхронизации в дата-центре измеряется единицами миллисекунд, между дата-центрами десятками. Это больше, чем длительность многих операций, поэтому сравнивать метки с разных машин с точностью до миллисекунды нельзя.
• Практические правила Go: чтобы померить длительность, берут монотонные часы (в Go time.Now() хранит монотонную составляющую, и разность двух time.Time корректна даже при переводе часов), а метки времени в данных читают как «примерно» и корректность на них не строят.
• Опасный антипаттерн: last-write-wins по wall clock. Часы одного узла спешат на 200 мс - и его записи всегда «выигрывают», а данные, записанные позже, молча теряются. Так теряют данные в Cassandra при кривой синхронизации времени.

Happened-before и логические часы

Лэмпорт заметил: чтобы упорядочивать события, физическое время не нужно, хватает отношения «произошло раньше» (→), которое задают три правила: (1) в пределах одного процесса события упорядочены; (2) отправка сообщения предшествует его получению; (3) отношение транзитивно. События, не связанные этим отношением, называются конкурентными. Про них нельзя сказать, какое было раньше, и это не незнание, а объективное свойство.

Оба вида логических часов удобно представить как бумажную переписку. Часы Лэмпорта нумеруют письма подряд: по номерам видно, что письмо №7 написано после №5, но если два человека писали одновременно, номера всё равно выстроятся в один ряд и создадут ложное впечатление очерёдности. Векторные часы добавляют приписку «твои письма прочитал по 4-е включительно, своих написал 6»: по ней сразу видно, знал ли автор о твоём последнем письме, когда писал своё. Если он не знал о твоём, а ты о его, письма разошлись в пути; события конкурентны, и это видно явно, а не угадывается по времени на штемпеле.

• Часы Лэмпорта. У каждого процесса счётчик. Перед локальным событием C++. При отправке сообщения к нему прикладывается C. При получении C = max(C, C_msg) + 1. Свойство: если a → b, то C(a) < C(b). Обратное неверно: из C(a) < C(b) не следует, что a было раньше, события вполне могут оказаться конкурентными. То есть часы Лэмпорта дают полный порядок (ничьи разрешают по id процесса), но обнаружить конкурентность не дают.
• Векторные часы. Вектор из N счётчиков, по одному на процесс; процесс инкрементирует свою позицию, при получении берёт поэлементный максимум. Теперь a → b тогда и только тогда, когда вектор a покомпонентно меньше или равен вектору b и где-то строго меньше; если ни один не меньше другого, события конкурентны, и видно это сразу. Цена: размер метаданных растёт с числом узлов, а узлы бывают эфемерными. Именно так Dynamo и Riak находили конфликтующие версии и отдавали их разрешать приложению (siblings).

// После записи кладём в сессию/куку момент (или LSN) и N секунд читаем с мастера.
const stickyWindow = 3 * time.Second

func (r *Repo) pickConn(ctx context.Context) *sql.DB {
    if t, ok := LastWriteAt(ctx); ok && time.Since(t) < stickyWindow {
        return r.primary          // свои свежие данные только с мастера
    }
    return r.replica              // всё остальное с реплики
}

SET lock:job42 <uuid> NX PX 30000     # NX = только если свободен, PX = TTL
# снимаем только свою блокировку, атомарно через Lua:
# if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) end

// UPDATE ... WHERE fence < $token: ресурс сам отсекает устаревшего владельца
res, _ := db.Exec(ctx,
    `UPDATE jobs SET result = $1, fence = $2 WHERE id = $3 AND fence < $2`,
    data, token, jobID)
if n, _ := res.RowsAffected(); n == 0 {
    return ErrStaleLockHolder
}

Что стоит запомнить

• Отсутствие ответа не позволяет отличить падение узла от задержки сети или потерянного ответа.
• Ретраи нужны только для повторяемой операции с budget/deadline; jitter уменьшает синхронный retry storm.
• Fencing token защищает от устаревшего владельца, когда downstream ресурс сравнивает токен.

Частые ошибки

• Не повторяй неидемпотентный side effect после timeout, не выяснив исход предыдущей попытки.
• Не трактуй CAP как постоянный выбор только между consistency и availability вне сетевого разделения.
• Не считай распределённый lock корректным, если операция продолжится после истечения lease без fencing.

func backoff(attempt int) time.Duration {
    const base, max = 100 * time.Millisecond, 10 * time.Second
    exp := base << attempt
    if exp > max { exp = max }
    return time.Duration(rand.Int63n(int64(exp)))
}

UPDATE jobs SET result = $1, fence = $2 WHERE id = $3;