Ας υποθέσουμε ότι είμαστε ένα μεγάλο δίκτυο διαφήμισης. Τοποθετούμε banners σε συνεργατικές ιστοσελίδες σε όλο τον κόσμο. Πρέπει να σχεδιάσουμε ένα σύστημα συλλογής και επεξεργασίας γεγονότων σε πραγματικό χρόνο. Αυτά τα δεδομένα είναι κρίσιμα για δύο σκοπούς: Χρέωση: Απομείωση χρημάτων από διαφημιστές για κλικ. Ανάλυση: Εμφάνιση της τρέχουσας απόδοσης των καμπανιών (CTR, εμφανίσεις) στον πίνακα ελέγχου. Δεδομένα εισόδου (για τον υπολογισμό φόρτου) Πρέπει να εκτιμήσετε μόνοι σας τις απαιτούμενες δυνατότητες (RPS, κυκλοφορία, αποθήκευση), βασιζόμενοι στα ακόλουθα metrics: Δίκτυο συνεργατών: 500.000 ενεργές ιστοσελίδες. Κυκλοφορία: Μέσο όρο, κάθε ιστοσελίδα λαμβάνει 2 προβολές σελίδας ανά δευτερόλεπτο. Μπλοκ διαφημίσεων: Σε κάθε σελίδα εμφανίζονται ταυτόχρονα 3 banners. Μετατροπή: Ο μέσος CTR (Click-Through Rate) είναι 1%. Ανωμαλία: Η αιχμή φόρτου (βραδινές ώρες) είναι 4 φορές μεγαλύτερη από το μέσο όρο. Μέγεθος γεγονότος: Το αντικείμενο γεγονότος (ID banner, ID ιστοσελίδας, UserID, Timestamp, τύπος γεγονότος) ζυγίζει περίπου 500 bytes. Τεχνικές απαιτήσεις Near Real-Time: Τα δεδομένα στην αναλυτική διεπαφή πρέπει να εμφανίζονται με καθυστέρηση όχι μεγαλύτερη από 10 δευτερόλεπτα. Αξιοπιστία: Η απώλεια κλικ δεν είναι αποδεκτή (αυτό σημαίνει άμεση απώλεια χρημάτων). Η απώλεια εμφανίσεων (impressions) είναι αποδεκτή μέχρι 0,01%. Κλιμάκωση: Το σύστημα πρέπει να μπορεί να επεκταθεί εύκολα με την αύξηση του αριθμού των πλατφορμών.

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

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

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