服务器架构设计1------概述

服务器常用架构包括四种： 

1. 多线程 
2. 多进程 
3. 基于 I/O 复用的事件循环架构 
4. SEDA 模式 

前两种架构适用于类 web 服务器。这样的服务器只需处理来自客户端的请求，且请求间几乎是相互独立的。后两种架构适用于构造复杂的服务器，比如 Cassandra 系统中的一个节点，再比如 Redis 服务器。 

多线程或多进程：多线程服务器对每个客户端来的请求生成一个新的线程来服务它。多进程服务器则生成一个新的进程。一个经常用的优化措施是使用线程池(或进程池)。对于web服务器，每个用户请求，可以在非常短的时间内处理完成，所以同一个时刻，线程数和进程数并不会太多。 

基于 I/O 复用的事件循环：就是利用操作系统的 I/O 复用函数，比如 select, epoll, 采用一个主线程来监听所有的事件(网络 I/O 事件、timer 事件等)，并在这个线程中调用相应的回调函数。 基于 I/O 复用的事件循环的好处之一是所有事件都在一个线程中处理，就不用考虑非常复杂的并发问题，大大简化了程序。 因为要在主线程中处理所有的事件，所以要求每个事件的处理时间必须要短。如果有些操作非常耗时，那么就要启动工作线程来处理耗时的操作，工作完成后通知主线程。一般通过管道来解决这个通信问题。(MooseFS 中的 chunkserver 就是这样做的) 

更详细的说明可以参照：http://blog.csdn.net/lmh12506/article/details/7753978

SEDA：这种模式就是把对一个请求的完成过程划分为多个 stage。每一个 stage 对应一个线程池。在前面的一个 stage 完成之后就把请求扔到下一个 stage。可以把它想成一个流水作业。 SEDA 这种架构使得每个 stage 可以单独的控制和调优，这是它的一个优点。 它的缺点在于跨 stage 的控制比较难。 比如如果前一个 stage 的处理时间非常短，后一个 stage 是一个磁盘 I/O stage, 处理时间很长，那么请求就会在后一个 stage 堆积起来；划分成多个 stage 多，全局的过载控制就比较难。 Cassandra 系统中就有这个问题。