Кратко — архитектура и паттерны, которые я бы предложил для системы телеметрии на уровне миллионы событий в секунду, с объяснением компромиссов.
1) Высокоуровневая архитектура (поток):
- Клиенты / SDK → ingestion edge (gateway, load‑balancer, buffering) → durable message bus (stream broker) → stream processing (stateless + stateful) → OLAP/TS/Key‑Value хранилища + cold storage → API/реалтайм‑дашборды / ML.
- Резервные элементы: dead‑letter queue, replay pipeline, schema registry, auth/audit, monitoring.
2) Технологии (проверенные варианты)
- Ingestion: TCP/HTTP/GRPC collectors, nginx/TCP balancers, Envoy или Kafka REST. Edge buffering (local batching).
- Broker: Apache Kafka или cloud‑варианты (Confluent, AWS MSK, Google Pub/Sub) — для высокой устойчивости и реплея; альтернативы: Pulsar (multi‑tenant, tiered storage).
- Stream processing: Apache Flink (stateful, event‑time, exactly‑once support), Kafka Streams/ksqlDB (tight Kafka интеграция), Apache Beam (portable).
- Hot storage / queries: ClickHouse или Druid (OLAP/aggregations), Elasticsearch (search), Cassandra/DynamoDB (fast key‑value / wide column).
- Cold/long‑term: S3/GS/Tiered storage (для event sourcing / архивов).
- Schema/serialization: Avro/Protobuf/JSON Schema + Schema Registry.
- Observability: Prometheus, Grafana, Jaeger/Tempo.
3) Ключевые паттерны
- Partitioning / sharding: шардирование по ключу (deviceId, customerId) + consistent hashing для равномерной нагрузки.
- Queue + backpressure: брокер с retention + consumer‑side rate control; DLQ для некорректных событий.
- Event sourcing: хранить «сырые» события в topic/append‑only store для replay и ре‑процессинга.
- CQRS: разделить write path (events) и read models (проекции для запросов).
- Stateful stream processing + checkpoints: для агрегатов, окон, дедупа.
- Exactly‑once vs idempotency: хранить eventId, применять idempotent handlers или использовать транзакции/2PC для критичных операций.
4) Масштабирование (формулы и принципы)
- Масштаб параллелизма через partitions: общая пропускная способность ≈ $\text{partitions}\times \text{throughput\_per\_partition}$.
Пример: если одна partition держит $\approx 10,000$ evt/s, то для $\approx 1,000,000$ evt/s нужно $\approx 100$ partitions.
- Репликация и устойчивость: latency ∝ синхронные реплики; write latency растёт с увеличением replication factor $RF$. Обычно $RF=3$ — баланс durability/availability.
- Batch/linger: повысить пропускную способность через батчи, но батчи увеличивают задержку (latency ∝ batch\_size / input\_rate).
5) Компромиссы: задержка vs согласованность/надёжность
- Latency vs durability: синхронная репликация и fsync → увеличивает задержку, но даёт сильную гарантию потерь. Асинхронная репликация → низкая задержка, риск потери при падении.
- Exactly‑once vs throughput: exactly‑once (Flink 2PC, Kafka transactions) даёт семантику, но добавляет накладные расходы и увеличивает latency и complexity. Часто практично: at‑least‑once + идемпотентные операции (меньше overhead).
- Consistency vs availability (CAP): для распределённых чтений/записей выбираете AP (быстрые ответы, eventual consistency) или CP (сильная согласованность, возможны задержки). Телеметрия обычно допускает eventual consistency для агрегатов, а критичные биллинговые/контрольные — требуют CP.
- Hot keys: сильное шардирование помогает, но если ключ «горячий», нужен дополнительный сплит/rehash, windowing или per‑key throttling.
6) Практические рекомендации и настройки
- Параметры Kafka: replication.factor $=3$, min.insync.replicas $=2$, acks=all для гарантированной записи; batch.size и linger.ms тюнинг для throughput/latency.
- Hot key mitigation: добавлять salt/namespace, adaptive routing, или использовать hierarchical aggregation.
- Stateful processing: хранить state в RocksDB (Flink) + регулярные checkpoints; checkpoint interval выбираете между latency и recovery time.
- Retention + compaction: raw events — долгоживущие (S3); topics для проекций — compacted topics для последних состояний.
- Deduplication: хранить recently seen ids в TTL‑KV (например Redis or RocksDB) для at‑least‑once исправления.
7) Операционные аспекты
- Capacity planning: планируйте margin $>20\%$ для пиков. Моделируйте пиковые QPS и latency SLO.
- Autoscaling: шарды/partitions не масштабируются мгновенно — используйте больше initial partitions или систему перераспределения данных.
- Testing & chaos: нагрузочные тесты, тесты восстановления, тестирование replays.
- Observability: latency percentiles ($p_{50},p_{95},p_{99}$), throughput, lag per partition, consumer rebalances, error rates.
8) Пример целевых SLO/метрик (ориентир)
- Ingress throughput: $\approx 10^6$ evt/s (кластер).
- End‑to‑end latency (raw ingest → processing output): «реaltime» пул — целить $<100$ ms для простых путей; агрегации/оконные вычисления — $100-1000$ ms или больше в зависимости от окна.
- Delivery semantics: at‑least‑once по умолчанию; exactly‑once только там, где критично.
Подытоживая: базовый выбор — Kafka + Flink (или Kafka Streams) + ClickHouse/Cassandra + S3; использовать partitioning/sharding, event sourcing для replay, CQRS для проекций, idempotency/DEDUP для надёжности. Балансируйте latency и consistency: для массовой телеметрии чаще выбирают высокую доступность и eventual consistency с возможностью переобработки событий.