MicrocosmWorksInnovoimassa ja Arkkitehtuuria Digitaalisessa Kosmoksessa
TietoaYhteystiedot
MicrocosmWorksInnovoimassa ja suunnittelemassa digitaalista kosmosta

Toimitamme IT-ratkaisuja, joilla on merkitystä. Olemme intohimoisia teknologiasta, turvallisuudesta ja autamme yrityksiä kasvamaan luotettavan, innovatiivisen IT-infrastruktuurin kautta.

[email protected]
+91 7011868196
New Delhi, India

AI Kasvuhubi

AI HubStartup-innovaatiotYrityskiihdyttämö

Ratkaisut

Kaikki ratkaisutHyvinvointi- ja kuntoilusovelluksetAI-videoplatformiAI-agenttikehitys

Resurssit

OivalluksetToimialan oppaatKäyttötapausmallitArkkitehtuurimallitTapaustutkimukset

Yritys

Tietoa meistäYhteystiedotTyömme

Palvelut

Digitaalinen konsultointiPilvi-infrastruktuuriSaaS-kehitysAI-kehitysVideoteknologia
ERP-kehitysZoho-mukautusOdoo-kehitysSalesforce-integraatioMukautettu CRM-kehitys
QuickBooks-integraatioIoT-ratkaisutLohkoketjukehitys
KyberturvallisuuskonsultointiIT-tuki - L3

© 2026 MicrocosmWorks. Kaikki oikeudet pidätetään.

TietosuojakäytäntöKäyttöehdot
Takaisin Tapaustutkimuksiin
AI SurveillanceJulkaistu June 22, 2026 · Päivitetty June 22, 2026

Automaattisesti skaalautuva RTSP-suoratoistoarkkitehtuuri kahdella orkestraattorilla ja nollapakettihäviöllä

Valvonta-alustan oli skaalattava videostriimausinfrastruktuuriaan dynaamisesti — käsittelemään missä tahansa 10–200+ IP-kameraa satojen samanaikaisten katsojien ja AI-käsittelytyöntekijöiden kanssa — samalla taaten nollapakettihäviön skaalausoperaatioiden aikana ja ylläpitäen vakaita striimi-URL-osoitteita, jotka eivät koskaan muutu.

Keskustele Projektistasi
rtsp-streaming-autoscale-mediamtx.webp
AI Surveillance
Domain
11
Technologies
6
Key Results
Delivered
Status

Haaste

Kiinteä striimausinfrastruktuuri ei kyennyt käsittelemään kasvavan valvonta-alustan vaihtelevia vaatimuksia:

  • Skaalautuvuuden vaihtelu — Kameroiden määrä ja katsojien kysyntä vaihtelivat dramaattisesti päivän aikana (10-kertainen huippu-kuoppa-suhde)
  • Ylisuunnittelun kustannukset — Huippukuormituksen varaaminen tarkoitti yli 70 %:n joutokäyntiä resursseille hiljaisina aikoina
  • Pakettihäviö skaalauksen aikana — Striimauspalvelimien lisääminen tai poistaminen aiheutti striimin keskeytyksiä pudottaen frameja AI-käsittelytyöntekijöiltä
  • URL-osoitteiden epävakaus — Kamerat ja katsojat, jotka oli konfiguroitu tietyillä palvelin-IP-osoitteilla, tarvitsivat uudelleenkonfigurointia infrastruktuurin muuttuessa
  • Erilaiset skaalaustarpeet — Kamerasyötön ja katsojien jakelun oli pohjimmiltaan erilaiset kuormitusmallit, jotka vaativat itsenäistä skaalausta
  • AI-työntekijän keskeytys — AI-käsittelyputket kaatuivat, kun niiden lähdestriimauspalvelin skaalattiin alas

Meidän Ratkaisumme

Suunnittelimme automaattisesti skaalautuvan striimausarkkitehtuurin kahdella orkestraattorilla, jossa on erilliset syöttö- ja jakeluklusterit, 5-vaiheinen hallittu alasajo nollapakettihäviöllä, vakaat DNS-pohjaiset URL-osoitteet ja automatisoitu AI-työntekijöiden uudelleenyhteys.

Arkkitehtuuri

  • Striimauspalvelin: MediaMTX RTSP/WebRTC/HLS-protokollatuella
  • Syöttöklusteri: 1–10 palvelinta, jotka vastaanottavat kameroiden RTSP-striimejä
  • Jakeluklusteri: 2–20 palvelinta, jotka palvelevat katsojia (WebRTC/HLS) ja AI-työntekijöitä (RTSP)
  • Kaksi orkestraattoria: Itsenäiset skaalausohjaimet syöttöä ja jakelua varten
  • Kuormantasaajat: Erilliset kuormantasaajat kullekin klusterille protokollakohtaisilla algoritmeilla
  • Palvelurekisteri: Redis palvelimen tilan, striimien kartoituksen ja koordinoinnin hallintaan
  • Tilannevalvonta: Aktiiviset kuntotarkistukset automatisoidulla palautuksella
  • DNS-kerros: Vakaat verkkotunnukset, jotka osoittavat kuormantasaajiin (URL-osoitteet eivät koskaan muutu)

Kahden orkestraattorin suunnittelu

Miksi kaksi orkestraattoria

Syötöllä ja jakelulla on pohjimmiltaan erilaiset skaalausominaisuudet:

  • Syöttö skaalautuu kameroiden määrän ja sisäänpäin suuntautuvan kaistanleveyden mukaan (ennustettavissa, kasvaa tasaisesti)
  • Jakelu skaalautuu katsojamäärän ja AI-työntekijöiden kysynnän mukaan (purskeinen, ennustamaton)

Erilliset orkestraattorit antavat kummankin skaalata itsenäisesti erikoistuneilla käytännöillä, mittareilla ja kynnysarvoilla — ilman, että toisen klusterin skaalauspäätökset vaikuttavat toiseen.

Syöttöorkestraattori

  • Ensisijainen mittari: Kamerayhteydet palvelinta kohti
  • Toissijainen mittari: Saapuvan kaistanleveyden käyttöaste
  • Skaalaus ylöspäin: Kun CPU ylittää kynnysarvon tai kameroiden määrä palvelinta kohti ylittää kapasiteetin
  • Skaalaus alaspäin: Kun käyttöaste laskee alle kynnysarvon jatkuvan vakausjakson ajan
  • Palvelinalue: 1–10 palvelinta

Jakeluorkestraattori

  • Ensisijainen mittari: Katsoja- + AI-työntekijäyhteydet palvelinta kohti
  • Toissijainen mittari: Lähtevän kaistanleveyden käyttöaste
  • Skaalaus ylöspäin: Kun CPU ylittää kynnysarvon tai yhteyksien määrä palvelinta kohti ylittää kapasiteetin
  • Skaalaus alaspäin: Kun käyttöaste laskee alle kynnysarvon jatkuvan jakson ajan (pidempi vakausjakso kuin syötöllä)
  • Palvelinalue: 2–20 palvelinta (vähintään 2 korkean käytettävyyden varmistamiseksi)

Nollapakettihäviö: 5-vaiheinen hallittu alasajo

Kun jakelupalvelin on ajoitettu poistettavaksi, 5-vaiheinen prosessi varmistaa, ettei frameja katoa:

Vaihe 1: Esihälytys

Palvelin merkitään "DRAINING"-tilaksi palvelurekisterissä. Kuormantasaajan painoa vähennetään, jotta uudet yhteydet reitittyvät muualle. Redis pub/sub -ilmoitukset ja webhookit varoittavat AI-työntekijöitä valmistautumaan siirtoon.

Vaihe 2: Kuormantasaajan päivitys

Palvelin poistetaan kuormantasaajan taustapoolista. Uudet yhteydet eivät pääse tyhjentyvälle palvelimelle. Olemassa olevat yhteydet jatkuvat keskeytyksettä.

Vaihe 3: AI-työntekijän siirto

AI-työntekijät katkaisevat yhteyden tyhjentyvältä palvelimelta ja muodostavat uudelleen yhteyden toimiviin jakelupalvelimiin. Tarkistuspistepohjainen tilansäilytys varmistaa, että käsittely jatkuu täsmälleen siitä framesta, mihin se jäi. Kokonaiskatkos: noin 3 sekuntia ilman yhtäkään kadonnutta framea.

Vaihe 4: Katsojien tyhjentäminen

Jäljellä olevat katsojayhteydet tyhjenevät luonnollisesti konfiguroitavan aikavälin kuluessa. Nykyaikaiset videosoittimet muodostavat automaattisesti uudelleen yhteyden samaan vakaaseen URL-osoitteeseen, joka reitittyy toimiviin palvelimiin. Useimmat katsojat eivät koe keskeytystä.

Vaihe 5: Puhdistus

Tarkista, että kaikki yhteydet ovat sulkeutuneet. Poista palvelin palvelurekisteristä. Tuhoa pilvipalvelimen instanssi. Tallenna skaalausmittarit.

Vakaat URL-osoitteet

URL-arkkitehtuuri varmistaa, että kamerat ja asiakkaat eivät koskaan tarvitse uudelleenkonfigurointia:

  • Kameran julkaisukohde: Vakaa syötön verkkotunnus
  • Katsojan/AI-pääsyn kohde: Vakaa jakelun verkkotunnus
  • DNS-tietueet osoittavat kuormantasaajan IP-osoitteisiin (jotka ovat pysyviä)
  • Kuormantasaajat hoitavat reitityksen taustapalvelimille läpinäkyvästi
  • Taustapalvelimia voidaan lisätä, poistaa tai korvata ilman URL-muutoksia

Palvelurekisteri (Redis)

Keskitetty Redis-instanssi koordinoi koko järjestelmää:

  • Palvelimen tilan seuranta (aktiivinen, tyhjentymässä, offline)
  • Striimien kartoitus palvelimiin (mikä kamera on millä syöttöpalvelimella)
  • AI-työntekijän tila- ja tarkistuspistetiedot
  • Kuormitusmittarit palvelinta kohti skaalauspäätöksiä varten
  • Pub/sub-kanavat reaaliaikaisia koordinointitapahtumia varten

AI-asiakkaan uudelleenyhteys

AI-asiakaskirjasto tarjoaa saumattoman uudelleenyhteyden:

  • Kuuntelee palvelimen poistoilmoituksia Redis pub/sub -palvelun kautta
  • Automaattinen framien tarkistuspisteiden luonti säännöllisin väliajoin
  • Uudelleenyhteys toimivaan jakelupalvelimeen ilmoituksen yhteydessä
  • Jatka käsittelyä tarkistuspisteestä minimaalisella viiveellä
  • Mittarien raportointi uudelleenyhteystapahtumista

Tilannevalvonta

  • Aktiiviset kuntotarkistukset jokaisella palvelimella säännöllisin väliajoin
  • Automaattiset kuormantasaajan päivitykset palvelinvikojen yhteydessä
  • Automaattiset palautuskäynnistimet reagoimattomille palvelimille
  • Käyttöajan seuranta ja käytettävyysraportointi

Tärkeimmät ominaisuudet

  1. Kaksi orkestraattoria — Itsenäinen skaalaus syöttö- ja jakeluklustereille
  2. Nollapakettihäviö — 5-vaiheinen hallittu alasajo AI-työntekijän siirrolla
  3. Vakaat URL-osoitteet — DNS-pohjainen reititys varmistaa, etteivät URL-osoitteet koskaan muutu skaalauksen aikana
  4. AI-työntekijän uudelleenyhteys — Tarkistuspistepohjainen siirto noin 3 sekunnin viiveellä ja nollalla framen häviöllä
  5. Itsenäinen skaalaus — Syöttö ja jakelu skaalautuvat omien mittareidensa perusteella
  6. Palvelurekisteri — Redis-pohjainen koordinointi palvelimen tilan ja striimien kartoitusten osalta
  7. Tilannevalvonta — Aktiiviset tarkistukset automaattisella palautuksella
  8. Kustannusoptimointi — Automaattinen skaalaus alaspäin alhaisen kysynnän aikana

Tulokset

Pakettihäviö: 0,00 % AI-työntekijöille skaalausoperaatioiden aikana
AI-uudelleenyhteys: ~3 sekuntia tarkistuspistepohjaisella jatkamisella
Ylöspäin skaalauksen aika: ~60 sekuntia käynnistyksestä palvelun tarjoamiseen

Teknologiapino

MediaMTXPythonFastAPIRedisDockerCloud VM APIsLoad BalancersDNSPrometheusGrafanaWebSocket

caseStudyDetail.more Tapaustutkimukset

Tutustu lisää teknisiin toteutuksiimme

AI Accounting

AI-pohjainen laskujen käsittely OCR:n ja QuickBooks-integraation avulla

Keskisuuri yritys, joka käsitteli satoja toimittajalaskuja kuukausittain, halusi poistaa manuaalisen tiedonsyötön poimimalla laskutiedot automaattisesti AI/OCR:n avulla ja synkronoimalla ne suoraan QuickBooks-järjestelmään kirjanpitoa ja maksujen seurantaa varten.

Lue Tapaustutkimus
Video Encoding

Asiakaspuolen mainosten upotus (CSAI) SCTE-35-merkkien jäsennyksellä ja monialustaisen soittimen integroinnilla

Videoiden suoratoistoalustan piti toteuttaa Client-Side Ad Insertion (CSAI) verkko-, mobiili- ja Connected TV -sovellusten yli — mahdollistaen personoidut, laitekohtaiset mainoskokemukset täydellä mainosinteraktion tuella (klikkaavat peittokuvat, kumppanibannerit, ohituspainikkeet), joita server-side insertion ei voi tarjota.

Lue Tapaustutkimus

Valmis Muuttamaan Liiketoimintaasi?

Keskustellaan siitä, miten voimme soveltaa vastaavia ratkaisuja haasteisiisi.

Ota YhteyttäcaseStudyDetail.viewAllCaseStudies
Alaspäin skaalauksen aika: ~220 sekuntia täydellä hallitulla alasajolla
URL-vakaus: 100 % — ei URL-osoitemuutoksia missään skaalaustapahtumissa
Käyttöaika: 99,95 % järjestelmän käytettävyys
Web Scraping

Tekoälykäyttöinen blogisisällön kaavinta- ja generointialusta

Mediakonserni tarvitsi älykkään sisältöalustan, joka voisi automatisoida blogisisällön luomisen kaapimalla olemassa olevaa verkkosisältöä, analysoimalla sitä AI:lla ja luomalla alkuperäisiä, SEO-optimoituja blogikirjoituksia poimitusta tiedosta.

Lue Tapaustutkimus

Usein kysytyt kysymykset

MicrocosmWorks toteutti aktiivinen-aktiivinen kaksoisorkestraattorimallin, jossa molemmat orkestraattorit ylläpitävät synkronoitua tilaa suoratoistotehtävistä ja workerien kunnosta, automaattisella failoverilla, joka siirtää suoratoiston hallinnan selviytyneelle orkestraattorille sekunneissa, jos toinen vikaantuu. Tämä eliminoi yksittäisen vikapisteen, josta perinteiset yhden orkestraattorin mallit kärsivät, varmistaen nollapakettihäviön orkestraattorin huollon tai odottamattomien kaatumisten aikana.

MicrocosmWorks suunnitteli elegantin poistumismekanismin, jossa poistuvat työntekijät jatkavat niille määrättyjen striimien palvelemista, kunnes kaikki yhteydet on siirretty puhtaasti uusille työntekijöille RTSP TEARDOWN- ja re-SETUP-sekvenssien kautta. Uudet työntekijät alustetaan täysin ja niiden terveystarkastus suoritetaan ennen striimimääräysten vastaanottamista, ja siirtymä käyttää päällekkäisiä ikkunoita, joissa sekä vanhat että uudet työntekijät palvelevat lyhyen aikaa samaa striimiä estääkseen katkokset.

MicrocosmWorks valitsi MediaMTX:n tähän projektiin, koska se on kevyt, avoimen lähdekoodin ja suunniteltu erityisesti RTSP-uudelleenstriimausta varten minimaalisella resurssikuormituksella per striimi verrattuna täysiverisiin mediapalvelimiin. Se tukee dynaamista striimin luomista API:n kautta, toimii tehokkaasti kontteissa Kubernetes-pohjaista automaattista skaalausta varten ja välttää kaupallisten vaihtoehtojen, kuten Wowza, striimikohtaiset lisenssimaksut, jotka voivat tulla kohtuuttomiksi mittakaavassa.

MicrocosmWorks otti käyttöön kattavan observointipinon, joka seuraa striimikohtaisia mittareita, mukaan lukien pakettihäviöasteen, jitterin, uudelleenkytkentöjen määrän ja päästä päähän -viiveen, hälytyksillä, jotka laukeavat ennen kuin heikkeneminen tulee näkyväksi loppukäyttäjille. Valvontajärjestelmä seuraa myös orkestraattorin päätöksentekomittareita, kuten skaalaustapahtumia, striimien siirtojen kestoja ja worker-resurssien käyttötrendejä ennakoivan kapasiteettisuunnittelun mahdollistamiseksi.

Kyllä, MicrocosmWorks suunnitteli työnodit tukemaan samanaikaista RTSP-ulostuloa reaaliaikaisille katsojille ja segmentoituja tallennuksia objektitallennukseen, itsenäisellä resurssinallokoinnilla kullekin työkuormalle. Tallennus käyttää erillistä kirjoituspolkua, joka puskuroi segmenttejä paikallisesti ennen lataamista, joten tallennuksen I/O-piikit eivät koskaan vaikuta live-streamin toimitukseen, ja auto-scaler ottaa huomioon molempien työkuormien yhdistetyn resurssitarpeen skaalauspäätöksiä tehdessään.