springboot netty如何實(shí)現(xiàn)長連接 netty框架做游戲服務(wù)器怎么樣?
netty框架做游戲服務(wù)器怎么樣?如果你指的是單機(jī)的話,不說Netty會(huì)怎么樣,服務(wù)器都有可能直接崩潰掉,你的算一下,按平均每鏈接傳輸數(shù)據(jù)1K,100W鏈接大概數(shù)據(jù)量會(huì)在1G左右,G級(jí)服務(wù)器網(wǎng)卡也受不
netty框架做游戲服務(wù)器怎么樣?
如果你指的是單機(jī)的話,不說Netty會(huì)怎么樣,服務(wù)器都有可能直接崩潰掉,你的算一下,按平均每鏈接傳輸數(shù)據(jù)1K,100W鏈接大概數(shù)據(jù)量會(huì)在1G左右,G級(jí)服務(wù)器網(wǎng)卡也受不了的,我們?cè)诰W(wǎng)絡(luò)編程中對(duì)單機(jī)來講,成功解決了C10K的問題,這種M級(jí)別的鏈接,可能暫時(shí)解決不了。對(duì)于如此大的并發(fā),一般我們都是通過負(fù)載均衡的進(jìn)行處理,如新浪微博,同時(shí)在線100W以上,通過約100多個(gè)節(jié)點(diǎn)處理,每個(gè)節(jié)點(diǎn)也就才10000并發(fā)左右。
交互游戲是怎么實(shí)現(xiàn)的?
(一)需要使用客戶端與服務(wù)端建立長鏈接的進(jìn)行通訊,目前使用Netty通訊,實(shí)現(xiàn)長鏈接。Netty自己開發(fā)一個(gè)server,根據(jù)入?yún)?shù)返回一個(gè)json字符串。
寫好這個(gè)server需要了解:
(1)TCP協(xié)議:三次握手、四次揮手、tcp如何保證包的可靠性傳輸(ack,seq,超時(shí)重傳),流量控制(滑動(dòng)窗口,擁堵控制)等
(2)IO通信的幾種,阻塞IO,非阻塞IO,多路復(fù)用IO,信號(hào)量IO通信,異步IO。目前tomcat支持阻塞IO,多路復(fù)用IO,Netty編程都支持,看程序員自己的實(shí)現(xiàn)
(3)非阻塞IO原始API比較復(fù)雜,后來出現(xiàn)REACTOR的NIO,目前Netty可以支持這種開發(fā)
(二)算法,paceman的算法就是最優(yōu)路徑,一般可以使用圖的深度優(yōu)先遍歷算法
ghost使用動(dòng)態(tài)規(guī)劃的算法,計(jì)算下一步
(三)環(huán)境,可以使用docker進(jìn)行打鏡像使環(huán)境統(tǒng)一部署
長連接的實(shí)質(zhì)是什么?用什么協(xié)議比較好?如何優(yōu)化?
不管長短連接都是tcp層面的,而線程則是處理邏輯層面的事情,沒有一一對(duì)應(yīng)的關(guān)系。單線程通過io多路復(fù)用,比如epoll,select,iocp也可以同時(shí)維護(hù)幾萬個(gè)長連接。
首先說下,短連接是指的每次客戶端有請(qǐng)求就和服務(wù)器建立一個(gè)tcp連接,服務(wù)器端處理完本次請(qǐng)求就立即關(guān)閉連接。短連接適合業(yè)務(wù)請(qǐng)求小且不頻繁的邏輯,比如timeserver等,好處就是編程簡單,服務(wù)器資源也不會(huì)被一批客戶一直占用。
Tcp建立連接和釋放連接都是需要時(shí)間以及資源消耗的,對(duì)于有些業(yè)務(wù),比如游戲,客戶端和服務(wù)器之間頻繁的通信,如果每次都是臨時(shí)建立請(qǐng)求,就非常浪費(fèi)服務(wù)器資源且體驗(yàn)不好。所以就需要長連接,但是長連接帶來的問題就是邏輯復(fù)雜。前后端都需要維護(hù)連接的狀態(tài),本身tcp底層是會(huì)維護(hù)心跳的,但是這個(gè)心跳頻率是不確定的。為了實(shí)時(shí)掌握連接情況,大多數(shù)情況,業(yè)務(wù)層會(huì)自己寫一套心跳邏輯,同時(shí)會(huì)維護(hù)一個(gè)session會(huì)話狀態(tài)層。