Web并发模型粗浅探讨
Download as PPTX, PDF18 likes2,306 views
本文探讨了web并发模型的基本概念，包括并发、并行和吞吐量等。讨论了多进程和多线程的优缺点，尤其在处理IO密集型和CPU密集型请求时的表现。最后，介绍了事件驱动的IO模型及其在高度并发场景下的优势与挑战。
2. [threads-in-ruby-enough-already](http://yehudakatz.com/2010/08/14/threads-in-rubyenough-already/)
3. [about-concurrency-and-the-gil](http://merbist.com/2011/10/03/about-concurrency-and-thegil/)
4. [the-ruby-global-interpreter-lock](http://ablogaboutcode.com/2012/02/06/the-ruby-globalinterpreter-lock/)
node.js Call/CC
1. [callcc-and-node-js](http://blog.kghost.info/index.php/2011/10/callcc-and-node-js/)
Non blocking ruby web framework: Goliath
1. [goliath-non-blocking-web-framework](http://www.igvita.com/2011/03/08/goliath-nonblocking-ruby-19-web-server/)
Golang
1. [Go语言并发编程之美](http://qing.weibo.com/2294942122/88ca09aa33002ele.html)](https://image.slidesharecdn.com/webv3-131209210443-phpapp02/85/Web-60-320.jpg)
Web并发模型粗浅探讨
- 2. 基本概念 • 并发concurrency • 并行parallelism • 吞吐量throughput
- 5. 吞吐量 • 单位时间内服务器总的请求处理量 – – – – 以 request/second 来衡量，如1200rps 每个请求的处理时间latency 服务器处理请求的并发workers 其他因素如GC也会影响吞吐量 – – – – 平均每个请求的latency – 200ms 总共40个workers 理论吞吐量上限 1000/200*40 = 200rps 理论每日处理动态请求上限1700万，目前实际每日 处理动态请求270-330万，预估实际处理上限600万 • 举例：CSDN new bbs
- 6. IO类型 • 磁盘文件操作，例如读硬盘文件 • 操作系统调用，例如shell命令 • 网络操作 – 访问数据库 MySQL, MongoDB, ... – 访问其他Web服务，发起网络连接 – 访问缓存服务器 Memcached, Redis
- 8. IO密集型并发 • 并发真能提高吞吐量吗？ – 假设每个请求执行100ms，顺序执行10个请求共需要1s – 单核服务器并发处理10个请求，假设平均分配时间片 10ms，请求1到请求10将在900ms到1000ms间执行完 毕。吞吐量没有任何提高。并发越多，所有请求都变 得非常缓慢。(考虑到任务的场景切换开销，吞吐量还 会下降，需要超过1s才能执行完毕)。 • 大多数Web型应用都是IO密集型 – 执行请求100ms当中，可能有80ms花在IO上，只有 20ms消耗CPU时钟周期，最好情况下，请求1到请求10 将在190ms到280ms间执行完毕，吞吐量极大提高。 • IO密集型应用，大部分CPU花在等待IO上了，所以 并发可以有效提高系统的吞吐量
- 9. 顺序执行10个请求，每个请求100ms，总共1s执行完毕 R1 R2 ...... R10 并发执行10个请求，每个请求分配10ms的时间片，仍然1s执行完毕 吞吐量没有提高，每个请求处理时间变长
- 11. 并发和并行 • 纯CPU密集型的应用 – 在单核上并发执行多个请求，不能提高吞吐量 • 由于任务来回场景切换的开销，吞吐量反而会下降 – 只有多核并行运算，才能有效提高吞吐量 • IO密集型的应用 – 由于请求过程中，很多时间都是外部IO操作， CPU在wait状态，所以并发执行可以有效提高系 统吞吐量
- 12. Web并发模型 • • • • • multi-process multi-thread multi-process + multi-thread(GIL) event I/O coroutine
- 13. multi-process • 常见多进程Web服务端编程模型 – PHP – Python – Ruby
- 14. 多进程的管理 • 多进程并发 – 每个进程可以并发处理1个请求，并发能力等于 进程数量 – 由操作系统负责进程调度，程序无法控制 – 可以通过操作系统命令影响进程调度优先nice • 多进程调度 – 例如在一台4核服务器上，运行10个PHP进程。 由操作系统负责给某个PHP进程分配某个CPU内 核的时间片，实现10个并发处理
- 15. 多进程优点 • 并发模型非常简单，由操作系统调度运行稳定强壮 • 非常容易管理 – 很容易通过操作系统方便的监控，例如每个进程CPU，内存 变化状况，甚至可以观测到进程处理什么Web请求 – 很容易通过操作系统管理进程，例如可以通过给进程发送 signal，实现各种管理: unicorn • 隔离性非常好 – 一个进程崩溃不会影响其他进程 – 某进程出现问题的时候，只要杀掉它重启即可，不影响整体 服务的可用性 – 很容易实现在线热部署和无缝升级 • 代码兼容性极好，不必考虑线程安全问题 • 多进程可以有效利用多核CPU，实现并行处理
- 16. 多进程的监控手段 • 监控进程CPU top –p pid – 简单处理甚至可以查看进程处理的URL请求 • 监控进程的IO iotop –p pid • 监控进程的物理内存使用 ps, /proc
- 17. 多进程缺点 • 内存消耗大户 – 每个独立进程都需要加载完整的应用环境，内存消 耗超大。(COW模式可以缓解这个问题) – 例如每个Rails进程物理内存占用为150MB，20个 workers，则需要3GB物理内存。 • CPU消耗偏高 – 多进程并发，需要CPU内核在多个进程间频繁切 换，而进程的场景切换(context switch)是非常昂贵 的，需要大量的内存换页操作。 • 很低的I/O并发处理能力
- 18. 多进程的低IO并发问题 • 多进程的并发能力非常有限 – 每个进程只能并发处理1个请求 – 单台服务器启动的进程数有限，并发处理能力无法有 效提高 • Rails进程消耗内存很大，单台服务器一般启动30个Rails实例 • PHP FastCGI进程非常轻量级，但单台服务器一般启动64个 • 只适合处理短请求，不适合处理长请求 – 每个请求都能在很短时间内执行完毕，因而不会造成 进程被长期阻塞 – 一旦某个操作特别是IO操作阻塞，就会造成进程阻塞， 当大面积IO操作阻塞发生，服务器就无法响应了 – 对于无法预知的外部IO操作，应用代码必须设置 timeout参数，以防进程阻塞
- 19. 缓解多进程低IO并发问题 • 用nginx做前端Web Server – 适当增大proxy buffer size，避免多进程 request/response buffer IO开销 – 使用X-sendfile，避免多进程读取大文件IO开销 • 凡IO操作都要设置timeout – 避免无法预知的IO挂起造成进程阻塞 • 编写智能防火墙代码 – 防止务质爬虫和其他恶意的DOS攻击行为 • 长请求和短请求分离开，不要放在一起
- 20. 多进程spawn • 静态spawn – 适合大型应用，稳定处理请求 – FastCGI(PHP/Ruby) / WSGI(Python) – Unicorn(Ruby) • 动态spawn – 适合较小型应用，请求伸缩变化大，节省资源 – Apache module(PHP) – Passenger(Ruby/Python)
- 21. PHP的轻量级进程 • 轻量级进程 – 无虚拟机，无GC，简单解析器，内存管理简单 – 每请求的内存管理模型：每个请求都需要初始 化整个框架，请求执行完毕释放所有内存 – 每个进程初始化一般10MB，远远小于 Python/Ruby
- 22. PHP的优点 • 每个进程占用内存少，可以多启动一些进 程数量，并发处理能力高于Python/Ruby • 基本没有内存泄露的烦恼 – 即使应用代码有内存泄露问题，每个请求执行 完毕，所有内存对象全部释放，基本不会造成 严重后果
- 23. PHP的缺点 • 每请求的内存管理模型造成PHP性能低下 – 每个请求都需要初始化整个应用代码，造成 bootstrap速度很缓慢 – 重型PHP框架性能不可避免的低下：例如Drupal性 能尤其差，必须依赖多种缓存机制缓解性能问题 – PHP社区多采用轻量级框架缓解性能问题 • 由于每请求都彻底释放内存，无法实现进程内跨请求 共享资源，必须使用IPC(进程间通讯方式) – 通用数据库连接池 – 内存字典表 – 其他昂贵的需要耗时建立的共享资源
- 24. PHP的大型应用 • PHP在大型应用的场景 – 由于PHP的内存模型限制，很多大型应用在较 早期就会不可避免的遇到PHP的瓶颈 – PHP的瓶颈无法解决，必须调整架构，因此在 早期就会引入中间应用层(C++, Java)，让PHP退 化为View层模板语言 – 案例：taobao，facebook，yahoo
- 25. multi-thread • 常见多线程模型(1:1) – Java VM / .net CLR – 1 native thread : 1 process thread – 在一个重量级进程当中启动多个线程并发处理 请求 • 多线程并发 – 每个线程可以并发处理1个请求，并发能力取决 于线程数量 – 线程的调度由VM负责，可以通过编程控制
- 26. 多线程优点 • 多线程并发内存消耗比较少 – 每个线程需要一个thread stack保存线程场景，thread stack一 般只需要十几到几十KB内存，不像多进程，每个进程需要加 载完整的应用环境，需要分配十几到上百MB内存。 – 线程可以共享资源，特别是可以共享整个应用环境，不必像 多进程每个进程要加载应用环境。 • 多线程并发CPU消耗比较小 – 线程的场景切换开销小于进程的场景切换 • 很容易创建和高效利用共享资源 – 数据库线程池 – 字典表，进程内缓存...... • IO并发能力很高 – Java VM可以轻松维护几百个并发线程的线程切换开销，远 高于多进程单服务器上几十个并发的处理能力 • 可有效利用多核CPU，实现并行运算
- 27. 多线程的缺点 • VM的内存管理要求超高 – 对内存管理要求非常高，应用代码稍不注意，就会产生 OOM(out of memory)，需要应用代码长期和内存泄露做斗争 – GC的策略会影响多线程并发能力和系统吞吐量，需要对GC 策略和调优有很好的经验 – 在大内存服务器上的物理内存利用率问题 • VM内存堆不宜过大，一般2GB为宜。过大的内存堆会造成GC效率 下降。在物理内存很多的服务器上为了有效利用更多内存，不得 不跑多个Java VM，增加了复杂度。 • 对共享资源的操作 – 对共享资源的操作要非常小心，特别是修改共享资源需要加 锁操作，很容易引发死锁问题 • 应用代码和第三方库都必须是线程安全的 – 使用了非线程安全的库会造成各种潜在难以排查的问题 • 单进程多线程模型不方便通过操作系统管理 – 一旦出现线程死锁或者线程阻塞很容易导致整个VM进程挂 起失去响应，隔离性很差
- 28. multi-thread with GIL • Ruby MRI / Python – Global Interpreter Lock：有限制的并发 – 执行纯Ruby code的时候@mutex.lock，只有一 个线程并发，其他线程等待，无法实现并发 – IO操作或者操作系统调用，释放锁，多线程IO 并发 – 由于加锁，无法利用多核，只能使用1个CPU内 核，因而无法实现多核并行运算
- 29. Why multi-thread(GIL) • 提供简化的并发策略 – 对CPU密集型运算，并发不能提高吞吐量：加锁，禁止 并发 – 对IO密集型运算，并发可以有效提高吞吐量：解锁，允 许多线程并发 • 性能 – 对CPU密集型运算，多线程并发由于线程场景切换带来 的开销，吞吐量要差于单进程顺序执行 • 兹容性 – 加锁可以保证代码和库的兼容性 • GC和内存管理 – Ruby和Python的GC内存管理无法和Java VM相提并论， 严重依赖多线程会带来非常严重的内存管理问题
- 30. MRI multi-thread IO Concurrency request1 code DB read request2 lock code request3 lock lock DB write code DB read code DB write code DB read code code rainbows! write buffer code DB write write buffer code write buffer
- 31. multi-process + multi-thread(GIL) • why multi-thread(GIL) + multi-process – 由于GIL，多线程只能跑在1个CPU内核上，无法有效利 用多核CPU，跑多个进程可以有效利用多核 • 进程数 = 服务器CPU内核数 – 一个进程不宜跑过多线程 • Ruby进程建议开64个线程 • 线程过多的时候，线程场景切换的开销会很高 • pros and cons – 内存消耗低于单纯的多进程并发 • 1个多线程的进程内存占用大概是1个单线程的进程内存的1.5-2 倍 – 非常有效的提高了IO并发处理能力 – IO库和操作系统调用库必须保证线程安全
- 32. Rainbows! configuration Rainbows! do name = 'website' use :ThreadPool worker_processes 4 worker_connections 64 listen "unix:/var/run/#{name}.sock” pid "/var/run/#{name}.pid" stderr_path "/var/log/#{name}.log" stdout_path "/var/log/#{name}.log" end
- 33. event IO • 常见event IO编程模型 – Nginx / Lighttpd – Ruby EventMachine / Python Twisted – node.js • event IO原理 – 单进程单线程 – 内部维护一个事件队列 – 每个请求切成多个事件 • 每个IO调用切成一个事件 • 编程调用process.next_Tick()方法切分事件 – 单进程顺序从事件队列当中取出每个事件执行下去
- 35. event IO的优点 • 惊人的IO并发处理能力 – nginx单机可以处理50K以上的HTTP并发连接 – node.js单机可以处理几千上万个HTTP并发连接 • 极少的内存消耗 – 单一进程单一线程，无场景切换无需保存场景 • CPU消耗偏低 – 无进程或者线程场景切换的开销
- 36. event IO的缺点 • 必须使用异步编程 – 异步编程是一种原始的编程方式 – 代码量和复杂度都会有很大的增加，提高了编程的难度，以 及开发和维护成本 – 复杂的业务逻辑(例如工作流业务)会造成代码迅速膨胀，极 难维护 – 异步事件流使得异常处理和调试有很大困难 • CPU密集型的运算会阻塞住整个进程 – 需要通过编程，将密集型的任务拆分为多个事件 • 所有IO操作必须使用异步库 – 一旦不小心使用同步IO操作，会造成整个进程阻塞，库的兼 容性必须非常小心 • 只能跑在1个CPU内核上，无法有效利用多核并行运算 – 运行多个进程来利用多核CPU
- 37. 读写文件的代码片段 常见同步代码
- 39. node.js的异步编程 • IO操作都需要异步回调，稍微复杂的代码有 十几层嵌套，可阅读性，代码维护性很差 • 缓解异步回调嵌套的努力 – eventproxy – async.js – wind.js – 把嵌套层次平铺展开，并未从根本上消除问题 • 用coroutine解决异步编程问题
- 40. coroutine • 原生支持coroutine的编程语言 – Go goroutine – Erlang process – Lua coroutine – Scala(Java VM) actor – Ruby Fiber • 库或者第三方实现 – Stackless Python – node-fibers
- 41. coroutine原理 • 在单个线程上运行多个纤程，每个纤程维护1 个context • 纤程非常轻量级，单个线程可以轻易维护几万 个纤程 • 纤程调度依赖于应用程序框架 • 纤程切换 – 必须自己编程来实现 – 一般应用层代码不需要编程，框架层实现纤程调度 • 纤程本质上是基于event IO之上的高级封装， 但消除了event IO原始的异步编程复杂度
- 44. coroutine的优点 • 支持极高的IO并发，比event IO略低 • 纤程的创建和切换的系统开销非常小，CPU 和内存消耗都很小 • 编程方式和常见的同步编程基本一致，是 event IO的高级封装形式
- 45. coroutine的缺点 • 纤程运行在单线程上，无法有效利用多核 实现并行运算 – 通过启动多个进程或者多个线程来利用多核 CPU • CPU密集型的运算会阻塞住整个进程 – 通过编程，将密集型的任务拆分为多步 • 所有IO操作必须使用异步库 – 一旦不小心使用同步IO操作，会造成整个进程 阻塞，库的兼容性必须非常小心
- 48. Web并发模型适用场景 CPU密集型 多进程 IO密集型 多线程 event IO coroutine • 应用场景CPU密集运算多，应使用多进程和多线程 • CPU密集：大量字符串运算，正则表达式匹配，大量内存对象创建和操作等 • 应用场景IO密集并发，应使用event IO和coroutine • IO密集：大量IO操作(发起HTTP连接，数据库访问)，维持长连接等
- 49. Web并发应用场景 • website • web api service • real-time / long-poll
- 50. website • 场景特点 – 业务逻辑比较复杂 – 功能点多，页面处理逻辑多，代码量比较大 – IO并发要求不高，一般几十并发workers足够 • 常用编程语言 – Java / .net – PHP – Python / Ruby
- 51. web service • 场景特点 – 业务逻辑比较简单，功能点较少 – 无页面逻辑，输出json/xml数据 – IO并发要求比较高，往往要求几百上千并发 • 常用编程语言 – Java / .net – node.js – Go – Python / Ruby (multithread or Fiber)
- 52. real-time • 场景特点 – 业务逻辑很简单，功能单一 – 无页面逻辑，服务器维持长连接，持续push数 据json/xml到客户端 – IO并发要求极高，单机往往维持几千上万长连 接 • 常用编程语言 – node.js – Go
- 53. Web应用场景对比列表 Website Web Service Read-time 业务逻辑和功能 复杂，功能多 简单，功能少 单一，功能极少 输出数据 HTML json/xml json/xml IO并发要求 很低 高 极高 常用编程语言 PHP, Python, Ruby Java, .net Go, node.js 个人偏好 Ruby Ruby/Java node.js
- 55. Ruby • 支持多种Web并发模式 – Ruby社区当前主流并发模式是多进程模型 – 随着Rails4.0即将推出，默认设置多线程安全模式，社 区逐渐向多线程并发发展 – 在Web service场景也有优秀的基于Fiber的框架，可支 持极高的IO并发 • Goliath (em-synchrony) • sinatra-synchrony • MRI虚拟机性能很差 – MRI的代码结构不清晰，改进难度大 – core team团队比较小，进展比较缓慢 – GC效率差，和主流商业虚拟机Java VM，V8有巨大差 距，是Ruby应用迈向顶级规模的主要障碍，例如Twitter
- 57. Ruby应用场景 • website – 大型website适合用rails，提供了应有尽有的基础设施 – rails框架比较重，性能瓶颈往往在View层页面模板渲染 和Restful的routes上，对于小型website，可以使用轻量 级框架sinatra和padrino • web service – sinatra/grape (multi-thread + multi-process) – sinatra-synchrony(fiber) – Goliath(fiber) • real-time – Goliath(fiber)
- 58. node.js • 特点 – – – – – 纯event IO并发，极其适合超高IO并发场景 JavaScript V8引擎的性能非常好 适合IO密集型并发，不适合CPU密集并发 不适合开发业务逻辑过于复杂的应用 异步编程复杂度和调试难度偏高 • 场景 – 网页游戏服务器端 – 网页长连接服务器端 • 问题 – event IO异步编程是一种相当原始的编程方式，coroutine提 供了更高抽象层次的编程方式，但是node社区似乎并不热衷 于coroutine，仍然陶醉于异步事件回调编程(why?)
- 60. 参考资料 ruby multithread and GIL discussion 1. [multithreaded-rails-is-generallybetter](http://www.unlimitednovelty.com/2010/08/multithreaded-rails-is-generally-better.html) 2. [threads-in-ruby-enough-already](http://yehudakatz.com/2010/08/14/threads-in-rubyenough-already/) 3. [about-concurrency-and-the-gil](http://merbist.com/2011/10/03/about-concurrency-and-thegil/) 4. [the-ruby-global-interpreter-lock](http://ablogaboutcode.com/2012/02/06/the-ruby-globalinterpreter-lock/) node.js Call/CC 1. [callcc-and-node-js](http://blog.kghost.info/index.php/2011/10/callcc-and-node-js/) Non blocking ruby web framework: Goliath 1. [goliath-non-blocking-web-framework](http://www.igvita.com/2011/03/08/goliath-nonblocking-ruby-19-web-server/) Golang 1. [Go语言并发编程之美](http://qing.weibo.com/2294942122/88ca09aa33002ele.html)