多进程多线程权衡

多进程多线程权衡  http://yueyue7373.blog.163.com/blog/static/13954915220113289416189/

2011-04-28 09:04:16|  分类： 杂七杂八|举报|字号 订阅

根据实际情况来判断，哪个更加合适就是哪个好。 我们按照多个不同的维度，来看看多线程和多进程的对比（注：因为是感性的比较，因此都是相对的，不是说一个好得不得了，另外一个差的无法忍受）。

对比维度多进程多线程总结数据共享、同步数据共享复杂，需要用IPC；数据是分开的，同步简单因为共享进程数据，数据共享简单，但也是因为这个原因导致同步复杂各有优势内存、CPU 占用内存多，切换复杂，CPU利用率低占用内存少，切换简单，CPU利用率高线程占优创建销毁、切换创建销毁、切换复杂，速度慢创建销毁、切换简单，速度很快线程占优编程、调试编程简单，调试简单编程复杂，调试复杂进程占优可靠性进程间不会互相影响一个线程挂掉将导致整个进程挂掉进程占优分布式适应于多核、多机分布式；如果一台机器不够，扩展到多台机器比较简单适应于多核分布式进程占优 看起来比较简单，优势对比上是“线程 3.5 v 2.5 进程”，我们只管选线程就是了？ 呵呵，有这么简单我就不用在这里浪费口舌了，还是那句话，没有绝对的好与坏，只有哪个更加合适的问题。我们来看实际应用中究竟如何判断更加合适。

1）需要频繁创建销毁的优先用线程原因请看上面的对比。这种原则最常见的应用就是Web服务器了，来一个连接建立一个线程，断了就销毁线程，要是用进程，创建和销毁的代价是很难承受的

2）需要进行大量计算的优先使用线程所谓大量计算，当然就是要耗费很多CPU，切换频繁了，这种情况下线程是最合适的。这种原则最常见的是图像处理、算法处理。

3）强相关的处理用线程，弱相关的处理用进程什么叫强相关、弱相关？理论上很难定义，给个简单的例子就明白了。一般的Server需要完成如下任务：消息收发、消息处理。“消息收发”和“消息处理”就是弱相关的任务，而“消息处理”里面可能又分为“消息解码”、“业务处理”，这两个任务相对来说相关性就要强多了。因此“消息收发”和“消息处理”可以分进程设计，“消息解码”、“业务处理”可以分线程设计。当然这种划分方式不是一成不变的，也可以根据实际情况进行调整。

 4）可能要扩展到多机分布的用进程，多核分布的用线程原因请看上面对比。

 5）都满足需求的情况下，用你最熟悉、最拿手的方式至于“数据共享、同步”、“编程、调试”、“可靠性”这几个维度的所谓的“复杂、简单”应该怎么取舍，我只能说：没有明确的选择方法。但我可以告诉你一个选择原则：如果多进程和多线程都能够满足要求，那么选择你最熟悉、最拿手的那个。 需要提醒的是：虽然我给了这么多的选择原则，但实际应用中基本上都是“进程+线程”的结合方式，千万不要真的陷入一种非此即彼
的误区。

多线程与多进程

1、多线程的优点
  a 数据共享方便（不需要进程间的通信）
  b 占用系统内存小
  c 提高cpu利用率
  
2. 多进程的优点
 a. 一个进程core掉不会影响到其他进程
 b. 编程简单
 
3. 多线程的缺点
 a  调试困难
 b  防止读写竞争，锁机制
 c 编程复杂
 
  
4. 多进程的缺点
  a 耗资源

 多线程一般都不会采用共享内存的方式，而采用的是优秀的内存池技术来实现IPC，比如ngnix的内存管理，可伸缩，动态大小。而多进程除了采用socket通信方式，共享内存是被大量使用的。共享内存的最大缺点就是不可伸缩，而最大优点就是稳定，即使程序down掉，重启，数据依然可以重新用。当然前提是不把共享内存删除。共享内存相比socket也有很大的缺点,就是不能跨机器。所以任何一个服务器都需要分析该选用哪种方式更加好，然后选择用哪种模式。对于业务逻辑比较复杂的，肯定不可能就在一台服务器上。服务器之间选择socket是必然，RPC方式并不堪大用。

平行扩展一般有两种类型，一个是服务器之间连接成网，多个协同处理请求，一种是一个中心型，由中心分配任务，单点完成。采用哪种主要看业务逻辑，以及划分的服务器功能。多数情况下两种都是可以选择的。对于单一任务很重的业务尽量不要让它与其他服务器之间采用非socket方式，以应对其单独部署在一机器上的可能。无论哪种，我个人认为多线程+socket方式来实现比较合适，而不是选择多进程，多进程意味着就是共享内存的方式来实现IPC，但是这种情况可能都需要拷贝内存，或者说拿到数据处理完。而消费者-生产者模型，锁是必须的，而这个内存拷贝或者就地处理就加大了锁的颗粒度。线程就不必要，拿到指针就OK了。减少了锁，就加大了并发。很多多进程中往往使用占用内存多，速度最慢的信号量，建议大家改成posix互斥，和条件变量来实现，速度快很多。