码迷,mamicode.com
首页 > 其他好文 > 详细

高并发编程thirft源码解析

时间:2018-11-25 16:25:45      阅读:194      评论:0      收藏:0      [点我收藏+]

标签:高度   问题   socket   logserver   连接数   serve   一个队列   thrift   默认   

我用的thrift模式:

网络编程模式

arg.selectorThreads(Integer.parseInt(mProp.get("LogServerSelectorThread").toString()));
这步骤是启动了多个线程,每个线程里面有个bocking queue队列,队列元素是socketchannel,线程启动后就不断消费这个队列
并不是select使用了多线程,而是便利selectkey时,没当有一个连接socketchannel进来就加入队列,


arg.workerThreads(Integer.parseInt(mProp.get("LogServerWorkThread").toString()));  //worker线程数
这一步其实是处理selector的连接数,内部使用了ExcuteService这个线程池,
每天有个连接进来,就是用从这个线程池里面任意取一个线程来执行下面这个方法,目的是分别client到一个指定SelectorThread线程里面
invoker.submit(new Runnable() { public void run() { doAddAccept(targetThread, client); } });

 

问题1: 为什么这里使用了两个多线程,为什么不用一个就够了呢?

我的分析是:
1、如果用一个线程池,那么不断有连接进来,就会不断生成一个线程处理,
每个线程都要处理完这些数据才会释放,那么并发高度时候,就会有大量的处理线程积压,
这个线程池就会不断膨胀,最终崩溃
2、如果每个线程内部采用一个队列,那就要分别启动这些线程,并加入socketchannel到这个队列里面

thirft调度策略有:FAIR_ACCEPT和FAST_ACCEPT,默认是后者,
就是说FAST_ACCEPT模式其实就是答案里说的,只是用了一个线程池模式,没有用ExcuteServcie

 

 

问题2: SelectorThread内部为什么用blocking queue,而不用concurrent queue呢?

因为这个queue不需要共享,blocking queue效率更快

 

高并发编程thirft源码解析

标签:高度   问题   socket   logserver   连接数   serve   一个队列   thrift   默认   

原文地址:https://www.cnblogs.com/geektcp/p/10015557.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!