Seni Bina Penstriman RTSP Penskalaan Auto dengan Dwiorkestrator & Tanpa Kehilangan Paket

Kami mereka bentuk seni bina penstriman penskalaan auto dwiorkestrator dengan kluster pengambilan dan pengedaran yang berasingan, penutupan berperingkat 5 fasa untuk kehilangan paket sifar, URL berasaskan DNS yang stabil, dan penyambungan semula pekerja AI automatik.

Seni Bina

• Pelayan Penstriman: MediaMTX untuk sokongan protokol RTSP/WebRTC/HLS
• Kluster Pengambilan: 1-10 pelayan menerima strim RTSP kamera
• Kluster Pengedaran: 2-20 pelayan melayan penonton (WebRTC/HLS) dan pekerja AI (RTSP)
• Dwiorkestrator: Pengawal penskalaan bebas untuk pengambilan dan pengedaran
• Load Balancer: Load balancer berasingan setiap kluster dengan algoritma yang sesuai protokol
• Daftar Perkhidmatan: Redis untuk status pelayan, pemetaan strim, dan koordinasi
• Pemantauan Kesihatan: Pemeriksaan kesihatan aktif dengan pemulihan automatik
• Lapisan DNS: Nama domain stabil menunjuk ke load balancer (URL tidak pernah berubah)

Reka Bentuk Dwiorkestrator

Mengapa Dua Orkestrator

Pengambilan dan pengedaran mempunyai ciri penskalaan yang berbeza secara asasnya:

• Pengambilan berskala dengan kiraan kamera dan lebar jalur masuk (boleh diramal, berkembang mantap)
• Pengedaran berskala dengan kiraan penonton dan permintaan pekerja AI (berkembang mendadak, tidak dapat diramal)

Orkestrator berasingan membolehkan setiap satu berskala secara bebas dengan polisi, metrik, dan ambang khusus — tanpa keputusan penskalaan satu kluster menjejaskan yang lain.

Orkestrator Pengambilan

• Metrik Utama: Sambungan kamera setiap pelayan
• Metrik Sekunder: Penggunaan lebar jalur masuk
• Skala Ke Atas: Apabila CPU melebihi ambang atau kamera setiap pelayan melebihi kapasiti
• Skala Ke Bawah: Apabila penggunaan jatuh di bawah ambang untuk tempoh penstabilan yang berterusan
• Julat Pelayan: 1 hingga 10 pelayan

Orkestrator Pengedaran

• Metrik Utama: Sambungan penonton + pekerja AI setiap pelayan
• Metrik Sekunder: Penggunaan lebar jalur keluar
• Skala Ke Atas: Apabila CPU melebihi ambang atau sambungan setiap pelayan melebihi kapasiti
• Skala Ke Bawah: Apabila penggunaan jatuh di bawah ambang untuk tempoh yang berterusan (penstabilan lebih lama daripada pengambilan)
• Julat Pelayan: 2 hingga 20 pelayan (minimum 2 untuk ketersediaan tinggi)

Tanpa Kehilangan Paket: Penutupan Berperingkat 5 Fasa

Apabila pelayan pengedaran dijadualkan untuk dialih keluar, proses 5 fasa memastikan tiada bingkai yang hilang:

Fasa 1: Pra-Pemberitahuan

Pelayan ditandakan sebagai "DRAINING" dalam daftar perkhidmatan. Berat load balancer dikurangkan supaya sambungan baharu dialihkan ke tempat lain. Pemberitahuan Redis pub/sub dan webhook memaklumkan pekerja AI untuk bersedia untuk penghijrahan.

Fasa 2: Kemas Kini Load Balancer

Pelayan dikeluarkan daripada kumpulan backend load balancer. Tiada sambungan baharu boleh mencapai pelayan yang sedang dikosongkan. Sambungan sedia ada diteruskan tanpa gangguan.

Fasa 3: Penghijrahan Pekerja AI

Pekerja AI memutuskan sambungan daripada pelayan yang sedang dikosongkan dan menyambung semula ke pelayan pengedaran yang sihat. Pemeliharaan keadaan berasaskan pusat pemeriksaan memastikan pemprosesan disambung semula dari bingkai yang tepat di mana ia berhenti. Jumlah jurang: kira-kira 3 saat tanpa bingkai hilang.

Fasa 4: Pengosongan Penonton

Sambungan penonton yang tinggal mengosongkan secara semula jadi dalam tetingkap yang boleh dikonfigurasi. Pemain video moden menyambung semula secara automatik ke URL stabil yang sama, yang menghala ke pelayan yang sihat. Kebanyakan penonton tidak mengalami gangguan.

Fasa 5: Pembersihan

Sahkan semua sambungan telah ditutup. Buang pelayan daripada daftar perkhidmatan. Musnahkan instans awan. Rekod metrik penskalaan.

URL Stabil

Seni bina URL memastikan kamera dan klien tidak perlu konfigurasi semula:

• Target penerbitan kamera: Nama domain pengambilan yang stabil
• Target akses Penonton/AI: Nama domain pengedaran yang stabil
• Rekod DNS menunjuk ke IP load balancer (yang kekal)
• Load balancer mengendalikan penghalaan ke pelayan backend secara telus
• Pelayan backend boleh ditambah, dialih keluar, atau diganti tanpa perubahan URL

Daftar Perkhidmatan (Redis)

Instans Redis terpusat menyelaraskan keseluruhan sistem:

• Penjejakan status pelayan (aktif, mengosong, luar talian)
• Pemetaan strim ke pelayan (kamera mana berada pada pelayan pengambilan mana)
• Keadaan pekerja AI dan data pusat pemeriksaan
• Metrik beban setiap pelayan untuk keputusan penskalaan
• Saluran Pub/sub untuk peristiwa koordinasi masa nyata

Penyambungan Semula Klien AI

Pustaka klien AI menyediakan penyambungan semula yang lancar:

• Mendengar pemberitahuan pengalihan keluar pelayan melalui Redis pub/sub
• Pusat pemeriksaan bingkai automatik pada selang masa yang tetap
• Penyambungan semula ke pelayan pengedaran yang sihat apabila ada pemberitahuan
• Sambung semula pemprosesan dari pusat pemeriksaan dengan jurang minimum
• Pelaporan metrik untuk peristiwa penyambungan semula

Pemantauan Kesihatan

• Pemeriksaan kesihatan aktif pada setiap pelayan pada selang masa yang tetap
• Kemas kini load balancer automatik pada kegagalan pelayan
• Pencetus pemulihan automatik untuk pelayan yang tidak responsif
• Penjejakan waktu beroperasi dan pelaporan ketersediaan

Ciri-ciri Utama

1. Dwiorkestrator — Penskalaan bebas untuk kluster pengambilan dan pengedaran
2. Tanpa Kehilangan Paket — Penutupan berperingkat 5 fasa dengan penghijrahan pekerja AI
3. URL Stabil — Penghalaan berasaskan DNS memastikan URL tidak pernah berubah semasa penskalaan
4. Penyambungan Semula Pekerja AI — Penghijrahan berasaskan pusat pemeriksaan dengan jurang ~3 saat dan kehilangan bingkai sifar
5. Penskalaan Bebas — Pengambilan dan pengedaran berskala berdasarkan metrik mereka sendiri
6. Daftar Perkhidmatan — Koordinasi berasaskan Redis untuk status pelayan dan pemetaan strim
7. Pemantauan Kesihatan — Pemeriksaan aktif dengan pemulihan automatik
8. Pengoptimuman Kos — Penskalaan ke bawah automatik semasa tempoh permintaan rendah