老手拍磚。轉(zhuǎn)載請注明 ziyebuboka
http://m.shnenglu.com/ziyebuboka/ 總所周知，要想服務(wù)器的高效率實現(xiàn)，那么多線程是不可避免的，但是游戲服務(wù)器的多玩家交互的特殊性又使得在邏輯層實現(xiàn)多線程成為了安全瓶頸，以往的架構(gòu)也是只有通過結(jié)構(gòu)功能的不同來實現(xiàn)多線程，比如 網(wǎng)絡(luò)層一個線程 邏輯層一個線程 等等，但是如此并不能有效的通過多線程方式來較好的實現(xiàn)服務(wù)器的高效處理。本文就是探討的如何通過結(jié)合游戲服務(wù)器的特殊性來異變當前主流的網(wǎng)絡(luò)包架構(gòu)模式從而實現(xiàn)服務(wù)端的多線程。
先來看下主流網(wǎng)絡(luò)包的架構(gòu)模式：
網(wǎng)絡(luò)層單獨線程來對LinkManager進行管理，收發(fā)消息加入到LinkMessageBuff（單個Link的消息緩存）中---》收到消息加入服務(wù)器消息隊列中（這里一般可以通過一個消息回調(diào)函數(shù)將消息BUFF引出加入到服務(wù)器的消息隊列中），而后是服務(wù)器的消息處理線程對消息隊列進行處理，拿出消息做邏輯處理。
如此架構(gòu)，在通用模式下較好，較好的實現(xiàn)了模塊化方式，單獨庫的形式，并且與服務(wù)器的具體邏輯處理耦合度較低（只有服務(wù)器開啟的一次網(wǎng)絡(luò)包導(dǎo)出消息的回調(diào)函數(shù)的注冊），但是如此出現(xiàn)的情況是，消息加入到了服務(wù)器的主消息隊列，而后只有一個消息邏輯處理線程對其進行操作，進行各個邏輯處理，在某種程度上無法較好的實現(xiàn)多線程。
http://m.shnenglu.com/ziyebuboka/ 這種情況下，我也做過討論和嘗試，一般的處理情況是在主消息隊列邏輯處理線程之下再分線程（比如可直接轉(zhuǎn)發(fā)線程，或者根據(jù)邏輯模塊轉(zhuǎn)發(fā)線程處理），但是得到的結(jié)果是，
一個是安全上無法做到保證，比如說從主消息隊列再直接轉(zhuǎn)發(fā)分配到多個線程進行處理，但是這里就無法保證消息處理的先后順序了，大家都很清楚，在一些玩家的邏輯操作上，先后順序是需要嚴格的保證的。
一個是開發(fā)成本過高，比如實現(xiàn)單個邏輯模塊單獨線程（比如幫派 國家 隊伍的消息處理單獨），如此的話，在某種邏輯操作上，先后順序可得到保證，但是帶來的后果是開發(fā)成本與學(xué)習(xí)成本過高，在開發(fā)過程中將會陷入鎖的海洋。。。。而對于一般程序員來說，實在要求過高。。。而且也過于接近下層結(jié)構(gòu)，無法有效隔離層次，實現(xiàn)較好的模塊化開發(fā)。。
再來看看異變的架構(gòu)：
http://m.shnenglu.com/ziyebuboka/ 首先我們先來說下服務(wù)器結(jié)構(gòu)，服務(wù)器中的場景（地圖）概念很重要，每一個玩家處在服務(wù)器中，最真實的就是處在服務(wù)器的某一個場景某一點上，每一個場景都必然具備一個PlayerManager來對玩家進行管理。而每一個玩家對應(yīng)的正是一個Link。
如果我們反向思維一下。略微的將LinkManager上移一個層次，將其作為一個場景中的單位，其實一些問題就好解決了。下面具體的說下
我們把網(wǎng)絡(luò)層對LinkManager進行管理收發(fā)消息的線程做多線程處理，但是此處有一個難點，就是你無法知道與控制與為什么是這個線程管理這個Link 而另一個線程管理另幾個Link。
我們將此線程處理也上移一個層次，與場景結(jié)合，一個場景一個線程，來管理處于此場景中的玩家Link，每個Link在自己所處于的場景線程中將對消息進行邏輯處理，如此則將前面的幾個問題都解決了。安全上可保證，比如，因為處于一個場景中的，則同步信息可保證安全，而對于上層邏輯也無需關(guān)注很多的線程概念。而對于不同場景間的交互信息（比如遠距離組隊，聊天消息），則可通過場景的轉(zhuǎn)發(fā)消息加入目標場景消息隊列的機制來處理，因而消息處理的安全任然可以保證。
得到的結(jié)果就是以場景為單位來做多線程對網(wǎng)絡(luò)層進行管理，如此雖然在庫的耦合度上有所增加，但是很多問題都可解決了。此為專門增對游戲服的網(wǎng)絡(luò)包的特殊架構(gòu)，而摒棄了過于通用性所帶來的弊端
下面具體的說下網(wǎng)絡(luò)層上是如何實現(xiàn)：
每一個Link都具備了一個socket，玩家加入到一個場景，則將此Link加入到此場景的LinkMange,并將本socket加入到本場景的fd_set中，而后本場景內(nèi)只需要對存在于本場景fd_set中的socket做select處理，對本場景內(nèi)的Link做收發(fā)消息處理即可。（本場景LinkManager初始化時已加入服務(wù)器socket）
http://m.shnenglu.com/ziyebuboka/ //補充1：
缺點的確有，從架構(gòu)上來說，層次互饒的確不好，但是具備了一定的好處，而且可以從設(shè)計模式的角度做好層次互分，我是這么認為的
1：首先 如果還是在網(wǎng)絡(luò)層一個線程對所有SOCKET做處理 再轉(zhuǎn)發(fā)至各個場景消息隊列 由各個場景的消息處理線程對其做處理，也的確可實現(xiàn)消息處理的多線程，但是不可避免的，在SOCKET對LINK的管理上任然會出現(xiàn)性能瓶頸，因為在進出口上只有一條路（如果進出口這里直接用多線程，則會出現(xiàn)無法知道與控制與為什么是這個線程管理這個Link 而另一個線程管理另幾個Link）
2：如果將LINK的管理層次上到場景級別，缺點是一定層度上與架構(gòu)第二層次互饒，但是優(yōu)點是對各個LINK的管理也不再是一條路了，由各個場景LINK管理線程對各個場景內(nèi)的LINK做管理，也是多條路了，而后再發(fā)至各個場景消息隊列，又各個場景消息處理線程對消息做邏輯層次處理，可解決瓶頸
3：從模式角度來解決耦合度的問題，制造SceneLinkManager 掛接各個場景，制造各個SceneLinkManager線程，服務(wù)器啟動根據(jù)場景來生成，而SceneLogic與PlayerLogic仍在上一層次，消息進入隊列從Link找到Player,并且再制造每個場景的消息邏輯處理線程，消息隊列的邏輯處理只在這里面進行，因而我們?nèi)匀徽J為此Manager還是屬于網(wǎng)絡(luò)層次，對于上層邏輯無需關(guān)注SceneLinkManager的操作。
//補充2：
@expter
你說的這個就是文里面一開始提到的主流線程的架構(gòu)模式了。網(wǎng)絡(luò)層一個，邏輯層一個。安全性等等肯定都是可以做到非常好的，但是效率上肯定就差了，其實各個場景本來就是獨立，完全可以單獨開線程，這個文討論的就是如何用安全高效的方式來解決多線程
10:27 不知道 在回復(fù)中所提到的也是一種主流方式，在消息的邏輯處理模塊為各個場景單獨開線程，但是網(wǎng)絡(luò)層收發(fā)消息的處理上仍然還是一個，所以我這里提出的就是可以依據(jù)游戲服務(wù)器的特殊性，以場景為單位來管理本場景內(nèi)的LINK，在網(wǎng)絡(luò)收發(fā)處為每個場景開線程來收發(fā)。
也有一種情況可以是直接在網(wǎng)絡(luò)層為link分組各個線程管理，比如預(yù)生成的1000個Link，0--499號Link是A線程管理，500--999是B線程管理，但是這樣會在消息同步等方面出現(xiàn)問題，比如A玩家和B玩家打架 A砍了B一刀，B砍了A一刀，這時候在先后順序上就有可能出現(xiàn)問題了，A的Link在A線程，B的Link在B線程，有可能是A的操作是先做，但是B線程先Tick了，導(dǎo)致B的砍一刀比A的砍一刀先處理了。。所以我這里提出是以場景為單位來管理Link 則這種問題就會避免了。。
我這里提出的模式就是網(wǎng)絡(luò)層以場景為單位線程管理本場景內(nèi)LINK,而后是各個場景再來各個的邏輯處理線程處理各個場景的消息隊列
結(jié)束語，本文寫的不好，有不清楚的地方提出我再加。歡迎評論與討論，也希望能得到更好的方式。
http://m.shnenglu.com/ziyebuboka/