Angenommen, wir sind ein großes Werbenetzwerk. Wir platzieren Banner auf Partnerseiten weltweit. Wir müssen ein System entwerfen, um Ereignisse in Echtzeit zu sammeln und zu verarbeiten. Diese Daten sind für zwei Zwecke kritisch: Abrechnung: Geldabzug von Werbetreibenden für Klicks. Analytik: Anzeige der aktuellen Kampagnenleistung (CTR, Impressionen) im Dashboard. Eingabedaten (zur Berechnung der Last) Sie müssen die erforderlichen Kapazitäten selbst einschätzen (RPS, Traffic, Speicher), basierend auf den folgenden Metriken: Partnernetzwerk: 500.000 aktive Websites. Verkehr: Im Durchschnitt erhält jede Website 2 Seitenansichten pro Sekunde. Werbebanner: Auf jeder Seite werden 3 Banner gleichzeitig angezeigt. Konversion: Die durchschnittliche CTR (Click-Through-Rate) beträgt 1%. Unregelmäßigkeit: Die Spitzenlast (Abendstunden) ist 4-mal höher als der Durchschnitt. Größe des Ereignisses: Das Ereignisobjekt (Banner-ID, Website-ID, UserID, Timestamp, Ereignistyp) wiegt etwa 500 Byte. Technische Anforderungen Near Real-Time: Daten in der Analyseoberfläche sollten mit einer Verzögerung von höchstens 10 Sekunden erscheinen. Zuverlässigkeit: Klickverluste sind nicht akzeptabel (das bedeutet direkten Geldverlust). Impressionverluste (Impressions) sind im Rahmen von 0,01% akzeptabel. Skalierbarkeit: Das System sollte bei wachsender Anzahl der Plattformen leicht erweiterbar sein.

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

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

• Активных сайтов: 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 секунд.