Реконнект: jittered backoff, thundering herd, восстановление сообщений

Сервер перезапускается для деплоя. Все 10 миллионов подключённых клиентов мгновенно получают close-код 1006. Все повторяют попытку ровно через 1 секунду. Десять миллионов SYN-пакетов одновременно бьют в load balancer. Он рушится. Сервер так и не восстанавливается. WebSocket не имеет встроенного реконнекта — а значит, один наивный цикл retry отделяет вас от уничтожения собственного сервиса во время maintenance-окна.

Что происходит при разрыве

Когда WebSocket-соединение обрывается — сетевой глюк, перезапуск сервера, idle timeout прокси — клиент получает событие close с кодом 1006 (аномальное закрытие — close-фрейм не получен). Приложение должно решить: переподключаться ли, и если да — когда и как.

Сам WebSocket не предоставляет никакой логики реконнекта. Это полностью зона ответственности приложения.

Проблема thundering herd

Если каждый клиент повторяет попытку с одинаковым фиксированным интервалом после разрыва, retry приходят на сервер синхронизированными волнами:

• T=0: сервис падает, 10 миллионов клиентов отключаются.
• T=1с: все 10 миллионов клиентов повторяют попытку одновременно.
• Сервер получает 10 миллионов SYN-пакетов за ~1 секунду.
• SYN backlog заполняется. Новые соединения дропаются.
• T=2с: все 10 миллионов снова повторяют попытку с тем же интервалом.
• Сервер не получает тихого момента для восстановления.

Даже exponential backoff без jitter не помогает: синхронизированное удвоение всё равно создаёт синхронизированные волны.

Jittered exponential backoff

Решение — добавить случайность (jitter) к таймингу retry каждого клиента, чтобы 10 миллионов попыток размазались по окну в несколько секунд вместо одновременного прихода.

Алгоритм:

attempt = 0
base_ms = random(100, 500)      // разное для каждого клиента
max_ms  = 60_000

while not connected:
  delay = min(base_ms * 2^attempt, max_ms)
  delay = delay * random(0.5, 1.5)   // ±50% jitter
  sleep(delay)
  attempt += 1
  try_connect()

Пример разброса для перезапуска сервера с 100k клиентов:

• Клиент A выбирает base=150 мс, jitter → retry через 186 мс
• Клиент B выбирает base=340 мс, jitter → retry через 412 мс
• Клиент C выбирает base=210 мс, jitter → retry через 288 мс

100k retry размазаны по 10+ секундам. Сервер обрабатывает их небольшими пакетами и восстанавливается за 1–2 retry-окна, а не рушится.

Восстановление сообщений и гарантия at-least-once

Реконнект восстанавливает соединение. Он не восстанавливает потерянные сообщения. Любые сообщения, отправленные сервером пока клиент был отключён — или отправленные клиентом, но не подтверждённые сервером — исчезают, если приложение их не отслеживает.

Паттерн:

1. Каждое сообщение получает ID, сгенерированный клиентом. Отправитель держит сообщение в очереди retry до получения ACK для этого ID.
2. Сервер ACK-ирует каждый message ID. Отправитель убирает подтверждённые сообщения из очереди retry.
3. При реконнекте клиент переотправляет неподтверждённые сообщения. Сервер проверяет Redis stream или БД: если message ID уже существует — отправляет ACK клиенту, но не публикует повторно (предотвращает дубликаты для других подписчиков).

Это реализует at-least-once доставку с идемпотентной дедупликацией — ни одно сообщение не потеряно, ни одно не доставлено другим клиентам более одного раза.

Для дедупликации серверу нужно долговечное состояние, переживающее перезапуски. Типичное хранилище:

• Redis stream (быстрый, постоянный, упорядоченный, с настраиваемым retention).
• PostgreSQL (долговечный, с поиском, подходит для истории сообщений с требованиями аудита).

Поток реконнекта клиента:

1. Переподключиться с backoff.
2. После установки соединения отправить { type: "resume", lastSeenId: "msg-4291" }.
3. Сервер читает stream с msg-4292 и доставляет пропущенные сообщения.
4. Сервер ACK-ирует доставку.
5. Клиент подтверждает получение и обновляет lastSeenId.