unix网络编程--服务器模型选择

服务器编程模型

1.单核多线程和多核多线程

a) 单核多线程，在单个处理器上跑多个线程

i. 无阻塞时，单核多线程并没什么效用，反而会因为多次切换上下文降低速度。相当于一个人边切苹果，边切梨，频繁切换。

ii. 有IO阻塞时，充分利用。相当于一个人边切苹果，边烧水。

b) 多核多线程，在多个处理器上跑多个线程

i. 无阻塞时，很有效用。相当于专人变切苹果，专人边切梨（一人一个任务）

ii. 有IO阻塞时，有点浪费。相当于专人切苹果，专人等水烧开（烧水这个任务无需专人等着，等水烧开的线程被阻塞挂起）。

2.服务器编程模型

a) 每个进程/线程处理一个连接+阻塞式IO+线程池

i. 存在的问题【一个进程/线程处理一个连接的问题】：

1. 机器创建的进程线程数有限，这限制了连接数的上限。

2. 进程创建多了，数据拷贝频繁，影响性能

3. 进程上下文、线程上下文切换频繁，影响性能

b) IO复用+one loop one thread（事件驱动）+阻塞式IO+线程池

i. select+阻塞式IO

1. select轮询所有受监听描述符，太慢；描述字上限；

2. 阻塞式IO

a) 【惊群现象】：select和read是两个独立的原子操作。如果多个select监听一个socket，当socket可读时，所有的select都会被唤醒，那么真正读到的只有一个线程，其他的线程会被阻塞

b) select和read是两个独立的原子操作。select返回-->分配线程处理fd后--->发现数据分节有错，丢弃掉--->线程阻塞式IO发现缓冲区无数据可读--->线程阻塞（线程资源很宝贵。阻塞是没干活，但占资源）

c) 发送缓冲区1000，发送数据量2000，向发送缓冲区写了1000，缓冲区满，无法发送。本发送线程阻塞。如果是非阻塞的话，下次再次检测到可发送时，再发送，本线程不阻塞。

ii. epoll+阻塞式IO

1. 阻塞式IO的问题（见上）

2. 无轮询问题

c) epoll的ET模式+one loop one thread（事件驱动）+非阻塞式IO+线程池

i. Reactor模式

1. 在主线程上注册事件

2. epoll_wait等待事件

3. 事件到来，主线程为事件分配工作线程

4. 工作线程完成实际工作，返回主线程

ii. Proactor模式

1. 主线程上注册事件，注册信号处理函数

2. epoll_wait等待事件

3. 事件到来，主线程调用异步IO处理

4. 处理结束，工作线程回调信号处理函数

5. 返回主线程

iii. ET模式下必须使用非阻塞IO

1. ET是指从无到有才会通知该fd。数据读不完，下次也不会通知，所以read时一定要采用循环的方式一直读到read函数返回-1为止。

2. 如果epoll通知该fd可以写数据了。然后打算写100B数据，但是内核buf只有50B的可用空间，这时候，你的进程就被阻塞了。。。，如果是非阻塞，本次没写完，大可以下次再检测到可写时再写，而不是傻等内核读完数据，缓冲区有空了，再写。（线程进程都是很宝贵的资源，尽量保持少的线程、进程）

3.其他

1.32bitlinux能有多少线程？地址空间2^32，则内存大小4G，线程栈默认10M，大概400。

2.多线程提高并发数？不能提供并发连接数。用one thread per connect，32位系统也就400个连接，远远达不到并发连接数要求。所以要用reactor，这样的话连接支持数，限制就位于cpu资源了。

3.多线程能提高吞吐量吗？对于计算密集型来说，不能；IO密集型来说，能；见1.

 参考：http://www.kegel.com/c10k.html

http://blog.csdn.net/u011438608/article/details/44623661#t1