CN106484713A - 一种基于面向服务的分布式请求处理系统 - Google Patents

Abstract

本发明提供了一种基于面向服务的分布式请求处理系统，包括：主服务器管理器、从属于该主服务器管理器的多个主服务器以及从属于各主服务器的多个从服务器，所述主服务器管理器根据客户端的请求，查询与该请求的类型对应的空闲主服务器并将所述主服务器的信息返回给所述客户端；所述主服务器接收来自所述客户端的请求信息，并将该请求信息发送至选定的从服务器中进行处理；所述从服务器对所述请求信息进行处理并将处理结果通过所述主服务器返回至所述客户端。本发明的架构使用廉价PC服务器，通过横向扩展服务器集群，按照主从节点的模式，支持海量数据的分布式计算。相比使用大型机服务器，本发明所述架构成本低，可扩展性好。

Description

一种基于面向服务的分布式请求处理系统

技术领域

本发明涉及计算机技术的软件开发领域，具体涉及一种基于面向服务的分布式请求处理系统。

背景技术

随着业务数据量的爆炸式增长，传统的客户端服务器模型已经无法适应大数据环境下海量的应用请求。目前处理和分析海量数据的方法主要有：

1、使用大型机服务器甚至服务器集群。从提高硬件处理能力的角度，提高了服务器端处理海量请求的能力。大型机使用专用的处理器指令集、操作系统和应用软件。在I/O能力、稳定性、安全性等方面，大型机与廉价服务器相比具有显著优势。

2、使用基于Hadoop的分布式系统。以分布式文件系统(DFS)为存储系统，以MapReduce为计算模型的分布式框架，由数千台廉价服务器组成。对于大数据的分析与处理，Hadoop等分布式系统已经在实践中得到了广泛的应用，日志处理，用户行为分析等一系列大数据应用通过Hadoop平台得到了解决。

然而，在上述这些方法中，大型机和服务器集群的价格往往十分昂贵，虽然具有更强的I/O能力和计算能力，但如果缺乏有效的优化调度，也会造成I/O和计算资源的浪费，因此必须搭配一套中间件系统，对海量请求进行缓冲、优化，以发挥大型机和服务器集群的最大性能。基于Hadoop的分布式系统，非常适合离线大数据分析应用，但对于在线的应用，特别是基于事务的数据库访问，Hadoop缺乏对事务的保护。此外，Hadoop只是一个分布式计算和分布式存储平台，对于客户端的海量请求，同样需要一套请求的监听和缓冲系统。因此，Hadoop可以看做是面向服务的分布式软件架构中负责分布式计算的一个模块。

发明内容

为了解决上述技术问题，本申请的实施例首先提供了一种基于面向服务的分布式请求处理系统，该系统，包括：主服务器管理器、从属于该主服务器管理器的多个主服务器以及从属于各主服务器的多个从服务器，所述主服务器管理器根据客户端的请求，查询与该请求的类型对应的空闲主服务器并将所述主服务器的信息返回给所述客户端；所述主服务器接收来自所述客户端的请求信息，并将该请求信息发送至选定的从服务器中进行处理；所述从服务器对所述请求信息进行处理并将处理结果通过所述主服务器返回至所述客户端。

优选地，所述主服务器管理器对所有主服务器进行心跳检测，在检测到主服务没有心跳时则将其移除。

优选地，还包括消息接口，所述消息接口支持发布订阅模式，在所述多个从服务器同时执行一个长计算请求时，各个从服务器通过所述消息接口互相通信，同时，所述消息接口发布所述长计算请求中各个从服务器的中间结果和/或各个从服务器之间的共享状态。

优选地，还包括缓存服务器，若请求为数据库查询请求时，则客户端访问所述缓存服务器，判断所述缓存服务器中是否存储有相应的数据库查询结果，如果有则获取所述数据库查询结果，否则客户端将所述数据库查询请求发送至数据库主服务器中，数据库主服务器将该请求信息发送至选定的数据库从服务器中进行查询处理，进而获取数据库查询结果，其中，所述缓存服务器将数据库历史的查询语句和查询结果相关联地进行存储。

优选地，所述缓存服务器根据数据库历史的查询语句判断其中是否存在相应的数据库的表名，若存在则判断该表名是否被标记过期，若该表名未被标记过期则获取与之对应的数据库查询结果。

优选地，若该表名被标记过期，则数据库从服务器将获取的数据库查询结果通过数据库主服务器发送至所述缓存服务器中用来更新过期的数据库查询结果，所述缓存服务器取消该表名的过期标记。

优选地，所述数据库主服务器基于优先级对请求队列进行调度优化来执行对数据库进行编辑的编辑请求。

优选地，所述数据库主服务器在每次执行编辑请求之前，将所述请求队列拷贝到本地的本地队列中。

优选地，所述数据库主服务器首先执行请求队列中所有对应编辑请求的数据库删除操作、然后执行所有对应编辑请求的数据库添加操作，之后执行所有对应编辑请求的数据库更新操作，最后执行所有对应编辑请求的数据库读取操作。

与现有技术相比，上述方案中的一个或多个实施例可以具有如下优点或有益效果。

本发明的架构使用廉价PC服务器，通过横向扩展服务器集群，按照主从节点的模式，支持海量数据的分布式计算。相比使用大型机服务器，本发明所述架构成本低，可扩展性好。同时，本发明通过针对长计算请求，数据库请求等不同类型的请求，使用不同类型的主服务器进行处理，因此支持基于请求类型的优化调度，避免了I/O和计算资源的浪费。同时，针对数据库请求的请求队列优化和缓存技术，也提高了本发明所述架构的整体性能。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明的技术方案而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构和/或流程来实现和获得。

附图说明

附图用来提供对本申请的技术方案或现有技术的进一步理解，并且构成说明书的一部分。其中，表达本申请实施例的附图与本申请的实施例一起用于解释本申请的技术方案，但并不构成对本申请技术方案的限制。

图1是本发明实施例的基于面向服务的分布式请求处理系统的结构框图。

图2是本发明实施例的(常规)主服务器的框架图。

图3是本发明实施例的缓存结构的示意图。

图4是利用图1所示系统执行一般请求处理的流程示意图。

图5是利用图1所示系统执行数据库访问请求处理的流程示意图。

图6是图1所示的基于面向服务的分布式请求处理系统工作时的时序图。

具体实施方式

以下将结合附图及实施例来详细说明本发明的实施方式，借此对本发明如何应用技术手段来解决技术问题，并达成相应技术效果的实现过程能充分理解并据以实施。本申请实施例以及实施例中的各个特征，在不相冲突前提下可以相互结合，所形成的技术方案均在本发明的保护范围之内。

另外，附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

随着业务数据量的爆炸式增长，传统的客户端服务器模型已经无法适应大数据环境下海量的应用请求。本发明实施例以主从(Master-Slave)分布式模型为框架基础，提出了一种基于面向服务的分布式请求处理系统，本系统中主服务器管理器负责管理不同类型的主服务器的地址和状态信息，具体的主服务器负责接收客户端的请求并进行异步派发，最后由从服务器执行具体的请求处理。本系统支持同步、异步请求访问，基于优先级请求队列的调度优化和缓冲服务器，旨在提高在大数据量访问时服务器端的吞吐量、健壮性和处理请求的效率。

需要说明的是，虽然本发明实施例的系统在具体应用时也是基于多个服务器的服务器集群来实现的，但是相比背景技术中提到的大型机服务器集群来说，使用廉价的服务器即可实现本系统。

图1是本发明实施例的基于面向服务的分布式请求处理系统的结构框图。如图1所示，该分布式请求处理系统主要包括主服务器管理器(后文简称Master管理器)10、从属于Master管理器10的多个主服务器(后文简称Master)20(例如图中的DB主服务器和SDE主服务器)以及从属于每个Master 20的多个从服务器(后文简称Slave)30。主服务器管理器10根据客户端的请求，查询与该请求的类型对应的空闲主服务器20并将主服务器20的信息返回给客户端；主服务器20接收来自客户端的请求信息，并将该请求信息发送至选定的从服务器30中进行处理；从服务器30对请求信息进行处理并将处理结果通过主服务器20返回至客户端。

下面对本系统的各个组成结构进行详细说明。

Master管理器10负责对多个Master 20进行统一管理，它的主要功能包括如下。

(1)对Master 20进行动态添加和删除。

Master管理器10可以通过主动地调用AddMaster和RemoveMaster方法添加和移除Master 20，同时具体Master 20也可以调用AttachManager方法与Master管理器10进行主动绑定。

(2)提供查询到的空闲Master 20的接口给客户端，对客户端请求会被分配到哪个Master 20上进行负载均衡。

如图2所示，每个Master 20都维护着一个请求队列，当任务数发生改变时，则会通知Master管理器10当前请求队列中待执行任务的个数。Master管理器10根据每个Master 20中待执行任务的个数和Master 20的类型(例如数据库型主服务器)进行负载均衡，并返回给客户端空闲的Master 20的地址。

(3)Master管理器10的后台线程对所有Master 20做心跳检测，如果某个Master 20没有心跳，则将其从Master管理器10所维护的正常状态Master列表中移除。心跳是指Master 20定期向Master管理器10发送消息，通知自己状态正常，如果遇到网络中断，Master管理器10可以根据心跳检测，识别哪些Master 20的服务目前不可用。

在本实施例中，Master管理器10的数据结构如下：

在本实施例中，Master 20包括常规Master和特殊Master(本例中将DB Master视为特殊Master)。一般，常规Master负责接受客户端的请求并进行异步派发，交由Slave 30进行实际计算工作，它的框架图如图2所示，常规Master 20包括监听线程、请求队列和工作线程，它负责接收客户端的请求，将请求和socket放入请求队列，其中，socket是一种网络套接字，用来描述IP地址、端口和客户端服务器之间的通信链路，通过工作线程提取请求队列中的请求，并进行异步派发，派发给相应的从服务器。

常规Master 20的主要功能包括如下。

(1)绑定服务。Master 20可以根据类型绑定不同的服务，比如数据库访问、GIS访问、业务相关长计算任务等等。每一个服务相当于客户端与Master之间远程过程调用的接口，客户端可以按照接口的定义，发送请求到相应的Master 20中并等待结果。

(2)监听请求。Master 20的监听线程负责监听客户端发来的请求，并将请求的上下文信息存入请求队列，随后监听线程继续监听新的请求。

(3)异步派发。Master 20的工作线程负责读取并处理请求队列中的请求，根据请求策略中设置的优先级进行调度。

常规Master 20接收的客户端请求会包含一个描述请求信息的请求策略结构体，它描述了请求的类型、方法名称、资源消耗类型、通信类型以及优先级信息。其结构如下所示：

在本例中，常规Master的数据结构如下：

接下来，对Slave 30的功能进行描述。

Slave 30负责任务的实际执行，它拥有一组监听线程，负责监听请求的到来，监听线程接收到请求后，直接在ProcessTask函数中处理请求。根据请求不同的业务逻辑，需要实现不同的ProcessTask函数。处理完成后，Slave 30将请求结果返回给Master 20，随后Master 20将接收到的结果返回给客户端。

当多个Slave 30同时执行一个长计算的请求时，Slave 30之间可能会进行通信。在本发明实施例中，使用消息接口50(如图1、图4所示)作为Master 20与Slave 30之间、Slave 30与Slave 30之间通讯的一个范型。消息接口50支持发布订阅模式，即一个服务可能有很多订阅者，当一个发布者发送消息时，所有的订阅者都可以收到消息。消息接口50是物理发布者，真正的发布者通过远程过程调用调用消息接口50发布消息，消息可以是长计算请求中各个Slave 30的中间结果和/或各个Slave 30之间的共享状态。订阅者对消息接口50发布的服务进行订阅。

订阅模式的主要流程如下：消息接口50首先声明一系列发布服务，之后订阅者针对自己感兴趣的发布服务进行订阅，然后发布者调用RPC函数，通知消息接口50发布一条消息，最后所有订阅者接收到该消息。

对于与数据库相关的请求，在本发明中做了特殊处理，如图1所示，本系统还包括缓存服务器40。而且DB Master是针对数据库请求做了特殊优化的Master20，其除了具备常规Master 20的基本功能以外，它还支持缓存服务器40和基于请求队列的调度优化。

若请求为数据库查询请求时，则客户端访问缓存服务器40，判断缓存服务器40中是否存储有相应的数据库查询结果，如果有则获取数据库查询结果，否则客户端将数据库查询请求发送至数据库主服务器中，数据库主服务器将该请求信息发送至选定的数据库从服务器中进行查询处理，进而获取数据库查询结果，其中，缓存服务器40将数据库历史的查询语句和查询结果相关联地进行存储。缓存服务器40根据数据库历史的查询语句判断其中是否存在相应的数据库的表名，若存在则判断该表名是否被标记过期，若该表名未被标记过期则获取与之对应的数据库查询结果。

由上可知，缓存服务器40负责减少查询请求的数据库访问次数，如果之前其他用户检索了同样的内容，当前用户的查询请求就可以直接从缓存服务器40中获取，而不需要再发送请求给其他服务器。

缓存服务器40中的缓存物理结构是一个图(Map)，它是一种支持根据键快速定位值的数据结构。缓冲的Map定义如下：CacheMap<表名，DetailMap<SQL语句，查询结果>>，它是一个二级Map，给定SQL语句可以快速确定缓存中是否存在该SQL语句的查询结果。图3是本发明实施例的缓存结构的示意图，缓存是一个二级Map结构，第一级Map的键(Key)是表名(S、T)，第二级Map的键是SQL语句(例如“select*from S”等)，第二级Map的值(Value)是查询结果集。举例而言，缓存结构中“select*from T where id＝1”是数据库的SQL查询语句，表示在T表中，查找所有id等于1的记录；“recordset1”表示是上述SQL的查询结果集。

另外，当数据库发生改变后，需要对缓存进行更新，本发明实施例设计了一种基于CacheMap的延时更新策略。该延时更新策略并不在数据库发生改变时立刻更新缓存，而是当下一次的读请求到达时，才更新缓存，这样可以避免不必要的更新，降低缓存服务器40的负荷。

延时策略的描述具体如下：DB主服务器20接收到插入(Insert)、更新(Update)和删除(Delete)请求后，从SQL语句中提取表名，并在本地标记该表为过期，同时通过远程过程调用告诉缓存服务器40该表过期，此时CacheMap并没有更新，数据库和缓存信息可能不一致。当以后选择(Select)该表的请求到来，缓存中由于该表已经被标记为过期，所以提示未击中。需要说明的是，缓存击中表示数据库查询请求的结果集存储在缓存服务器中，可以直接返回结果，速度最快。缓存未击中则需要到数据库中进行实际查询。数据库从服务器执行Select请求后，检查到该表被标记为过期，将获取的数据库查询结果通过数据库主服务器发送至缓存服务器40中来更新过期的数据库查询结果，同时缓存服务器40取消该表在本地过期标记。缓存服务器40收到数据库服务器传过来的查询结果后，根据表名和SQL语句更新自己的CacheMap，同时取消该表的过期标记。

数据库主服务器基于优先级对请求队列进行调度优化来执行对数据库进行编辑的编辑请求。请求队列的调度与优化是指DB Master的一个工作线程在请求队列的拷贝后，并不是直接按照优先级进行顺序访问，而是基于一个优化策略，合并重复和冗余的查询请求，将数据库访问次数降到最低。数据库主服务器首先执行请求队列中所有对应编辑请求的数据库删除操作、然后执行所有对应编辑请求的数据库添加操作，之后执行所有对应编辑请求的数据库更新操作，最后执行所有对应编辑请求的数据库读取操作。

调度与优化的算法具体如下：

在步骤S110中，数据库主服务器的工作线程每次处理(在每次执行编辑请求)前，都将请求队列(RequsetQueue)拷贝到本地的本地队列(LocalQueue)，避免处理请求时对请求队列的独占。由于多线程并发操作数组时，可能引起冲突，因而必须首先进行上锁操作。当一个线程更改数组时，其他线程必须等待，如果更改过程中涉及其他长计算函数，就会阻塞很长时间，因此拷贝数组到本地备份的做法是必要的。

在步骤S120中，扫描LocalQueue，首先选取m_operation＝Delete的请求，发送查询给DB_Slave，让其执行数据库删除操作，并返回执行结果给客户端，之后，扫描本地队列，如果有删除(Delete)请求的记录标示字符串和已删除对象的相同，则直接返回删除成功；如果有读取(Read)和更新(Update)请求的记录标示字符串和已删除对象的相同，则直接返回失败；之后继续扫描下一个Delete请求。

在步骤S130中，扫描LocalQueue，选取m_operation＝Create的请求，发送查询给DB_Slave，让其执行数据库添加操作，并返回执行结果给客户端，之后，扫描LocalQueue。如果有添加(Create)请求的记录标示字符串和已添加对象的相同，则直接返回添加成功；之后继续扫描下一个Create请求；

在步骤S140中，倒序扫描LocalQueue，选取m_operation＝Update的请求，发送查询给DB_Slave，让其执行数据库更新操作，并返回执行结果给客户端，之后，倒序扫描LocalQueue，如果有更新(Update)请求的记录标示字符串和已更新对象的相同，则直接返回失败。返回失败的原因是同一条记录只有最后一次更改才是有效更改。之后继续扫描下一个Update请求。

在步骤S150中，扫描LocalQueue，选取m_operation＝Read的请求，发送查询给DB_Slave，让其执行数据库读取操作，并返回执行结果给客户端，之后，扫描LocalQueue，如果有Read请求的记录标示字符串和已添加对象的相同，则直接返回已读取对象执行结果，之后继续扫描下一个Read请求。

在步骤S160中，此时LocalQueue已经为空，休眠(Sleep)一小段时间(100ms)后，返回步骤S110中，循环执行。

该方式合并重复和冗余的查询请求，将数据库访问次数降到最低，同时，每次将请求队列拷贝一份本地请求队列的做法，可以避免阻塞，提高系统吞吐量。

下面参照图4来说明本实施例中的基于面向服务的分布式请求处理系统是执行一般请求处理(除数据库访问处理以外)的流程，图4中包含了长计算请求，其特点是需要各个Slave 30之间的通信来实现复杂计算函数，则需要消息接口50。概括来说，客户端请求通过该请求处理系统的Master管理器10定位到不同的Master 20，再由Master 20调度发送具体任务到Slave 30并执行。

具体来说，客户端需要发送一个请求，它首先向Master管理器10询问空闲的Master 20，需要说明的是，Master 20的类型需要和请求的类型一致，比如与数据库相关的请求需要由DB Master来负责处理，与GIS相关的请求由GISMaster负责处理。

客户端获取空闲的Master信息，例如地址后，将请求以远程过程调用(RPC)的方式发送给具体的Master 20。Master 20的请求监听线程接收到请求后，将请求信息放入请求队列之后继续新一轮的监听。与此同时，Master 20的工作线程负责将请求转发。Master 20的工作线程从请求队列中拷贝请求到本地的副本，同时清空请求队列，再根据请求任务的优先级逐一执行副本中的请求。Master 20的工作线程选取一个空闲的Slave 30，将请求以RPC方式发送给该Slave 30，请求中包含的计算、I/O等耗时操作全部由Slave 30完成。请求处理的结果由Slave 30通知给其从属的Master 20，再由Master 20通知客户端。由于Master 20的监听线程在接收到请求，放入请求队列后不会阻塞，可以继续新一轮的监听，因此本系统可以支持大量客户端的并发请求处理。

另一方面，对于与数据库相关的请求，本发明做了特殊处理。下面参考图5来说明本实施例的系统执行数据库访问的请求处理的流程。图5针对数据库请求，一个Slave 30处理一个请求，不需要和其他Slave 30交互，不需要消息接口50。

如图5所示，客户端的任意一个DB封装层在发送查询请求前，会首先访问缓存服务器40，如果缓存击中，则缓存服务器40直接将查询结果返回给客户端。如果缓存未击中，客户端才按照正常的请求处理模式进行处理。主要的处理流程前面已经说明，此处不再赘述，仅就数据库请求的两个特殊处理给与说明。

第一个特殊处理是DB Master 20的工作线程在拷贝请求队列前，会对请求队列进行调度优化，以减少数据库访问次数为目标，合并部分请求。比如请求队列中有4条对同一张表、同一个记录的update语句，事实上，只有最后一条update语句是起作用的，我们可以删除前三条update语句，将数据库访问次数减少了75％。

第二个特殊处理是DB Master 20负责更新缓存，具体采取一种Lazy的方式更新缓存，增删改的操作只是在DB Master 20和缓存服务器40上把相关表标记为过期，只有当新的查询请求来临时，才真正更新缓存。

图6是本发明实施例的基于面向服务的分布式请求处理系统执行请求处理的时序图，下面参考图6来说明各组成之间执行的先后顺序与依赖关系。

客户端的请求首先查询缓存，如果缓存服务器存在对应纪录，则直接返回结果，否则，将向主服务器管理器询问空闲主服务器，并将请求发送给该主服务器。其中，主服务器管理器维护了主服务器列表，并根据每个主服务器发来的心跳判断其状态。主服务器接受请求并将请求放入请求队列。接下来主服务器将请求队列中的请求发送给不同的从服务器进行并发处理，如果是长计算请求，还会通过消息接口传递中间结果、共享状态。从处理器执行完毕后将结果发送给主服务器，主服务器将结果返回客户端。

综上所述，本系统中Master管理器负责管理不同类型Master的地址和状态信息，具体的Master负责接收客户端的请求并进行异步派发，最后由Slave进行具体的请求处理。本系统支持多种模式的请求访问类型，基于优先级请求队列的调度优化以及基于延迟更新的缓冲服务器。利用本发明的设计方案，可以提高系统在大量并发请求访问时，服务器端的吞吐量、健壮性和处理请求的效率。

应用示例

假设数据库中包含人员表T和部门表S，其结构如下表所示。目前，有多个客户端用户提交数据库访问请求，下面我们将详细描述一下如何利用本实施例的分布式请求处理系统所构成服务器集群执行请求处理的流程。

在步骤1中，开启缓存服务器40，初始化缓存Map为空，表信息也为空。

在步骤2中，开启5个DB Slave服务，每个服务启动一组监听线程(监听线程池大小设置为100)，等待请求的到来。

在步骤3中，开启DB Master服务，调用AddSlave函数添加之前启动的5个DB Slave，启动一组监听线程(监听线程池大小设置为3)，等待请求的到来，同时启动一组工作线程(工作线程池设置为500)，循环访问请求队列。

在步骤4中，开启Master管理器服务，调用AddMaster函数添加DB Master。同时与DB Master建立心跳检测连接，DB Master每个3s发送一个心跳通知Master管理器。

在步骤5中，多个客户端同时向服务器发送SQL请求，具体SQL语句如下表所示。

编号	SQL请求
		客户端1	″select*from T″
客户端2	″select*from T″
		客户端3	″update S set department＝’开发部’where id＝2″
客户端4	″update S set department＝’项目开发部’where id＝2″
		客户端5	″update S set department＝’项目开发部’where id＝2″

客户端首先解析数据库请求类型，客户端1和客户端2都是查询请求，所以首先访问缓存服务器，但是都没有击中缓存，因此，同其他请求一样，开始向Master管理器询问DB Master的地址。

在步骤6中，Master管理器返回DB Master的地址给客户端。

在步骤7中，客户端发送请求到DB Master。请求的信息包括SQL语句和请求策略，其中请求策略设置了请求类型为数据库请求，方法类型为DBACCESS_Execute，资源类型为正常(Normal)，通信类型为同步，优先级类型为高(High)。

在步骤8中，DB Master的三个监听线程依次接收到5个客户端发来的请求，并将它们放入请求队列。此时，请求队列包含了5个SQL请求。

在步骤9中，DB Master的一组工作线程循环处理请求队列，假设工作线程A正在检查请求队列，这时请求队列非空，工作线程A将请求线程拷贝的本地，并清空请求队列。工作线程A首先对本地请求队列的拷贝进行调度优化，由于之前设置的优先级都为High，所以顺序不作调整。接下来由于请求队列中没有Delete操作和Create操作，所以首先倒序扫描三个Update操作，先执行最后一个Update语句”update S set department＝’开发项目部’where id＝2”；工作线程A调用ChooseSlave函数选取一个DB Slave作为请求的实际处理者，将该SQL请求发送给DB Slave。

在步骤10中，DB Slave的某个监听线程接收到DB Master的请求，直接进行数据库访问，执行”update S set department＝’开发项目部’where id＝2”，数据库执行Update语句成功，DB Slave随之把成功信息返回给DB Master。

在步骤11中，DB Master接收到成功返回值后，继续把成功信息返回给客户端，同时设置本地和缓存服务器的S表为过期。然后，倒序扫描剩下两条Update语句，根据表名和where语句，确定这两条Update语句和之前Update语句更新的是同一条记录，因此直接返回给客户端更新失败信息。

在步骤12中，DB Master继续处理查询请求，按顺序首先执行客户端1的请求”select*from T”，工作线程A调用ChooseSlave函数选取一个DB Slave作为请求的实际处理者，将该SQL请求发送给DB Slave。

在步骤13中，DB Slave的某个监听线程接收到DB Master的请求，直接进行数据库访问，得到匹配的结果。DB Slave随后把查询结果返回给DB Master。

在步骤14中，DB Master接收到查询结果，把查询结果返回给客户端，同时更新缓存服务器。然后，继续扫描下一条查询语句，发现SQL语句一样，直接把刚才的结果返回给客户端，不再重复访问DB Slave和数据库。

在步骤15中，缓存服务器接收到DB Master传来的查询语句和查询结果，解析出表名，放入缓存Map中。

在步骤16中，过了一段时间，客户端6生成查询请求”select*from T”，首先查询缓存服务器，缓存击中，缓存服务器直接把结果返回给客户端。

虽然本发明所揭露的实施方式如上，但所述的内容只是为了便于理解本发明而采用的实施方式，并非用以限定本发明。任何本发明所属技术领域内的技术人员，在不脱离本发明所揭露的精神和范围的前提下，可以在实施的形式上及细节上作任何的修改与变化，但本发明的专利保护范围，仍须以所附的权利要求书所界定的范围为准。

Claims (9)

1.一种基于面向服务的分布式请求处理系统，包括：主服务器管理器、从属于该主服务器管理器的多个主服务器以及从属于各主服务器的多个从服务器，

所述主服务器管理器根据客户端的请求，查询与该请求的类型对应的空闲主服务器并将所述主服务器的信息返回给所述客户端；

所述主服务器接收来自所述客户端的请求信息，并将该请求信息发送至选定的从服务器中进行处理；

所述从服务器对所述请求信息进行处理并将处理结果通过所述主服务器返回至所述客户端。

2.根据权利要求1所述的系统，其特征在于，

所述主服务器管理器对所有主服务器进行心跳检测，在检测到主服务没有心跳时则将其移除。

3.根据权利要求1所述的系统，其特征在于，还包括消息接口，所述消息接口支持发布订阅模式，

在所述多个从服务器同时执行一个长计算请求时，各个从服务器通过所述消息接口互相通信，同时，所述消息接口发布所述长计算请求中各个从服务器的中间结果和/或各个从服务器之间的共享状态。

4.根据权利要求1～3中任一项所述的系统，其特征在于，还包括缓存服务器，

若请求为数据库查询请求时，则客户端访问所述缓存服务器，判断所述缓存服务器中是否存储有相应的数据库查询结果，如果有则获取所述数据库查询结果，否则客户端将所述数据库查询请求发送至数据库主服务器中，数据库主服务器将该请求信息发送至选定的数据库从服务器中进行查询处理，进而获取数据库查询结果，

其中，所述缓存服务器将数据库历史的查询语句和查询结果相关联地进行存储。

5.根据权利要求4所述的系统，其特征在于，

所述缓存服务器根据数据库历史的查询语句判断其中是否存在相应的数据库的表名，若存在则判断该表名是否被标记过期，若该表名未被标记过期则获取与之对应的数据库查询结果。

6.根据权利要求5所述的系统，其特征在于，

若该表名被标记过期，则数据库从服务器将获取的数据库查询结果通过数据库主服务器发送至所述缓存服务器中用来更新过期的数据库查询结果，所述缓存服务器取消该表名的过期标记。

7.根据权利要求4所述的系统，其特征在于，

所述数据库主服务器基于优先级对请求队列进行调度优化来执行对数据库进行编辑的编辑请求。

8.根据权利要求7所述的系统，其特征在于，

所述数据库主服务器在每次执行编辑请求之前，将所述请求队列拷贝到本地的本地队列中。

9.根据权利要求7所述的系统，其特征在于，

所述数据库主服务器首先执行请求队列中所有对应编辑请求的数据库删除操作、然后执行所有对应编辑请求的数据库添加操作，之后执行所有对应编辑请求的数据库更新操作，最后执行所有对应编辑请求的数据库读取操作。