高性能服务器架构 第二篇

转自：http://www.doserv.com/article/2012/0831/5299117.shtml

上下文切换Context Switches

相对于数据拷贝影响的明显，非常多的人会忽视了上下文切换对性能的影响. 在我的经验里，比起数据拷贝，上下文切换是让高负载应用彻底完蛋的真正杀手. 系统更多的时间都花费在线程切换上，而不是花在真正做有用工作的线程上. 令人惊奇的是, (和数据拷贝相比)在同一个水平上，导致上下文切换原因总是更常见. 引起环境切换的第一个原因往往是活跃线程数比CPU个数多. 随着活跃线程数相对于CPU个数的增加，上下文切换的次数也在增加，如果你够幸运，这种增长是线性的，但更常见是指数增长. 这个简单的事实解释了为什么每个连接一个线程的多线程设计的可伸缩性更差. 对于一个可伸缩性的系统来说，限制活跃线程数少于或等于CPU个数是更有实际意义的方案. 曾经这种方案的一个变种是只使用一个活跃线程，虽然这种方案避免了环境争用，同时也避免了锁，但它不能有效利用多CPU在增加总吞吐量上的价值，因此除非程序无CPU限制(non-CPU-bound), (通常是网络I/O限制 network-I/O-bound), 应该继续使用更实际的方案.

一个有适量线程的程序首先要考虑的事情是规划出如何创建一个线程去管理多连接. 这通常意味着前置一个select/poll, 异步I/O，信号或者完成端口，而后台使用一个事件驱动的程序框架。关于哪种前置API是最好的有很多争论. Dan Kegel的C10K在这个领域是一篇不错的论文. 个人认为，select/poll和信号通常是一种丑陋的方案，因此我更倾向于使用AIO或者完成端口，但是实际上它并不会好太多. 也许除了select()，它们都还不错. 所以不要花太多精力去探索前置系统最外层内部到底发生了什么.

对于最简单的多线程事件驱动服务器的概念模型, 其内部有一个请求缓存队列，客户端请求被一个或者多个监听线程获取后放到队列里，然后一个或者多个工作线程从队列里面取出请求并处理. 从概念上来说，这是一个很好的模型，有很多用这种方式来实现他们的代码. 这会产生什么问题吗? 引起环境切换的第二个原因是把对请求的处理从一个线程转移到另一个线程. 有些人甚至把对请求的回应又切换回最初的线程去做，这真是雪上加霜，因为每一个请求至少引起了2次环境切换. 把一个请求从监听线程转换到成工作线程，又转换回监听线程的过程中，使用一种"平滑"的方法来避免环境切换是非常重要的. 此时，是否把连接请求分配到多个线程，或者让所有线程依次作为监听线程来服务每个连接请求，反而不重要了.

即使在将来, 也不可能有办法知道在服务器中同一时刻会有多少激活线程. 毕竟，每时每刻都可能有请求从任意连接发送过来，一些进行特殊任务的"后台"线程也会在任意时刻被唤醒. 那么如果你不知道当前有多少线程是激活的，又怎么能够限制激活线程的数量呢?根据我的经验，最简单同时也是最有效的方法之一是：用一个老式的带计数的信号量，每一个线程执行的时候就先持有信号量. 如果信号量已经到了最大值，那些处于监听模式的线程被唤醒的时候可能会有一次额外的环境切换, (监听线程被唤醒是因为有连接请求到来, 此时监听线程持有信号量时发现信号量已满,所以即刻休眠), 接着它就会被阻塞在这个信号量上，一旦所有监听模式的线程都这样阻塞住了，那么它们就不会再竞争资源了，直到其中一个线程释放信号量，这样环境切换对系统的影响就可以忽略不计. 更主要的是，这种方法使大部分时间处于休眠状态的线程避免在激活线程数中占用一个位置，这种方式比其它的替代方案更优雅.

一旦处理请求的过程被分成两个阶段(监听和工作)，那么更进一步，这些处理过程在将来被分成更多的阶段(更多的线程)就是很自然的事了. 最简单的情况是一个完整的请求先完成第一步,然后是第二步(比如回应). 然而实际会更复杂: 一个阶段可能产生出两个不同执行路径，也可能只是简单的生成一个应答(例如返回一个缓存的值). 由此每个阶段都需要知道下一步该如何做，根据阶段分发函数的返回值有三种可能的做法：

请求需要被传递到另外一个阶段(返回一个描述符或者指针)

请求已经完成(返回ok)

请求被阻塞(返回"请求阻塞")。这和前面的情况一样，阻塞到直到别的线程释放资源

应该注意到在这种模式下，对阶段的排队是在一个线程内完成的，而不是经由两个线程中完成. 这样避免不断把请求放在下一阶段的队列里，紧接着又从该队列取出这个请求来执行。这种经由很多活动队列和锁的阶段很没必要.

这种把一个复杂的任务分解成多个较小的互相协作的部分的方式，看起来很熟悉，这是因为这种做法确实很老了. 我的方法，源于CAR在1978年发明的"通信序列化进程" (Communicating Sequential Processes CSP)，它的基础可以上溯到1963时的Per Brinch Hansen and Matthew Conway--在我出生之前! 然而，当Hoare创造出CSP这个术语的时候，“进程”是从抽象的数学角度而言的，而且，这个CSP术语中的进程和操作系统中同名的那个进程并没有关系. 依我看来，这种在操作系统提供的单个线程之内，实现类似多线程一样协同并发工作的CSP的方法，在可扩展性方面让很多人头疼.

一个实际的例子是，Matt Welsh的SEDA，这个例子表明分段执行的(stage-execution) 思想朝着一个比较合理的方向发展. SEDA是一个很好的 "server Aarchitecture done right" 的例子，值得把它的特性评论一下：

1. SEDA的批处理倾向于强调一个阶段处理多个请求，而我的方式倾向于强调一个请求分成多个阶段处理.

2. 在我看来SEDA的一个重大缺陷是给每个阶段申请一个独立的在加载响应阶段中线程"后台"重分配的线程池. 结果，原因1和原因2引起的环境切换仍然很多.

3. 在纯技术的研究项目中，在Java中使用SEDA是有用的，然而在实际应用场合，我觉得这种方法很少被选择.