一個典型的游戲服務器設計中,一般都是用的多線程,服務器中一般運行兩類線程,N個SOCKET IO線程,1個邏輯線程,
IO線程接受客戶端發來的信息,通過消息隊列發送給邏輯線程處理后,再發送消息給客戶端,發送消息這里一般是IO線程處理實際發送。
其實我認為,如果邏輯線程都是消耗的CPU運算資源的話,服務器完全采用單線程的方式來做。
首先,我們看IO處理,基本就是數據入隊、出隊,send、recv操作,作為服務器的SOCKET處理一般都是異步SOCKET,也就是說,send、recv操作只是將信息copy到socket底層的發送接收緩沖區去了,不存在IO堵塞的問題。
然后,我們再來看邏輯處理,前面已經說了,采用單線程的前提是邏輯處理只是消耗CPU運算資源,那么,不管你開幾個線程,對單核的CPU來說,它的處理速度就是這么多,并不會因為你線程開的越多,就處理的越快。
因此我們可不可以這樣說呢,在單核機器上,只消耗CPU運算的服務,多線程并不比單線程能提高多少效率。
接下來,我們再討論下多核的情況,你肯定要想,我這臺服務器是4個雙核CPU,就只跑一個單線程的服務器不是虧死了,多線程多好,我開8個線程,就能很好的利用我的機器啦。是啊,我也覺得這樣很好,不過在LINUX、UNIX下,對線程的支持并不像WINDOWS下那么好,LINUX、UNIX下一般都是用LWP(輕量級進程)的方式來支持多線程程序的,Linux內核只提供了輕量進程的支持,限制了更高效的線程模型的實現,但Linux著重優化了進程的調度開銷,一定程度上也彌補了這一缺陷。同時,濫用多線程也會造成不必要的上下文切換,不必要的同步機制的引入(如pthread_mutex),讓程序頻繁的在內核和用戶間頻繁切換。另外,從開發角度來看,單線程開發比多線程環境開發更不容易出錯和更加健壯。
在游戲服務器架構中,為了提高玩家在線人數,實現負載均衡,現在一般都是采用分布式的多進程服務器集群的方式,我們來看看服務器集群中,每個服務進程是采用多線程的方式還是單線程的方式好呢?我覺得,對于有慢速IO訪問的需求的應用進程,多線程肯定比單線程好,最典型的情況就是數據庫訪問這塊,完全可以采用N個DB線程,一個邏輯線程的架構,而對只是消耗CPU運算資源的應用進程,盡量單線程就行了,如果覺得單線程負載不行的話,完全可以分成多個進程來跑。。
以上只是我自己的一些看法,表達有限,歡迎指正。。。
Feedback
多進程單線程。
一個游戲邏輯進程,一個SOCKET進程,一個DB進程,對于MMORPG,還有一個NPC進程處理怪物的AI。
一個游戲邏輯進程,一個SOCKET進程,一個DB進程,對于MMORPG,還有一個NPC進程處理怪物的AI。
# re: 多線程還是單線程? 回復 更多評論
2010-07-06 11:58 by Kevin Lynx@tanxw
AI單獨到一個進程里,這些邏輯模塊之間又涉及到線程同步問題了。
@浩毛
對于只有游戲邏輯和網絡IO的進程而言,你說的只開一個線程,似乎也在理。不過由于網絡IO這塊情況可能比理論上要復雜很多,例如實際使用的網絡IO機制(IOCP)、網絡層數據的拷貝、封包組建等,似乎保險的做法還是開多個線程來做。何況,邏輯線程可能還會涉及到限幀問題。拿去運營的服務器一般也是多核的。LINUX下線程實現的效率如果真的太那個啥,或者可以考慮多進程的結構(網絡模塊和邏輯模塊位于不同進程)。
AI單獨到一個進程里,這些邏輯模塊之間又涉及到線程同步問題了。
@浩毛
對于只有游戲邏輯和網絡IO的進程而言,你說的只開一個線程,似乎也在理。不過由于網絡IO這塊情況可能比理論上要復雜很多,例如實際使用的網絡IO機制(IOCP)、網絡層數據的拷貝、封包組建等,似乎保險的做法還是開多個線程來做。何況,邏輯線程可能還會涉及到限幀問題。拿去運營的服務器一般也是多核的。LINUX下線程實現的效率如果真的太那個啥,或者可以考慮多進程的結構(網絡模塊和邏輯模塊位于不同進程)。
1,socket
2,db
3,event(這里的event是對網絡包的切割或是拼接形成的一個完整事件)
很和諧的三層,在linux一個獨立的服務器(功能獨立),基本照這個模式可以復制出N個服務器。至于是否拆成獨立進程,我是這么考慮的,
1,該模塊是否有很獨立,單一的功能,如驗證
2,該模塊的功能對性能要求是否苛刻,比如AI
2,db
3,event(這里的event是對網絡包的切割或是拼接形成的一個完整事件)
很和諧的三層,在linux一個獨立的服務器(功能獨立),基本照這個模式可以復制出N個服務器。至于是否拆成獨立進程,我是這么考慮的,
1,該模塊是否有很獨立,單一的功能,如驗證
2,該模塊的功能對性能要求是否苛刻,比如AI
一個DB服務器
一個logingate服務器
一個邏輯服務器
其實個人覺得有一個NPC服務器來處理各種模擬事件來維護一個真實的world挺好
一個logingate服務器
一個邏輯服務器
其實個人覺得有一個NPC服務器來處理各種模擬事件來維護一個真實的world挺好
@Kevin Lynx
游戲服務器要提高負載,都是集群的方式,一般都有N個網關的,不管你用IOCP,EPOLL還是KQUEUE,甚至是SELECT都可以的,而網關的功能很簡單的,就是外網和內網之間的信息轉發。因此一個線程就夠了。
對于游戲服務器組件之間的通訊(IPC)來說,就那么幾個連接,SOCKET的上下文切換的消耗是很小的。
另外,IOCP,EPOLL,KQUEUE這種機制,只有在服務器接受了N個客戶端,但是服務器只和其中的很少一部分客戶端在交互的情況下(很少的客戶端在并發接收和發送)才能體現出它們的優點。
而對于游戲服務器來說,你有1000個客戶端在線,這些客戶端基本都在同時發包,可讀可寫事件每個FD都差不多同時產生,這種情況下,EPOLL還是SELECT,效率上來看差別不大。因此,對于需要處理大量高并發的長連接請求的服務器來說,多進程的方式要輕松的多。
游戲服務器要提高負載,都是集群的方式,一般都有N個網關的,不管你用IOCP,EPOLL還是KQUEUE,甚至是SELECT都可以的,而網關的功能很簡單的,就是外網和內網之間的信息轉發。因此一個線程就夠了。
對于游戲服務器組件之間的通訊(IPC)來說,就那么幾個連接,SOCKET的上下文切換的消耗是很小的。
另外,IOCP,EPOLL,KQUEUE這種機制,只有在服務器接受了N個客戶端,但是服務器只和其中的很少一部分客戶端在交互的情況下(很少的客戶端在并發接收和發送)才能體現出它們的優點。
而對于游戲服務器來說,你有1000個客戶端在線,這些客戶端基本都在同時發包,可讀可寫事件每個FD都差不多同時產生,這種情況下,EPOLL還是SELECT,效率上來看差別不大。因此,對于需要處理大量高并發的長連接請求的服務器來說,多進程的方式要輕松的多。
# re: 多線程還是單線程? 回復 更多評論
2010-07-10 16:32 by hoodlum1980雖然可能需要的計算量是固定的,但是在單核上的多線程和單線程也是不一樣的。采用多線程和單線程主要影響你的任務被系統調度的情況。
只有注冊用戶登錄后才能發表評論。 | ||
【推薦】100%開源!大型工業跨平臺軟件C++源碼提供,建模,組態!
![]() |
||
相關文章:
|
||
網站導航:
博客園
IT新聞
BlogJava
博問
Chat2DB
管理
|
||
|