我只是一个搬运工,只为感兴趣的话题. . .
Linux 开发,使用多线程还是用 IO 复用 select/epoll?
每分钟有2K用户访问,服务器端处理请求选择用多线程(每个用户一个线程),还是用I/O复用?
5 条评论
默认排序
按时间排序
26 个回答
我是来指出排名第一的回答的BUG的:
"
多线程的模式有很多的,leader-follow还有Half-Sync/Half-Async.
现在这个年代,以我见过的代码,真没见过几个是一个连接上来就一个线程的了.
"
- 多线程模型适用于处理短连接,且连接的打开关闭非常频繁的情形,但不适合处理长连接。多线程模型默认情况下,(在Linux)每个线程会开8M的栈空间,再TCP长连接的情况下,2000/分钟的请求,几乎可以假定有上万甚至十几万的并发连接,假定有10000个连接,开这么多个线程需要10000*8M=80G的内存空间!即使调整每个线程的栈空间,也很难满足更多的需求。甚至攻击者可以利用这一点发动DDoS,只要一个连接连上服务器什么也不做,就能吃掉服务器几M的内存,这不同于多进程模型,线程间内存无法共享,因为所有线程处在同一个地址空间中。内存是多线程模型的软肋。
- "
多线程的模式有很多的,leader-follow还有Half-Sync/Half-Async.
现在这个年代,以我见过的代码,真没见过几个是一个连接上来就一个线程的了.
每
分钟有2K?差点看成每秒钟。
这2K个用户是长连接呢还是短连接呢?如果是短连接,或者连接后通信不频繁的话,线程(池)就可以,如果一直是2k的并发,那还是异步(感谢 @程ocean提醒,补充完整:用epoll配合非阻塞IO实现,epoll本身并非异步)靠谱点。再高就要异步加并行(多线程/多进程)了。
这2K个用户是长连接呢还是短连接呢?如果是短连接,或者连接后通信不频繁的话,线程(池)就可以,如果一直是2k的并发,那还是异步(感谢 @程ocean提醒,补充完整:用epoll配合非阻塞IO实现,epoll本身并非异步)靠谱点。再高就要异步加并行(多线程/多进程)了。
我也同意event loop + thread pool的做法,
epoll + 多线程 + 多进程部署 效率真的不错。
先用select接口(poll/epoll,kq,iocp)接受请求,这样可以保证并发,在这个环节他只管收,不处理业务,把FD放到一个buffer(一个q里面),然后业务处理模型对接线程池。可以使复杂业务处理上的负担被分担。select+线程池,这样兼顾了并发(牺牲了一点性能),又保证了因为逻辑代码的简洁性。如果选择完全异步的方式,你就要在业务处理里面使用完全的异步API,至少很多数据库驱动,缓存驱动等等你需要用的到技术都没有提供异步API,很多业务要保障流程的正确是需要同步操作的,而且业务如果全部使用异步API,各种不明确回调和闭包导致内存暴栈的危险上升(我想各位应该被nodejs折磨过吧),对开发人员思考方式和技术实力都有较高的要求。一个部门里面有两个了解epoll就算技术非常NB的核心部门了吧,假若有能正确驾驭epoll,了解各种触发方式,状态机,特别是要能正确读写完整的信息,而没有造成大量的CLOSE_WAIT,是特别特别不易的。
我曾在tornado上面搭建过一个线程池。原型参见: nikoloss/iceworld · GitHub
虽然不算最完美的解决方案,但是也在工作中省去了很多烦恼。他的效率虽没有原生tornado高,但是非常适合多人合作(尽管如此效率还是要暴webpy几条街)。
epoll + 多线程 + 多进程部署 效率真的不错。
先用select接口(poll/epoll,kq,iocp)接受请求,这样可以保证并发,在这个环节他只管收,不处理业务,把FD放到一个buffer(一个q里面),然后业务处理模型对接线程池。可以使复杂业务处理上的负担被分担。select+线程池,这样兼顾了并发(牺牲了一点性能),又保证了因为逻辑代码的简洁性。如果选择完全异步的方式,你就要在业务处理里面使用完全的异步API,至少很多数据库驱动,缓存驱动等等你需要用的到技术都没有提供异步API,很多业务要保障流程的正确是需要同步操作的,而且业务如果全部使用异步API,各种不明确回调和闭包导致内存暴栈的危险上升(我想各位应该被nodejs折磨过吧),对开发人员思考方式和技术实力都有较高的要求。一个部门里面有两个了解epoll就算技术非常NB的核心部门了吧,假若有能正确驾驭epoll,了解各种触发方式,状态机,特别是要能正确读写完整的信息,而没有造成大量的CLOSE_WAIT,是特别特别不易的。
我曾在tornado上面搭建过一个线程池。原型参见: nikoloss/iceworld · GitHub
虽然不算最完美的解决方案,但是也在工作中省去了很多烦恼。他的效率虽没有原生tornado高,但是非常适合多人合作(尽管如此效率还是要暴webpy几条街)。