@true
你說(shuō)的這種模式也是使用較廣的，而且比較適合使用在賬號(hào)代理角色代理上，比如玩家的定時(shí)保存信息，完全是無(wú)序不需要保證先后順序的，則可以在邏輯層直接轉(zhuǎn)空閑線程處理，而玩家退出登錄這類要保證先后順序的操作就必須要由一個(gè)線程單獨(dú)處理。在邏輯模塊的開(kāi)發(fā)上我個(gè)人還沒(méi)成功使用過(guò)，有序和無(wú)序的分開(kāi)解決，是解決了安全問(wèn)題，但是無(wú)形中進(jìn)一步加大了開(kāi)發(fā)上手度和難度，而且各邏輯模塊間也再也不能直接交互了，只能以消息棒的形式交互了。
@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ì)列
我覺(jué)得開(kāi)發(fā)中還是需要在必要的地方結(jié)合特項(xiàng)目的特殊情況做特殊考慮與處理，
這也就是一種構(gòu)思了，還需要一些具體實(shí)施
從設(shè)計(jì)模式角度來(lái)說(shuō)，肯定是不夠好的了，要不怎么叫異變呢。。。
不過(guò)從性能上來(lái)說(shuō)，個(gè)人認(rèn)為還是提高的。。。
@keror
通用完全獨(dú)立模塊和效率必然要選擇其一了。
@不知道
缺點(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的操作。
A*是最垃圾的，實(shí)際開(kāi)發(fā)中肯定不會(huì)用了 哈
BLOG玩的不熟，其實(shí)這方面我OUT了。。。。晚上研究下。。。。。。。俺本來(lái)是準(zhǔn)備畫(huà)圖的，然后一打字就顯麻煩就直接打字畫(huà)了。。然后還自認(rèn)為格式弄的很好，而后發(fā)出來(lái)成這樣了。。。。。。
謝謝支持。力求最淺的表達(dá)出所應(yīng)了解度
一到晚上就精神了、、、、、、、不到個(gè)幾點(diǎn)睡不著啊
"籃子"。。。。。。。。。。剛才讀樓上評(píng)論歪音了