2010年底后再來看2010年都干了啥

@true
你說的這種模式也是使用較廣的，而且比較適合使用在賬號代理角色代理上，比如玩家的定時保存信息，完全是無序不需要保證先后順序的，則可以在邏輯層直接轉空閑線程處理，而玩家退出登錄這類要保證先后順序的操作就必須要由一個線程單獨處理。在邏輯模塊的開發上我個人還沒成功使用過，有序和無序的分開解決，是解決了安全問題，但是無形中進一步加大了開發上手度和難度，而且各邏輯模塊間也再也不能直接交互了，只能以消息棒的形式交互了。

@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,而后是各個場景再來各個的邏輯處理線程處理各個場景的消息隊列

我覺得開發中還是需要在必要的地方結合特項目的特殊情況做特殊考慮與處理，
這也就是一種構思了，還需要一些具體實施
從設計模式角度來說，肯定是不夠好的了，要不怎么叫異變呢。。。
不過從性能上來說，個人認為還是提高的。。。

@keror
通用完全獨立模塊和效率必然要選擇其一了。

@不知道
缺點的確有，從架構上來說，層次互饒的確不好，但是具備了一定的好處，而且可以從設計模式的角度做好層次互分，我是這么認為的
1：首先 如果還是在網絡層一個線程對所有SOCKET做處理 再轉發至各個場景消息隊列 由各個場景的消息處理線程對其做處理，也的確可實現消息處理的多線程，但是不可避免的，在SOCKET對LINK的管理上任然會出現性能瓶頸，因為在進出口上只有一條路（如果進出口這里直接用多線程，則會出現無法知道與控制與為什么是這個線程管理這個Link 而另一個線程管理另幾個Link）
2：如果將LINK的管理層次上到場景級別，缺點是一定層度上與架構第二層次互饒，但是優點是對各個LINK的管理也不再是一條路了，由各個場景LINK管理線程對各個場景內的LINK做管理，也是多條路了，而后再發至各個場景消息隊列，又各個場景消息處理線程對消息做邏輯層次處理，可解決瓶頸
3：從模式角度來解決耦合度的問題，制造SceneLinkManager 掛接各個場景，制造各個SceneLinkManager線程，服務器啟動根據場景來生成，而SceneLogic與PlayerLogic仍在上一層次，消息進入隊列從Link找到Player,并且再制造每個場景的消息邏輯處理線程，消息隊列的邏輯處理只在這里面進行，因而我們仍然認為此Manager還是屬于網絡層次，對于上層邏輯無需關注SceneLinkManager的操作。

A*是最垃圾的，實際開發中肯定不會用了 哈

BLOG玩的不熟，其實這方面我OUT了。。。。晚上研究下。。。。。。。俺本來是準備畫圖的，然后一打字就顯麻煩就直接打字畫了。。然后還自認為格式弄的很好，而后發出來成這樣了。。。。。。

謝謝支持。力求最淺的表達出所應了解度

哈

。。。。。。。。。。。。。。。。。。。

一到晚上就精神了、、、、、、、不到個幾點睡不著啊

拍磚就好 本來就是新手看啦

"籃子"。。。。。。。。。。剛才讀樓上評論歪音了

昨晚還漏了模塊，晚上在2里補