web并发模型
并发:cpu划分时间片,轮流执行每个请求任务,时间片到期后,换到下一个、
并行:在多核服务器上,每个cpu内核执行一个任务,是真正的并行
IO密集型的应用,由于请求过程中很多时间都是外部IO操作,CPU在wait状态,所以并发执行可以有效提高系统吞吐量
纯CPU密集型的应用:在单核上并发执行多个请求,不能提高系统吞吐量(由于任务来回场景切换的开销,吞吐量反而会下降);只有多核并行运算,才能有效提高吞吐量
web并发模型有:multi-process multi-thread multi-process+multi-thread event I/O coroutine
多进程优点
- 并发模型非常简单,由操作系统调度运行稳定强壮
- 非常容易管理(通过操作系统进行监控与系统管理)
- 隔离性好
- 代码兼容性极好,不必考虑线程安全问题
- 多进程可以有效利用多核cpu,实现并行处理
多进程缺点
- 内存消耗大户(每个独立进程都需要加载完整的应用环境,内存消耗超大)
- cpu消耗偏高(多进程并发,需要CPU内核在多个进程间频繁切换,而进行的场景切换是非常昂贵的,需要大量的内存换页操作)
- 很低的I/O并发处理能力
- 每个进程的并发能力非常有限,单台服务器启动的进程数有限,并发能力无法有效提高
- 只适合处理短请求,不适合处理长请求(每个请求都能在很短时间内执行完毕,因而不会造成进程长期阻塞,一但某个进程特别是IO操作阻塞,会造成进程阻塞,当大面积IO操作阻塞发生,服务器就无法响应了)
多线程优点
- 多线程并发内存消耗比较小
- 多线程并发CPU消耗比较小
- 很容易创建和高效利用共享资源
- IO并发能力很高
- 可高效利用多核CPU,实现并行运算
多线程的缺点
- VM的内存管理要求超高
- 对内存管理要求非常高,应用代码稍不注意,就会产生OOM
- GC的策略会影响线程并发能力和系统吞吐量,需要对GC策略和调优有很好的经验
- 在大内存服务器上的物理利用率问题(VM内存堆不宜过大,一般2GB为宜,过大的内存堆会造成GC效率下降,在物理内存很大的服务器上为了有效利用更多内存,需要跑多个VM,增加了复杂度)
- 对共享资源的操作
- 应用代码和第三方库都必须是线程安全的
- 单进程多线程模型不方便通过操作系统管理(一旦出现线程死锁或者线程阻塞很容易导致整个VM进程挂起失去响应,隔离性很差)
event IO原理
- 单进程单线程
- 内部维护一个事件队列
- 每个请求切成多个事件
- 单进程顺序从事件队列中取出每个事件执行下去
event IO的优点
- 惊人的IO并发处理能力
- 极少的内存消耗(单一进程单一线程,无场景切换无需保存场景)
- CPU消耗偏低(无进程或者线程场景切换的开销)
event IO的缺点
- 必须使用异步编程
- CPU密集型的运算会阻塞整个进程
- 所有IO操作必须使用异步库
- 只能跑在1个CPU内核上,无法有效利用多核并行运算(运行多个进程利用多核CPU)
coroutine原理
- 在单个线程上运行多个纤程,每个纤程维护一个context
- 纤程非常轻量级,单个线程可以轻易维护几万个纤程
- 纤程的调度主要依赖应用程序框架
- 纤程的切换(必须自己编程实现,一般框架实现了纤程调度)
- 纤程本质上是基于event IO之上的高级封装,但消除了event IO原始的异步编程复杂度
coroutine的优点
- 支持极高的IO并发,和event IO基本相当
- 纤程的创建和切换的系统开销非常小,CPU和内存消耗都很小
coroutine的缺点
- 纤程运行在单线程上,无法有效利用多核实现并行运算(通过启动多个进程或者多个线程来利用多核CPU)
- CPU密集型的运算会阻塞整个进程
- 所有IO操作必须使用异步库
原文: 《《Web并发模型粗浅探讨》》
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。