多线程与并发服务器设计
常见并发服务器方案
1.iterative(循环式/迭代式)服务器
这种服务器有很多缺陷 :
单线程,不能充分利用多核cpu
因为是短链接,有可能上一次断开的连接就是本次的连接,这样效率明显下降
不能并发处理
2.concurrent(并发式)服务器
注:如果是多进程,记得关闭监听套接字,因为子进程会继承套接字。
如果是多线程,就不用关闭监听套接字了,因为线程没有继承打开的套接字。
3.prefork or threaded服务器(预先创建进程和线程)
这种服务器由于多个进程在accept等待中,当一个请求到达时,都会被触发,但是只有一个成功返回。这是一种“惊群”现象。
4.reactive(反应式)服务器(使用的是reactor模式)
不适合执行时间比较长的服务,所以为了让客户感觉是在“并发”处理而不是“循环”处理,每个请求必须在相对较短时间内执行
5.reactor+thread per request
每个请求过来,创建一个线程。这样就能利用多CPU
6.reactor+worker thread
7.reactor+thread pool(第5种方案的改进)
一个客户端来连接,并且发送请求包过来,在Reactor中(这是一个线程)读取请求包,并这个请求包丢到线程池中处理,线程池会取出工作线程对其进行处理。这是即使计算量较大,时间较长,也没有关系,因为是线程池中的线程进行处理的,不会影响到Reactor这个I/O线程,还可以接受其它客户端的连接,所以能够计算密集型任务。
处理完成之后,线程池中的线程并不负责数据的发送,要响应数据包,还必须丢到I/O线程中来发送或者异步地调用I/O线程的发送方法来发送
8.multiple reactors(能适应更大的突发I/O)
reactors in threads(one loop per thread)
每个线程都有一个reactor,也就是事件循环
reactors in process
每个进程都有一个reactor
每一个reactor都是一个线程(或进程),将监听套接字加入mainReactor,每当客户端连接过来时,监听套接字产生可读事件,acceptor就返回已连接套接字,把返回的已连接套接字加入subReactor里,用它来处理客户端的连接,如果再来一个客户端,就按顺序的分配到下一个subReactor,当第三个客户端连接的时候又回到了第一个subReactor。这种方式称为round robin(轮叫),它能够保证subReactors中处理的事件是均匀的,而不至于每一个事件循环处理的连接过多。每一个连接只能在一个subReactor中处理,而不能在一个subReactor中read,在另一个subReactor中send
这种方式能够适应突发的I/O请求
9.multiple reactors+thread pool(one loop per thread+threadpool)(突发I/O与密集计算)
多个subReactor共享一个线程池,其实就相当于两个线程池(I/O线程池+计算线程池Threadpoll)
10.proactor服务器(proactor模式,基于异步I/O)
前面介绍的服务器都是基于同步I/O,异步I/O使得I/O操作和其他操作能够重叠,I/O操作的时候,计算操作也在同时执行理论上proactor比reactor效率要高一些
异步I/O能够让I/O操作与计算重叠。充分利用DMA特性
Linux异步IO
glibc aio(aio_*),有bug
kernel native aio(io_*),也不完美。目前仅支持 O_DIRECT 方式来对磁盘读写,跳过系统缓存。要自已实现缓存,难度不小。
boost asio实现的proactor,实际上不是真正意义上的异步I/O,底层是用epoll来实现的,模拟异步I/O的。
常见并发服务器方案比较
二、一些常见问题
1、Linux能同时启动多少个线程?
对于 32-bit Linux,一个进程的地址空间是 4G,其中用户态能访问 3G 左右,而一个线程的默认栈 (stack) 大小是 8M,心算可知,一个进程大约最多能同时启动 350 个线程左右。2、多线程能提高并发度吗?
如果指的是“并发连接数”,不能。假如单纯采用 thread per connection 的模型,那么并发连接数大约350,这远远低于基于事件的单线程程序所能轻松达到的并发连接数(几千上万,甚至几万)。所谓“基于事件”,指的是用 IO multiplexing event loop 的编程模型,又称 Reactor 模式。
3、多线程能提高吞吐量吗?
对于计算密集型服务,不能。如果要在一个8核的机器上压缩100个1G的文本文件,每个core的处理能力为200MB/s,那么“每次起8个进程,一个进程压缩一个文件”与“只启动一个进程(8个线程并发压缩一个文件)”,这两种方式总耗时相当,但是第二种方式能较快的拿到第一个压缩完的文件。
4、多线程能提高响应时间吗?
可以。参考问题35、多线程程序日志库要求
线程安全,即多个线程可以并发写日志,两个线程的日志消息不会出现交织。用一个全局的mutex保护IO
每个线程单独写一个日志文件
前者造成全部线程抢占一个锁(串行写入)
后者有可能让业务线程阻塞在写磁盘操作上。(磁盘IO时间比较长)
解决办法:用一个logging线程负责收集日志消息,并写入日志文件,其他业务线程只管往这个“日志线程”发送日志消息(如通过BlockingQueue提供接口),这称为“异步日志”,也是一个经典的生产者消费者模型。
6、线程池大小的选择
如果池中执行任务时,密集计算所占时间比重为P(0<P<=1),而系统一共有C个CPU,为了让C个CPU跑满而不过载,线程池大小的经验公式T=C/P,即T*P=C(让CPU刚好跑满 )假设C=8,P=1.0,线程池的任务完全密集计算,只要8个活动线程就能让CPU饱和
假设C=8,P=0.5,线程池的任务有一半是计算,一半是IO,那么T=16,也就是16个“50%繁忙的线程”能让8个CPU忙个不停。
7、线程分类
I/O线程(这里特指网络I/O)计算线程
第三方库所用线程,如logging,又比如database