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