在传统的服务器编程模型中,我们会为每一个请求分配一个线程,请求结束后终止该线程,或者把线程放回线程池。 Java 的 Servlet 就属于这种模型的典型。对于 PHP, Ruby, Python 这些语言,要么对于多线程支持不好,要么在多线程下表现不好,通常我们会为每个请求分配一个进程,但整体模型都差不多。
通常我们的请求并不是一直在消耗CPU, 一个请求的大部分时间都花在等待磁盘,数据库,cache,其他服务返回上面,或者说等待一个事件发生(比如 web 版的 IM, 通常会建立一个 HTTP 请求,等待其他人给你发消息)。 所以对于一个8核的 CPU,支撑100个并发,CPU消耗并不大,负载也不会太高,甚至 1000 左右的并发请求数也不会有大问题。但在高并发下,首先是由于线程数/进程数过多消耗了太多的内存资源,同时大部分CPU都消耗在上下文切换上边,所以系统负载很高,服务器效率大幅度降低,服务响应变慢甚至不可用。
为了让服务器支持高并发,通常我们需要一个新的框架来处理这些请求,比如 Java 这边就有 comet和netty, python 有 tornado, ruby 有 eventmachine。还有很多直接基于 epoll 系统调用, 或者基于 libevent, libev, libcoro的应用。
在解决这个问题时,发展出了 reactor[1] 和 proactor[2] 两种设计模式, 关于 reactor 模式,可以参考一下 libevent, netty 的编程范例。关于 proactor 模式,可以参考一下 node.js, Java NIO.2[3] 的编程范例,在此不做解释。对于 libcoro, jscex[4],从实现层面上仍然可以认为是 proactor 模式,但避免了写大量的 callback 方法,所以更加易用。
go 语言用于解决高并发的技术被成为 goroutine[5], 与 erlang 的 process 类似,但仍然有如下的不同
- erlang 接收消息的主题是 erlang process, go 语言是 channel
- 一个 goroutine 可以引用多个 channel, 同样一个 channel 也可以被多个 goroutine 引用 (对于常规的生产者-消费者模型, goroutine 比 erlang 方便)
- channel 属于强类型,在编译期可以检查出更多的错误,如果一个 goroutine 希望接收多种类型的消息,一般可以引用多个channel
- channel 可以设置为堵塞型或者设定一个 buffer size, 并且可以用select测试 channel 是否已满, erlang 则无法测试(?)
[1] http://en.wikipedia.org/wiki/Reactor_pattern
[2] http://en.wikipedia.org/wiki/Proactor_pattern
[3] http://jcp.org/en/jsr/detail?id=203
[4] https://github.com/JeffreyZhao/jscex
[5] http://golang.org/doc/GoCourseDay3.pdf
有疑问加站长微信联系(非本文作者)