netty框架做游戲服務器怎么樣？

如果你指的是單機的話，不說Netty會怎么樣，服務器都有可能直接崩潰掉，你的算一下，按平均每鏈接傳輸數據1K，100W鏈接大概數據量會在1G左右，G級服務器網卡也受不了的，我們在網絡編程中對單機來講，成功解決了C10K的問題，這種M級別的鏈接，可能暫時解決不了。對于如此大的并發，一般我們都是通過負載均衡的進行處理，如新浪微博，同時在線100W以上，通過約100多個節點處理，每個節點也就才10000并發左右。

交互游戲是怎么實現的？

（一）需要使用客戶端與服務端建立長鏈接的進行通訊，目前使用Netty通訊，實現長鏈接。Netty自己開發一個server，根據入參數返回一個json字符串。

寫好這個server需要了解：

（1）TCP協議：三次握手、四次揮手、tcp如何保證包的可靠性傳輸（ack，seq，超時重傳），流量控制（滑動窗口，擁堵控制）等

（2）IO通信的幾種，阻塞IO，非阻塞IO，多路復用IO，信號量IO通信，異步IO。目前tomcat支持阻塞IO，多路復用IO，Netty編程都支持，看程序員自己的實現

（3）非阻塞IO原始API比較復雜，后來出現REACTOR的NIO，目前Netty可以支持這種開發

（二）算法，paceman的算法就是最優路徑，一般可以使用圖的深度優先遍歷算法

ghost使用動態規劃的算法，計算下一步

（三）環境，可以使用docker進行打鏡像使環境統一部署

長連接的實質是什么？用什么協議比較好？如何優化？

不管長短連接都是tcp層面的，而線程則是處理邏輯層面的事情，沒有一一對應的關系。單線程通過io多路復用，比如epoll，select，iocp也可以同時維護幾萬個長連接。

首先說下，短連接是指的每次客戶端有請求就和服務器建立一個tcp連接，服務器端處理完本次請求就立即關閉連接。短連接適合業務請求小且不頻繁的邏輯，比如timeserver等，好處就是編程簡單，服務器資源也不會被一批客戶一直占用。

Tcp建立連接和釋放連接都是需要時間以及資源消耗的，對于有些業務，比如游戲，客戶端和服務器之間頻繁的通信，如果每次都是臨時建立請求，就非常浪費服務器資源且體驗不好。所以就需要長連接，但是長連接帶來的問題就是邏輯復雜。前后端都需要維護連接的狀態，本身tcp底層是會維護心跳的，但是這個心跳頻率是不確定的。為了實時掌握連接情況，大多數情況，業務層會自己寫一套心跳邏輯，同時會維護一個session會話狀態層。