Кратко по сравнению и затем — предложенная архитектура.
Сравнение подходов
- Задержки:
- Пакетная обработка: большие латентности, обычно обработка раз в интервал → задержка от десятков секунд до минут/часов. Пример: $\text{latency}\gtrsim 60\text{s}$.
- Потоковая обработка: низкая сквозная задержка; есть микробатчи (латентность $\sim 100\text{ms}-1\text{s}$) и true streaming (латентность от $\lesssim 10\text{ms}$ до сотен мс в зависимости от стека и нагрузки).
- Гарантии доставки:
- Пакетная: легко обеспечить exactly‑once (за счёт атомарной обработки и транзакций над входными/выходными хранилищами).
- Потоковая: типично at‑least‑once; exactly‑once достижимо (идемпотентные обработчики, транзакции, two‑phase commit, распределённые чекпоинты), но с накладными расходами на задержку и пропускную способность.
- Состояние:
- Пакетная: состояние вычисляется на всей выборке (stateless или recompute); нет необходимости в постоянном низколатентном state store.
- Потоковая: часто stateful (окна, агрегаты, сессии). Используют локальные state store (RocksDB и т.п.) + асинхронное снапшотирование/чанглоги для устойчивости. Частое чекпоинтирование повышает надёжность, но может влиять на задержку/пропускную способность.
- Масштабируемость:
- Пакетная: масштабируется горизонтально по данным (разбиение задач), хороша для больших бэчей; запуск новых задач менее чувствителен к консистентности state.
- Потоковая: масштабируется по шардированию ключей и параллельности операторов; stateful рескейлинг и миграция состояния сложнее и может требовать сохранения снапшотов/перераспределения.
Архитектура для системы реального времени с жёсткими требованиями по задержке
Ключевые решения (принципы):
- Использовать потоковую обработку (streaming) с минимизацией сетевых и дисковых задержек.
- Разрешить компромиссы в гарантиях доставки: предпочесть at‑least‑once + идемпотентность/дедупликацию либо выбирать exactly‑once там, где критично, понимая накладные расходы.
- Хранить активный state локально (in‑memory или RocksDB) с асинхронной репликацией в быстрый журнал.
- Минимизировать GC/паузы — либо тонкая настройка JVM/ZGC, либо нативная реализация (Rust/C++) для ultra‑low latency.
- Колокация данных и вычислений, аппаратный SSD/NVMe, быстрые сети (10/25/100 GbE, RDMA если нужно).
Компоненты и поток данных:
1) Ингест (producers)
- Лёгкие агенты на источниках (edge) для предобработки и фильтрации.
- Использовать бинарный протокол без больших батчей; для ультра‑низкой задержки — Aeron/Chronicle/Aeron Cluster или tuned Kafka.
2) Лог сообщений (постоянный журнал)
- Быстрый брокер с минимальной буферизацией:
- Kafka, tuned для low‑latency (producer linger $=0$, batch.size малый, acks $=$ $\text{’1’}$/$\text{’all’}$ в зависимости от компромисса).
- Для sub‑ms/микросекунд — Aeron/Chronicle Queue или RDMA‑брокеры.
- Репликация увеличивает задержку; для жёсткой латентности можно ослабить репликацию на пути критических сообщений и иметь резервные механизмы.
3) Потоковый движок (stream processor)
- Предпочтение: движок с поддержкой stateful processing и асинхронных чекпоинтов (напр., Apache Flink с RocksDB) либо нативное решение для минимальных задержек.
- Локальный state store (RocksDB или in‑memory), подача входа через partitioned keyBy для масштабирования.
- Чекпоинты делаются асинхронно, интервал чекпоинтов настраивается в зависимости от RTO/RPO (например, checkpoint interval $\approx 5\text{s}$—настройка по SLA).
- Для критичных по задержке путей: минимизировать операции, требующие глобального обмена (shuffles).
4) Долговременное хранилище / материализованные представления
- Быстрый in‑memory кэш (Redis/KeyDB) или materialized view (например, ksqlDB/Materialize) для ответов под низкую латентность.
- Тяжёлые агрегации/исторические запросы → асинхронно в cold storage (S3, HDFS).
5) Sinks / Action
- Низколатентные ответные системы (push to user, actuator) прямо из потокового движка или из in‑memory cache.
- Для критичных уведомлений — прямой TCP/UDP/GRPC выход, избегать дополнительных брокеров.
Операционные практики и параметры:
- Общий budget задержки: задать SLA, например end‑to‑end $\le 50\text{ms}$ или для ultra systems $\le 5\text{ms}$. Декомпозировать на этапы (ingest, broker, processing, sink).
- Настройки брокера: producer linger $=0$, batch.size маленький; acks выбирать с учётом требуемой надёжности.
- State durability: локальный RocksDB + changelog в журнал (потоковый брокер) для восстановления; репликация changelog асинхронная.
- Управление нагрузкой: backpressure, rate limiting на источниках, приоритеты потоков.
- Отказоустойчивость: быстрые перезапуски, warm standby, автоматический рескейлинг с сохранением снапшотов (savepoints).
- Мониторинг: end‑to‑end latency SLOs, p99/p999, GC/pause metrics, network IO, queue lengths.
- Язык/рантайм: для очень жёсткой латентности избегать тяжёлого GC (использовать Rust/C++/Go или tuned JVM).
Примерный вариант стека для жёсткой задержки $\le 10\text{ms}$:
- Ingest: edge agents → Aeron/Chronicle (или Kafka с минимальной буферизацией)
- Broker: tuned Kafka/Aeron cluster (ритм: минимальные батчи)
- Processor: нативный стриминг на Rust/C++ или lightweight Flink с RocksDB и очень агрессивной тюнинг‑политикой
- State: локальная in‑memory + RocksDB + асинхронный changelog
- Sink: Redis/наносекундный push (Aeron/GRPC)
- Obs/FT: распределённый tracing, p99/p999 alerting, warm replicas
Коротко о компромиссах
- Чтобы снизить задержку, часто придётся ослабить задержки репликации/транзакционности или платить за них (сетевой/IO overhead). Решение: выбрать критичные для exactly‑once операции и реализовать идемпотентность/дедупликацию на приёме; для менее критичных — at‑least‑once.
Если нужно, могу предложить конкретную конфигурацию Kafka/Flink (параметры producer/consumer/rocksdb/checkpoint) и целевой латентный бюджет в миллисекундах для вашей нагрузки.