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里补