并发编程模型汇总理解

5种io模型：
1、阻塞
2、非阻塞
3、io多路复用
4、信号驱动
5、异步io

tcpserver编程模型：
1、accept+read/write + 阻塞io
单进程单线程，短连接，一次处理一个客户，无并发性
适用于短连接服务，如datetime
2、accept+fork +阻塞io
多进程，长连接，并发性底，开销大，每个连接一个进程
适用于计算响应的工作量大于fork的开销
3、accept+thread+阻塞io
多线程，长连接，并发性中，开销中，每个连接一个线程
比2的开销小，但是该方案的伸缩性受线程数的限制，导致并发数到顶就200个左右
5、单线程+reactor+非阻塞io
io复用，长连接，并发性高，开销底 ，单线程reactor
适用于io密集的应用，不适合cpu密集的应用
6、reactor+thread-per-task+非阻塞io
thread-per-request，并发性底，reactor用一个线程监听连接及所有请求，每个请求会开辟一个线程去处理（开辟线程的开销可以用线程池去避免），但当同一个连接的多个请求被多个线程去处理的时候，就会出现结果的次序不确定的问题。
7、reactor+worker thread+非阻塞io
worker-thread-per-connection，并发性底
为了解决6中的次序不确定问题，可以为每一个连接创建一个计算线程，每个连接上的请求都固定发给这个计算线程，但受到线程总数的限制，该方案或许还不如3.
该方案与6的主要区别还在于处于某个连接上的一长串的突发请求，6的突发请求能力更好，7则更加公平。
8、reactor-thread poll +非阻塞io
主线程io，工作线程计算
为了弥补6中创建线程的缺陷，使用线程池
全部io工作都给一个reactor线程去处理，而计算任务交给线程池，非常适合io压力不大，计算任务彼此独立的情况。
9、reactors in threads +非阻塞io--------muduo的默认模型
多线程，长连接，并发性高，开销底，one loop one thread
main reactor负责accept，每次有连接到挂在sub resctor，选择sub reactor的算法使用（负载均衡中的轮询调度算法，把每个连接按依次轮流挂到sub reactor中处理）
这样多个连接会放到多个线程中处理，充分利用了cpu资源，也能防止io压力过大导致一个reactor处理不过来的问题，另外因为同一个连接多个请求都是在一个线程中处理，所以也不会有处理结果次序不一致的问题。
10、reactors in processes
nginx的内置方案，适合连接之间无交互，因为进程之间独立，所以可以热升级
11、reactors+thread pool
最灵活的io和cpu配置
8和9的结合，适合应对突发io和突发计算并存的场合。