CN104539713B - 业务请求处理方法和装置 - Google Patents

Abstract

本发明提供了一种业务请求处理方法和装置，其中，所述方法包括：拦截应用向数据库发送的业务请求；将业务请求发送至多个数据库中的一个当前状态为正常运行的数据库进行处理，并存储业务请求；当判断在业务请求的执行过程中，处理业务请求的数据库发生故障时，为业务请求重新分配一个当前状态为正常运行的数据库；将业务请求发送至重新分配的数据库进行处理。通过本发明，能够提升业务请求的处理效率的同时，还能够提升用户的使用体验。

Description

业务请求处理方法和装置

技术领域

本发明涉及数据处理技术领域，特别是涉及一种业务请求处理方法和装置。

背景技术

目前，对于数据库集群来说，通常采用主从式结构，在多个数据库中存储相同的数据，当一个数据库发生故障时，集群会进行数据库切换，通过切换后的数据库来执行应用发送的业务请求。现有的应用与数据库集群中数据库之间通常采用直连的架构，数据库系统在处理业务请求时，应用直接向数据库发送业务请求，数据库返回相应的响应结果至应用。

采用现有的这种业务处理方法，当数据库在处理应用发送的某一业务请求(如处理一条SQL语句)的过程中发生故障时，集群会直接向应用发出业务请求处理失败的消息。如果应用再次请求，也即应用重新向数据库发送该业务请求，则集群会重新为该业务请求分配数据库，重新处理所述业务请求。而如果应用不再重新向数据库发送该业务请求，则本次业务请求处理的结果为失败。

可见，现有的业务处理方法，当数据库在处理应用发送的某一业务请求(如处理一条SQL语句)的过程中发生故障时，一方面，集群会直接向应用发出业务请求处理失败的消息，影响用户的使用体验。另一方面，应用需要重新发送该业务请求才可能得到相应的响应结果，既影响业务请求的处理效率又增加了应用的负担。

发明内容

鉴于上述现有的问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的业务处理方法和装置。

依据本发明的一个方面，提供了一种业务请求处理方法，包括：拦截应用向数据库发送的业务请求；将所述业务请求发送至多个数据库中的一个当前状态为正常运行的数据库进行处理，并存储所述业务请求；当判断在所述业务请求的执行过程中，处理所述业务请求的数据库发生故障时，为所述业务请求重新分配一个当前状态为正常运行的数据库；将所述业务请求发送至重新分配的所述数据库进行处理。

根据本发明的另一方面，提供了一种业务请求处理装置，所述业务请求处理装置包括：拦截模块，用于拦截应用装置向数据库装置发送的业务请求；发送模块，用于将所述业务请求发送至多个数据库装置中的一个当前状态为正常运行的数据库装置进行处理，并存储所述业务请求；执行模块，用于当判断在所述业务请求的执行过程中，处理所述业务请求的数据库装置发生故障时，为所述业务请求重新分配一个当前状态为正常运行的数据库装置；重发送模块，用于将所述业务请求发送至重新分配的所述数据库装置进行处理。

通过本发明，拦截应用向数据库发送的业务请求，再将拦截到的业务请求发送至数据库进行处理，并存储该业务请求。这样，当判断在该业务请求的执行过程中，处理该业务请求的数据库发生故障时，可以为该业务请求重新分配一个正常运行的数据库来处理该业务请求。通过本发明提供的业务请求处理方案，数据库发生故障时已进行处理但尚未处理完的业务请求可以重新分配正常运行的数据库来处理，一方面，由于业务请求被重新分配到集群中的数据库进行处理，因此，集群不会向应用返回业务请求失败或错误的消息，相应地则不会影响用户的使用体验。另一方面，由于应用未接收到业务请求失败的消息，因此不会重复发送该业务请求，不会增加应用的负担。而在判断出处理业务请求的数据库发生故障时，可以及时将业务请求重新发送至集群中的其他正常运行的数据库，相较于现有的方案中需要向应用返回业务请求失败的消息后再由应用重新发送的业务请求而言能够缩短业务处理时间，因此，能够提升业务请求的处理效率。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1是根据本发明实施例一的一种业务请求处理方法的步骤流程示意图；

图2是根据本发明实施例二的一种业务请求处理方法的步骤流程示意图；

图3是根据本发明实施例三的一种业务请求处理方法的步骤流程示意图；

图4是根据本发明实施例四的一种业务请求处理装置的结构示意图；

图5是根据本发明实施例五的一种业务请求处理装置的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

实施例一

参照图1，示出了本发明实施例一的一种业务请求处理方法的步骤流示意程图。

本实施例的业务请求处理方法包括以下步骤：

步骤S100：拦截应用向数据库发送的业务请求。

其中，业务请求为应用可以向数据库发送的任意业务请求，例如：请求获取某用户号码的请求、获取套餐剩余流量值的请求等。其中，本实施例中

需要说明的是，本实施例中可以由设置在应用和数据库之间的中间件来拦截应用向数据库发送的业务请求，也可以由其他任意适当的装置来拦截。

步骤S200：将业务请求发送至多个数据库中的一个当前状态为正常运行的数据库进行处理，并存储拦截的该业务请求。

多个数据库为两个或两个以上的数据库，多个数据库处于一个数据库集群中，各数据库之间存储有相同的数据。

步骤S300：当判断在业务请求的执行过程中，处理业务请求的数据库发生故障时，为业务请求重新分配一个当前状态为正常运行的数据库。

本领域技术人员可以根据实际需求设置判断业务请求是否在执行过程中的具体判断规则，例如：为业务请求的执行过程设置一个时间周期，在该时间周期内均可判定业务请求处于执行过程中。

对于判断处理业务请求的数据库发生故障的具体判断方式，也可以由本领域技术人员根据实际需求进行设置。优选地，将判断方式设置为：接收到与数据库之间连接中断的消息，则判定该数据库发生了故障。

步骤S400：将业务请求发送至重新分配的数据库进行处理。

由于重新分配的数据库能够正常运行，因此，在接收到业务请求时能够对该业务请求进行处理，返回相应的响应结果。

通过本实施例提供的业务请求处理方法，拦截应用向数据库发送的业务请求，再将拦截到的业务请求发送至数据库进行处理，并存储该业务请求。这样，当判断在该业务请求的执行过程中，处理该业务请求的数据库发生故障时，可以为该业务请求重新分配一个正常运行的数据库来处理该业务请求。通过本实施例提供的业务请求处理方法，数据库发生故障时已进行处理但尚未处理完的业务请求可以重新分配正常运行的数据库来处理，一方面，由于业务请求被重新分配到集群中的数据库进行处理，因此，集群不会向应用返回业务请求失败或错误的消息，相应地则不会影响用户的使用体验。另一方面，由于应用未接收到业务请求失败的消息，因此不会重复发送该业务请求，不会增加应用的负担。而在判断出处理业务请求的数据库发生故障时，可以及时将业务请求重新发送至集群中的其他正常运行的数据库，相较于现有的方案中需要向应用返回业务请求失败的消息后再由应用重新发送的业务请求而言能够缩短业务处理时间，因此，能够提升业务请求的处理效率。

实施例二

参照图2，示出了本发明实施例二的一种业务请求处理方法的步骤流示意程图。

本实施例的业务请求处理方法包括以下步骤：

步骤S102：中间件拦截应用向数据库发送的业务请求。

其中，本实施例中由中间件来拦截应用向数据库发送的业务请求，中间件设置于应用和多个数据库之间。多个数据库为两个或两个以上的数据库，多个数据库处于一个数据库集群中，各数据库之间存储有相同的数据。需要说明的是，应用、中间件以及多个数据库可以设置在同一台设备上，也可以各自设置在一台设备上。还可以将应用与多个数据库设置在同一台设备上，而将中间件设置在另一台设备上，或者，将中间件与多个数据库设置在同一台设备上，而将应用设置在另一台设备上。

所谓的之间并非是物理意义上的之间，而是由于中间件拦截应用与各数据库之间发送的数据，因此，才称其为设置于应用和多个数据库之间中间件。

其中，业务请求为应用可以向数据库发送的任意业务请求，例如：请求获取某用户号码的请求、获取套餐剩余流量值的请求等。

步骤S104：中间件将业务请求发送至多个数据库中的一个当前状态为正常运行的数据库进行处理，并存储业务请求。

多个数据库中可能存在发生故障的数据库，发生故障数据库无法处理业务请求，如果中间件将业务请求发送至发生故障的数据库，业务请求将被拒绝，无法得到相应的响应结果。因此，中间件在发送业务请求时，需要判断各数据库的当前状态，排除发生故障的数据库，将业务请求发送至当前状态为正常运行的数据库。

中间件在从多个当前状态为正常运行的数据库中选择数据库处理业务请求时，可以按照预设规则进行选择。预设规则可以由本领域技术人员根据实际需求进行设置，如：设置成随机选择一个数据库，遵从各数据库之间的负载均衡原则来选择一个数据库等。

对于中间件如何判断多个数据库中各数据库的当前状态是否为正常运行本实施例中不作具体限制。例如：在中间件中可以设置一个列表中记录各数据库对应的标识，以及各标识对应的当前状态，中间件通过查询该列表即可判断各数据库的当前状态。再例如：中间件可以通过判断与数据库之间的连接是否中断来判断数据库的当前状态等。

其中，业务请求可以设置在中间件中任意适当的位置。例如：中间件在预设的缓存中存储发送至数据库的业务请求；再例如：中间件将业务请求存储在预设的队列中等。

步骤S106：当中间件判断在业务请求的执行过程中，处理业务请求的数据库发生故障时，为业务请求重新分配一个当前状态为正常运行的数据库。

本领域技术人员可以根据实际需求设置中间件判断业务请求是否在执行过程中的具体判断规则，例如：为业务请求的执行过程设置一个时间周期，在该时间周期内中间件都可判定业务请求处于执行过程中。

中间判断处理业务请求的数据库发生故障的具体判断方式，也可以由本领域技术人员根据实际需求进行设置。优选地，将判断方式设置为：中间件接收到与数据库之间连接中断的消息，则判定该数据库发生了故障。

步骤S108：中间件将业务请求发送至重新分配的数据库进行处理。

由于重新分配的数据库能够正常运行，因此，在接收到业务请求时能够对该业务请求进行处理，返回相应的响应结果。

本实施例中对于中间件将业务请求发送至重新分配的数据库的具体过程不作具体限制。优选地，中间件选择一个与该数据库之间的空闲连接来发送该业务请求。

在针对处理集群中的数据库发生故障时相应的处理方案中，本领域技术目前多是针对数据库未执行的业务请求分配数据库的方案，而对于发生故障的数据库在故障时正在处理的业务请求的数据库再分配方案并未涉及。本实施例中记载的方法，正是一种解决数据库故障时正在处理的业务请求的数据库再分配的有效方法。

通过本实施例提供的业务请求处理方法，在应用和多个数据库之间设置中间件，由中间件拦截应用向数据库发送的业务请求，再由中间件将拦截到的业务请求发送至数据库进行处理，并存储该业务请求。这样，当中间件判断在该业务请求的执行过程中，处理该业务请求的数据库发生故障时，中间件可以为该业务请求重新分配一个正常运行的数据库来处理该业务请求。通过本实施例提供的业务请求处理方法，数据库发生故障时已进行处理但尚未处理完的业务请求可以由中间件重新分配正常运行的数据库来处理，一方面，由于业务请求被重新分配到集群中的数据库进行处理，因此，集群不会向应用返回业务请求失败的消息，相应地则不会影响用户的使用体验。另一方面，由于应用未接收到业务请求失败的消息，因此不会重复发送该业务请求，不会增加应用的负担。而中间件在判断出处理业务请求的数据发生故障时，可以及时将业务请求重新发送至集群中的其他正常运行的数据库，相较于现有的方案中需要向应用返回业务请求失败的消息后再由应用重新发送的业务请求而言能够缩短业务处理时间，因此，能够提升业务请求的处理效率。

实施例三

参照图3，示出了本发明实施例三的一种业务请求处理方法的步骤流程示意图。

本实施例的业务请求处理方法具体包括以下步骤：

步骤S202：中间件根据多个数据库可支持的连接的信息，生成连接池。

其中，中间件设置于应用和多个数据库之间。连接池用于管理多个数据库中各数据库可支持的连接。

需要说明的是，中间件可以为每个数据库分别建立一个连接池，也可以为多个数据库建立一个连接池。

中间件根据数据库可支持的连接的信息，生成连接池的一种可选的生成方式如下：中间件根据数据库可支持的连接的信息确定数据库可支持的连接上限；中间件在连接池中设置相同的数量的连接，并存储数据库可支持的连接的信息，以便中间件在建立与数据库之间的连接时，从连接池中选择一个空闲连接根据数据库可支持的连接的信息建立与数据库之间的连接。例如：数据库可支持的连接上限为50个连接，那么，中间件在连接池中建立50个连接，在连接池中存储数据库可支持的50个连接对应的连接信息。

采用上述优选的实现方式重复在中间件中为多个数据库分别建立连接池，即可完成中间件根据多个数据库可支持的连接的信息，生成连接池的过程。

中间件根据多个数据库可支持的连接的信息，生成连接池的另一种可选的生成方式如下：中间件根据各数据库可支持的连接的信息确定各数据库可支持的连接上限，在中间件中存储各数据库可支持的连接的连接信息；中间件在连接池中分别为各数据库设置与各数据库可支持的连接上限相同的数量的连接；并将连接池中分配给各数据库的连接进行标识以进行区分。

例如：多个数据库为两个分别标记为第一数据库与第二数据库的数据库，中间件根据第一数据库可支持的连接信息确定第一数据库可支持的连接的上限为50个连接，根据第二数据库可支持的连接信息确定第一数据库可支持的连接的上限为40个连接；中间件在连接池中建立90个连接；同时存储第一数据与第二数据库的可支持连接的连接信息；中间件将连接池中的50个连接标识为用于与第一数据库建立连接使用，将连接池中剩余的40个连接标记为用于与第二数据库之间建立连接使用。

中间件根据多个数据库可支持的连接的信息，生成连接池后，可以根据数据库的当前状态，将连接池中对应于各个数据库的各连接的连接状态设置为可用状态或不可用状态。优选地，当中间件判断数据库发生故障时，将连接池中对应于发生故障的数据库的所有连接的连接状态设置为不可用状态，当判断发生故障的数据库恢复正常运行时，将连接池中对应于恢复正常运行的数据库的所有连接的连接状态由不可用状态修改为可用状态。

例如：在中间件的连接池中为第一数据库建立50个连接，为第二数据库建立40个连接。当中间件判断第一数据库发生故障如：数据库宕机时，中间件将连接池中建立的与第一数据库的50个连接的连接状态设置为不可用状态，而另外的建立的与第二数据库之间的连接的连接状态仍为可用状态。通过根据数据库的当前状态设置连接池中与数据库对应的连接的连接状态，当中间件为业务请求分配连接时，则可通过判断连接池中的建立的与数据库之间的连接的当前状态来确定数据库是否发生了故障。

步骤S204：中间件拦截应用向数据库发送的业务请求。

优选地，中间件在拦截到应用向数据库发送的业务请求后，向应用返回业务请求被接受的消息。通过向应用返回业务请求被接受的消息，使得应用能够确认本次的业务请求已被成功受理，避免应用不断向数据库或中间件发送询问消息，减少应用的操作负担以及网络的信息交互负担。

步骤S206：中间件将业务请求发送至多个数据库中的一个当前状态为正常运行的数据库进行处理，并存储发送至数据库的该业务请求。

一种优选的中间件将业务请求发送至多个数据库中的一个当前状态为正常运行的数据库进行处理的方式为：中间件从多个当前状态为正常运行的数据库中选择一个数据库，获取自身的连接池中对应于选择的数据库的各个连接的状态信息；根据各个连接的状态信息，从至少一个可用连接中选择一个可用连接；将选择的可用连接的状态从可用状态更改为不可用状态，并使用选择的连接将业务请求发送至选择的数据库进行处理。

上述优选的实现方式中，中间件从多个当前状态为正常运行的数据库中选择一个数据库，目的是保证业务请求能够发送至正常运行的数据库。中间件从被选择的数据库在连接池中对应的连接中选择一个可用连接，目的是保证业务请求能够成功发送至该数据库。而将选择的可用连接的连接状态从可用状态更改为不可用状态，可以使中间件能够通过连接的连接状态快速高效地确定可用连接，从而快速高效为请求分配连接资源。假设，连接池中的某个连接已被占用，但是连接的状态仍为可用状态，这样，当应用需要选择连接发送业务请求时由于不能获知该连接被占用，仍可能调用该连接发送业务请求，将会导致业务请求发送失败。

需要说明的是，本领域技术人员可以根据实际需求设置中间件存储业务请求的具体方式。具体实现方式包括但不限于：第一种，将业务请求按照发送至数据库的时间进行分类存储，设置每5分钟为一个时间段，将5分钟内发送至数据库的所有业务请求存储在一块存储空间中；第二种，为每个应用分配一块存储空间，将拦截到的业务请求存储到发送该业务请求的应用对应的存储空间中；第三种，将发送至数据库的所有业务请求存储在一块存储空间中。

步骤S208：当中间件判断在业务请求的执行过程中，处理业务请求的数据库发生故障时，为业务请求重新分配一个当前状态为正常运行的数据库。

中间件判断在业务请求的执行过程中，处理业务请求的数据库发生故障的具体方式包括但不限于：

第一种，中间件在已将业务请求发送至数据库进行处理后，接收到与数据库之间连接中断的消息之前，未拦截到所述数据库返回的、对业务请求的响应结果，则中间件确定在业务请求的执行过程中，处理业务请求的数据库发生故障。

第二种，中间件在将业务请求发送至数据库进行处理后，在预定时间内未拦截到数据库返回的、对业务请求的响应结果，则确定在业务请求的执行过程中，处理业务请求的数据库发生故障。

其中，预定时间的具体设定可以由本领域技术人员根据实际需求进行设置，例如：将预定时间设置成业务请求发出后5秒。当然还可以是其他值，如10秒、8秒等。

中间件为业务请求重新分配一个当前状态为正常运行的数据库时，可以获取多个数据库的当前状态；根据获取的多个数据库的当前状态，确定当前状态为正常运行的至少一个数据库；从至少一个当前状态为正常运行的数据库中选择一个数据库。

对于数据库的当前状态，可以在连接池中标记各连接的连接状态的同时标记各数据库的当前状态，也可以在中间件中集中记录各数据库的当前状态。相应地，在获取数据库的当前状态时，中间件可以从连接池中获取各数据库的当前状态，可以从集中的存储的各数据库当前状态的相应位置获取该数据。

步骤S210：中间件将接池中对应于发生故障的该数据库的所有连接的连接状态设置为不可用状态。

需要说明的是，对于发生故障的该数据库的所有连接的连接状态设置的步骤，并不局限于在为业务请求重新分配一个当前状态为正常运行的数据库之后执行，该步骤可以在判断数据库发生故障后的任意时刻执行。

步骤S212：中间件获取连接池中对应于选择的数据库的各个连接的状态信息。

在中间件自身的连接池中为被选择的数据库分配有多个连接，而这些连接中有些可能已被发送至该数据库的业务请求占用，此时为不可用状态；而有些可能是处于空闲，此时为可用状态，而中间件仅能够通过可用连接将业务请求发送至该数据库，因此，需要获取各个连接的状态信息，来选择一个可用连接。

优选地，将被业务请求占用的连接的连接状态标记为不可用状态，将空闲的连接的连接状态标记为可用状态。

步骤S214：中间件根据各个连接的状态信息，从至少一个可用连接中选择一个可用连接。

本实施例中，可用连接为数据库运行状态正常，且未被业务请求占用空闲的连接，对应的连接状态为可用状态。

对于中间件从至少一个可用连接中选择一个可用连接的具体选择方式本实施例不作具体限制，当连接池中为该数据库分配的连接中存在多个空闲连接，中间件可以随机从中选择一个空闲连接，也可以按照连接空闲时间的长短选择一个空闲时间最长的连接，当然还可以按照其他的选择方式进行选择。

步骤S216：中间件将选择的可用连接的状态从可用状态更改为不可用状态，并使用选择的连接将业务请求发送至选择的数据库进行处理。

中间件通过将可用连接的连接状态更改为不可用状态，可以高效快速地判断出连接池中各个连接的连接状态，从而更为有效地为业务请求选择可用连接。

步骤S218：中间件拦截重新分配的数据库通过选择的连接返回的、对业务请求的响应结果，并将拦截到的响应结果发送至发送业务请求的应用。

数据库接收业务请求，在处理完该业务请求后，会通过之前中间件选择的连接返回对业务请求的响应结果。此时，中间件拦截该响应结果。

步骤S220：中间件将连接的状态从不可用状态更改为可用状态。

本步骤中，中间件在拦截到通过选择的连接返回的响应结果时，释放与选择的数据库之间的该连接，并将该连接的连接状态由不可用状态修改为可用状态，便于中间件为尚未得到处理的业务请求分配连接，提高连接的使用率。

需要说明的是，释放与该数据库之间的连接，并非在连接池中将该连接删除，而是将其放入空闲连接中，以供中间件需要与该数据库之间再次建立连接时调用。

步骤S222：中间件按照设定规则监测发生故障的数据库是否恢复正常运行，依据判断结果修改数据库的当前状态。

一种优选的中间件按照设定规则监测发生故障的数据库是否恢复正常运行，依据判断结果修改数据库的当前状态的方式如下：

中间件按照设定规则向发生故障的数据库发送连接请求；若接收到对连接请求的成功响应，则确定发生故障的数据库已恢复正常运行，在连接池中将已恢复正常运行的数据库对应的连接的状态设置为可用状态；若未接收到对连接请求的成功响应，则确定发生故障的数据库未恢复正常运行，返回执行中间件按照设定规则向发生故障的数据库发送连接请求的步骤。

其中，设定规则可以由本领域技术人员根据实际需求进行设置，例如：设置成每隔30秒钟向发生故障的数据库发送一次连接请求。

需要说明的是，本步骤并不局限于在步骤S220之后执行，本步骤可以在中间件判断出数据库发生故障后的任意时机执行，当然也包括与步骤S208至步骤S220中的任意步骤并行执行。

本实施例中的业务处理方法可以应用于多种数据库系统，优选地，将本实施例中的业务请求处理方法应用于非分布式数据库系统，更优选地，应用于关系型数据库系统。目前非分布式数据库系统如关系型数据库系统在处理业务请求时，当数据库在处理应用发送的某一业务请求(如处理一条SQL语句)的过程中发生故障时，通过对数据库进行切换，仅能保证切换后应用向数据库发送的业务请求被成功处理，但数据库发生故障时正在处理的业务请求则不会重新被执行，可见存在背景技术部分所指出的问题。通过将本实施例中提供的业务处理方法应用于关系型数据库系统能够效解决非分布式数据库系统中其存在的上述问题。

通过本实施例提供的业务请求处理方法，除具有实施例一中所述的业务请求方法的有益效果外，中间件还根据各数据库可支持的连接的信息生成连接池，在连接池中管理为各数据库建立的连接，同时，依据数据库的当前状态，来修改连接池中与数据库对应的各连接的状态，更便于中间件对各连接的管理。此外，本实施例提供的业务请求处理方法，还可以按照设定规则监测发生故障的数据库是否恢复正常运行，依据判断结果修改数据库的当前状态，在数据库恢复正常运行后，在中间件中将恢复正常运行的数据库对应的连接的状态设置为可用状态，中间件则可以通过该数据库对应的连接向数据库发送业务请求，能够对数据库进行高效利用。

实施例四

参照图4，示出了本发明实施例四的一种业务请求处理装置的结构示意图。

本实施例的业务请求处理装置可以设置于应用装置和多个数据库装置之间，业务请求处理装置包括：拦截模块302，用于拦截应用装置向数据库装置发送的业务请求；发送模块304，用于将业务请求发送至多个数据库装置中的一个当前状态为正常运行的数据库装置进行处理，并存储业务请求；执行模块306，用于当判断在业务请求的执行过程中，处理业务请求的数据库装置发生故障时，为业务请求重新分配一个当前状态为正常运行的数据库装置；重发送模块308，用于将业务请求发送至重新分配的数据库装置进行处理。

需要说明的是，业务请求处理装置、应用装置和多个数据库装置可以设置在同一设备中，也可以分别设置在不同的设备中。本实施例中对此不作具体限制。

通过本实施例提供的业务请求处理装置，拦截应用向数据库发送的业务请求，再将拦截到的业务请求发送至数据库进行处理，并存储该业务请求。这样，当判断在该业务请求的执行过程中，处理该业务请求的数据库装置发生故障时，可以为该业务请求重新分配一个正常运行的数据库来处理该业务请求。通过本实施例提供的业务请求处理装置，数据库装置发生故障时已进行处理但尚未处理完的业务请求可以重新分配正常运行的数据库装置来处理，一方面，由于业务请求被重新分配到集群中的数据库装置进行处理，因此，集群不会向应用装置返回业务请求失败的消息，相应地则不会影响用户的使用体验。另一方面，由于应用装置未接收到业务请求失败的消息，因此不会重复发送该业务请求，不会增加应用装置的负担。而业务请求处理装置在判断出处理业务请求的数据库装置发生故障时，可以及时将业务请求重新发送至集群中的其他正常运行的数据库装置，相较于现有的方案中需要向应用装置返回业务请求失败的消息后再由应用装置重新发送的业务请求而言能够缩短业务处理时间，因此，能够提升业务请求的处理效率。

实施例五

参照图5，示出了本发明实施例五的一种业务请求处理装置的结构示意图。

本实施例对实施例四中的业务请求处理装置进行了进一步优化，优化后的业务请求处理装置包括：拦截模块402，用于拦截应用装置向数据库装置发送的业务请求；发送模块404，用于将业务请求发送至多个数据库装置中的一个当前状态为正常运行的数据库装置进行处理，并存储业务请求；执行模块406，用于当判断在业务请求的执行过程中，处理业务请求的数据库装置发生故障时，为业务请求重新分配一个当前状态为正常运行的数据库装置；重发送模块408，用于将业务请求发送至重新分配的数据库装置进行处理。

优选地，执行模块406判断在业务请求的执行过程中，处理业务请求的数据库装置发生故障时：在已将业务请求发送至数据库装置进行处理后，接收到与数据库装置之间连接中断的消息之前，未拦截到数据库装置返回的、对业务请求的响应结果，则执行模块406确定在业务请求的执行过程中，处理业务请求的数据库装置发生故障。

优选地，执行模块406判断在业务请求的执行过程中，处理业务请求的数据库装置发生故障时：在将业务请求发送至数据库装置进行处理后，在预定时间内未拦截到数据库装置返回的、对业务请求的响应结果，则执行模块406确定在业务请求的执行过程中，处理业务请求的数据库装置发生故障。

优选地，本实施例的业务请求处理装置还包括：连接池生成模块410，用于在拦截模块402拦截应用装置向数据库装置发送的业务请求之前，根据多个数据库装置可支持的连接的信息，生成连接池，其中，连接池用于管理多个数据库装置可支持的连接。

优选地，本实施例的业务请求处理装置还包括：第一状态设置模块412，用于在连接池生成模块410根据多个数据库装置可支持的连接的信息，生成连接池之后，根据数据库装置的当前状态，将连接池中对应于各个数据库装置的各个连接设置为可用状态或不可用状态。

优选地，本实施例的业务请求处理装置还包括：第二状态设置模块414，用于当执行模块406判断数据库装置发生故障时，将连接池中对应于发生故障的数据库装置的所有连接的连接状态设置为不可用状态。

优选地，发送模块404包括：数据库选择模块4042，用于从多个当前状态为正常运行的数据库装置中选择一个数据库装置，获取中间件装置自身的连接池中对应于选择的数据库装置的各个连接的状态信息；可用连接选择模块4044，用于根据各个连接的状态信息，从至少一个可用连接中选择一个可用连接；以及业务请求发送模块4046，用于将选择的可用连接的状态从可用状态更改为不可用状态，并使用选择的连接将业务请求发送至选择的数据库装置进行处理；存储模块4048，用于存储业务请求。

优选地，执行模块406为业务请求重新分配一个当前状态为正常运行的数据库装置时，获取多个数据库装置的当前状态；根据获取的多个数据库装置的当前状态，确定当前状态为正常运行的至少一个数据库装置；从至少一个当前状态为正常运行的数据库装置中选择一个数据库装置。

优选地，重发送模块408包括：连接状态获取信息4082，用于获取连接池中对应于选择的数据库装置的各个连接的状态信息；可用连接选择模块4084，用于根据各个连接的状态信息，从至少一个可用连接中选择一个可用连接；业务请求重发送模块4086，用于将选择的可用连接的状态从可用状态更改为不可用状态，并使用选择的连接将业务请求发送至选择的数据库装置进行处理。

优选地，本实施例的业务请求处理装置还包括：响应结果拦截模块416，用于在重发送模块408将业务请求发送至重新分配的数据库装置进行处理之后，拦截重新分配的数据库装置通过选择的连接返回的、对业务请求的响应结果，并将拦截到的响应结果发送至发送业务请求的应用装置。

优选地，本实施例的业务请求处理装置还包括：第三状态设置模块418，用于在响应结果拦截模块416拦截重新分配的数据库装置通过选择的连接返回的、对业务请求的响应结果之后，将连接的状态从不可用状态更改为可用状态。

优选地，本实施例的业务请求处理装置还包括：连接请求发送模块420，用于在执行模块判断数据库装置发生故障后，按照设定规则向发生故障的数据库装置发送连接请求；第一执行模块422，用于若接收到对连接请求的成功响应，则确定发生故障的数据库装置已恢复正常运行，在连接池中将已恢复正常运行的数据库装置对应的连接的状态设置为可用状态；第二执行模块424，用于若未接收到对连接请求的成功响应，则确定发生故障的数据库装置未恢复正常运行，调用连接请求发送模块420。

优选地，本实施例的业务请求处理装置应用于非分布式数据库系统。

优选地，本实施例的业务请求处理装置应用于关系型数据库系统。

优选地，本实施例的业务请求处理装置为中间件装置，该中间件装置设置于应用装置和多个数据库之间，中间件装置中设置有自身的连接池，中间件在拦截到应用装置向数据库装置发送的业务请求时，将业务请求发送至多个数据库装置中的一个当前状态为正常运行的数据库装置进行处理，并存储业务请求，当判断在业务请求的执行过程中，处理业务请求的数据库装置发生故障时，为业务请求重新分配一个当前状态为正常运行的数据库装置；将业务请求发送至重新分配的数据库装置进行处理。

本实施例的业务请求处理装置用于实现前述实施例一、实施例二以及实施例三中相应的业务请求处理的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

在此提供的业务请求处理方案不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造具有本发明方案的系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的业务请求处理方案中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”或“包括”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

本发明实施例公开了A1、一种业务请求处理方法，包括：拦截应用向数据库发送的业务请求；将所述业务请求发送至多个数据库中的一个当前状态为正常运行的数据库进行处理，并存储所述业务请求；

当判断在所述业务请求的执行过程中，处理所述业务请求的数据库发生故障时，为所述业务请求重新分配一个当前状态为正常运行的数据库；

将所述业务请求发送至重新分配的所述数据库进行处理。

A2、根据A1所述的方法，其中，所述判断在所述业务请求的执行过程中，处理所述业务请求的数据库发生故障的步骤包括：

在已将所述业务请求发送至数据库进行处理后，接收到与所述数据库之间连接中断的消息之前，未拦截到所述数据库返回的、对所述业务请求的响应结果，则所述中间件确定在所述业务请求的执行过程中，处理所述业务请求的数据库发生故障。

A3、根据A1所述的方法，其中，所述判断在所述业务请求的执行过程中，处理所述业务请求的数据库发生故障的步骤包括：

在将所述业务请求发送至数据库进行处理后，在预定时间内未拦截到所述数据库返回的、对所述业务请求的响应结果，则确定在所述业务请求的执行过程中，处理所述业务请求的数据库发生故障。

A4、根据A1-A3任一项所述的方法，其中，在所述拦截应用向数据库发送的业务请求的步骤之前，所述方法还包括：

根据所述多个数据库可支持的连接的信息，生成连接池，其中，所述连接池用于管理所述多个数据库可支持的连接。

A5、根据A4所述的方法，其中，在所述根据所述多个数据库可支持的连接的信息，生成连接池的步骤之后，所述方法还包括：

根据所述数据库的当前状态，将所述连接池中对应于各个数据库的各个连接设置为可用状态或不可用状态。

A6、根据A5所述的方法，其中，所述方法还包括：

当判断数据库发生故障时，将连接池中对应于发生故障的所述数据库的所有连接的连接状态设置为不可用状态。

A7、根据A5或A6所述的方法，其中，所述将所述业务请求发送至所述多个数据库中的一个当前状态为正常运行的数据库进行处理的步骤进一步包括：

从多个当前状态为正常运行的数据库中选择一个数据库，获取连接池中对应于选择的所述数据库的各个连接的状态信息；

根据所述各个连接的状态信息，从至少一个可用连接中选择一个可用连接；以及

将选择的所述可用连接的状态从可用状态更改为不可用状态，并使用选择的所述连接将所述业务请求发送至选择的所述数据库进行处理。

A8、根据A5或A6所述的方法，其中，所述为所述业务请求重新分配一个当前状态为正常运行的数据库的步骤包括：

获取所述多个数据库的当前状态；

根据获取的所述多个数据库的当前状态，确定当前状态为正常运行的至少一个数据库；

从所述至少一个当前状态为正常运行的数据库中选择一个数据库。

A9、根据A8所述的方法，其中，所述将所述业务请求发送至重新分配的所述数据库进行处理的步骤包括：

获取连接池中对应于选择的所述数据库的各个连接的状态信息；

根据所述各个连接的状态信息，从至少一个可用连接中选择一个可用连接；

将选择的所述可用连接的状态从可用状态更改为不可用状态，并使用选择的所述连接将所述业务请求发送至选择的所述数据库进行处理。

A10、根据A9所述的方法，其中，在所述将所述业务请求发送至重新分配的所述数据库进行处理的步骤之后，所述方法还包括：

拦截重新分配的所述数据库通过选择的连接返回的、对所述业务请求的响应结果，并将拦截到的所述响应结果发送至发送所述业务请求的应用。

A11、根据A10所述的方法，其中，在所述拦截重新分配的所述数据库通过选择的连接返回的、对所述业务请求的响应结果的步骤之后，所述方法还包括：

将所述连接的状态从不可用状态更改为可用状态。

A12、根据A1所述的方法，其中，在所述判断数据库发生故障后，所述方法还包括：

按照设定规则向发生故障的所述数据库发送连接请求；

若接收到对所述连接请求的成功响应，则确定发生故障的所述数据库已恢复正常运行，在连接池中将所述已恢复正常运行的数据库对应的连接的状态设置为可用状态；

若未接收到对所述连接请求的成功响应，则确定所述发生故障的数据库未恢复正常运行，返回执行按照设定规则向发生故障的所述数据库发送连接请求的步骤。

A13、根据A1所述的方法，其中，所述业务请求处理方法应用于非分布式数据库系统。

A14、根据A1或A13所述的方法，其中，所述业务请求处理方法应用于关系型数据库系统。

本发明实施例还公开了B15、一种业务请求处理装置，所述业务请求处理装置包括：

拦截模块，用于拦截应用装置向数据库装置发送的业务请求；

发送模块，用于将所述业务请求发送至多个数据库装置中的一个当前状态为正常运行的数据库装置进行处理，并存储所述业务请求；

执行模块，用于当判断在所述业务请求的执行过程中，处理所述业务请求的数据库装置发生故障时，为所述业务请求重新分配一个当前状态为正常运行的数据库装置；

重发送模块，用于将所述业务请求发送至重新分配的所述数据库装置进行处理。

B16、根据B15所述的业务请求处理装置，其中，所述执行模块判断在所述业务请求的执行过程中，处理所述业务请求的数据库装置发生故障时：

在已将所述业务请求发送至数据库装置进行处理后，接收到与所述数据库装置之间连接中断的消息之前，未拦截到所述数据库装置返回的、对所述业务请求的响应结果，则所述执行模块确定在所述业务请求的执行过程中，处理所述业务请求的数据库装置发生故障。

B17、根据B15所述的业务请求处理装置，其中，所述执行模块判断在所述业务请求的执行过程中，处理所述业务请求的数据库装置发生故障时：

在将所述业务请求发送至数据库装置进行处理后，在预定时间内未拦截到所述数据库装置返回的、对所述业务请求的响应结果，则所述执行模块确定在所述业务请求的执行过程中，处理所述业务请求的数据库装置发生故障。

B18、根据B15-B17任一项所述的业务请求处理装置，其中，所述业务请求处理装置还包括：

连接池生成模块，用于在所述拦截模块拦截应用装置向数据库装置发送的业务请求之前，根据所述多个数据库装置可支持的连接的信息，生成连接池，其中，所述连接池用于管理所述多个数据库装置可支持的连接。

B19、根据B18所述的业务请求处理装置，其中，所述装置还包括：

第一状态设置模块，用于在所述连接池生成模块根据所述多个数据库装置可支持的连接的信息，生成连接池之后，根据所述数据库装置的当前状态，将所述连接池中对应于各个数据库装置的各个连接设置为可用状态或不可用状态。

B20、根据B19所述的业务请求处理装置，其中，所述业务请求处理装置还包括：

第二状态设置模块，用于当所述执行模块判断数据库装置发生故障时，将所述连接池中对应于发生故障的所述数据库装置的所有连接的连接状态设置为不可用状态。

B21、根据B19或B20所述的业务请求处理装置，其中，所述发送模块包括：

数据库选择模块，用于从多个当前状态为正常运行的数据库装置中选择一个数据库装置，获取连接池中对应于选择的所述数据库装置的各个连接的状态信息；

可用连接选择模块，用于根据所述各个连接的状态信息，从至少一个可用连接中选择一个可用连接；以及

业务请求发送模块，用于将选择的所述可用连接的状态从可用状态更改为不可用状态，并使用选择的所述连接将所述业务请求发送至选择的所述数据库装置进行处理；

存储模块，用于存储所述业务请求。

B22、根据B19或B20所述的业务请求处理装置，其中，所述执行模块为所述业务请求重新分配一个当前状态为正常运行的数据库装置时，获取所述多个数据库装置的当前状态；根据获取的所述多个数据库装置的当前状态，确定当前状态为正常运行的至少一个数据库装置；从所述至少一个当前状态为正常运行的数据库装置中选择一个数据库装置。

B23、根据B22所述的业务请求处理装置，其中，所述重发送模块包括：

连接状态获取信息，用于获取连接池中对应于选择的所述数据库装置的各个连接的状态信息；

可用连接选择模块，用于根据所述各个连接的状态信息，从至少一个可用连接中选择一个可用连接；

业务请求重发送模块，用于将选择的所述可用连接的状态从可用状态更改为不可用状态，并使用选择的所述连接将所述业务请求发送至选择的所述数据库装置进行处理。

B24、根据B23所述的业务请求处理装置，其中，所述业务请求处理装置还包括：

响应结果拦截模块，用于在所述重发送模块将所述业务请求发送至重新分配的所述数据库装置进行处理之后，拦截重新分配的所述数据库装置通过选择的连接返回的、对所述业务请求的响应结果，并将拦截到的所述响应结果发送至发送所述业务请求的应用装置。

B25、根据B24所述的业务请求处理装置，其中，所述业务请求处理装置还包括：

第三状态设置模块，用于在所述响应结果拦截模块拦截重新分配的所述数据库装置通过选择的连接返回的、对所述业务请求的响应结果之后，将所述连接的状态从不可用状态更改为可用状态。

B26、根据B15所述的业务请求处理装置，其中，所述业务请求处理装置还包括：

连接请求发送模块，用于在所述执行模块判断数据库装置发生故障后，按照设定规则向发生故障的所述数据库装置发送连接请求；

第一执行模块，用于若接收到对所述连接请求的成功响应，则确定发生故障的所述数据库装置已恢复正常运行，在连接池中将所述已恢复正常运行的数据库装置对应的连接的状态设置为可用状态；

第二执行模块，用于若未接收到对所述连接请求的成功响应，则确定所述发生故障的数据库装置未恢复正常运行，调用所述连接请求发送模块。

B27、根据B15所述的业务请求处理装置，其中，所述业务请求处理装置应用于非分布式数据库系统。

B28、根据B15或B27所述的业务请求处理装置，其中，所述业务请求处理装置应用于关系型数据库系统。

Claims (22)

1.一种业务请求处理方法，包括：

根据多个数据库可支持的连接的信息，生成连接池，其中，所述连接池用于管理所述多个数据库可支持的连接；

根据所述数据库的当前状态，将所述连接池中对应于各个数据库的各个连接设置为可用状态或不可用状态；

拦截应用向数据库发送的业务请求；

将所述业务请求发送至多个数据库中的一个当前状态为正常运行的数据库进行处理，并存储所述业务请求；

当判断在所述业务请求的执行过程中，处理所述业务请求的数据库发生故障时，为所述业务请求重新分配一个当前状态为正常运行的数据库；

当判断数据库发生故障时，将所述连接池中对应于发生故障的所述数据库的所有连接的连接状态设置为不可用状态；

将所述业务请求发送至重新分配的所述数据库进行处理。

2.根据权利要求1所述的方法，其中，所述判断在所述业务请求的执行过程中，处理所述业务请求的数据库发生故障的步骤包括：

在已将所述业务请求发送至数据库进行处理后，接收到与所述数据库之间连接中断的消息之前，未拦截到所述数据库返回的、对所述业务请求的响应结果，则确定在所述业务请求的执行过程中，处理所述业务请求的数据库发生故障。

3.根据权利要求1所述的方法，其中，所述判断在所述业务请求的执行过程中，处理所述业务请求的数据库发生故障的步骤包括：

在将所述业务请求发送至数据库进行处理后，在预定时间内未拦截到所述数据库返回的、对所述业务请求的响应结果，则确定在所述业务请求的执行过程中，处理所述业务请求的数据库发生故障。

4.根据权利要求1所述的方法，其中，所述将所述业务请求发送至所述多个数据库中的一个当前状态为正常运行的数据库进行处理的步骤进一步包括：

从多个当前状态为正常运行的数据库中选择一个数据库，获取连接池中对应于选择的所述数据库的各个连接的状态信息；

根据所述各个连接的状态信息，从至少一个可用连接中选择一个可用连接；以及

将选择的所述可用连接的状态从可用状态更改为不可用状态，并使用选择的所述连接将所述业务请求发送至选择的所述数据库进行处理。

5.根据权利要求1所述的方法，其中，所述为所述业务请求重新分配一个当前状态为正常运行的数据库的步骤包括：

获取所述多个数据库的当前状态；

根据获取的所述多个数据库的当前状态，确定当前状态为正常运行的至少一个数据库；

从所述至少一个当前状态为正常运行的数据库中选择一个数据库。

6.根据权利要求5所述的方法，其中，所述将所述业务请求发送至重新分配的所述数据库进行处理的步骤包括：

获取连接池中对应于选择的所述数据库的各个连接的状态信息；

根据所述各个连接的状态信息，从至少一个可用连接中选择一个可用连接；

将选择的所述可用连接的状态从可用状态更改为不可用状态，并使用选择的所述连接将所述业务请求发送至选择的所述数据库进行处理。

7.根据权利要求6所述的方法，其中，在所述将所述业务请求发送至重新分配的所述数据库进行处理的步骤之后，所述方法还包括：

拦截重新分配的所述数据库通过选择的连接返回的、对所述业务请求的响应结果，并将拦截到的所述响应结果发送至发送所述业务请求的应用。

8.根据权利要求7所述的方法，其中，在所述拦截重新分配的所述数据库通过选择的连接返回的、对所述业务请求的响应结果的步骤之后，所述方法还包括：

将所述连接的状态从不可用状态更改为可用状态。

9.根据权利要求1所述的方法，其中，在所述判断数据库发生故障后，所述方法还包括：

按照设定规则向发生故障的所述数据库发送连接请求；

若接收到对所述连接请求的成功响应，则确定发生故障的所述数据库已恢复正常运行，在连接池中将所述已恢复正常运行的数据库对应的连接的状态设置为可用状态；

若未接收到对所述连接请求的成功响应，则确定所述发生故障的数据库未恢复正常运行，返回执行按照设定规则向发生故障的所述数据库发送连接请求的步骤。

10.根据权利要求1所述的方法，其中，所述业务请求处理方法应用于非分布式数据库系统。

11.根据权利要求1或10所述的方法，其中，所述业务请求处理方法应用于关系型数据库系统。

12.一种业务请求处理装置，所述业务请求处理装置包括：连接池生成模块，用于在拦截模块拦截应用装置向多个数据库装置发送的业务请求之前，根据所述多个数据库装置可支持的连接的信息，生成连接池，其中，所述连接池用于管理所述多个数据库装置可支持的连接；

拦截模块，用于拦截应用装置向数据库装置发送的业务请求；

发送模块，用于将所述业务请求发送至多个数据库装置中的一个当前状态为正常运行的数据库装置进行处理，并存储所述业务请求；

执行模块，用于当判断在所述业务请求的执行过程中，处理所述业务请求的数据库装置发生故障时，为所述业务请求重新分配一个当前状态为正常运行的数据库装置；

重发送模块，用于将所述业务请求发送至重新分配的所述数据库装置进行处理；

第一状态设置模块，用于在所述连接池生成模块根据所述多个数据库装置可支持的连接的信息，生成连接池之后，根据所述数据库装置的当前状态，将所述连接池中对应于各个数据库装置的各个连接设置为可用状态或不可用状态；

第二状态设置模块，用于当所述执行模块判断数据库装置发生故障时，将所述连接池中对应于发生故障的所述数据库装置的所有连接的连接状态设置为不可用状态。

13.根据权利要求12所述的业务请求处理装置，其中，所述执行模块判断在所述业务请求的执行过程中，处理所述业务请求的数据库装置发生故障时：

在已将所述业务请求发送至数据库装置进行处理后，接收到与所述数据库装置之间连接中断的消息之前，未拦截到所述数据库装置返回的、对所述业务请求的响应结果，则所述执行模块确定在所述业务请求的执行过程中，处理所述业务请求的数据库装置发生故障。

14.根据权利要求12所述的业务请求处理装置，其中，所述执行模块判断在所述业务请求的执行过程中，处理所述业务请求的数据库装置发生故障时：

在将所述业务请求发送至数据库装置进行处理后，在预定时间内未拦截到所述数据库装置返回的、对所述业务请求的响应结果，则所述执行模块确定在所述业务请求的执行过程中，处理所述业务请求的数据库装置发生故障。

15.根据权利要求12所述的业务请求处理装置，其中，所述发送模块包括：

数据库选择模块，用于从多个当前状态为正常运行的数据库装置中选择一个数据库装置，获取连接池中对应于选择的所述数据库装置的各个连接的状态信息；

可用连接选择模块，用于根据所述各个连接的状态信息，从至少一个可用连接中选择一个可用连接；以及

业务请求发送模块，用于将选择的所述可用连接的状态从可用状态更改为不可用状态，并使用选择的所述连接将所述业务请求发送至选择的所述数据库装置进行处理；

存储模块，用于存储所述业务请求。

16.根据权利要求12所述的业务请求处理装置，其中，所述执行模块为所述业务请求重新分配一个当前状态为正常运行的数据库装置时，获取所述多个数据库装置的当前状态；根据获取的所述多个数据库装置的当前状态，确定当前状态为正常运行的至少一个数据库装置；从所述至少一个当前状态为正常运行的数据库装置中选择一个数据库装置。

17.根据权利要求16所述的业务请求处理装置，其中，所述重发送模块包括：

连接状态获取信息，用于获取连接池中对应于选择的所述数据库装置的各个连接的状态信息；

可用连接选择模块，用于根据所述各个连接的状态信息，从至少一个可用连接中选择一个可用连接；

业务请求重发送模块，用于将选择的所述可用连接的状态从可用状态更改为不可用状态，并使用选择的所述连接将所述业务请求发送至选择的所述数据库装置进行处理。

18.根据权利要求17所述的业务请求处理装置，其中，所述业务请求处理装置还包括：

响应结果拦截模块，用于在所述重发送模块将所述业务请求发送至重新分配的所述数据库装置进行处理之后，拦截重新分配的所述数据库装置通过选择的连接返回的、对所述业务请求的响应结果，并将拦截到的所述响应结果发送至发送所述业务请求的应用装置。

19.根据权利要求18所述的业务请求处理装置，其中，所述业务请求处理装置还包括：

第三状态设置模块，用于在所述响应结果拦截模块拦截重新分配的所述数据库装置通过选择的连接返回的、对所述业务请求的响应结果之后，将所述连接的状态从不可用状态更改为可用状态。

20.根据权利要求12所述的业务请求处理装置，其中，所述业务请求处理装置还包括：

连接请求发送模块，用于在所述执行模块判断数据库装置发生故障后，按照设定规则向发生故障的所述数据库装置发送连接请求；

第一执行模块，用于若接收到对所述连接请求的成功响应，则确定发生故障的所述数据库装置已恢复正常运行，在连接池中将所述已恢复正常运行的数据库装置对应的连接的状态设置为可用状态；

第二执行模块，用于若未接收到对所述连接请求的成功响应，则确定所述发生故障的数据库装置未恢复正常运行，调用所述连接请求发送模块。

21.根据权利要求12所述的业务请求处理装置，其中，所述业务请求处理装置应用于非分布式数据库系统。

22.根据权利要求12或21所述的业务请求处理装置，其中，所述业务请求处理装置应用于关系型数据库系统。