比如说，nginx的并发能力特别强，到底并发能力强指的是多线程还是多进程？
另外多进程和多线程的区别是什么？到底应该用多进程还是用多线程？
--
FROM 110.255.89.*

并发&并行是一个业务概念，多线程&多进程是实现方式，至于线程进程区别，你需要从基础学起了

【 在 ludongxing 的大作中提到: 】
: 比如说，nginx的并发能力特别强，到底并发能力强指的是多线程还是多进程？
: 另外多进程和多线程的区别是什么？到底应该用多进程还是用多线程？
--
FROM 111.198.29.*

多进程容错能力强一些（可用性），一个进程崩了，不会影响其他进程；如果只有多线程而没有多进程，只要有一个崩了，就全崩了。

Nginx作为网络服务，高可用性是必须的。

网络服务端的话，尽可能利用SO_REUSEPORT，针对同一个端口开多个socket，用多个线程/进程去执行accept()，提高accept()的速度。
--
修改:z16166 FROM 123.115.163.*
FROM 123.115.163.*

首先赞楼上的技术性，其次我也说两句呗。

比如说有1000个client连到你的server，就有1000个socket要处理(刨掉listen的不算)。在程序里recv或者read下，如果对面没有数据，是怎样的情况？

如果没数据recv就不返回，这叫阻塞方式。那么recv(skt_1)阻塞住了，skt_2有数据怎么办？单进程就没法处理了。如果没数据recv返回个特殊标志，这叫非阻塞，你可以轮着询问(轮询，不是gang rape:-))各个socket，这样CPU狂转，效率不高。

多进程方式可以每个进程干一个socket，如果socket很多，比如C10K, C100K，进程太多了，而且创建/销毁进程很耗资源。

线程比进程轻量，但是地址空间不隔离，方便是方便，但一个线程出错可能破坏另一个线程的数据，不好调试。

linux的epoll，你可以声明说我对n个socket的状况感兴趣，然后epoll_wait，如果没事，操作系统的内核可以去干别的事，你的程序阻塞。如果至少一个有事，它会返回，你可以知道哪些有事，进行相应处理。这样单进程单线程程序也能用。古早的Windows下可以用消息队列。

但是CPU多个核，一核忙着其它围观？或者别着我不懂的原因，多进程/线程可以再和epoll结合起来，比如56个核56个线/进程，每个处理若干个socket。56个民族56朵花，56个进程端口是一家，它们的能力汇成一句话，连吧连吧来连吧。

lighttpd应该也值得一看。
--
修改:billybear04 FROM 106.121.137.*
FROM 106.121.137.*

【 在 zli07 的大作中提到: 】
: nginx 的并发高，靠的是异步 io，也就是 io 不会等待，实际上它是单线程+多进程模式：首先有个 master process，解析配置文件，然后根据配置 fork 出 n 个 worker process, 当客户端连接过来的时候，会有某一个 worker process 处理这个连接的请求，同时由于异步 io 的机制，一个进程可以同时处理很多个（成千上万）用户的请求。
epoll这种是不是需要手动修改linux中对进程中文件描述符的限制
--
FROM 106.37.187.*