服务器三大框架？

从系统架构来看，目前的商用服务器大体可以分为三类，即对称多处理器结构(SMP：SymmetricMulti-Processor)，非一致存储访问结构(NUMA：Non-UniformMemoryAccess)，以及海量并行处理结构(MPP：MassiveParallelProcessing)。

一、SMP(SymmetricMulti-Processor)

所谓对称多处理器结构，是指服务器中多个CPU对称工作，无主次或从属关系。各CPU共享相同的物理内存，每个CPU访问内存中的任何地址所需时间是相同的，因此SMP也被称为一致存储器访问结构(UMA：UniformMemoryAccess)。对SMP服务器进行扩展的方式包括增加内存、使用更快的CPU、增加CPU、扩充I/O(槽口数与总线数)以及添加更多的外部设备(通常是磁盘存储)。

SMP服务器的主要特征是共享，系统中所有资源(CPU、内存、I/O等)都是共享的。也正是由于这种特征，导致了SMP服务器的主要问题，那就是它的扩展能力非常有限。对于SMP服务器而言，每一个共享的环节都可能造成SMP服务器扩展时的瓶颈，而最受限制的则是内存。由于每个CPU必须通过相同的内存总线访问相同的内存资源，因此随着CPU数量的增加，内存访问冲突将迅速增加，最终会造成CPU资源的浪费，使CPU性能的有效性大大降低。实验证明，SMP服务器CPU利用率最好的情况是2至4个CPU。

二、NUMA(Non-UniformMemoryAccess)

由于SMP在扩展能力上的限制，人们开始探究如何进行有效地扩展从而构建大型系统的技术，NUMA就是这种努力下的结果之一。利用NUMA技术，可以把几十个CPU(甚至上百个CPU)组合在一个服务器内。

NUMA服务器的基本特征是具有多个CPU模块，每个CPU模块由多个CPU(如4个)组成，并且具有独立的本地内存、I/O槽口等。由于其节点之间可以通过互联模块(如称为CrossbarSwitch)进行连接和信息交互，因此每个CPU可以访问整个系统的内存(这是NUMA系统与MPP系统的重要差别)。显然，访问本地内存的速度将远远高于访问远地内存(系统内其它节点的内存)的速度，这也是非一致存储访问NUMA的由来。由于这个特点，为了更好地发挥系统性能，开发应用程序时需要尽量减少不同CPU模块之间的信息交互。利用NUMA技术，可以较好地解决原来SMP系统的扩展问题，在一个物理服务器内可以支持上百个CPU。比较典型的NUMA服务器的例子包括HP的Superdome、SUN15K、IBMp690等。

但NUMA技术同样有一定缺陷，由于访问远地内存的延时远远超过本地内存，因此当CPU数量增加时，系统性能无法线性增加。如HP公司发布Superdome服务器时，曾公布了它与HP其它UNIX服务器的相对性能值，结果发现，64路CPU的Superdome(NUMA结构)的相对性能值是20，而8路N4000(共享的SMP结构)的相对性能值是63。从这个结果可以看到，8倍数量的CPU换来的只是3倍性能的提升。

三、MPP(MassiveParallelProcessing)

和NUMA不同，MPP提供了另外一种进行系统扩展的方式，它由多个SMP服务器通过一定的节点互联网络进行连接，协同工作，完成相同的任务，从用户的角度来看是一个服务器系统。其基本特征是由多个SMP服务器(每个SMP服务器称节点)通过节点互联网络连接而成，每个节点只访问自己的本地资源(内存、存储等)，是一种完全无共享(ShareNothing)结构，因而扩展能力最好，理论上其扩展无限制，目前的技术可实现512个节点互联，数千个CPU。目前业界对节点互联网络暂无标准，如NCR的Bynet，IBM的SPSwitch，它们都采用了不同的内部实现机制。但节点互联网仅供MPP服务器内部使用，对用户而言是透明的。

在MPP系统中，每个SMP节点也可以运行自己的 *** 作系统、数据库等。但和NUMA不同的是，它不存在异地内存访问的问题。换言之，每个节点内的CPU不能访问另一个节点的内存。节点之间的信息交互是通过节点互联网络实现的，这个过程一般称为数据重分配(DataRedistribution)。

但是MPP服务器需要一种复杂的机制来调度和平衡各个节点的负载和并行处理过程。目前一些基于MPP技术的服务器往往通过系统级软件(如数据库)来屏蔽这种复杂性。举例来说，NCR的Teradata就是基于MPP技术的一个关系数据库软件，基于此数据库来开发应用时，不管后台服务器由多少个节点组成，开发人员所面对的都是同一个数据库系统，而不需要考虑如何调度其中某几个节点的负载。

通过IPC和RPC，程序能利用其它程序或计算机处理的进程。客户机/服务器模式计算把远程过程调用与其它技术（如消息传递）一道，作为系统间通信的一种机制。客户机执行自己的任务，但靠服务器提供后端文件服务。RPC为客户机提供向后端服务器申请服务的通信机制，如图R-4所示。如果你把客户机/服务器应用程序想作是一个分离的程序，服务器能运行数据访问部分，因为它离数据最近，客户机能运行数据表示和与用户交互的前端部分。这样，远程过程调用可看作是把分割的程序通过网络重组的部件。LPC有时也称耦合（Coupling）机制。
用这种方式分割程序，当用户要访问数据时就无需每次拷贝整个数据库或它的大部分程序到用户系统。其实，服务器只处理请求，甚至只执行一些数据计算，把得出的结果再发送给用户。因为当数据存放在一个地方时，数据库同步很容易实现，所以多个用户可同时访问相同的数据。
分布式计算环境是由一个通信系统——网络连接的计算机集群。很容易把这个网络看成一个计算平台，若是对等方式，其中任何一台计算机都能成为客户机或服务器。一些处理任务可被分成独立运行程序在不同的网络计算机上并行处理，而独立的程序被交给最适合这个任务的计算机处理。这种策略可利用计算机空闲资源，提高网络的效益。一个典型的企业网包括许多运行着不同 *** 作系统的异构计算机系统。
随着企业网的产生，开发商必须编制可在各种计算机和网络通信协议中都能运行的程序。现在人们正努力使得远程过程调用独立，这意味着开发商就不用考虑底层的网络和网络上数据传输所用的协议，下面介绍RPC在开放式软件基金（OSF）的分布式计算环境(DCC）中实现的相关方法。RPC工作于多种分布式计算环境。
SunSoft的开放网络计算（ONC）的远过程调用/外部数据表示（RPC/XDR）协议被广泛采用。在三百一十万个运行网络文件系统(NFS）的系统中，有二百八十万个使用ONCRPC库，并在分布式应用中作为客户机或服务器。ONCRPC被IBM的所有 *** 作系统所支持（除了OS/400）。UNⅨ系统实验室把RPC/XDR当作是UNⅨ System V Release 4的一个标准部分。Novell支持下一代ONC+传输自立远程过程调用（TI-RPC）技术．TI-RPC 使用运输层接口（TLI）实现传输自立。TLI提供了一种访问面向连接或非连接传输服务的通用方法（这在“STERAMS环境”中有所叙述）。
Open Software Foundation(OSF)RPC 开放软件基金会(OSF）的RPC
RPC工具提供了一种编程语言和编译器，它们使用可看作是本地过程的可运行于客户机和服务器上的模块开发分布式应用程序。运行时设施（run-timefacility）使得分布式应用程序能在多机种异构系统上运行，这样使得底层体系结构和运输协议对于应用程序是透明的。
程序员用接口定义语言（IDL）建立接口定义（interface definition）。IDL是程序员用来设计远程运行的过程的工具。IDL编译器把IDL接口定义转换成与客户机和服务器相连的占位程序（stub）。客户机上的占位程序可加入到服务器的过程，而服务器上的占位程序也可加入到客户机过程。位于客户机服务器的RPC运行时设施与占位程序合作，来提供RPC *** 作。
异构环境中使用RPC的一个问题在于，不同的机器有不同的数据表示，OSFRPC通过具有调用机器的基本数据表示的特征调用来解决这个问题。当收到调用时，若根据特征知道两台机器数据表示不同的话，接收器就进行数据转换。
RPC运行时设施提供把客户机请求传送给服务器和在网上发送和接收响应的功能。DCERPC运行时设施也和网络上其它DCE服务相互作用，这些DCE服务有命名、安全和定时服务。运行时设施有下列特征：
可在多种网络上运行。开发者无需为每个网络编写特定的应用程序。
提供客户机或服务器或网络上的故障恢复。它支持文件系统、数据库和其它传输可变长数据的服务。
提供独立于任何一个目录服务的基于名字定位服务器的方法。
提供安全工具的接口，以防RPC通信遭受破坏。安全服务保证机密信息的保密性和提供鉴别来保护通信完备性。
支持网上并发或并行处理的多线程调度，于是一个应用程序就能同时执行多个 *** 作
提供多供应商提供的系统环境的可移植性和相互 *** 作性。
有几种RPC模式。一个很流行的模式是开放软件基金会的分布式计算环境（DCE）。1991年11月，美国电气和电子工程师协会在它的ISO远程过程调用规范（ISO/IEC CD 11578 N6561， ISO/IEC）中定义了远程过程调用。
远程过程调用（RPC）跨越了开放系统互连（OSI）网络通信模型中的传输层和应用层。远程过程调用使得开发应用程序更容易。
客户端/服务器通信的替代方法包括信息队列和IBM的高级程序间通信（APPC）。

首先介绍了Hadoop平台下作业的分布式运行机制，然后对Hadoop平台自带的4种任务调度器做分析和比较，最后在分析JobTracker类文件的基础上指出了创建自定义任务调度器所需完成的工作。首先Hadoop集群式基于单服务器的，只有一个服务器节点负责调度整个集群的作业运行，主要的具体工作是切分大数据量的作业，指定哪些Worker节点做Map工作、哪些Worker节点做Reduce工作、与Worker节点通信并接受其心跳信号、作为用户的访问入口等等。其次，集群中的每个Worker节点相当于一个器官，运行着主节点所指派的具体作业。这些节点会被分为两种类型，一种是接收分块之后的作业并做映射工作。另一种是负责把前面所做的映射工作按照约定的规则做一个统计。Task－Tracker通过运行一个简单循环来定期地发送心跳信号（heartbeat）给JobTracker．这个心跳信号会把TaskTracker是否还在存活告知JobTracker，TaskTracker通过信号指明自己是否已经准备好运行新的任务．一旦TaskTracker已经准备好接受任务，JobTracker就会从作业优先级表中选定一个作业并分配下去．至于到底是执行Map任务还是Reduce任务，是由TaskTracker的任务槽所决定的．默认的任务调度器在处理Reduce任务之前，会优先填满空闲的Map任务槽．因此，如果TaskTracker满足存在至少一个空闲任务槽时，JobTracker会为它分配Map任务，否则为它选择一个Reduce任务．TaskTracker在运行任务的时候，第一步是从共享文件系统中把作业的JAR文件复制过来，从而实现任务文件的本地化．第二步是TaskTracker为任务新建一个本地文件夹并把作业文件解压在此目录中．第三步是由Task－Tracker新建一个TaskRunner实例来运行该任务．Hadoop平台默认的调度方案就是JobQueueTaskScheduler，这是一种按照任务到来的时间先后顺序而执行的调度策略．这种方式比较简单，JobTracker作为主控节点，仅仅是依照作业到来的先后顺序而选择将要执行的作业．当然，这有一定的缺陷，由于Hadoop平台是默认将作业运行在整个集群上的，那么如果一个耗时非常大的作业进入执行期，将会导致其余大量作业长时间得不到运行．这种长时间运行的优先级别并不高的作业带来了严重的作业阻塞，使得整个平台的运行效率处在较低的水平．Hadoop平台对这种FIFO（FirstINAndFirstOut）机制所给出的解决法是调用SetJobPriority（）方法，通过设置作业的权重级别来做平衡调度．FairScheduler是一种“公平”调度器，它的目标是让每个用户能够公平地共享Hadoop集群计算能力．当只有一个作业运行的时候，它会得到整个集群的资源．随着提交到作业表中作业的增多，Hadoop平台会把集群中空闲出来的时间槽公平分配给每个需要执行的作业．这样即便其中某些作业需要较长时间运行，平台仍然有能力让那些短作业在合理时间内完成［3］．FairScheduler支持资源抢占，当一个资源池在一定时段内没有得到公平共享时，它会终止该资源池所获得的过多的资源，同时把这些释放的资源让给那些资源不足的资源池．Hadoop平台中的CapacityScheduler是由Yahoo贡献的，在调度器上，设置了三种粒度的对象：queue，job，task．在该策略下，平台可以有多个作业队列，每个作业队列经提交后，都会获得一定数量的TaskTracker资源．具体调度流程如下．（1）选择queue，根据资源库的使用情况从小到大排序，直到找到一个合适的job．（2）选择job，在当前所选定的queue中，按照作业提交的时间先后以及作业的权重优先级别进行排序，选择合适的job．当然，在job选择时还需要考虑所选作业是否超出目前现有的资源上限，以及资源池中的内存是否够该job的task用等因素．（3）选择task，根据本地节点的资源使用情况来选择合适的task．虽然Hadoop平台自带了几种调度器，但是上述3种调度方案很难满足公司复杂的应用需求．因此作为平台的个性化使用者，往往需要开发自己的调度器．Hadoop的调度器是在JobTracker中加载和调用的，因此开发一个自定义的调度器就必须搞清楚JobTracker类文件的内部机制．作为Hadoop平台的核心组件，JobTracker监控着整个集群的作业运行情况并对资源进行管理调度．每个Task－Tracker每隔3s通过heartbeat向JobTracker汇报自己管理的机器的一些基本信息，包括内存使用量、内存的剩余量以及空闲的slot数目等等［5］．一旦JobTracker发现了空闲slot，便会调用调度器中的AssignTask方法为该TaskTracker分配task。

---