后臺(tái)開(kāi)發(fā)框架UDPServer的工作原理

這篇文章給大家分享的是有關(guān)后臺(tái)開(kāi)發(fā)框架UDPServer的工作原理的內(nèi)容。小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)。如下資料是關(guān)于UDPServer的介紹和工作原理的內(nèi)容。

第一個(gè)接觸的叫udpserver。顧名思義，就是只支持udp的服務(wù)框架。因?yàn)槲覀儾块T(mén)是做音視頻產(chǎn)品的，音視頻數(shù)據(jù)對(duì)實(shí)時(shí)性要求很高，因此常用udp傳輸數(shù)據(jù)。Udp server是同步多進(jìn)程模型，包含1個(gè)Interface進(jìn)程和多個(gè)Worker進(jìn)程。

Iterface進(jìn)程負(fù)責(zé)接收來(lái)自外部的請(qǐng)求，做一些合法性校驗(yàn)和格式轉(zhuǎn)換后，轉(zhuǎn)發(fā)給后端的Worker進(jìn)程。Worker進(jìn)程監(jiān)聽(tīng)不同的端口收包，并處理業(yè)務(wù)邏輯。Worker進(jìn)程的回包直接發(fā)給客戶(hù)端。

此處有幾個(gè)點(diǎn)值得關(guān)注：

首先，Worker進(jìn)程監(jiān)聽(tīng)的是不同端口。

監(jiān)聽(tīng)相同的端口顯然是更常見(jiàn)的做法，而監(jiān)聽(tīng)相同的端口也需要注意一點(diǎn)，即監(jiān)聽(tīng)的端口socket必須是從父進(jìn)程中繼承得到的，而非Worker自己創(chuàng)建的socket。因?yàn)閷?duì)于前者內(nèi)核才能保證調(diào)度的均勻性，而后者是沒(méi)有這種效果的，內(nèi)核只會(huì)把請(qǐng)求包扔給同一個(gè)Worker。

這里之所以使用監(jiān)聽(tīng)不同端口的方案，是為了保證調(diào)度的可控性，請(qǐng)求包發(fā)往哪個(gè)Worker是有預(yù)期的，可以做更個(gè)性化的調(diào)度策略，問(wèn)題定位也方便得多。Udp server默認(rèn)是使用輪詢(xún)的調(diào)度方式。

第二點(diǎn)是，Worker進(jìn)程回包是直接返回給客戶(hù)端的。

另一種常見(jiàn)做法是通過(guò)Interface進(jìn)程回包，缺點(diǎn)是Interface會(huì)成為瓶頸。而Worker直接回包的缺點(diǎn)是向外部暴露Worker，不過(guò)這個(gè)問(wèn)題并不十分嚴(yán)重。相較之下，我們更希望獲得性能的提升。為了給客戶(hù)端回包，Interface會(huì)把客戶(hù)端的ip和端口封裝到請(qǐng)求包發(fā)給Worker。

框架雖簡(jiǎn)單，但是性能非常優(yōu)異，作為echosvr性能可達(dá)30w+ QPS。但是這個(gè)框架不支持TCP，因此只能作為內(nèi)部的服務(wù)框架使用。

看完上述內(nèi)容，你們對(duì)UDPServer有進(jìn)一步的了解嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀。