Перейти к содержанию

C. Flink recovery при несогласованном Redis state

Раздел 04 · Failure matrix

Тип материала: учебный архитектурный сценарий. Не описывает систему конкретной компании. Все операции, IDs и числа ниже — HYPOTHETICAL.

Проверка источников: 2026-11-02. Интеграционный fault test этого сценария — NOT_RUN; documented behavior и предлагаемый recovery не считаются выполненным испытанием.

Normal flow

Kafka 4.1→Flink 1.20.3→Redis 7.4. Flink управляет оконным state; Redis служит projection для быстрых feature reads. Для serving нужна generation, entity revision и completeness marker. Прямой Redis INCR не является checkpoint-aware transaction.

Normal flow вычисляет feature snapshot, публикует versioned absolute value и watermark/completeness evidence. Policy API знает, насколько state свежий и полон.

Иллюстративная схема нормального пути:

flowchart LR
 K[Replayable Kafka] --> F[Flink managed windows]
 F --> V[Versioned feature snapshot]
 V --> R[Redis generation]
 R --> A[Decision API checks completeness]

Failure timeline

sequenceDiagram
 participant F as Flink
 participant C as Checkpoint store
 participant R as Redis
 F->>R: Publish feature version v2
 F->>C: Complete checkpoint c2
 Note over R: Restore older Redis snapshot
 F->>C: Restore c2
 Note over F,R: Flink progress ahead of serving state
 F->>R: Rebuild into new generation
 R-->>F: Validate cut and publish marker

Состояние систем после отказа

Участник Durable состояние Неопределённость / проверка
Kafka История может содержать нужный replay interval Проверить retention и source offsets
Flink Checkpoint c2 содержит managed state/frontier Не включает произвольный rollback Redis
Redis Старая/частичная generation API не должен считать TCP availability completeness

Retry и replay

Replay только от c2 может не послать features, потерянные Redis, если в окне больше нет новых событий. Replay от более старого checkpoint плюс INCR может, напротив, удвоить ещё сохранившиеся increments. TTL по processing time также не восстанавливает event-time window.

Обнаружение проблемы

Сравнить Redis generation/completeness с published cut и Flink checkpoint ID, проверить absence of expected keys и feature age. Значение ноль без marker неотличимо от missing state. Decision API должен видеть degraded/incomplete.

Recovery protocol

  1. Остановить использование incomplete Redis generation для решений с денежным эффектом.
  2. Выбрать rebuild source: полный managed state export либо replay, покрывающий нужные окна.
  3. Построить новую Redis namespace с versioned absolute updates; не смешивать её с live INCR.
  4. Согласовать live/rebuild cut и правила поздних revisions.
  5. Проверить key sets, feature values и freshness; атомарно опубликовать ready generation.
  6. Денежный эффект всё равно подтверждать authoritative ledger.

Гарантии и trade-offs

Функциональная идемпотентность versioned SET требует атомарного compare-version и одинакового payload на равной revision. Это не делает Redis финансовым source of truth. Без полного source/state export recovery completeness UNKNOWN. Реальные Flink/Redis restore и переключение generation NOT_RUN.

Практическая проверка

Redis recovery lab требует fault после checkpoint и rollback только Redis; в report отделены model checks от Redis runtime. Сравните с 02 antifraud.

Источники и версии