选用多线程还是IO多路复用必须要看场景的！
选择select还是epoll也是需要看场景的！
如果是短连接，服务器使用线程池(多线程)处理完毕，马上进行释放，保证活跃的线程所需要的内存和CPU效率是在服务器承受范围之内，那么多线程比IO多路复用效果要好，因为无论是select还是epoll都需要去额外的监听，监听到需要数据处理，才调用回调函数，分配处理线程去执行，这段时间有性能和资源的消耗，这种情况无疑是多线程模型更有优势！
如果是长连接，因为连接长时间不释放，服务端需要保持线程去维护连接，这时候所有空闲的连接都相当于一个阻塞的状态，而且多线程需要的内存资源比较多，高并发的情况服务器直接死机了！而使用IO多路复用，用来维持连接的线程只有一个(或几个)，不会有多余的内存开销，这时候IO多路复用的优势得以体现！
如果确定选择IO多路复用，又该选择select/epoll哪种模型呢？
首先来看下select和epoll的本质区别:都有一个监听线程去监听事件，但是select采取轮询的方式，不管有多少连接过来都要一一轮询，有通信数据就处理，而epoll是把所有socket对应的文件挂在红黑树上，而活跃的放在一张双向链表中，只处理这个链表中的连接！如果有新的连接需要处理，从红黑树上塞到链表中进行处理！
比如1000个连接中，只有十个有数据传输，select需要从1000个中遍历出这10个，然后进行处理，而epoll模型只需要从链表中取出来即可使用！
由此可见，如果是少量连接，同时大量连接都是活跃的情况下，select可能稍微略胜一筹，但如果是大量连接，且活跃数占比少的情况，epoll堪称完美模型，在可预见的范围中，epoll增加连接，性能几乎不衰减！
写一个类似epoll的处理模型，会对以后的高并发，多线程处理大有助益，更多的技术分享，敬请关注。。。
评论0
加载中...
多线程和用select/epoll是没有关联的，在select和epoll模型里也可以使用多线程进行io处理，select/epoll 的出现是为了解决一个线程对应一个请求时阻塞线程的问题，基于epoll的事件模型，解决了线程的阻塞问题即一个线程可以为多个请求服务
评论0
加载中...
多线程既每个线程负责处理一个用户连接，当等待数据（如读写数据）时线程被阻塞挂起，数据就绪后线程恢复执行。优点是开发相对简单，缺点是处理并发能力差一些。
IO复用是事件驱动的方式，既等待数据时线程保存处理当前连接的上下文，然后线程切换去处理其它数据就绪的请求。优点是处理并发的能力强，缺点是开发相对复杂一些。一些开源的库，如libevent，可以让事件驱动的开发更容易。
Web服务器Apache和Nginx分别对应上面的两种模式。Nginx就是以高性能高并发著称。
在问题描述中每分钟2K的请求，如果能够在一秒内就能完成一个请求的处理，并发在每秒30到40之间，那多线程模式就可以了，40个线程就能达到要求；如果每个请求要一分钟才能处理完，那并发连接数就是2K,创建2k个线程可能就不大现实。可以考虑基于事件驱动的方式。
具体选择那种的关键还是看，同时保持多大的并发连接。
评论0
加载中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
