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