Sobes.tech
Intervyu yordami
Resurslar
Intervyuga tayyorgarlik
Resurslar
Ish qidirish
Resurslar
Huquqiy
Savollarga qaytish
Senior

Farz qilaylik, biz katta reklama tarmog'imiz. Biz butun dunyo bo'ylab hamkor saytlarida bannerlar joylashtiramiz. Bizga real vaqt rejimida voqealarni yig'ish va ishlov berish tizimini loyihalash kerak. Bu ma'lumotlar ikki maqsad uchun juda muhim: Hisoblash: Kliklar uchun reklama beruvchilardan pul olish. Tahlil: Kampaniyalarning hozirgi samaradorligini (CTR, ko'rsatmalar) shaxsiy panelda ko'rsatish. Kiritma ma'lumotlar (yuklamani hisoblash uchun) Siz o'zingiz talab qilinadigan quvvatlarni baholashingiz kerak (RPS, trafik, saqlash), quyidagi metriklarga asoslanib: Hamkor tarmoq: 500,000 faol sayt. Trafik: Har bir sayt o'rtacha 2 sahifa ko'rinishiga ega sekundiga. Reklama bloklari: Har bir sahifada 3 ta banner bir vaqtning o'zida ko'rsatiladi. Konversiya: O'rtacha CTR (Click-Through Rate) 1%. Noto'g'ri: Pikoviy yuk (kechqurun soatlari) o'rtacha bilan solishtirganda 4 baravar yuqori. Voqealar hajmi: Voqea obyekti (Banner ID, Sayt ID, UserID, Timestamp, voqea turi) taxminan 500 bayt. Texnik talablar Near Real-Time: Analitik interfeysda ma'lumotlar 10 sekunddan ortiq bo'lmagan kechikish bilan paydo bo'lishi kerak. Ishonchlilik: Kliklar yo'qotilishi mumkin emas (bu to'g'ridan-to'g'ri pul yo'qotish). Ko'rsatmalar yo'qotilishi 0.01% gacha qabul qilinadi. O'sish imkoniyati: Tizim platformalar soni ortishi bilan osongina kengaytirilishi kerak.

sobes.tech AI

AIdan javob

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

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

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