大数据时代的大规模事务处理监测系统

（一）大规模事务处理系统概述

大规模事务处理系统平台是用于开发并行海量数据库系统的分布式大规模事务处理中间件，它提供对海量数据的并行加载和存储、海量数据的并行查询分析功能。它由多个局部自治的数据库管理系统和一组中间件组成，中间件用于对这些数据库进行管理，并为用户的管理和操作提供统一视图。大规模事务处理系统作为一个海量信息系统开发和管理平台，针对海量信息系统特点，解决了如下技术难点：

（1）提供海量信息的分布存储。通过数据划分技术，按照划分规则，将海量信息划分成相互独立的集合，分别存储到多个局部数据库中，使整个系统的存储能力随数据库节点个数线性增加。

（2）提供海量信息的并行加载。数据库并行化技术包括操作间并行和操作内流水并行，通过数据划分方式，将数据均衡分布到多个局部数据库上，从而实现多个数据库并行加载，使得整个系统加载能力得到线性提高；另外，由于数据划分等操作，可能增加数据加载的开销，因此，在该系统中采用流水并行方式，将整个数据加载过程分割成多个独立步骤，使得步骤间按流水并行方式完成加载任务。

（3）海量数据加载需要海量的接入能力。该系统采用多个加载流水线方式，实现并行加载，并将流水线均衡分配给用户，既保证了海量用户接入能力，也保证了海量数据接入能力。

（4）提供对海量信息的并行查询与分析。对海量信息的查询主要是并行数据库技术，以往的并行数据库并行查询算法都包含三个阶段，即数据重分布、并行子查询执行、结果合并，由于数据重分布开销太大，并行算法在商用数据库中采用的很有限，一般用于数据挖掘等数据后处理应用，对于海量信息的在线查询分析，不断有大量数据加载，因而不可能采用上述技术。该系统在加载时即进行数据分布，因此查询时只执行后两个阶段。为了提高系统的适应性，采用了数据复制技术，对于某些小表，通过将其复制到相关局部节点上，可以减少数据交换的数量，从而提高性能。

（5）为用户提供统一的对多个异构自治数据库的管理和使用接口。该系统为了提供统一接口，采用SQL92标准作为数据库的查询语言，用户不感知多数据库存在，由大规模事务处理系统对多个数据库进行管理和维护，对所有请求并行化，并调度局部数据库完成请求。并行域和OTS是维护多数据库一致性的主要技术。

（6）提供高可靠性服务。大规模事务处理系统及其管理的数据库系统无单点失效问题，即在单点失效的情况下可以正常运行。为了解决单点失效问题，该系统采用了高可用体系结构实现磁盘和操作系统容错，采用冗余服务技术、负载平衡和容错服务技术解决服务对象容错，负载平衡和容错服务采用热备份技术解决本身的单点失效。

（7）系统在线维护，包括系统在线升级，在单点失效情况下可以在线故障恢复。通过负载平衡和容错服务技术所实现的系统在线升级，实际上是用新的服务对象代替旧服务对象的过程，在线故障恢复是通过动态保持冗余服务方式实现，这两种技术通过系统管理工具的动态配置和在线运行维护功能实现，即通过更改配置可以实现在线升级，通过检测冗余服务对象，判断其是否满足配置要求，如果因为对象失效等原因不能满足配置要求，则管理工具自动根据配置要求，启动冗余服务对象，并进行初始化，建立和其他对象的连接关系。

（8）系统规模和处理能力可以在线调整，并动态负载均衡。该技术特点是通过冗余服务方式、负载平衡和容错服务技术实现的。

（二）大规模事务处理系统结构

大规模事务处理系统结构如图3-1所示，它的主要服务是由一组加载服务对象和一组查询服务对象构成，加载服务对象负责海量信息的并行加载，加载服务对象在进行加载时通过数据划分，调度多个数据库并行加载，提高了大规模事务处理系统的加载性能，另外，加载服务对象采用多层次设计，分别包括数据划分服务器、批量表加载服务器、表加载服务器三个层次，它们采用松散藕合方式组合在一起，在这三个层次之间，通过流水并行进一步提高系统的加载性能。

并行查询服务负责对海量信息数据进行高效的并行查询和分析，它同样由多个层次的服务对象组成，包括并行查询服务器、数据查询服务器以及结果服务对象等，并行查询服务器负责查询请求的并行优化和分解、并行查询规划生成和并行查询调度执行，数据查询服务器负责查询在局部数据库执行，结果服务器负责查询结构的缓冲、结果合并，并与客户交互，将结果返回用户。

图3-1 大规模事务处理系统结构

数据库访问对象负责解决异构数据库接口的不一致性，整个系统中，除了数据库访问对象必须和底层数据库相关外，其他服务对象都和数据库无关。

另外两个重要的对象是两个CORBA（公共对象请求代理体系结构）服务，OTS是一个分布式对象事务服务，完成两阶段提交协议，用于维护全局数据库的一致性；AFLS为负载平衡和容错服务，通过冗余服务技术，提高系统的容错能力，着重解决服务对象负载分配可能出现的不均衡问题，并能实现动态负载均衡。

（三）监测系统的设计

1.监测系统设计的基本思想

监测系统是大规模事务系统管理工具的一个重要组成部分，是系统管理的基础，本节将讨论系统设计的目的、原则和基本思想。

（1）监测的目的。

①解决开发和测试阶段中的错误。在部署一个应用之前，可能存在很多错误，而在分布环境下发现一个错误是非常困难的，如果在调试阶段通过一种通用的、并且不影响系统的监测工具来获取不同对象之间的通信消息，将有利于问题的解决和工作效率的提高。

②在系统运行阶段通过监测了解系统运行情况，帮助管理员发现错误并进行故障定位。

③通过获取到的信息可以进一步对系统的性能进行分析，发现系统性能瓶颈所在，在此基础上改进系统的性能。

④系统监测作为管理工具的一个重要组成部分，为系统的配置、部署和自动维护提供科学依据。

（2）监测机制的实现原则。

①监测的透明性：监测对应用（对象）来说是透明的，他们应该感知不到监测机制的存在；监测可以动态地开关。

②监测内容的可伸缩性：用户能根据需要对系统进行监测，即监测内容是可以动态配置。

③监测策略的自主性和可扩展性：自主性是指监测系统通过分析历史信息可以实时调整自己的策略，可扩展性主要是指用户可以根据需要通过策略编辑器进行策略编辑，例如用户可以调整系统报警的条件以及指定发现故障后采用何种处理方式等。

④监测系统规模的可扩展性：监测系统应支持服务对象、服务器节点和数据库的在线规模扩展。

（3）监测系统设计的基本思想。

大规模事务处理监测系统是一个集信息采集与传输、数据处理和决策支持于一体的综合系统。该监测系统具有以下基本功能：系统服务对象状态监测与分析；应用服务器节点状态监测与分析；数据库状态监测；检测系统各种可能的错误，并给出报警信息；帮助管理员进行错误定位和解决故障；发现系统出现的性能瓶颈并提出优化建议。

基于以上监测目的和实现原则，监测系统设计的基本思想如下：

①在每个服务对象实例上附加一个服务代理SA（Server Agent），它负责收集各个服务对象实例的管理信息。

②在系统每个应用服务器主机上都驻留一个主机管理者HM（Host Manager），它向上为监测中心提供服务器主机的管理接口，向下管理驻留在本服务器主机上的各个实例对象。HM负责定时收集本服务器主机的状态信息和运行在本服务器主机上的对象实例的状态信息，如果发现失效的对象实例，负责向监测中心报警。

③系统设置一个管理全局的监测中心，它负责收集和处理系统全局的监测信息、各个对象实例的状态信息、各个主机HM的状态信息、数据库状态信息。这些信息需要及时更新，以保证系统的正常运行。它为系统管理员提供图形用户界面GUI，能够动态地监视系统的运行状况，及时显示服务器的状态信息和系统中各个对象实例的运行情况，以便系统管理员发现问题并及时做出调整。它能依据系统策略要求进行信息处理，并将处理完的信息送往错误分析及故障定位器、负载性能分析器等。

2.监测系统体系结构

（1）系统的构成。

监测系统的结构如图3-2所示（数据库监测部分未画出），各部分主要功能：

图3-2 大规模事务处理监测系统结构

服务代理SA（Server Agent）：依附在服务对象实例上的探测器对象，对服务对象实例及ORB本身进行监测并获取被监测实体的通信消息以及相关信息。

主机管理者HM（Host Manager）：HM通过SA收集驻留在本服务器主机上所有服务对象实例信息，收集主机本身的运行状态信息，并经过数据预处理后将结果信息传递给监测中心；接受监测中心发出的指令并下达到本主机的每个代理服务SA，使SA按照用户的要求工作。

监测中心：根据收集的信息分析系统是否按照系统配置的要求正常运行；依据系统策略要求进行信息处理，并将处理完的信息送往错误分析及故障定位器、负载性能分析器等，最后通过GUI将系统运行情况动态显示给用户；按照用户指令通过HM设置SA的工作方式；各种信息的存储、监测日志的记录、系统参数设置以及提供系统配置的编辑等等。

GUI：接受信息管理中心提供的信息并将系统状态以各种表现形式呈现给观察者，提供通用历史趋势图、实时数据表、动态棒形图、动态X一Y曲线图、功能拓扑图、对象状态拓扑图、报警信号等，用户还可以根据需要定制各种特色的可视化画面。

故障分析及故障定位：通过获取的信息进行故障分析，并帮助管理员进行故障定位。

负载分析：计算并分析系统负载平衡状态，分析是否出现性能瓶颈，并提出解决的建议。

策略管理：策略是一套指导和确定如何监测、分析和处理信息的业务规则。策略管理的目标是确保业务规则总是得到遵循。

数据存储：提供系统日志和系统配置的存储和读取机制。

OM（Object Manager）服务对象类管理者，在监测系统中每一类服务对象都有一个管理者OM，它为服务对象类提供管理接口，集中管理每个服务对象类的各个实例。

（2）系统主要特点。

该体系结构具有如下特点：

①监测透明性：监测工具对于大规模事务处理系统来说是透明的，监测工具的动态开启和关闭不会影响原有系统的正常运行。

②重大故障检测的实时性：监测工具对系统重大故障采用“事件驱动”，能保证及时发现系统故障。

③预报警：监测工具具有一定的智能性，能不断更新自己的诊断知识库，采用了模糊匹配推理机制，具有一定的预报警功能。

④高安全性：建立了一套独立的加密系统，用于对用户口令进行加密，用户口令经过加密后存储在数据库中，操作人员必须拥有用户口令才能对监测系统进行管理操作，从而避免了无关人员或恶意攻击者对系统的破坏。

⑤高可靠性：使用主备式失效检测器，保证监测结果的可靠性。

⑥良好的人机接口：监测工具的客户端使用可视化开发工具进行开发，具有良好图形化人机交互界面。监测软件的人机界面结合了菜单、工具栏、命令按钮、图标等多种操作方式，操作方便，界面布局合理，同时在人机接口程序中还采取了大量的容错和防误操作设计，最大限度地减少误操作的发生。

⑦对象规模在线扩展：当系统对象规模需要扩展时，只需在配置文件中添加对象实例的相关信息即可，监测工具自动将其纳入监测范围，一旦扩展的对象实例开始运行，对应的HM就会自动收集添加的对象实例的状态信息。

⑧服务器规模在线扩展：当系统增加服务器主机时，只需在配置文件中添加该主机的相关信息，同时在增加的主机上部署HM并使其处于运行状态，监测工具即可对其进行监测。

⑨数据库规模在线扩展：数据库规模扩展时，只需在配置文件中添加数据库信息即可。

（3）系统信息收集机制。

基本的信息收集方式通常有两种：推模式（push）和拉模式（pull），在推模式下，被监控对象实施主动行为，主动向监控对象发送信息。在拉模式下监控对象实施主动行为，主动向被监控对象发布指令收集信息。两种监控模式各有优劣，监控对象和被监控对象之间具体采用哪种交互类型取决于应用程序的需求。一般来说，如果应用运行的通信带宽是紧缺资源，更看重通信的效率，则可以选择push模式；而如果应用只需在特定的时间点检查被监控对象的状态，则pull模式更加合适。

由监测系统的体系结构可以知道，信息收集主要由监测中心、主机管理者HM和服务代理SA三级构成，图3-3展示了三者之间信息交换的基本模式。

图3-3 系统信息收集模式

主机管理者HM和服务代理SA之间采用的是拉模式，即HM定期向SA收集对象实例的相关信息。HM和监测中心之间则采用了推和拉相结合的模式，监测中心定期向HM收集各服务对象实例及服务器主机的相关信息，但为了保证系统对错误和故障处理的实时性，一旦HM判断所获得的信息出现异常则主动以推的方式向监测中心报告，即采用“事件驱动”方式。(www.xing528.com)

3.监测系统体系结构设计的关键问题

（1）服务代理SA。SA是附加在被监测对象实例上的监测器，与被监测对象实例同属一个进程，对监测器的设计通常有两种方案：

①在被监测的服务对象中增加管理接口，即监测器作为被监测的服务对象的一段代码，完全嵌入至服务对象中。

②重新定义一套IDL接口，并且把该套接口的实现同服务对象的实现相分离，即监测器作为一个单独的对象存在。

两种方法各有利弊，对于第一种方法，监测器实际上成了服务对象的一部分，在服务对象的接口中添加管理接口，并把新接口的实现和服务对象的实现相结合。这种方法简化了代码的实现和接口的访问，因为只要找到服务对象实例就可以访问服务对象实例的所有接口，但这么做却破坏了服务对象实例的程序代码，代码的改写和维护工作比较繁琐，同时还降低了代码的重用性。在第二种方法中，我们定义了一套新的IDL接口，使得SA形成了一个新对象，并且通过改变POA的策略使得服务对象和新对象都注册到ORB中。这种方法虽然使得系统中增加了大量的对象，但监测器作为单独的对象存在，可以最大限度实现监测系统与被监测对象的分离，同时所添加的新接口不仅不破坏服务对象程序代码，还使代码具有通用性，任何服务对象，只通过简单修改就可以使接口生效。

（2）服务对象运行状态的设置与获取。服务对象实例的运行状态可以定义为如下四种：

①正常状态（Normal）：服务对象实例可以正常地接受和发送请求。

②半活跃状态（Request Decline）：服务对象实例不响应请求，而是把接收到的请求重新发送给其他服务对象实例。如果服务对象有缓存，并且缓存中存有没有执行的任务，那么允许该服务对象实例执行这些任务。

③停止状态（Stop）：服务对象实例既不能响应请求也不能够发送请求，并且服务对象的缓存为空。

④挂起状态（Suspend）：服务对象实例不存在，也就是说，服务对象实例在后台进程中不存在。

绝大部分的服务对象都支持两种状态，即正常状态和挂起状态。但是，要支持半活跃状态或者停止状态，服务对象自身必须提供Commit接口。

Commit接口描述：提交操作，返回值是布尔型。Commit操作使服务对象尽快完成缓存中的任务，任务完成后返回True，否则返回False。如果服务对象有缓存，那么这个服务对象必须提供Commit接口。

值得注意的是，对于没有缓存的服务对象而言，半活跃状态和停止状态是一样的，所以此类对象不用提供该接口。

服务代理SA设置了两个接口用来设置和获取对象的运行状态：

①SetObjState（ObjState State）接口：负责改变服务对象实例运行状态。

②GetObjState接口：负责获取服务对象实例当前的运行状态。

截获器根据SetObjState（ObjState State）中变量的值来改变对象实例当前的运行状态。当服务对象实例进入半活跃状态时，截获器“截获”ORB内核的执行过程，同时抛出重定向异常（exception ForwardRequest{Objectforward reference}），此时客户方的ORB负责将当前请求以及所有后续的请求发给异常中forwardee reference域指出的新引用地址。

服务对象实例进入半活跃状态以后，调用服务对象的Commit接口，当接口调用返回true后（对象缓存为空）对象实例就进入了停止状态。

在服务对象进行状态转换的同时，必须遵循如下的原则：要使一个正常运行的服务对象实例进入到挂起状态（Suspend），这个服务对象实例必须首先进入半活跃状态（Request Decline），然后再进入停止状态（Stop），最后达到挂起状态（Suspend）。服务对象的状态不允许跨越变化。其理由是：如果一个服务对象正在处理任务，或者服务对象的缓存中存有任务，那么跨越性的状态变化就会使服务对象在执行完所有任务以前就进入了挂起状态。也就是服务对象丢掉了许多任务，这对于系统是不允许的。

GetObjState接口通过查询当前变量state的值即可得到对象实例当前的运行状态。

（3）数据存储。监测系统的数据主要分为四类：

①系统配置数据，存储整个系统的配置和部署情况，配置数据是系统监测的依据和基础。

②系统运行日志数据，主要是记录系统运行的状态，以便管理员对系统历史运行情况的查询。

③策略库数据，主要存储各种监测分析策略和系统参数。

④整个监测过程会产生的大量监测数据，数据存储中心可存储这些数据，监测中心根据要求对原始数据进行计算、分类、统计和重新构造等抽象化分析后建立有效的数据集，抽象后的结果仍存储在数据存储中心。

数据的存储方式有数据文件和数据库两种：

①数据文件方式：这种方式对数据存取的程序实现更接近于底层，实现方式灵活，有较高的存储效率和存取速度，整个系统的资源开销小，它适合数据结构简单、读写频繁且数据规模小的应用要求。

②数据库方式：主要用于存储大规模数据，技术成熟，支持软件和维护工具多，功能强大，可靠性强，使用方便，实现程序比较简单。

根据监测系统的特点，系统配置和策略库读写频繁，且数据规模较小，采用数据文件方式，而原始数据和错误日志则采用数据库方式。

（4）策略管理。策略是一套指导和确定监测系统如何进行信息处理、错误分析和性能分析的业务规则。策略管理的目标是确保业务规则总是得到遵循。业务规则由条件和行为结合在一起构成，条件回答“我们应在何时何地执行策略?”的问题，行动回答“执行策略必须做什么?”的问题。业务规则示例如图3-4所示：

图3-4 业务规则示例

基于策略的系统监测将显著改进系统管理人员过去所遵循的传统方法，它使业务和系统管理人员能够采用业务规则，并使这些业务规则自动转换成特有的指令，从而模拟和定义被监测对象。

策略管理器通过以下组成部分完成基于策略的管理：

①策略控制台，是策略管理器和系统之间的接口，主要用于输入和编辑策略。为了防止用户误操作，工作人员进行数据输入时，策略控制台必须对其输入的数据进行检测，如：输入的数值型数据中不能包含非数字类型字符，比如字母、空格等均为非法输入；输入阀值时其上限必须大于下限，等等。控制台定义了一套规范，用户输入和编辑的策略必须符合这种规范。此外，系统还采用屏蔽无关键的方法对工作人员输入过程进行控制，即对于工作人员按下的无关键，程序将不予以响应，从而避免出错。

②策略库，一般是生成的规则和策略的目录业务，策略库允许授权用户进行修改，前面已经讨论过，由于策略库读写比较频繁并且数据规模较小，所以采用文件方式进行存储。

③策略决策点，负责存取存储在策略库内的策略模式，并根据策略信息做出决策。

④策略执行点，负责调用执行和实现策略的目标模块，如调用自动维护、报警、故障分析及处理意见、错误定位等。

（5）故障分析。故障分析器是监测系统的重要组成部分，它由知识库、策略库和推理机组成。策略库存储用户输入生成的规则和判断故障的策略，知识库主要用来存放系统故障诊断知识，当出现某种故障时，系统将获取该故障产生前一段时间的历史状态和数据以及该故障发生时的各种状态和数据，并将其存入知识库，因此知识库是不断更新的，策略库和知识库是推理机构的依据和基础。

系统采用了两种推理机制：征兆推理（又称模糊匹配推理）和规则推理（又称精确推理）。征兆推理采用模糊匹配的方法，模糊匹配认为两事物已经相似到可以认为匹配的某个程度，就认为两者是模糊匹配的。这种推理方式主要是将获取的信息与知识库中出现某种故障前一段时间的历史数据进行比较，如果两者的趋势是模糊匹配的，推理机构就会认为可能会出现某种故障并发出预警。而规则推理则是根据系统正常工作特性及制定的判断标准判定其运行状态是属于正常还是异常，如果状态属于异常，则确认出现故障并启动报警，同时将故障的描述添加到日志表中，并调用故障定位机构确定产生故障的位置。

（6）故障定位。故障定位机构主要是在推理机判断出现故障时帮助用户定位故障的位置，系统根据不同的情况采用了两种定位方法，一种是在系统中某资源失效或者状态出现异常时向用户提供该资源位置（如所在服务器、使用端口、进程ID等），另一种方法是根据对象拓扑图来定位故障，对象拓扑图是根据系统中对象之间的关系而构成的，图中的每个点代表了系统中某一个对象实例，当两个对象实例之间建立链接时，就在二者之间连线，线的粗细代表该链接上的数据流量，同时以数据的形式在线上将链接的某些参数表示出来（例如请求的名称、ID等）。根据对象拓扑图可以实时跟踪某个请求的处理情况，下面以本系统中在加载数据时出现了数据丢失这种情况来说明故障定位机构的工作流程，图3-5是系统对象拓扑图的一部分。

图3-5 对象拓扑图

用户发出请求向数据库中加载4000条记录，DivideServer收到后按一定的策略分发给加载服务对象实例LoadDB01，LoadDB02，LoadDB03，LoadDB04，然后由各加载对象实例向数据库中加载记录，而在这一过程中每个环节都可能因为出错而丢失数据。如果监测到的信息表明在加载的过程中丢失了数据，根据拓扑图很快就知道丢失数据的具体位置，如图中所示，LoadDB04接收到1000条记录，然而通过查询数据库知道成功插入到DB04数据库的记录却只有200条，由此可知道到在LoadDB04加载是发生了错误。根据拓扑图来进行故障定位的最大优点是直观、快捷，能帮助用户很快找到产生故障的位置，不但能对错误定性，而且还能定量。

（7）负载分析。对于一个分布式计算机系统，由于任务到达的随机性，以及各处理结点（服务对象）处理能力上的差异，当系统运行一段时间后，某些结点（或对象实例）分配的任务还很多（称之为超载），而另一些结点（或对象实例）却是空闲的（称之为轻载）。一方面，使超载结点（或对象实例）上的任务尽快完成是当务之急；另一方面，使某些结点（或对象实例）空闲是一种浪费。如何避免这种空闲与忙等待并存的情况，从而有效地提高系统的资源利用率，减少任务的平均响应时间，成为了负载均衡产生的原因，而负载监测是负载均衡的必要前提，它为系统的负载管理提供科学的依据，本节着重研究了大规模事务处理环境下的服务对象和服务器主机的负载索引（又称为负载度量）和负载计算问题，并对各种可能的策略、方注进行了深入探讨和分析。

①负载的度量。

服务对象负载的度量参数。

对于分布式服务对象实例负载刻画一般可以采用以下几种参数：

A.链接数：以服务对象实例当前服务的客户数量描述系统负载，在一定程度上反映了对象实例负载情况，但对于基于CORBA的服务对象实例负载分析来说，得到链接数需要ORB底层支持。

B.请求数：通过服务对象实例单位时间内接收并处理的请求数量来刻画服务对象实例负载。

C.请求处理时间：单位时间内服务对象实例处理请求所占用的时间，这实际上反映的是对象实例的忙闲程度。

服务器主机负载的度量参数。

一般来讲，对于服务器主机的负载可以用以下几种参数来刻画：

A. CPU利用率：利用系统调用获取CPU利用率，可以十分准确地描述系统当前负载，这种度量方式较为通用，特别是对于计算密集型应用。

B.内存利用率：以内存使用情况来度量系统负载，主要适用于内存消耗型应用，如数据查询或数据加载需要缓存大量结果集的应用。

C.进程个数：以当前服务器主机上运行的进程个数描述主机负载，由于不同进程占用资源不同，再加上多线程技术的引入，一个进程有可能有多个线程，且其数目可以动态改变，因而对进程数目的统计，不能准确地描述主机负载状况。

D.请求数：由服务器接收处理的请求数量来刻画系统负载，定义简单，易于获取，精确程度较高，特别适用于对象交互型应用。

除去上述几种参数，还可以用活动事务数、网络带宽、I/U队列长度、I/0设备数等等描述主机负载。然而，通过比较分析，可以看出CPU利用率、内存利用率和服务器处理的请求数量，具有通用性，适合绝大多数应用。其他度量方式与应用特点结合更为紧密。负载平衡服务应该提供几种通用的度量方式，供用户选择配置，同时应该允许用户根据应用特点开发自己的负载度量方法。

对服务对象和服务器主机，可以使用一种参数来度量它的负载，也可以综合使用几种来刻画。如果采用资源综合使用情况来刻画负载，可以更为真实的反映服务对象和主机负载状况，但这也带来较高负载获取与计算开销。

②可变阀值和阀长的负载分析模型。

上面已经讨论了刻画对象和服务器负载的各种参数，不管采用何种方式度量负载，只要最终形成一个一维的负载值，那么下面的负载分析模型就可以做到与负载度量无关。

在下面的负载分析模型中，不管是服务对象还是服务器主机，都统称为成员。对于系统中每一个成员，可以用一个正整数C来抽象地描述其处理能力，称C为该成员的能力值，处理能力C的最小阀值用正整数T（T＜C）来描述，而阀长用正整数a来描述，于是，当前成员的实际负载L和处理能力T与阀长a之间存在如下函数关系：

如图3-6，成员的当前状态处于图中描述的三个区域之一，当成员负载L小于T-a时，处于空闲区域，表示该成员任务量较小，可以成为任务的接受者；当成员负载处于负载适中区域时，表示该成员的负载适中，当成员处于过载区域时表示该成员负载很重。

图3-6 负载状态描述图