精华 跨平台模块tagg2,让node多线程支持
发布于 2年前 作者 DoubleSpout 5238 次浏览

上一篇文章详细介绍了Jorge开发的Threads A GoGo模块,这个模块让node支持了多线程的模型,让node可以更好的胜任cpu密集型的应用场景。 上篇文章的传送门: nodejs多线程,真正的非阻塞(cnode) nodejs多线程,真正的非阻塞(我的博客)

不过Threads A GoGo模块(以下简称tagg)开发的比较早,而且已经1年多没有更新了,所以tagg模块还在使用node-waf编译addon,而且tagg模块并不支持windows,对于我个人来讲tagg模块的api并不是我想要的,不友好。比如我要传入到线程的执行,需要写方法名的字符串进去,而且返回值只能通过线程中的return来获得,等等。 于是我就有了对tagg模块进行改造的想法,当然其中不乏遇到一些坑,这些坑在下一篇博客中再进行总结吧,本文主要介绍我对tagg模块进行改造而创建的tagg2模块,毕竟流的还是tagg模块的血,不想改名字了。

安装:npm install tagg2 请保证nodejs的版本在0.8.x以上 github项目地址: https://github.com/DoubleSpout/node-threads-a-gogo2

enter image description here

1、tagg2模块对tagg模块改造最主要的一点就是跨平台支持,对windows、linux和mac都很友好,我在win8(node v0.10.6),centos 2.6.4(node v0.8.16),以及mac ml 10.8.1(node v0.10.6)都经过测试,可以编译通过和运行测试代码。吊丝买不起苹果啊,只能开个vmware虚拟机测试,唉~

2、tagg2模块第二个对tagg模块的改造就是node v0.10.x的支持,由于新的node版本将全部支持node-gyp而放弃node-waf,所以编译的方式也有所改变,tagg2模块放弃了node-waf的支持,采用node-gyp进行编译代码。

3、对tagg模块的api进行改造,新改造的api更加友好,比如我们执行一个执行40次斐波那契算法的线程:

//加载tagg2的模块
var tagg = require('tagg2'); 

//子线程工作函数
var th_func = function(){
    var fibo =function fibo (n) {
             return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1;
        }
    thread.end(fibo(40));
}

//创建子线程,并且注册回调
var thread = tagg.create(th_func, function(err, res){
    if(err) throw new(err);//如果在线程中throw异常,err就会得到相应的错误
    console.log(res);//fibo(40)的结果
    thread.destroy();//摧毁线程
});

当然实际情况可能更加复杂,fibo的次数需要住线程传递进去,没关系,tagg2模块完全可以做到,tagg2可以通过buffer将参数传递给子线程,目前0.1.x版本仅支持字符串,以后会陆续支持2进制等。 虽然tagg2使用起来更加简单,不过还是有些地方需要注意的,比如上述代码 th_func 是独立执行在子线程中的,并不是node的实例,所以在子线程中是无法使用node的api,比如无法require(‘fs’)等,也无法访问主线程的变量和模块,为什么这样下文对tagg2线程原理会有所介绍。

4、tagg2模块同时还支持线程池,创建固定大小的线程时,让线程支持复用,不会过多的创建线程造成程序内存不足而崩溃。多余的任务会自动进行排队。

var thread = tagg.create(3);
thread.dirname = __dirname;
thread.pool(th_func,buf,thread_cb);//将任务放入线程池

thread.pool(th_func,buf,thread_cb);
thread.pool(th_func,buf,thread_cb);
thread.pool(th_func,buf,thread_cb);
thread.pool(th_func,buf,thread_cb);

console.log('thread.totalThreads: '+thread.totalThreads()) //线程池中的所有线程数量
console.log('thread.idleThreads: '+thread.idleThreads())  //线程池闲置线程的数量
console.log('thread.pendingJobs: '+thread.pendingJobs()) //线程池工作的线程数量

thread.destory(); //摧毁线程池

4、为了完善线程的局限性,tagg2还有一个重要的特性,当我们调用 tagg.create 函数创建子线程时,可以对线程做一个配置,比如我们这样创建一个子线程:

var thread = tagg.create(th_func,{buffer:buf,fastthread:false,dirname:__dirname},function(err, res){
    if(err) throw new(err);
    console.log(res);//thread.end
    thread.destroy();//摧毁线程
});

当我们设置option中 fastthread:false,就会创建一个慢线程来执行任务,所谓慢线程将是一个新的nodejs的实例,拥有完全的nodejs的api,比如require(‘fs’)等。这个慢线程实际上就是一个nodejs进程,tagg2模块式利用child.fork()来进行的。所以严格上来说是创建了一个nodejs的进程而不是线程。

5、在线程中tagg2设置了一些全局变量来帮助使用者更好的完成任务

console.log(param); //用来向输出流输出内容,主要用于线程的调试等
throw(errstr); //抛出一个异常,会触发回调函数中的error参数
thread对象,保存了一些有用的属性和方法。
thread.id 标识了一条线程的id,当使用thread pool时无用
thread.buffer 保存了主线程传递过来的buffer对象,由于目前只支持string,所以此buffer对象只有toString()方法。
thread.buffer.toString() 返回主线程传递过来的buffer字符串
thread.end(param) 表示线程任务执行完毕,将参数传递给回调函数,会赋值回调函数的第二个参数
require(filepath) 当在fastthread中,require 参数 filepath 请输入相对地址,表示相对于本目录的文件,比如在本目录中有a.js,所以在线程中就得写 require('a.js'),还支持../../和绝对路径 /user等样式。

其他一些详细的用法请参阅github上的readme。

6、为什么 tagg2 中的 fastthread 不能够访问全局的变量和使用node的api? 这有必要简单介绍下tagg2模块的工作原理和流程,tagg2模块是接受用户的任务,然后将任务进行包装,利用pthread创建一个线程,然后用node的libuv库,写好回调函数然后丢入到异步池中,同时tagg2模块维护了一个队列,在丢入libuv异步池的同时,也将任务的指针丢入了队列,并且告知队列有新任务。队列调用libuv的api,执行回调函数。 回调函数将利用v8引擎的isolate类,创建一个新的v8实例,同时v8手册上有说一个isolate实例同时只能够让一个线程进行访问,所以我们无法对当前主线程的isolate进行多线程同时读写,这也就是为什么我们无法访问当前主线程的变量的原因。

介绍就先写到这里吧,tagg2模块还在实验中,请不要用于对外的生产环境,以后我会丰富tagg2模块的功能。如果在安装或者使用中有任何疑问或者错误,请联系我,qq:53822985。

另外cnodejs的图片上传功能是不是坏了

博客原文:http://snoopyxdy.blog.163.com/blog/static/6011744020134186614267/

14 回复

回复在看~~~~~~~~~~~~~~~~~~~~

感谢撸主的辛勤研究和介绍。支持一下!

其实我觉得,由于v8引擎自身的特点(或者说缺陷),决定了nodejs直接支持多线程是比较困难的,即使用各种办法实现,最后免不了还是回到多线程加锁、互斥的老路子上了。。。这样会不会得不偿失呢? 。。。充分利用nodejs的多进程机制也许更有前途。不知道我的想法对不对,请指正。

同意你的观点,多进程模型确实是目前nodejs应付复杂cpu密集型场景比较好的解决方案。不过由于线程创建切换和摧毁的开销要小于进程,所以一些简单的cpu密集型任务利用线程模型也能够轻松应付。下个版本要把多进程模型加入进程池功能了。谢谢捧场啊

老吴出品,必属精品!

@snoopy 感谢楼主的分享,我感觉node的一个宗旨就是:一个进程里面只要一个线程,其实无论怎么,单线程模式cpu利用率肯定比多线程高,比多线程模式稳定。就像这种情景:一大批人去井边喝水,多线程模式是当一个人喝一口之后就继续去排队,单线程模式就是让这个人喝饱,然后下一个来喝,如果从总体来看肯定是后者先完成这一批人的所有需求,因为这样可以避免一些不必要的事情,比如来回更换喝水的人,甚至避免了一些争吵,只是这显的有点不公平而已,但是对先喝水的来说就有无比的优越感了。还有就是除去i/o操作的话,实际的应用中真正的cpu密集型除了科学计算类的就很少有其它的类了吧,所以说node的单线程模式是疯狂的,大胆的。以上是个人认知。

顶老吴!!!

存在即合理这句哲学名言也可以反过来理解,不存在也是合理的。nodejs的线程池类模块几乎没有,如果不是群众的眼睛集体瞎了,就是线程池在nodejs没用武之地。当然我对楼主吃螃蟹的行为深感佩服,除此之外,呃。或许象前面几位留言的,搞搞进程池会是更好的选择。

数据说话~佩服snoopy 的行动力。

@showen 感觉个有个的好处

创建线程,不如做个线程池用户去用。虽然线程池未必给node.js 性能加分。至少可以证明,楼主强悍,爱折腾。哈哈。

线程确实使用场景不是很广泛,进程使用场景广泛一些,tagg2模块也加入了进程的支持的,做了下封装,统一了api,设置fastthread为false就是使用进程模式了

线程池tagg2模块里有的,tagg2模块是基于外国朋友的tagg模块改造的,我不强悍,只是把那些代码做了跨平台支持和添加了部分功能而已,那个人才是牛人啊。

@showen 你的比喻很形象,确实在现实场景中,多线程的node是比较少的。还是多进程运用的比较多,但是多一种选择总不会错。因为V8已经把整个node模型都固定死了,所以node的多线程不可能存在多个人抢水喝然后有人掉下去的情况 ,这样是好事坏呢?

回到顶部