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