多进程单线程模型与单进程多线程模型之争

3年前 (2016-03-22) Jason Liu 运维 0评论 已收录 151℃
文/Tulayang(简书作者)
原文链接:http://www.jianshu.com/p/c61a7746d139
著作权归作者所有,转载请联系作者获得授权,并标注“简书作者”。

楔子

似乎有人不知道nodejs是支持多核的?v0.10 Cluster可以搭建nodejs多核服务。v0.12重写了Cluster,据说提升了非常大的性能。

服务器,事件

多进程单线程模型典型代表:nginx
单进程多线程模型典型代表:memcached

另外redis, mongodb也可以说是走的“多进程单线程模”模型(集群),只不过作为数据库服务器,需要进行写保护,只提供了读同步。

原因很简单,因为服务器的发展大部分都是归功于Linux Unix,而不是Windows。

Linux内核提供的epoll为开发服务器提供了很大的便利,libevent和libev都是对epoll的封装,nginx自己实现了对epoll的封装。

libevent和libev都是知名的Linux系统C事件驱动编程框架。

我没说错的话,nodejs是建立在libev基础上。

memcached也依赖libevent。

所以,nginx在Windows上不像Linux快是有很大原因的。

模型,模型,多进程单线程 单进程多线程

  • 多进程单线程

    master进程管理worker进程:

    • 接收来自外界的信号
    • 向各worker进程发送信号
    • 监控woker进程的运行状态
    • 当woker进程退出后(异常情况下),会自动重新启动新的woker进程

    友情提示:nodejs属于这一种好不好,不是只能单核

单进程多线程

单进程多线程
  • 单进程多线程

    主线程负责监听客户端的连接请求,workers线程负责处理已经建立好的连接的读写等事件

单进程多线程

单进程多线程

单进程多线程肯定比多进程单线程快一些

多进程单线程单进程多线程的目的都是想尽可能的利用CPU,减少CPU的空闲时间,特别是多核环境。

他们在实际运行中,所利用的CPU工作数应该都是相同的。也就是说,你有4核,在某个时刻要么是CPU同时在4个进程做任务(多进程单线程),要么是CPU同时在4个线程上做任务(单进程多线程)。

不过,单进程多线程肯定比多进程单线程快一些。

这是因为,多进程单线程的CPU切换,是从一个进程到另一个进程,而单进程多线程的CPU切换则只在一个进程内,每个进程|线程都有自己的上下文堆栈保存,进程间的切换消耗更大一些。

这就好比是,多进程单线程是在4个函数中切换,各自拥有自己的变量;单进程多线程在1个函数中的4个子函数切换,拥有相同的全局变量。

但是,没有你想象的“快几倍”。

副作用,副作用,单进程多线程肯定有其不利的一面

我一直提过副作用。

如果你仔细看多进程单线程的图,就应该明白,这种模型提供了一种保护机制。

当其中一个进程内部读取错误,master可以让ta重启。这使得你的服务器在表面上并没有感到“曾经崩溃”。

对于master,完全不涉及服务器的业务,使得ta能被安全隔离。

再来看单进程多线程

问题很明显,只有一个进程,一旦其中出现一个错误,整个进程都有可能挂掉。你当然可以为ta编写一个“守护程序”来重启,但是重启期间,你的服务器是真的“挂掉了”。

另外,编写单进程多线程这样的服务器,在代码上非常容易出错,而且难以控制代码的稳定性,有很多你难以琢磨的bug在等着你,因为有太多的锁,太多的全局变量需要处理,这也是函数式“纯函数”所反对的。

nodejs不能CPU密集处理?

你觉得ruby,python,php就能密集处理?

有人说:java, c#。

拜托,如果你真的想要密集处理,请使用C C++。(我个人只会用C)你见过哪个数据库服务器是java c#写的?

而现在,我觉得Rust lang是一个好的方向:

  • 面向操作系统编程
  • 从语言层面上提供并发
  • 自诩C++的替代者
  • 将会重写firefox
  • Mozilla开发
  • Javascript的作者Brendan Eich是编写者之一
  • 类似javascript的语法和编写体验

而且我已经开始憧憬未来使用nodejs + Rust开发服务器体验的场景。

相关推荐

嗨、骚年、快来消灭0回复。