您好,登錄后才能下訂單哦!
這篇文章給大家分享的是有關后臺開發框架UDPServer的工作原理的內容。小編覺得挺實用的,因此分享給大家學習。如下資料是關于UDPServer的介紹和工作原理的內容。
第一個接觸的叫udpserver。顧名思義,就是只支持udp的服務框架。因為我們部門是做音視頻產品的,音視頻數據對實時性要求很高,因此常用udp傳輸數據。Udp server是同步多進程模型,包含1個Interface進程和多個Worker進程。
Iterface進程負責接收來自外部的請求,做一些合法性校驗和格式轉換后,轉發給后端的Worker進程。Worker進程監聽不同的端口收包,并處理業務邏輯。Worker進程的回包直接發給客戶端。
此處有幾個點值得關注:
首先,Worker進程監聽的是不同端口。
監聽相同的端口顯然是更常見的做法,而監聽相同的端口也需要注意一點,即監聽的端口socket必須是從父進程中繼承得到的,而非Worker自己創建的socket。因為對于前者內核才能保證調度的均勻性,而后者是沒有這種效果的,內核只會把請求包扔給同一個Worker。
這里之所以使用監聽不同端口的方案,是為了保證調度的可控性,請求包發往哪個Worker是有預期的,可以做更個性化的調度策略,問題定位也方便得多。Udp server默認是使用輪詢的調度方式。
第二點是,Worker進程回包是直接返回給客戶端的。
另一種常見做法是通過Interface進程回包,缺點是Interface會成為瓶頸。而Worker直接回包的缺點是向外部暴露Worker,不過這個問題并不十分嚴重。相較之下,我們更希望獲得性能的提升。為了給客戶端回包,Interface會把客戶端的ip和端口封裝到請求包發給Worker。
框架雖簡單,但是性能非常優異,作為echosvr性能可達30w+ QPS。但是這個框架不支持TCP,因此只能作為內部的服務框架使用。
看完上述內容,你們對UDPServer有進一步的了解嗎?如果還想學到更多技能或想了解更多相關內容,歡迎關注億速云行業資訊頻道,感謝各位的閱讀。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。