Supposons que nous sommes un grand réseau publicitaire. Nous plaçons des bannières sur des sites partenaires dans le monde entier. Nous devons concevoir un système de collecte et de traitement des événements en temps réel. Ces données sont critiques pour deux objectifs: Facturation : Déduire de l'argent aux annonceurs pour les clics. Analytique : Afficher l'efficacité actuelle des campagnes (CTR, impressions) dans le tableau de bord. Données d'entrée (pour le calcul de la charge) Vous devez estimer vous-même les capacités requises (RPS, trafic, stockage), en vous basant sur les métriques suivantes: Réseau partenaire : 500 000 sites actifs. Trafic : En moyenne, chaque site reçoit 2 vues de pages par seconde. Blocs publicitaires : Sur chaque page, 3 bannières sont affichées simultanément. Conversion : Le taux moyen de clics (CTR) est de 1%. Inégalité : La charge de pointe (heures du soir) est 4 fois supérieure à la moyenne. Taille de l'événement : L'objet de l'événement (ID de la bannière, ID du site, UserID, Timestamp, type d'événement) pèse environ 500 octets. Exigences techniques Presque en temps réel : Les données dans l'interface analytique doivent apparaître avec un retard ne dépassant pas 10 secondes. Fiabilité : La perte de clics n'est pas acceptable (cela entraîne une perte d'argent). La perte d'impressions est acceptable jusqu'à 0,01%. Scalabilité : Le système doit pouvoir s'étendre facilement avec la croissance du nombre de plateformes.

Для проектирования системы сбора и обработки событий в реальном времени для крупной рекламной сети с указанными параметрами, рассмотрим ключевые аспекты:

Оценка нагрузки

• Активных сайтов: 500,000
• Просмотры страниц в секунду на сайте: 2
• Баннеры на странице: 3
• CTR: 1%
• Пиковая нагрузка: ×4
• Размер события: 500 байт

Расчёт событий в секунду (RPS):

• Просмотры страниц: 500,000 × 2 = 1,000,000 в секунду
• Показов баннеров: 1,000,000 × 3 = 3,000,000 показов в секунду
• Клики: 3,000,000 × 1% = 30,000 кликов в секунду

Пиковая нагрузка: 3,000,000 × 4 = 12,000,000 показов и 30,000 × 4 = 120,000 кликов в секунду.

Трафик данных

• Показ: 500 байт × 12,000,000 = ~6 ГБ/сек
• Клик: 500 байт × 120,000 = ~60 МБ/сек

Архитектура системы

1. Сбор данных:

   • Использовать легковесные агенты или SDK на сайтах для отправки событий.
   • Протоколы: HTTP/2, gRPC или Kafka Producer для высокой пропускной способности.

2. Приём и буферизация:

   • Использовать распределённый брокер сообщений (например, Apache Kafka) для устойчивого приёма и буферизации событий.
   • Настроить партиционирование по ID сайта или баннера для масштабируемости.

3. Обработка:

   • Потоковая обработка с помощью систем типа Apache Flink, Kafka Streams или собственного сервиса на Go.
   • Клики обрабатывать с гарантией доставки (exactly-once или at-least-once).
   • Показов можно допускать небольшую потерю (0.01%), использовать компромиссы в обработке.

4. Хранение:

   • Для биллинга — база данных с транзакционной поддержкой (например, PostgreSQL, CockroachDB).
   • Для аналитики — OLAP-хранилище или колоночная БД (ClickHouse, Druid) для быстрых агрегаций.

5. Отображение данных:

   • Кэширование агрегированных данных для быстрого доступа в личном кабинете.
   • Обновление данных с задержкой не более 10 секунд.

Масштабируемость и надёжность

• Горизонтальное масштабирование всех компонентов.
• Репликация и резервирование брокеров и баз данных.
• Мониторинг и алерты на потерю данных и задержки.

Итог

• Система должна выдерживать до 12 млн событий в секунду на пике.
• Использовать распределённые технологии для приёма и обработки.
• Обеспечить гарантии доставки для кликов и минимальные потери для показов.
• Обеспечить near real-time обновление аналитики с задержкой до 10 секунд.