CN106952085A - 一种数据存储与业务处理的方法及装置 - Google Patents

Abstract

本申请公开了一种数据存储和业务处理的方法及装置，该方法在数据存储时，针对每个用户，获取该用户的数据，将该用户的数据拆分成多个数据集合，并将多个数据集合分别存储在至少两个服务器中，在基于存储的数据执行业务处理时，服务器接收携带有用户标识以及业务所需数据的数据标识的业务处理请求，在本地保存的该用户标识对应的数据中，判断是否存在该数据标识对应的数据，若是，则获取本地保存的该数据标识对应的数据，并根据获取的数据执行业务，若否，则从其他的服务器中获取该数据标识对应的数据，并根据获取的数据执行业务，通过上述方法，即使某个服务器出现故障，用户仍可通过其他服务器中存储的数据来执行业务。

Description

一种数据存储与业务处理的方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种数据存储与业务处理的方法及装置。

背景技术

随着网络技术的不断发展，服务器可以为用户提供的业务也日趋多样化，如，服务器可为用户提供历史聊天记录查询业务。

目前，服务器在为用户提供业务之前，需要将用户的数据存储到服务器中，在现有技术中，服务器一般根据各用户的ID，将各用户分成N(N为正整数)组，并将每组内的用户对应的全部数据分别存储不同的服务器中，后续，服务器接收到用户发送的携带有用户ID的业务处理请求后，先在服务器中查询是否存在该用户ID对应的数据，如果存在该用户ID对应的数据，则直接获取该用户ID对应的数据，并根据获取的数据执行业务，如果不存在用户ID对应的数据，则将业务处理请求发送给其他服务器，使其他服务器根据用户ID对应的数据执行业务。

例如，服务器根据各用户的ID，将九个用户分成三组，每组包含三个用户，并将第一组包含的三个用户对应的历史聊天记录存储在服务器1中，将第二组包含的三个用户对应的历史聊天记录存储在服务器2中，将第三组包含的三个用户对应的历史聊天记录存储在服务器3中，后续，服务器1接收到用户发送的携带有用户ID的聊天记录查询业务请求时，在服务器1本地查询该用户ID对应的历史聊天记录，若查询到，则直接将查询到的历史聊天记录返回给用户，若未查询到，则将该聊天记录查询业务请求发送给服务器2和/或服务器3，使服务器2和/或服务器3查询该用户ID对应的历史聊天记录。

但是，在现有技术中，如果其中一个或几个服务器出现故障，则该服务器中存储的数据也就无法访问，也就是说，此时部分用户将无法正常执行业务。

发明内容

本申请实施例提供一种数据存储和业务处理的方法及装置，用以解决现有技术中当一个或几个服务器出现故障时，部分用户无法正常执行业务的问题。

本申请实施例提供的一种业务处理的方法，针对每个用户，该用户的数据分别存储在至少两个服务器中，所述方法包括：

服务器接收业务处理请求，其中，所述业务处理请求中携带有用户标识以及业务所需数据的数据标识；

在所述服务器本地保存的所述用户标识对应的数据中，判断是否存在所述数据标识对应的数据；

若是，则获取本地保存的所述数据标识对应的数据，并根据获取的数据执行业务；

若否，则从其他的服务器中获取所述数据标识对应的数据，并根据获取的数据执行业务。

本申请实施例提供的一种业务处理的方法，针对每个用户，该用户的总余额被拆分成多个子余额，并分别存储在至少两个服务器中，所述方法包括：

服务器接收业务处理请求，其中，所述业务处理请求中携带有用户标识以及业务所需的金额的金额量；

判断所述服务器本地保存的所述用户标识对应的子余额的余额量是否不小于所述金额量；

若是，则获取本地保存的所述金额量的子余额，根据获取的子余额执行业务；

若否，则从所述服务器本地以及其他的服务器中，获取所述金额量的子余额，并根据获取的子余额执行业务。

本申请实施例提供的一种数据存储的方法，所述方法包括：

针对每个用户，获取该用户的数据；

将该用户的数据拆分成包含的数据量相同的多个数据集合；

将所述多个数据集合分别存储在至少两个服务器中，并将该用户的用户标识、该用户的数据的数据总量、每个服务器的服务器标识、每个服务器中存储的数据集合的数据量存储在每个服务器中。

本申请实施例提供的一种数据存储的方法，所述方法包括：

针对每个用户，获取该用户的总余额；

将该用户的总余额平均拆分成多个子余额；

将所述多个子余额分别存储在至少两个服务器中，并将该用户的用户标识、该用户的总余额、每个服务器的服务器标识、每个服务器中存储的子余额的余额量存储在每个服务器中。

本申请实施例提供的一种业务处理的装置，针对每个用户，该用户的数据分别存储在至少两个服务器中，所述装置包括：

接收模块，用于接收业务处理请求，其中，所述业务处理请求中携带有用户标识以及业务所需数据的数据标识；

判断模块，用于在所述装置本地保存的所述用户标识对应的数据中，判断是否存在所述数据标识对应的数据；

执行模块，用于在所述判断模块的判断结果为是时，获取本地保存的所述数据标识对应的数据，并根据获取的数据执行业务；在所述判断模块的判断结果为否时，从其他的服务器中获取所述数据标识对应的数据，并根据获取的数据执行业务。

本申请实施例提供的一种业务处理的装置，针对每个用户，该用户的总余额被拆分成多个子余额，并分别存储在至少两个服务器中，所述装置包括：

接收模块，用于接收业务处理请求，其中，所述业务处理请求中携带有用户标识以及业务所需的金额的金额量；

判断模块，用于判断所述装置本地保存的所述用户标识对应的子余额的余额量是否不小于所述金额量；

执行模块，用于在所述判断模块的判断结果为是时，获取本地保存的所述金额量的子余额，根据获取的子余额执行业务；在所述判断模块的判断结果为否时，从所述装置本地以及其他的服务器中，获取所述金额量的子余额，并根据获取的子余额执行业务。

本申请实施例提供的一种数据存储的装置，所述装置包括：

获取模块，用于针对每个用户，获取该用户的数据；

拆分模块，用于将该用户的数据拆分成包含的数据量相同的多个数据集合；

存储模块，用于将所述多个数据集合分别存储在至少两个服务器中，并将该用户的用户标识、该用户的数据的数据总量、每个服务器的服务器标识、每个服务器中存储的数据集合的数据量存储在每个服务器中。

本申请实施例提供的一种数据存储的装置，所述装置包括：

获取模块，用于针对每个用户，获取该用户的总余额；

拆分模块，用于将该用户的总余额平均拆分成多个子余额；

存储模块，用于将所述多个子余额分别存储在至少两个服务器中，并将该用户的用户标识、该用户的总余额、每个服务器的服务器标识、每个服务器中存储的子余额的余额量存储在每个服务器中。

本申请实施例提供一种数据存储和业务处理的方法及装置，该方法在数据存储时，针对每个用户，获取该用户的数据，将该用户的数据拆分成多个数据集合，并将多个数据集合分别存储在至少两个服务器中，在基于存储的数据执行业务处理时，服务器接收携带有用户标识以及业务所需数据的数据标识的业务处理请求，在本地保存的该用户标识对应的数据中，判断是否存在该数据标识对应的数据，若是，则获取本地保存的该数据标识对应的数据，并根据获取的数据执行业务，若否，则从其他的服务器中获取该数据标识对应的数据，并根据获取的数据执行业务，通过上述方法，即使某个服务器出现故障，用户仍可通过其他服务器中存储的数据来执行业务。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的数据存储的过程；

图2A为本申请实施例提供的第一种数据存储的***的示意图；

图2B为本申请实施例提供的第二种数据存储的***的示意图；

图3为本申请实施例提供的业务处理的过程；

图4为本申请实施例提供余额存储的的过程；

图5为本申请实施例提供的支付处理的过程；

图6为本申请实施例提供的数据存储的装置结构示意图；

图7为本申请实施例提供的业务处理的装置结构示意图；

图8为本申请实施例提供的余额存储的装置结构示意图；

图9为本申请实施例提供的支付处理的装置结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

图1为本申请实施例提供的数据存储的过程，具体包括以下步骤：

S101：针对每个用户，获取该用户的数据。

在本申请实施例中，整个数据存储的***可以如图2A所示，其中，该***中执行步骤S101～步骤S103的是存储用户数据的至少两个服务器中的任意一个服务器来完成。另外，整个数据存储的***也可如图2B所示，其中，该***中执行步骤S101～步骤S103的是存储用户数据的至少两个服务器以外的中间设备来完成。下面仅以如图2B所示的中间设备来执行步骤S101～S103为例进行说明。

在实际应用中，服务器在为用户提供业务之前，需要将用户的数据存储在服务器中，因此，在本申请中，中间设备首先针对每个用户，获取该用户的数据。

例如，假设服务器可为用户A提供历史聊天记录查询业务，则首先由中间设备获取用户A的历史聊天记录(即，数据)。

S102：将该用户的数据拆分成包含的数据量相同的多个数据集合。

在本申请实施例中，由于任何数据的数据属性通常都包含数据量，因此，中间设备在将获取到的用户的数据拆分成多个数据集合时，可以根据数据量来对该用户的数据进行拆分，又由于后续在进行业务处理时，用户发送的业务处理请求可能被发送到服务器中的任意一个，而每个服务器最好都能够从本地存储的数据集合中获取业务处理所需的数据，因此，在根据数据量来对该用户的数据进行拆分后，所得到的每个数据集合中包含的数据量是相同的。

当然，本申请也提供了另一种拆分方式，具体的，拆分后的任意两个数据集合所包含的数据量之差在预设的阈值之内，所述阈值可以根据实际情况来设定。

另外，还需要说明的是，拆分成的数据集合的数量，可以根据要存储该用户的数据的服务器的数量而定，拆分成的数据集合的数量不小于要存储该用户的数据的服务器的数量。

延续上例，假设用户A的历史聊天记录有99条，共有3个服务器，采用将该用户的数据拆分成包含的数据量相同的多个数据集合的拆分方式，则中间设备可将用户A的历史聊天记录拆分成均包含33条历史聊天记录的数据集合1、数据集合2、数据集合3。

S103：将所述多个数据集合分别存储在至少两个服务器中，并将该用户的用户标识、该用户的数据的数据总量、每个服务器的服务器标识、每个服务器中存储的数据集合的数据量存储在每个服务器中。

在本申请实施例中，中间设备在将用户的数据拆分成多个数据集合后，可将要存储的多个数集合分别发送给至少两个服务器，每个服务器中存储至少一个数据集合。

为了方便后续在至少两个服务器中查询用户的数据，并根据查询到的用户的数据执行业务，在本申请中，服务器除了在本地保存数据集合以外，还需要保存该用户的用户标识、该用户的数据的数据总量、每个服务器的服务器标识、每个服务器中存储的数据集合的数据量，其中，每个服务器的服务器标识与该服务器中存储的数据集合的数据量具有对应关系，也就是说，由该对应关系就可以知道每个服务器存储的数据集合的数据量的情况。

延续上例，服务器1除了存储包含33条历史聊天记录的数据集合1以外，还可存储如表1所示的数据：

数据名	数据值
		用户标识	用户A
用户的数据的数据总量	99条历史聊天记录
		服务器1的标识	服务器1
服务器2的标识	服务器2
		服务器3的标识	服务器3
服务器2中存储的数据集合2的数据量	33条历史聊天记录
		服务器3中存储的数据集合3的数据量	33条历史聊天记录

表1

上述表1中所示的数据均可由中间设备发送给各服务器保存。

通过上述方法，即使某个服务器出现故障，用户仍可通过其他服务器中存储的数据来执行业务。

另外，当图1所示的步骤S101～S103由图2A所示的任一服务器来执行时，可由该服务器获取用户的全部数据，并拆分成多个数据集合，再保存至少一个数据集合，最后将其余的数据集合分发给其他的服务器存储，与此同时，该服务器可将该用户的用户标识、该用户的数据的数据总量、每个服务器的服务器标识、每个服务器中存储的数据集合的数据量存储在本地后，再将上述数据发送给其他的服务器存储。

在本申请实施例中，在通过上述步骤S101～S103对用户的数据进行存储后，后续，服务器可根据存储在不同服务器中的数据执行业务，整个业务处理流程如图3所示。

图3为本申请实施例提供的业务处理的过程，具体包括以下步骤：

S301：服务器接收业务处理请求。

在本申请实施例中，由于用户的数据是分别存储在不同的服务器中的，因此，用户通过终端发送的业务处理请求是任意发送给多个服务器中的一个，所述业务处理请求中携带有用户标识以及业务所需数据的数据标识，用于告知服务器需要对哪个用户的哪些数据进行处理。

S302：在所述服务器本地保存的所述用户标识对应的数据中，判断是否存在所述数据标识对应的数据，若是，执行步骤S303，若否，执行步骤S304。

在本申请实施例中，服务器接收到用户发送的业务处理请求后，根据业务处理请求中携带的用户标识，确定出该用户对应的数据集合，并根据业务处理请求中携带的数据标识，确定出到底是哪些数据集合是执行本次业务所需的数据集合，如果本地保存的数据集合中存在数据标识对应的数据，也就是说，存在执行本次业务所需的数据集合，则执行步骤S303，如果不存在数据标识对应的数据，则执行步骤S304。

S303：获取本地保存的所述数据标识对应的数据，并根据获取的数据执行业务。

S304：从其他的服务器中获取所述数据标识对应的数据，并根据获取的数据执行业务。

在本申请实施例中，服务器在确定出本地不存在数据标识对应的数据后，可直接向其他服务器发送数据获取请求，以此从其他服务器中获取到数据标识对应的数据，并根据获取的数据执行业务，其中，所述数据获取请求中携带有用户标识以及数据标识。

通过上述方法，当某个服务器出现故障时，用户保存在该服务器中数据不能被使用，但是，用户保存在其他服务器中的数据还可以使用，而执行本次业务所需的数据就很可能保存在其他服务器中，这样本次业务依然能够顺利的执行，而现有技术中，存储该用户的服务器发生故障，则本次业务一定不能被执行，相比于现有技术，很大程度上提高了业务被执行的可能性。

在实际应用中，服务器在执行某些业务时，只需要根据数据的数据量来执行业务，因此，业务处理请求中携带的业务所需数据的数据标识具体可以是业务所需数据的数据量，后续，服务器根据业务处理请求中携带的业务所需数据的数据量，判断该服务器本地保存的该用户标识对应的数据的数据量是否不小于该业务所需数据的数据量，若是，则确定该服务器本地存在该数据标识对应的数据，否则，确定该服务器本地不存在该数据标识对应的数据。

进一步的，由于存储该用户的数据不仅仅只有上述一个服务器，其他服务器中也存储有该用户的数据，因此，在本申请中，如果该服务器本地不存在该数据标识对应的数据，也就是说，该服务器本地保存的该用户标识对应的数据的数据量小于该业务所需数据的数据量，可以从其他服务器中获取该数据标识对应的数据，具体可以是，确定该业务所需数据的数据量与该服务器本地保存的该用户标识对应的数据的数据量的差值，从其他的服务器中获取该用户标识对应的、数据量为该差值的数据。

另外，本申请给出了从其他的服务器中获取该用户标识对应的、数据量为该差值的数据的一种具体的实施方式：按照其他的每个服务器中所述用户标识对应的数据的数据量从大到小的顺序，依次获取所述用户标识对应的数据，直至获取的数据量为所述差值为止。

在实际应用中，有可能出现其他服务器中存储的该用户标识对应的数据的数据量总和小于确定出的差值，因此，在本申请中，服务器在从其他的服务器中获取该用户标识对应的、数据量为该差值的数据之前，可先判断所有服务器存储的该用户标识对应的数据的数据量之和是否不小于业务所需数据的数据量，若是，则可从其他的服务器中获取数据，否则，说明该用户的数据量不足以执行本次业务，因此可直接拒绝执行该业务。

最后，服务器对获取到的数据执行业务处理后，需要更新本地保存的该用户标识对应的数据的数据量，也就是说，服务器更新该用户标识对应的数据的数据总量、本地保存该用户标识对应的数据的数据量以及其他的每个服务器保存的该用户标识对应的数据的数据量，由于服务器在本地保存的该用户标识对应的数据的数据量小于用户发送的业务请求中携带的数据量，则会从其他服务器中获取到该用户标识对应的数据的数据量，因此，服务器在更新本地保存的该用户标识对应的数据的数据量时，也需要向其他服务器发送更新请求，使得其他服务器根据更新请求中携带的该用户标识对应的数据的数据总量、本地保存所述用户标识对应的数据的数据量、其他的每个服务器保存的该用户标识对应的数据的数据量对本地保存的数据进行更新。

在此需要说明的是，以上业务处理中涉及到的服务器都是正常运行的服务器，如果某一服务器发生故障，该服务器接收不到用户发送的业务处理请求以及其他服务器向该服务器发送的数据获取请求，也就是说，对于接收到业务处理请求的服务器来说，该服务器可监测其他服务器是否出现故障，并在从其他的服务器中获取数据时，可从其他未出现故障的服务器中获取数据。

以上本申请实施例中提供的业务处理的方法，由于在实际应用中，服务器在执行支付、转账等与金额有关的业务时，需要根据金额的金额量(即，数据的数据量)来执行业务，因此，为了更清楚的阐述本方案数据存储以及业务处理的方法，下面以数据为余额为例进行详细说明。

图4为本申请实施例提供的余额存储的过程，具体包括以下步骤：

S401：针对每个用户，获取该用户的总余额。

在实际应用中，用户使用支付账户中的余额进行购买、支付等业务已经变得越来越普遍，在通过余额执行业务之前，需要先将用户的余额存储在服务器中，因此，本申请中，针对每个用户，服务器首先获取该用户的总余额。

例如，假设服务器为用户A提供余额支付业务，则中间设备首先获取用户A的总余额：300元。

S402：将该用户的总余额平均拆分成多个子余额。

延续上例，假设采用平均拆分的方式，要存储用户A的余额的服务器数量为3个，则中间设备可将该用户A的总余额平均拆分成三个子余额，即，子余额1为100元、子余额2为100元、子余额3为100元。

S403：将所述多个子余额分别存储在至少两个服务器中，并将该用户的用户标识、该用户的总余额、每个服务器的服务器标识、每个服务器中存储的子余额的余额量存储在每个服务器中。

在本申请实施例中，为了方便后续在至少两个服务器中查询用户的子余额，并根据查询到的用户的子余额执行支付业务，因此，可不仅将多个子余额分别存储在至少两个服务器中，还可将该用户的用户标识、该用户的总余额、每个服务器的服务器标识、每个服务器中存储的子余额的余额量存储在服务器中，并将存储在本地的上述数据发送给其他服务器，使其他服务器将上述数据存储在各自的本地。

延续上例，服务器1除了存储包含余额量为100元的子余额1以外，还可存储如表2所示的数据：

表2

上述表2中所示的数据均可由中间设备发送给各服务器保存。

通过上述方法，即使某个服务器出现故障，用户仍可通过其他服务器中存储的子余额来执行支付业务处理。

在本申请实施例中，在通过上述步骤S401～S403对用户的总余额进行存储后，后续，服务器可根据存储在不同服务器中的用户的子余额执行支付业务，整个支付处理流程如图5所示。

图5为本申请实施例提供的支付处理的过程，具体包括以下步骤：

S501：服务器接收业务处理请求。

在本申请实施例中，所述业务处理请求携带有用户标识以及业务所需的金额的金额量，用于告知服务器需要对哪个用户进行支付以及本次执行所需多少金额的金额量。

延续上例，用户A在购买一件商品时使用余额支付业务，因此，用户A通过终端向服务器发送支付业务处理请求，该支付业务处理请求中携带有用户A的用户标识以及支付业务所需的金额的金额量120元，假设接收该支付业务处理请求的是服务器1。

S502：判断所述服务器本地保存的所述用户标识对应的子余额的余额量是否不小于所述金额量，若是，则执行步骤S503，若否，则执行步骤S504。

延续上例，服务器1接收到支付业务处理请求后，根据用户A的用户标识查找到本地保存的用户A对应的子余额的余额量为100元，并根据支付业务所需的金额的金额量120元，判断本地保存的用户A对应的子余额的余额量小于支付业务所需的金额的金额量，则执行步骤S504，进行后续的处理。

S503：获取本地保存的所述金额量的子余额，根据获取的子余额执行业务。

S504：从所述服务器本地以及其他的服务器中，获取所述金额量的子余额，并根据获取的子余额执行业务。

在本申请实施例中，服务器在判断出本地保存的该用户标识对应的子余额小于业务所需的金额的金额量时，说明无法基于本地保存的子余额完成业务处理，因此，可以从其他服务器中获取该用户标识对应的子余额，并根据从服务器本地以及其他的服务器中获取到的子余额，执行业务处理。

具体的，服务器可确定业务处理请求中携带的金额量与该服务器本地保存的该用户标识对应的子余额的余额量的差值，获取该服务器本地保存的所述用户标识对应的全部子余额，并从其他的服务器中获取余额量为该差值的子余额，并根据从服务器本地以及其他的服务器中获取到的与金额量等同的子余额，执行业务处理。

在此需要说明的是，在从其他服务器中获取子余额时，具体可从其他未出现故障的服务器中获取子余额。

延续上例，假设服务器1监测到服务器3发生故障，而服务器2是正常运行的，因此，服务器1确定业务处理请求中携带的金额量120元与服务器1本地保存的用户A对应的子余额的余额量100元的差值，即，20元，将携带有差值为20元的数据获取请求发送给正常运行的服务器2，并接收服务器2返回的子余额的余额量20元，与此同时，获取服务器1本地保存的用户A对应的全部子余额100元，并根据从服务器1本地获取的100元以及服务器2中获取的20元，执行余额支付处理。

通过上述方法，当某个服务器出现故障时，用户保存在该服务器中子余额不能被使用，但是，用户保存在其他服务器中的子余额还可以使用，只要未出现故障的服务器中保存的该用户的子余额之和大于业务所需金额的金额量，本次业务就能够顺利的执行，而现有技术中，一般存储该用户的余额的服务器发生故障，则本次支付业务一定不能被执行，相比于现有技术，很大程度上提高了支付业务被执行的可能性。

进一步的，在从其他服务器中获取余额量为该差值的子余额时，可采用以下方式：按照其他的每个服务器中该用户标识对应的子余额的余额量从大到小的顺序，依次获取该用户标识对应的子余额，直至获取的余额量为所述差值为止。

最后，服务器对获取到的子余额执行业务处理后，需要更新本地保存的该用户标识对应的子余额的余额量，也就是说，服务器更新该服务器更新该用户标识对应的总余额、该服务器本地保存该用户标识对应的子余额的余额量、其他的每个服务器保存的该用户标识对应的子余额的余额量，由于服务器在本地保存的该用户标识对应的子余额的余额量小于用户发送的业务请求中携带的业务所需的金额的金额量，则会从其他服务器中获取到该用户标识对应的子余额的余额量，因此，服务器在更新本地保存的该用户标识对应的子余额的余额量时，也需要向其他服务器发送更新请求，使得其他服务器根据更新请求中携该用户标识对应的总余额、该服务器本地保存该用户标识对应的子余额的余额量、其他的每个服务器保存的该用户标识对应的子余额的余额量对本地保存的数据进行更新。

在此需要说明的是，假设接收业务处理请求的服务器以外的所有的其他服务器中存储的子余额的余额总量大于确定出的差值，但是，如果所有的其他服务器中的某个服务器出现故障后，剩余的其他正常的服务器中存储的子余额的余额总量小于确定出的差值，则不能为用户执行本次执行支付业务处理，则此时可向用户返回支付通知，所述支付通知用于告知用户的总余额没有发生任何变化，只是由于某个服务器出现故障，导致用户存储的余额无法用于支付业务，在服务器恢复正常运行之后，用户的余额可继续用于支付业务。

例如，一共有3个服务器，服务器1存储了30元，服务器2存储了30元，服务器3存储了30元，此时用户甲需要购买的商品价格为70元，假设服务器2发生了故障，服务器1接收到用户发送的支付业务处理请求后，确定出正常运行的其他服务器(即，服务器3)中存储的子余额的余额量小于确定出的差值(即，40元)，因此，服务器1向用户发送支付通知，告知用户甲，总余额仍为90，只是由于服务器2发生了故障，导致用户存储的90元的余额无法用于支付业务，在服务器2恢复正常运行之后，用户的余额可继续用于支付业务。

在本申请中，由于服务器在本地保存的子余额不足的情况下是需要从其他正常运行的服务器中获取到子余额，再根据本地保存的子余额与获取到的子余额执行支付业务处理，这涉及到服务器之间的转账操作，服务器之间的转账操作也势必会降低执行业务的处理效率，因此，在本申请中，对于每个用户而言，可判断该用户在每个服务器中存储的子余额的平均余额量是否大于一定的阈值，若是，则可对该用户使用本申请如图4和图5所示的余额存储以及支付处理的方法，若否，则可不对该用户使用如图4和图5所示的余额存储以及支付处理的方法。

针对上述提到的判断用户是否可使用如图4和图5所示的余额存储以及支付处理的方法，本申请提供了一种具体的实施方式，具体的，如果该用户存储在每个服务器中的子余额的平均余额量大于用户执行单笔支付业务所需要的平均金额的金额量，则该用户可使用如图4和图5所示的余额存储以及支付处理的方法，这样可以有效的避免了服务器之间的转账操作。其中，用户执行单笔支付业务所需要的平均金额的金额量可根据该用户的历史支付业务的金额来确定。

以上为本申请实施例提供的数据存储的方法、业务处理的方法、余额存储的方法以及支付处理的方法，基于同样的思路，本申请实施例提供四种装置，即，数据存储的装置，如图6所示，业务处理的装置，如图7所示，余额存储的装置，如图8所示，支付处理的装置，如图9所示。

图6为本申请实施例提供的数据存储的装置结构示意图，所述装置包括：

获取模块601，用于针对每个用户，获取该用户的数据；

拆分模块602，用于将该用户的数据拆分成包含的数据量相同的多个数据集合；

存储模块603，用于将所述多个数据集合分别存储在至少两个服务器中，并将该用户的用户标识、该用户的数据的数据总量、每个服务器的服务器标识、每个服务器中存储的数据集合的数据量存储在每个服务器中。

图7为本申请实施例提供的业务处理的装置结构示意图，针对每个用户，该用户的数据分别存储在至少两个服务器中，所述装置包括：

接收模块701，用于接收业务处理请求，其中，所述业务处理请求中携带有用户标识以及业务所需数据的数据标识；

判断模块702，用于在所述装置本地保存的所述用户标识对应的数据中，判断是否存在所述数据标识对应的数据；

执行模块703，用于在所述判断模块702的判断结果为是时，获取本地保存的所述数据标识对应的数据，并根据获取的数据执行业务；在所述判断模块702的判断结果为否时，从其他的服务器中获取所述数据标识对应的数据，并根据获取的数据执行业务。

所述业务所需数据的数据标识具体包括：所述业务所需数据的数据量；

所述判断模块702具体用于，判断所述装置本地保存的所述用户标识对应的数据的数据量是否不小于所述业务所需数据的数据量；

所述执行模块703具体用于，在所述判断模块702的判断结果为是时，确定所述装置本地存在所述数据标识对应的数据；在所述判断模块702的判断结果为否时，确定所述装置本地不存在所述数据标识对应的数据。

所述执行模块703具体用于，确定所述业务所需数据的数据量与所述装置本地保存的所述用户标识对应的数据的数据量的差值，从其他的服务器中获取所述用户标识对应的、数据量为所述差值的数据。

所述执行模块703具体用于，按照其他的每个服务器中所述用户标识对应的数据的数据量从大到小的顺序，依次获取所述用户标识对应的数据，直至获取的数据量为所述差值为止。

所述装置还包括：

更新模块704，用于所述装置更新所述用户标识对应的数据的数据总量、所述装置本地保存所述用户标识对应的数据的数据量、其他的每个服务器保存的所述用户标识对应的数据的数据量。

图8为本申请实施例提供的余额存储的装置结构示意图，所述装置包括：

获取模块801，用于针对每个用户，获取该用户的总余额；

拆分模块802，用于将该用户的总余额平均拆分成多个子余额；

存储模块803，用于将所述多个子余额分别存储在至少两个服务器中，并将该用户的用户标识、该用户的总余额、每个服务器的服务器标识、每个服务器中存储的子余额的余额量存储在每个服务器中。

图9为本申请实施例提供的支付处理的装置结构示意图，针对每个用户，该用户的总余额被拆分成多个子余额，并分别存储在至少两个服务器中，所述装置包括：

接收模块901，用于接收业务处理请求，其中，所述业务处理请求中携带有用户标识以及业务所需的金额的金额量；

判断模块902，用于判断所述装置本地保存的所述用户标识对应的子余额的余额量是否不小于所述金额量；

执行模块903，用于在所述判断模块902的判断结果为是时，获取本地保存的所述金额量的子余额，根据获取的子余额执行业务；在所述判断模块902的判断结果为否时，从所述装置本地以及其他的服务器中，获取所述金额量的子余额，并根据获取的子余额执行业务。

所述执行模块903具体用于，确定所述金额量与所述装置本地保存的所述用户标识对应的子余额的余额量的差值，获取所述装置本地保存的所述用户标识对应的全部子余额，并从其他的服务器中获取余额量为所述差值的子余额。

所述执行模块903具体用于，按照其他的每个服务器中所述用户标识对应的子余额的余额量从大到小的顺序，依次获取所述用户标识对应的子余额，直至获取的余额量为所述差值为止。

所述装置还包括：

更新模块904，用于所述装置更新所述用户标识对应的总余额、所述装置本地保存所述用户标识对应的子余额的余额量、其他的每个服务器保存的所述用户标识对应的子余额的余额量。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、***或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (22)

1.一种业务处理的方法，其特征在于，针对每个用户，该用户的数据分别存储在至少两个服务器中，所述方法包括：

服务器接收业务处理请求，其中，所述业务处理请求中携带有用户标识以及业务所需数据的数据标识；

在所述服务器本地保存的所述用户标识对应的数据中，判断是否存在所述数据标识对应的数据；

若是，则获取本地保存的所述数据标识对应的数据，并根据获取的数据执行业务；

若否，则从其他的服务器中获取所述数据标识对应的数据，并根据获取的数据执行业务。

2.如权利要求1所述的方法，其特征在于，所述业务所需数据的数据标识具体包括：所述业务所需数据的数据量；

在所述服务器本地保存的所述用户标识对应的数据中，判断是否存在所述数据标识对应的数据，具体包括：

判断所述服务器本地保存的所述用户标识对应的数据的数据量是否不小于所述业务所需数据的数据量；

若是，则确定所述服务器本地存在所述数据标识对应的数据；

否则，确定所述服务器本地不存在所述数据标识对应的数据。

3.如权利要求2所述的方法，其特征在于，从其他的服务器中获取所述数据标识对应的数据，具体包括：

确定所述业务所需数据的数据量与所述服务器本地保存的所述用户标识对应的数据的数据量的差值；

从其他的服务器中获取所述用户标识对应的、数据量为所述差值的数据。

4.如权利要求3所述的方法，其特征在于，从其他的服务器中获取所述用户标识对应的、数据量为所述差值的数据，具体包括：

按照其他的每个服务器中所述用户标识对应的数据的数据量从大到小的顺序，依次获取所述用户标识对应的数据，直至获取的数据量为所述差值为止。

5.如权利要求2～4任一所述的方法，其特征在于，所述方法还包括：

所述服务器更新所述用户标识对应的数据的数据总量、所述服务器本地保存所述用户标识对应的数据的数据量、其他的每个服务器保存的所述用户标识对应的数据的数据量。

6.一种业务处理的方法，其特征在于，针对每个用户，该用户的总余额被拆分成多个子余额，并分别存储在至少两个服务器中，所述方法包括：

服务器接收业务处理请求，其中，所述业务处理请求中携带有用户标识以及业务所需的金额的金额量；

判断所述服务器本地保存的所述用户标识对应的子余额的余额量是否不小于所述金额量；

若是，则获取本地保存的所述金额量的子余额，根据获取的子余额执行业务；

若否，则从所述服务器本地以及其他的服务器中，获取所述金额量的子余额，并根据获取的子余额执行业务。

7.如权利要求6所述的方法，其特征在于，从所述服务器本地以及其他的服务器中，获取所述金额量的子余额，具体包括：

确定所述金额量与所述服务器本地保存的所述用户标识对应的子余额的余额量的差值；

获取所述服务器本地保存的所述用户标识对应的全部子余额，并从其他的服务器中获取余额量为所述差值的子余额。

8.如权利要求7所述的方法，其特征在于，从其他的服务器中获取余额量为所述差值的子余额，具体包括：

按照其他的每个服务器中所述用户标识对应的子余额的余额量从大到小的顺序，依次获取所述用户标识对应的子余额，直至获取的余额量为所述差值为止。

9.如权利要求6～8任一所述的方法，其特征在于，所述方法还包括：

所述服务器更新所述用户标识对应的总余额、所述服务器本地保存所述用户标识对应的子余额的余额量、其他的每个服务器保存的所述用户标识对应的子余额的余额量。

10.一种数据存储的方法，其特征在于，所述方法包括：

针对每个用户，获取该用户的数据；

将该用户的数据拆分成包含的数据量相同的多个数据集合；

将所述多个数据集合分别存储在至少两个服务器中，并将该用户的用户标识、该用户的数据的数据总量、每个服务器的服务器标识、每个服务器中存储的数据集合的数据量存储在每个服务器中。

11.一种数据存储的方法，其特征在于，所述方法包括：

针对每个用户，获取该用户的总余额；

将该用户的总余额平均拆分成多个子余额；

将所述多个子余额分别存储在至少两个服务器中，并将该用户的用户标识、该用户的总余额、每个服务器的服务器标识、每个服务器中存储的子余额的余额量存储在每个服务器中。

12.一种业务处理的装置，其特征在于，针对每个用户，该用户的数据分别存储在至少两个服务器中，所述装置包括：

接收模块，用于接收业务处理请求，其中，所述业务处理请求中携带有用户标识以及业务所需数据的数据标识；

判断模块，用于在所述装置本地保存的所述用户标识对应的数据中，判断是否存在所述数据标识对应的数据；

执行模块，用于在所述判断模块的判断结果为是时，获取本地保存的所述数据标识对应的数据，并根据获取的数据执行业务；在所述判断模块的判断结果为否时，从其他的服务器中获取所述数据标识对应的数据，并根据获取的数据执行业务。

13.如权利要求12所述的装置，其特征在于，所述业务所需数据的数据标识具体包括：所述业务所需数据的数据量；

所述判断模块具体用于，判断所述装置本地保存的所述用户标识对应的数据的数据量是否不小于所述业务所需数据的数据量；

所述执行模块具体用于，在所述判断模块的判断结果为是时，确定所述装置本地存在所述数据标识对应的数据；在所述判断模块的判断结果为否时，确定所述装置本地不存在所述数据标识对应的数据。

14.如权利要求13所述的装置，其特征在于，所述执行模块具体用于，确定所述业务所需数据的数据量与所述装置本地保存的所述用户标识对应的数据的数据量的差值，从其他的服务器中获取所述用户标识对应的、数据量为所述差值的数据。

15.如权利要求14所述的装置，其特征在于，所述执行模块具体用于，按照其他的每个服务器中所述用户标识对应的数据的数据量从大到小的顺序，依次获取所述用户标识对应的数据，直至获取的数据量为所述差值为止。

16.如权利要求13～15任一所述的装置，其特征在于，所述装置还包括：

更新模块，用于所述装置更新所述用户标识对应的数据的数据总量、所述装置本地保存所述用户标识对应的数据的数据量、其他的每个服务器保存的所述用户标识对应的数据的数据量。

17.一种业务处理的装置，其特征在于，针对每个用户，该用户的总余额被拆分成多个子余额，并分别存储在至少两个服务器中，所述装置包括：

接收模块，用于接收业务处理请求，其中，所述业务处理请求中携带有用户标识以及业务所需的金额的金额量；

判断模块，用于判断所述装置本地保存的所述用户标识对应的子余额的余额量是否不小于所述金额量；

执行模块，用于在所述判断模块的判断结果为是时，获取本地保存的所述金额量的子余额，根据获取的子余额执行业务；在所述判断模块的判断结果为否时，从所述装置本地以及其他的服务器中，获取所述金额量的子余额，并根据获取的子余额执行业务。

18.如权利要求17所述的装置，其特征在于，所述执行模块具体用于，确定所述金额量与所述装置本地保存的所述用户标识对应的子余额的余额量的差值，获取所述装置本地保存的所述用户标识对应的全部子余额，并从其他的服务器中获取余额量为所述差值的子余额。

19.如权利要求18所述的装置，其特征在于，所述执行模块具体用于，按照其他的每个服务器中所述用户标识对应的子余额的余额量从大到小的顺序，依次获取所述用户标识对应的子余额，直至获取的余额量为所述差值为止。

20.如权利要求17～19任一所述的装置，其特征在于，所述装置还包括：

更新模块，用于所述装置更新所述用户标识对应的总余额、所述装置本地保存所述用户标识对应的子余额的余额量、其他的每个服务器保存的所述用户标识对应的子余额的余额量。

21.一种数据存储的装置，其特征在于，所述装置包括：

获取模块，用于针对每个用户，获取该用户的数据；

拆分模块，用于将该用户的数据拆分成包含的数据量相同的多个数据集合；

存储模块，用于将所述多个数据集合分别存储在至少两个服务器中，并将该用户的用户标识、该用户的数据的数据总量、每个服务器的服务器标识、每个服务器中存储的数据集合的数据量存储在每个服务器中。

22.一种数据存储的装置，其特征在于，所述装置包括：

获取模块，用于针对每个用户，获取该用户的总余额；

拆分模块，用于将该用户的总余额平均拆分成多个子余额；

存储模块，用于将所述多个子余额分别存储在至少两个服务器中，并将该用户的用户标识、该用户的总余额、每个服务器的服务器标识、每个服务器中存储的子余额的余额量存储在每个服务器中。