一种数据存储的方法及装置与流程

本申请涉及信息技术领域，尤其涉及一种数据存储的方法及装置。

背景技术：

随着信息化社会的发展，人们越来越依赖于网络执行各种业务，而提供业务的网络服务提供商也呈现爆发式的增长。对于服务提供商来说，通常采用应用服务器和数据库组合的形式来提供服务，其中，应用服务器用于进行数据处理，数据库用于存储数据，其结构可如图1a所示。

图1a为采用应用服务器和数据库来执行业务的系统结构示意图。其中，可见应用服务器101和数据库102均有多个，即采用分布式应用服务器以及分布式数据库来执行业务。并且，由配置中心103向各应用服务器发放任务，由数据库管理中心104向数据库中各分库发放任务。

其中，对于服务提供商来说，数据库中存储的任一数据均可以按照该数据后续可执行的操作，划分为变更类数据以及固定类数据。其中，变更类数据在产生并存储于数据库(即，写入)后，仍然可以根据后续业务需求被调用、查询以及变更(如，账户名、账户密码、账户余额等等)，而固定类数据在产生并存储于数据库后，仅可以被调用和查询，而无法再进行变更(如，单据信息、日志数据等)。

另外，对于服务提供商来说，通常用户在单位时间内执行业务的数量是不断变化、时刻波动的。由于日常的业务量波动较小，所以应用服务器和数据库的设备冗余便足以处理日常业务量波动时增加的业务量，但是由于在实际运行中还会出现可预计的业务量剧增的状况(如，春运期间售票服务提供商的接收到的业务量出现剧增，或者服务提供商因为提供优惠政策导致的接收到的业务量剧增)，而在业务量剧增情况下应用服务器和数据库需要处理业务量可能会增长至日常业务量的几倍甚至十几倍，所以此时该应用服务器和数据库的设备冗余就不足以处理业务量剧增时增加的业务量，从而导致业务积压，甚至会导致应用服务器和数据库的崩溃、无法正常执行业务。

于是，在现有技术中为了避免上述情况的发生，通常采用在出现业务量剧增的情况之前，临时对该应用服务器和数据库进行扩容的方式来解决这一问题，同时避免日常运行时，由于业务量相对较少而导致扩容增加的该应用服务器和数据库空闲，导致资源浪费的情况，如图1b所示。

图1b为对应用服务器和数据库进行扩容后执行业务的系统结构示意图。

具体的，该临时扩容的方法通常分为对应用服务器的扩容以及对数据库的扩容。其中，当对应用服务器扩容时，仅需在待扩容应用服务器105中部署好对应的应用程序代码并启动应用，再将该待扩容应用服务器加入配置中心，使该待扩容应用服务器105可以用于处理业务即可，可以做到简单、灵活的扩容。

但是，现有技术在对数据库进行扩容时，无论数据库中存储的是变更类数据还是固定类数据，均需要将原有数据库102中的数据同步到待扩容数据库106中。而由于数据库通常为分布式数据库，即，原有数据库102和待扩容数据库106中均包含多个分库，并且由于该待扩容数据库106在单位时间内可处理的业务量通常远大于该原有数据库102，所以该原有数据库102和待扩容数据库106中的分库的数量一般是不一致的(如，原有数据库包含10个分库，而扩容数据库包含100个分库)，这就导致在增加该待扩容数据库106时，无法通过数据库自身的同步机制来保证两个数据库中的数据的一致性，而需要先停止该原有数据库102的写操作(即，对处理业务产生的数据的存储操作)，之后再将该原有数据库102中的数据同步至该待扩容数据库106中，在检查数据同步无误后，最后将该原有数据库102的读写等操作转移至该待扩容数据库106中，完成对该数据库的扩容。

可见，现有技术中在对数据库进行扩容时，需要停止原有数据库的写入操作，导致业务无法正常进行、数据库扩容成本增加的问题。

技术实现要素：

本申请实施例提供一种数据存储的方法，用于解决在采用现有技术在对数据库进行扩容时，需要停止原有数据库的写入操作，等待待扩容数据库与原有数据库的数据同步，导致业务无法正常执行、数据库扩容成本增加的问题。

本申请实施例提供一种数据存储的装置，用于解决在采用现有技术在对数据库进行扩容时，需要停止原有数据库的写入操作，等待待扩容数据库与原有数据库的数据同步，导致业务无法正常执行、数据库扩容成本增加的问题。

本申请实施例采用下述技术方案：

一种数据存储的方法，包括：

接收业务请求，其中，处理所述业务请求产生的数据是固定类数据；

判断第一数据库是否启用；

若是，则为所述业务请求对应的标识添加第一标记，并处理所述业务请求，将处理所述业务请求产生的固定类数据与添加了第一标记的标识建立对应关系，并存储在第一数据库中，其中，所述第一标记用于表示所述的业务请求产生的固定类数据存储于所述第一数据库中；

否则，为所述业务请求对应的标识添加第二标记，并处理所述业务请求，将处理所述业务请求产生的固定类数据与添加了第二标记的标识建立对应关系，并存储在第二数据库中，其中，所述第二标记用于表示所述业务请求产生的固定类数据存储于所述第二数据库中。

一种数据存储的装置，包括：

接收模块，接收业务请求，其中，处理所述业务请求产生的数据是固定类数据；

判断执行模块，判断司仪数据库是否启用，若是则为所述业务请求对应的标识添加第一标记，并处理所述业务请求，将处理所述业务请求产生的固定类数据与添加了第一标记的标识建立对应关系，并存储在第一数据库中，其中，所述第一标记用于表示所述的业务请求产生的固定类数据存储于所述第一数据库中，否则，为所述业务请求对应的标识添加第二标记，并处理所述业务请求，将处理所述业务请求产生的固定类数据与添加了第二标记的标识建立对应关系，并存储在第二数据库中，其中，所述第二标记用于表示所述业务请求产生的固定类数据存储于所述第二数据库中。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

在接收到业务请求之后，可以通过判断第一数据库是否启用，为该业务请求对应的标识添加相应的标记，之后便可处理该业务请求，将处理该业务请求产生的固定类数据与添加了相应标记的标识建立对应关系，并存储于第一或者第二数据库中，其中，该标识中添加的标记用于表示该固定类数据存储的数据库是该第一数据库还是该第二数据库。可见通过本申请实施例提供的方法，仅需要通过添加在各业务请求对应的标识中的标记，即可确定处理该业务请求产生的固定类数据存储于哪一个数据库中，所以无需使该第一数据库和该第二数据库对存储的固定类数据进行数据同步，进而避免了现有技术中在对数据库扩容时，由于需要进行数据同步，导致数据库需要停止写入操作而造成的业务无法正常进行、数据库扩容成本增加的问题。

附图说明

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

图1a为采用应用服务器和数据库来执行业务的系统结构示意图；

图1b为对应用服务器和数据库进行扩容后执行业务的系统结构示意图；

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

图3为本申请实施例提供的数据库系统的结构示意图；

图4为本申请实施例提供的判断业务请求唯一性的具体过程；

图5是本申请实施例提供一种数据存储的装置结构示意图。

具体实施方式

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

以下结合附图，详细说明本申请各实施例提供的技术方案。

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

S101：接收业务请求。

由于在现有技术中为了提高数据库的运行效率，通常采用分布式的数据库系统存储数据，所以在本申请实施例中也可采用分布式的数据库系统进行所述的数据存储过程，于是在本申请中可由该分布式的数据库系统中的数据库管理中心接收业务请求。

另外，在本申请中，通过该数据库管理中心接收并处理的该业务请求所产生的数据可以是固定类数据，如，单据信息、日志数据等等。例如，接收到交易业务请求时，当该交易业务完成(无论该交易是成功还是失败，均可认为该交易完成)后，该数据库中可以存储有对应于该交易业务的单据信息(即，存储处理该交易业务产生的单据信息)，其中，该单据信息可包含：交易类型、交易双方信息、交易金额、交易结果、交易时间等等，可见该单据信息对应记录的是已经产生且不会改变的信息，也就是本申请所述的固定类数据，该固定类数据通常仅可被调用、查询，而无法再进行变更。为了方便本申请实施例的后续描述，在无特殊说明的情况下，后续本申请实施例中所记载的数据可以理解为固定类数据。

进一步的，为了满足该数据库系统在日常运行时，资源不出现浪费的情况，以及在业务量剧增时，该数据库系统仍可正常运行的需求，在本申请中，该数据库系统中可包含第一数据库以及第二数据库，其中，该第二数据库用于在日常运行时处理业务，该第一数据库用于在出现业务量剧增的情况时，临时加入该数据库系统中处理业务，也就是说，该第二数据库为原有数据库，而该第一数据库为待扩容数据库，其结构可如图3所示。

图3为本申请实施例提供的数据库系统的结构示意图。其中，可见该数据库管理中心201用于接收业务请求以及管理该第一数据库202和该第二数据库203，并且该第一数据库202和该第二数据库203均为分布式数据库，同时为了使该第二数据库对业务的处理能力可满足业务量剧增时增加的业务量，所以该第二数据库203的分库数量通常远大于该第一数据库202。

需要说明的是，由于本申请并不涉及对具体分库分表的访问方式，所以为了简化描述后续以第一数据库表示该第一数据库中的各分库，以第二数据库表示该第二数据库中的各分库。

例如，某分布式数据库系统中，包含数据库管理中心、原有数据库以及带扩容数据库，其中该原有数据库以及该待扩容数据库均为分布式数据库，并且由该数据库管理中心接收业务，假设，该数据库管理中心接收到了业务请求A，则该数据库管理中心需要根据该业务请求A继续执行后续的步骤。

S102：判断第一数据库是否启用，若是则执行步骤S103，若否则执行步骤S104。

在本申请实施例中，当该数据库管理中心接收到业务请求之后，便可通过判断该第一数据库是否启用，来决定后续操作的步骤。其中，由于该第一数据库为待扩容数据库，而只有在业务量剧增的情况下才需要启用该第一数据库，同时由于业务量剧情的情况通常不会无故出现，即，可以预测该数据量剧增的出现时间，所以可由工作人员根据实际需要来控制的该第一数据库是否启用，而该数据库管理中心仅需判断该第一数据库是否启用即可。

具体的，由于该数据库管理中心在接收到业务请求后，需要将该业务请求分配给空闲线程，并通过该线程执行该业务请求对应的业务，而该线程通过该第一数据库还是该第二数据库执行该业务是由该线程的线程变量决定的，并且由于各线程的线程变量是由该数据库管理中心中的分库分表组件来控制的，所以当需要启用该第一数据库时，工作人员可以通过该数据库管理中心更改该分库分表组件中分配给各线程的线程变量，使得各线程后续通过该第一数据库执行业务，也就是说，当该数据库管理中心在接收到该业务请求后，该业务请求可对应的业务可通过该第一数据库执行。

于是，判断该第一数据库是否启用，即判断该分库分表组件控制各线程的线程变量是否使该线程通过第一数据库执行业务，并且当该第一数据库启用时执行步骤S103，当该第一数据库未启用时执行步骤S104。

继续沿用上例，该数据库管理中心可通过该数据库管理中心的分库分表组件中的线程变量的值，判断该待扩容数据库是否启用，步假设当该线程变量的值为0时各线程通过该原有数据库(即，第二数据库)执行业务，当该线程变量的值为1时各线程通过该待扩容数据库(即，第一数据库)执行业务，进一步假设若此时该待扩容数据库已经启用(即，第一数据库已启用)，则时该数据库管理中心可确定该分库分表组件中的线程变量的值为1，并判断该待扩容数据库已启用，执行步骤S103，反之亦然。

S103：为所述业务请求对应的标识添加第一标记，并处理所述业务请求，将处理所述业务请求产生的固定类数据与添加了第一标记的标识建立对应关系，并存储在第一数据库中，其中，所述第一标记用于表示所述的业务请求产生的固定类数据存储于所述第一数据库中。

在本申请实施例中，当确定该第一数据库启用后，该数据库管理中心便可通过将该业务请求分配给空闲线程，并使该线程通过第一数据库执行该业务请求对应的业务，并将处理该业务产生的数据存储于该第一数据库中。

其中，通过该第一数据库执行该业务请求的过程可以分为：添加标记、处理业务以及存储数据等过程。

具体的，首先，当该第一数据库启用时，如在步骤S102中所述的由于线程变量的改变使得各线程均通过该第一数据库执行业务，于是在处理该业务请求对应的业务后，该业务请求产生的数据存储也可于该第一数据库中。但是，由于此时该数据库系统中的该第一数据库和该第二数据库均处于运行状态，即，均可通过线程调用、查询该第一和第二数据库并中存储的数据，所以为了表示该业务请求产生的数据存储于该第一数据库中，该数据库管理中心在判断该第一数据库启用时，便可为该业务请求对应的标识添加第一标记。

其中，该标识可以包括该业务请求的标识(即，业务标识)，也就是说，该数据库管理中心可为该业务请求的业务标识添加了第一标记。

其次，当该数据库管理中心为该业务请求对应的标识添加了第一标记后，便可分配线程处理该业务请求，并将处理该业务请求产生的数据与该添加了第一标记的标识建立对应关系，最后在将该数据存储于该第一数据库中，即，通过该第一数据库执行业务请求。

其中，如在步骤S101中所述的，该第一数据库可为待扩容数据库，其单位时间内的业务处理量要远大于该第二数据库(即，原有数据库)，所以当业务量剧增时，该数据库管理中心使得接收到的业务请求可通过该第一数据库处理，并且将处理该业务请求产生的数据存储于该第一数据库中，可以有效地提高该数据库系统单位时间内可处理的业务量。

最后，在将该数据存储于该第一数据库的同时，还可以将该数据、该添加第一标记的标识以及该数据与该标识的对应关系存储在该第一数据库中。其中，该对应关系可以通过该标识携带在该数据中的形式实现，并且当该数据存储于该第一数据库中时，该标识以及该对应关系就相当于存储与该数据库中。

进一步的，若执行该业务请求时需要调用在该数据库系统中已保存的数据，则在处理该业务请求之前，还需要调用该已保存的数据。

具体的，在确定该第一数据库启用后，进一步判断执行该业务请求是否需要调用已保存数据，若是，则由于在本申请中该已保存数据均为执行业务请求产生的数据，所以可以通存储的与该已保存数据的对应的标识中添加的标记，确定存储该已保存数据的数据库，并从该确定的数据库中调用该已保存数据，最后通过该已保存数据执行该业务请求对应的业务。

继续沿用上例，该数据库管理系统在判断该待扩容数据库已经启用后，可为该业务请求A对应的标识a，添加第一标记，如，1。则该业务请求A的标识可被变更为a1，其中该第一标记1表示处理该业务请求A产生的数据X存储于该待扩容数据库中。

进一步的假设，执行该业务请求A需要使用该原有数据库中已保存的数据Y，则该数据库管理系统在接受到该业务请求A时，该业务请求A中应携带有该产生该数据Y的业务请求对应的标识，如b2，其中，该标识中b用于表示该产生该数据的业务的标识、2表示该数据存储于该第二数据库中，即，存储于该原有数据库中。于是，在处理该业务请求A之前，还可以根据该数据Y对应的标识b2中的第二标记2，确定存储该数据Y的数据库为该原有数据库，并从该原有数据库中调用该数据Y，通过该数据Y执行该业务请求A。

S104：为所述业务请求对应的标识添加第二标记，并处理所述业务请求，将处理所述业务请求产生的固定类数据与添加了第二标记的标识建立对应关系，并存储在第二数据库中，其中，所述第二标记用于表示所述业务请求产生的固定类数据存储于所述第二数据库中。

在本申请实施例中，与步骤S103类似，当确定该第一数据库未启用后，该数据库管理中心便可通过将该业务请求分配给空闲线程，并使该线程通过第二数据库执行该业务请求对应的业务，并将处理该业务产生的数据存储于该第二数据库中。

具体的，由于该第一数据库未启用时，业务并不通过该第一数据库执行，处理该业务请求产生的数据可存储于该第二数据库，于是如步骤S103中所述，为了区分与该第一数据库启用和未启用时，存储处理业务产生的数据的数据库，需要为该业务请求对应的标识添加该第二标记，其中，该第二标记用于表示该业务请求产生的数据存储于该第二数据库中，以区别于步骤S103中的该第一数据库启用时，该业务请求产生的数据存储于该第一数据库中时，为该业务请求的标识添加的该第一标记。

进一步的，添加入该业务请求对应的标识中的该第一标记或者该第二标记，仅用于表示处理该业务请求产生的数据存储的数据库，所以该第一标记和该第二标记的形式可以是一致的，添加位置也可以是一致的(如，假设业务请求对应的标识为AF-1002，则该第一标记或者该第二标记可以以单个字母添加在该标识的最后一位的形式，使该标识具有表示该业务请求对应的数据的存储数据库，则，该业务请求对应的数据存储于第一数据库可表示为AF-1002a，存储于该第二数据库可表示为AF-1002b)。当然，具体该第一标记以及该第二标记可根据需要由人工进行设置，只要能够用于区别表示该业务请求产生的数据存储于不同的数据库中即可，本申请对此并不做具体限定。

另外，实际上步骤S104与步骤S103在具体实施过程中并没有本质区别，区别点仅在于为该业务请求对应的标识添加的标记以及处理该业务请求产生的数据存储的数据库等，所以本申请对此过程不在做过多赘述。

通过如图2所示的数据存储的方法，可见，在接收到业务请求后，首先需要判断该第一数据库是否启用，其次，根据该第一数据库是否启用的判断结果，确定处理该业务请求的数据库，最后将产生的数据存储于该确定的数据库中。并且，进一步的，不论该第一数据库是否启用，在处理该也请求之前，均需要为该业务请求对应的标识添加对应的标记，该标记用于表示该业务请求产生的数据存储于哪一个数据库，于是当存储该业务请求产生的数据时，同时也将该标识以及该标识与该数据的对应关系一并存储，使得后续在调用该业务请求产生的数据时，可以根据该标识中添加的标记，确定存储该数据的数据库。从而使得，在启用该第一数据库执行业务时，无需对该第一和第二数据库进行同步，并且也不影响对该第二数据库中数据的调用。避免了现有技术由于需要对数据库中的数据进行同步而导致的业务无法正常执行，数据库扩容成本高的问题。

另外，在本申请中，由于在网络状况不佳或者应用服务器运行错误等的情况下，该数据库管理中心有可能接收到重复的业务请求。而若重复的业务请求被重复执行，则可导致同一业务请求在该数据库系统中存储多个处理该业务请求产生的数据(即，破坏了数据库中数据的一致性)，所以为了避免这一情况的发生，当该数据库管理中心接收到该业务请求时(即，步骤S101)，还可根据该业务请求对应的标识，生成该业务请求对应的事务记录。其中，由于该事物记录由该业务请求对应的标识确定，所以该数据管理中心针对同一业务请求生成的事务记录是相同的，而该数据库管理中心后续则可根据该事务记录保证该业务请求不会被重试。

进一步的，当为该业务请求生成对应的事务记录后，由于同一业务请求生成的事务记录是相同的，所以该数据库管理中心就可以根据生成的与该业务请求对应的该事务记录，判断该事务记录是否是唯一的。

具体的，根据数据库中存储的各事务记录，判断该业务请求对应的事务记录是否唯一，若是，则可确定该业务请求不是重复的业务请求，后续可正常处理该业务请求对应的业务，并且可将该业务请求对应的事务记录存储于数据库中，以便当该业务请求被重复发送时，该数据库管理中心可以根据已存储的该业务请求的事务记录，确定该业务请求是重复的业务请求，若否，则确定该业务请求是被重复发送的业务请求，若再次处理该业务请求对应的业务，则可能造成数据库中的数据一致性被破坏，所以无需处理该业务请求对应的业务，并且可以返回错误信息，并拒绝处理该业务请求对应的业务，同时也可不存储该业务请求的事务记录。

并且，在本申请中，当该第一数据库启用时(即，通过该第一以及该第二数据库处理业务请求时)，将该业务请求的事务记录存储于该第一数据库，当该第一数据库未启用时(即，仅通过该第二数据库处理业务请求时)，将该事务记录存储于该第二数据库。以便当该第一数据库启用时，可以最大化的利用该第一数据库的处理业务的能力，并且，将该事物记录与处理该业务请求产生的数据存储于同一数据库中，也可保证与该业务请求相关数据均存储在相同的数据库中(如，处理该业务请求产生的数据、添加了标记的该业务请求的标识、该业务请求的事务记录以及该数据、该标识和该事务记录的对应关系)，方便后续对数据库中数据的管理。

可见，在本申请中，只有当判断该业务请求不是重复的业务请求时(即，在数据库中存储的各事务记录没有与该业务请求的事务记录一致的事务记录时)，该业务请求对应的业务才可继续进行正常的处理，从而避免该业务请求是重复的业务请求(即，避免重复的处理同一个业务与请求)，并且由于可将该业务请求的事务记录存储于处理该业务请求对应的业务的数据库中，进一步避免了后续当出现与该业务请求一致的业务请求时(即，对该业务请求的重复请求)，该数据库重复处理该业务请求对应的业务。

另外，通常在现有技术中，当一个业务请求是重复的业务请求时，在该数据库中应已经存储与该业务请求的事务记录一致的事务记录，所以当该数据库管理中心为该业务请求生成对应的事务记录后，可以确定该事务记录已经存在(即，该事务记录不是唯一的)，进而确定该业务请求是重复的业务请求，从而判断该业务请求是重复的，可以避免对同一业务请求的重复处理。

但是由于在本申请中，该数据库系统中存在该第一数据库以及该第二数据库，并且该第一数据库与该第二数据库中的数据并没有进行数据同步，所以当该第一数据库启用时，由该第一数据库处理业务请求对应的业务，所以此时该数据库系统也仅根据该第一数据库中存储的各事务记录，判断该业务请求的事务记录是否唯一，所以当该业务请求是由该第二数据库处理的，则在该第一数据库中不会存储有该业务请求的事务记录，从而造成该数据库管理中心误判该业务请求不是重复的业务请求，而通过该第一数据库再次处理该业务请求对应的业务，造成对同一个业务请求的重复处理。

同理，当该第一数据由启用变更为未启用时，该数据库系统中由该第二数据库处理业务请求对应的业务，而若此时，有已经通过该第一数据库处理的业务请求被重试时，则由于该第二数据库中并没有该业务请求的事务记录，从而造成该数据库管理中心误判该业务请求不是重复的业务请求，而通过该第二数据库再次处理该业务请求对应的业务，造成对同一个业务请求的重复处理。

所以进一步的在本申请中，为了避免误判该业务请求不是重复的业务请求，所以在当该第一数据库由启用变更为未启用以及有未启用变更为启用的前后，该数据库管理中心在判断接收到的业务请求的事务记录是否为全局唯一时，均需要根据该第一和/或该第二数据库中存储的各事务记录判断该业务请求的事务记录是否唯一。

具体的，当该第一数据库启用时，根据该第二数据库中存储的各事务记录，判断该业务请求对应的事务记录是否唯一，当该第一数据库未启用时，根据该第一数据库中存储的各事务记录，判断该业务请求对应的事务记录是否唯一。当判断结果为是时，则可与现有技术一致继续进行第二次判断，即，判断处理该业务请求的数据库中是否也存在与该业务请求的事务记录一致的事务记录，若是，则确定该业务请求为重复的业务请求，若否则确定该业务请求不是重复的业务请求，可以正常处理该业务请求对应的业务，并存储该事务记录，若判断结果为否时，则可确定该业务请求为重试的业务请求，无需在根据处理该业务请求的数据库中存储的事务记录进行后续的判断，而返回错误信息，拒绝处理该业务请求对应的业务，同时也可不存储该业务请求的事务记录，具体的判断流程可如图4所示。

图4为本申请实施例提供的判断业务请求唯一性的具体过程。即，判断该业务请求是否是重复的业务请求的具体过程。

需要说明的是，由于在当该第一数据库由启用变更为未启用后，该数据库管理中心还可以将存储于该第一数据库中的数据迁移至该第二数据库中，以便当该第一数据库中的数据全部迁移完毕后，可以完全停止通过该第一数据库处理业务，从而减少日常运行时数据库资源的浪费。而当完全停止通过第一数据库处理业务时(即，该第一数据库中的数据被全部转移后)，便无需在通过该第一数据库判断接收到的业务请求对应的事务记录是否唯一，于是可以不再通过上述流程进行判断，所以在本申请中，可以由工作人员根据需要控制该数据库管理中心，是该数据库管理中心判断是否需要根据该第一或者第二数据库中存储的各事务记录判断该业务请求的事务记录是否唯一。

进一步的，如上述为了减少日常运行时数据库资源的浪费的目的，(即，由于日常运行时，该数据库系统需要处理的业务量较低，所以无需使用该第一数据库处理业务，所以可以停止使用该第一数据库执行业务请求对应的业务)，在本申请中，当业务量剧增的情况结束时，还可以将该第一数据库由启用变更为未启用。

具体的，由于当该第一数据库为未启用时，该数据库系统中的该数据库管理中心使各线程通过该第二数据库执行业务，所以在判断该业务请求的事务记录是否唯一时，该数据库管理中心会先根据该第二数据库中存储的各事务记录判断该业务请求的事务记录是否唯一，于是处于减少该数据库管理中心运行压力的目的，在将该第一数据库中存储的数据迁移至该第二数据库中时，可先迁移在该第一数据库中存储的各事务记录，使得该数据库管理中心可以减少二次判断的过程(即，在该第一数据库未启用时，若该业务请求为重复的业务请求，则由更大几率根据该第二数据库中存储的各事务记录确定该业务请求为重复的业务请求，而无需后续在根据该第一数据库中存储的事务记录进行唯一性的判断)，并在该第一数据库中全部事务记录均迁移至该第二数据库之后，再将该第一数据库中的由处理各业务请求产生的各数据转移至该第二数据库中。

更进一步的，由于在将该第一数据库中存储的各事务记录迁移至该第二数据库中时，由该第一数据库执行的业务请求对应的业务中存在已经执行完毕的(即，处理业务产生的数据已经存储在该第一数据库的)，也同时存在尚未执行完毕的(即，业务请求对应的事务记录已经存储但是该业务请求尚未产生数据)，而为了保证数据存储的统一，对于尚未执行完毕的业务请求对应的事务记录，在本申请中可以暂不迁移，直至该业务请求执行完毕后，再迁移该事务记录。

于是，在本申请中，在迁移该第一数据库中的数据时，为了区别执行完毕的业务请求对应的事务记录以及未执行完毕的业务请求对应的事务记录，以便先将已执行完毕的业务请求对应的事务记录先转移至该第二数据库中，并等待该未执行完毕的业务请求执行完毕后在转移对应的事务记录，在业务请求处理完毕之前，该业务请求对应的事务记录的状态可以记录为待提交，而当该业务请求处理完毕后，再将该事务记录的状态由待提交变更为已提交。则将该第一数据库中的数据迁移至该第二数据库中的过程具体可以是：

首先，将该第一数据库中每个状态为已提交的事务记录迁移至该第二数据库，并删除所述第一数据库中迁移后的事务记录。

其次，针对该第一数据库中每个状态为待提交的事务记录，等待该事务记录的状态变更为已提交时，将该事务记录迁移到所述第二数据库中，并删除该第一数据库中的该事务记录。

最后，当该第一数据库中的全部事务记录均迁移至该第二数据库时，将该第一数据库中存储的所有数据迁移至该第二数据库，并删除该第一数据库中存储的所有数据。

需要说明的是，再将该第一数据库中存储的所有数据迁移至该第二数据库中时，由于此时该数据的存储数据库已经由该第一数据库变更为该第二数据库，所以为了后续的业务请求可以根据该数据对应的标识中添加的标记确定该数据的存储位置已经由该第一数据库变更为该第二数据库，所以在本申请中，针对该第一数据库中存储的每个数据，在将该数据迁移至该第二数据库中时，可先将与该数据对应的标识中的第一标记更改为第二标记，再将该数据以及该数据对应的更改标记后的标识迁移至所述第二数据库中，以通过待第二标记表示该数据存储于该第二数据库中。

另外，在本申请中所述的数据存储方法，并不仅限于当第一数据库为扩容数据库、该第二数据库为原有数据库的情况，由于在步骤S101中已经阐明，该第一数据库以及该第二数据库均可以是分布式数据库，所以本申请所述的该第一数据库以及该第二数据库，可以是分布式数据库中的不同数据库。

需要说明的是，本申请实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤S101和步骤S102的执行主体可以为设备1，步骤S103的执行主体可以为设备2；又比如，步骤S101的执行主体可以为设备1，步骤S102和步骤S103的执行主体可以为设备2；等等。并且，在本申请中所述的该第一数据库和该第二数据库，均可为分布式数据库，即，由多台设备组成的数据库，其中，该第一数据库、该第二数据库以及该数据库管理中心统称为数据库系统。

基于图2所示的数据存储过程，本申请实施例还对应提供一种数据存储的装置，如图5所示。

图5是本申请实施例提供一种数据存储的装置结构示意图，包括：

接收模块301，接收业务请求，其中，处理所述业务请求产生的数据是固定类数据；

判断执行模块302，判断司仪数据库是否启用，若是则为所述业务请求对应的标识添加第一标记，并处理所述业务请求，将处理所述业务请求产生的固定类数据与添加了第一标记的标识建立对应关系，并存储在第一数据库中，其中，所述第一标记用于表示所述的业务请求产生的固定类数据存储于所述第一数据库中，否则，为所述业务请求对应的标识添加第二标记，并处理所述业务请求，将处理所述业务请求产生的固定类数据与添加了第二标记的标识建立对应关系，并存储在第二数据库中，其中，所述第二标记用于表示所述业务请求产生的固定类数据存储于所述第二数据库中。

所述判断执行模块302，判断执行所述业务请求是否需要调用已保存的固定类数据，若是，根据所述业务请求携带的所述已保存的固定类数据对应的标识中的标记，确定存储所述已保存的固定类数据的数据库，并从确定的数据库中调用所述已保存的固定类数据，通过所述已保存的固定类数据执行所述业务请求对应的业务，若否，则根据所述业务请求执行对应的业务。

所述接收模块301，接收业务请求，根据所述业务请求对应的标识，生成所述业务请求对应的事务记录；

所述判断执行模块302，处理所述业务请求之前，确定所述事务记录是全局唯一的，并存储所述事务记录。

所述判断执行模块302，当所述第一数据库启用时，将所述事务记录存储于所述第一数据库，当所述第一数据库未启用时，将所述事务记录存储于所述第二数据库。

所述判断执行模块302，当所述第一数据库启用时，根据所述第二数据库中存储的各事务记录，判断所述业务请求对应的事务记录是否唯一，当所述第一数据库未启用时，根据所述第一数据库中存储的各事务记录，判断所述业务请求对应的事务记录是否唯一。

所述判断执行模块302，当所述业务请求处理完毕时，将所述事务记录的状态由待提交变更为已提交。

所述装置还包括：

迁移模块303，当所述第一数据库由启用变更为未启用时，将所述第一数据库中每个状态为已提交的事务记录迁移至所述第二数据库，并删除所述第一数据库中迁移后的事务记录，针对所述第一数据库中每个状态为待提交的事务记录，等待该事务记录的状态变更为已提交时，将该事务记录迁移到所述第二数据库中，并删除所述第一数据库中的该事务记录，当所述第一数据库中的全部事务记录均迁移至所述第二数据库时，将所述第一数据库中存储的所有固定类数据迁移至所述第二数据库，并删除所述第一数据库中存储的所有固定类数据。

所述迁移模块303，针对所述第一数据库中存储的每个固定类数据，将该固定类数据以及与该固定类数据对应的标识中的第一标记更改为第二标记，并将该固定类数据以及该固定类数据对应的更改标记后的标识迁移至所述第二数据库中。

具体的，上述如图5所示的数据存储的装置可以位于数据库系统中，具体可以位于数据库系统中的数据库管理中心中。

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

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

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

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

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

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

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

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