这个系列慢慢变成先设想后完成的模式了,上篇我们测试了以Yield当多任务处理.
楼主写了个小Demo也完成了类似功能,并且支持中途等待,直接等到完成回调后,继续处理下一阶段.
这个功能可以完成类似逻辑事件流,比如C需要等待A,B完成后再执行,而且写法也比较简单.直接上代码:
//创建事件,把Handle丢入Yield队列, //执行当发现有等待Handle状态为YieldWating //放入YieldWating队列 //回调时检查YieldWating队列,重新激活 Context.Wating(WatingResultSubCall, (r) => { myvalue = r; Console.WriteLine(myvalue); }, myvalue); yield return -1; Context.Wating(WatingResultSubCall, (r) => { myvalue = r; Console.WriteLine(myvalue); }, myvalue); yield return -1; //返回后继续运行 myvalue *= 100; Console.WriteLine(myvalue);
今天要解决的是关于多个模块和数据之间的交互,众所周知框架尝试使用单线程来避免所有的锁和开销.
但是并不是所有任务都可以在一个线程中解决,我们需要更多独立的模块和更多独立的线程.
但是又不期望开发者在开发时明确区分这些模块.
最好类似正常的函数直接使用,那么才是一个"优雅"的使用方式.
常规的切片一般基于2种:
1.逻辑切片,独立的功能放在独立的线程或者独立的服务器中运行.比如一个单独的聊天模块,或者拍卖行模块.
2.数据切片,切分若干个大小的地图,用于分开负载,或者简单的分多个区,分散玩家.
但是经常会混合起来,若干个区域的玩家,使用若干个独立的功能.
但是对于框架来说并不关心"切片方式",仅关心"调用位置",既:
是否在当前线程中运行?
1.是,则丢入当前线程
2.否,则丢入路由模块,由路由模块寻找所在线程并丢入执行.
那么路由模块承担什么角色?
1.管理所有模块,它需要知道所有模块所在的线程或者服务器节点?
2.管理所有对象,面向对象的过程,我喜欢把方法集成在对象内,当然你也可以不用这么做.路由模块需要知道所有对象所在线程.
3.负责中转所有消息,不管是基于什么传输/跨线程/跨AppDomain/跨服务器,只要完成中转.
从以上分析可以看出,在这样的机制下,实现分布式是一个非常简单的逻辑,无需修改任何代码,只要路由支持转发消息.那么可以部署到任何位置.
唯一要做的只要指定初始化位置即可.
当然所有的编写规则必须经过所谓的代理逻辑,有点像AOP么,确实比较像,只要符合规范的编写过程,那么一切都不是问题.
原文地址:http://blog.csdn.net/icesun963/article/details/41821861