TIM中网络模型变更

一直都隐隐约约的感觉TIM的网络模型还是有点问题,但却总说不出具体问题来。时不时就会想起这个事,今天在车上,终于恍然大悟。
也许是受wildfire和jabberd2的影响太深了(特别是wildfire),TIM中网络和业务处理的联系过于紧密,从套接口读到数据流后,马上就进入XML的PullParser分析阶段,虽然之后有刻意的分离网络操作和业务逻辑,但并不彻底。
有时候业务处理还是能够感觉到网络的存在,我觉得这是个不良的设计。
让我耿耿于怀的,是Reactor的单线程特性。或许在某些情况下这是它的优势,但运用不当,就会成劣势。现在的TIM把业务逻辑和网络IO都挤进了Reactor所控制的线程中,只要存在一点点的阻塞,吞吐率将大打折扣。
wildfire敢把网络和业务绑得那么紧,是因为它采用的per-request,per-thread的模型,网络IO引起的阻塞不会影响到其他request处理。我也没有wildfire那么大的胆子采用per-request,per-thread,上下文切换的消耗不说,毕竟线程的数量也是有限制的,我很怀疑到底能承受多少连接数,如果没有记错,Linux没有重编译内核,一个进程内最多是1024个线程,Windows能多些,好像是65535,数据可能不准确,但也说明了线程资源是有限的。同时,WFMOReactor在Windows下每个线程内可同时监视的句柄数(62个),也似乎太少了,这点也让我烦恼。
仔细推敲后,我认为还是把网络和业务完全脱离比较好一点,用至少一个线程专门操作套接口,突破WaitForMultipleObjects的句柄数限制,再用另外一个线程来完成业务。在业务线程上使用管道过滤器模式来一步一步的处理数据。当Reactor线程接收到数据后,放进MessageBlock里面,用Task框架来处理。
这种模型确实解决了原先的诸多毛病,但如果在这个时候改网络模型,对整个项目是个不小的冲击,极有可能导致在计划的时间内不能完成项目。犹豫了一下,为了保证品质,最终还是在SubVersion上创建了新的试验分支。
module.jpg

你可能感兴趣的:(TIM中网络模型变更)