Прескочи на главни садржај
🔒 Режим прегледа. Првих петнаест Foundations лекција је бесплатно; ова је Pro. Покрените 7-дневни trial да откључате едитор, AI савете и остатак курса. Картица је обавезна, можете отказати у било ком тренутку у Dashboard.
Покрени 7-дневни trial →
⚡
← Kursevi
›
System Design for Python Juniors
›
Модул 3 · Базе података и складиштење
›
Противпритисак у стримингу: прозори, испуштање, баферовање
quiz
41 / 105
🇷🇸
SR
▼
↗
Подели
⋯
Више
+125 XP
📋
Zadatak
📖
Teorija
🤖
AI Pomoć
Zadatak
📝 **Питање:** Ваша услуга преузима телеметрију ИоТ сензора при 1М догађаја/с. Низводни Кафка писац може да уради 600К/с. Након 30 минута, апликација ООМс. Најбоље решење? 📋 Изаберите тачан одговор. 💡 **Савет:** Поново прочитајте горњу теорију ако нисте сигурни.
🎯 Kviz
Pitanje
📝 **Питање:** Ваша услуга преузима телеметрију ИоТ сензора при 1М догађаја/с. Низводни Кафка писац може да уради 600К/с. Након 30 минута, апликација ООМс. Најбоље решење? 📋 Изаберите тачан одговор. 💡 **Савет:** Поново прочитајте горњу теорију ако нисте сигурни.
A
Buy bigger boxes — double the RAM per ingestion node and let the in-process queue keep growing until the next quarterly capacity review eventually catches up to the trend
B
Use a bounded buffer (e.g. ring buffer of 1M events) with a drop policy (drop oldest or sample) — telemetry is OK with sampling. Add monitoring on drop rate so you know when capacity is needed
C
Add Kafka brokers — bump the cluster from six brokers to twelve and re-partition the topic so the producer side can push the full 1M events per second without buffering
D
Run a cron job that restarts the ingestion service every thirty minutes — process restart clears the in-memory buffer and is the cheapest mitigation that can ship before tomorrow
Odgovori
💬 Diskusija
Budi prvi — postavi pitanje ili podeli savet.
Prijavi se
da bi se pridružio diskusiji. Čitanje je besplatno.
Učitavanje diskusije…