CN106933830A - 一种更新数据表时的业务执行方法及装置 - Google Patents

Abstract

本申请实施例提供一种更新数据表时的业务执行方法及装置，该方法先将接收到的更新数据表内的数据写入新建的更新缓存区，并且仍然保留存储原有数据表内数据的原有缓存区，后将业务总量拆分为测试业务量和正式业务量，并根据该更新缓存区和该原有缓存区中的数据分别执行测试业务量的业务和正式业务量的业务，实时监测测试业务量的业务是否正常，若正常，则增加测试业务量，并继续监测，否则，停止执行测试业务量的业务，并根据原有缓存区中的数据执行全部业务。通过上述方法，可保证更新数据的正确性，同时也可避免数据表锁死后业务不能正常执行，且在业务未正常执行时回滚至根据原有缓存区中数据执行全部业务，使业务依然可以正常执行。

Description

一种更新数据表时的业务执行方法及装置

技术领域

本申请涉及信息技术领域，尤其涉及一种更新数据表时的业务执行方法及装置。

背景技术

随着信息化社会的发展，人们越来越习惯于使用网络来进行业务，如，进行网上购物、通过网上银行缴费、网络即时通讯等。而由于在执行业务的过程中，服务器经常需要基于一些数据来执行业务，所以数据的正确性以及该数据更新的及时性，就直接影响了业务的正常进行。

在现有技术中，一般将业务所需的各类数据存储于数据库中，具体可以是数据库的数据表中，当需要更新数据表中的数据时，便将需要更新的数据由工作人员手动上传并***该数据表中。

但是在现有技术中，通常需要靠人工经验对更新的数据进行正确性的判断，这就导致更新的数据的正确性不能得到保证。而且，当需要大量的更新数据表中的数据时，由于更新的数据量较大，会导致该数据表长时间被锁死，进而使该数据表无法使用，则导致业务长时间无法执行。

另外，若之前没有对更新前的数据表进行备份，则当该数据表中更新的数据有错误时，也难以将数据表恢复至更新前的数据表，也会导致业务不能正常执行。

综上可知，现有技术中不能保证更新的数据的正确性，也可能导致业务长时间不能正常执行。

发明内容

本申请实施例提供一种更新数据表时的业务执行方法及装置，用以解决现有技术中不能保证更新的数据的正确性，也可能导致业务长时间不能正常执行的问题。

本申请实施例提供的一种更新数据表时的业务执行方法，包括：

接收更新数据表；

新建更新缓存区；

将所述更新数据表内的数据写入所述更新缓存区；

将业务总量拆分为测试业务量和正式业务量；

根据所述更新缓存区中的数据，执行测试业务量的业务，根据原有缓存区中的数据，执行所述正式业务量的业务；其中，所述原有缓存区中的数据为原有数据表内的数据；

监测所述测试业务量的业务是否正常执行；

若正常，则增加测试业务量，并继续监测测试业务量的业务是否正常执行，直至测试业务量等于业务总量为止；

若不正常，则停止根据所述更新缓存区中的数据执行测试业务量的业务，并根据所述原有缓存区中的数据执行全部业务。

本申请实施例提供的一种更新数据表时的业务执行装置，包括：

接收模块，用于接收更新数据表；

缓存模块，用于新建更新缓存区；

写入模块，用于将所述更新数据表内的数据写入所述更新缓存区；

拆分模块，用于将业务总量拆分为测试业务量和正式业务量；

测试模块，用于根据所述更新缓存区中的数据，执行测试业务量的业务，根据原有缓存区中的数据，执行所述正式业务量的业务；其中，所述原有缓存区中的数据为原有数据表内的数据；

监测执行模块，用于监测所述测试业务量的业务是否正常执行；若正常则，增加测试业务量，并使所述监测模块继续监测测试业务量的业务是否正常执行，直至测试业务量等于业务总量为止；若不正常，则指示所述测试模块停止根据所述更新缓存区中的数据执行测试业务量的业务，并根据所述原有缓存区中的数据执行全部业务。

本申请实施例提供一种更新数据表时的业务执行方法及装置，该方法在接收更新数据表后，建立对应的更新缓存区，将该更新数据表内的数据写入该更新缓存区，并且仍然保留原有数据表内数据对应的原有缓存区，将业务总量拆分为测试业务量和正式业务量，并根据更新缓存区中的数据执行测试业务量的业务，根据原有缓存区中的数据执行正式业务量的业务，实时监测测试业务量的业务是否正常，若正常，则增加测试业务量，并继续监测，否则，停止执行测试业务量的业务，并根据原有缓存区中的数据执行全部业务。通过上述方法，实时监测测试业务量的业务是否正常，并在正常时增加测试业务量，一方面可保证更新数据的正确性，另一方面也可避免更新数据量较大时，数据表被长时间锁死而导致业务不能正常执行，在不正常时可回滚至根据更新前的数据执行全部业务，也可保证当更新的数据出错时，业务依然可以正常执行。

附图说明

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

图1为本申请实施例提供的更新数据表时的业务执行过程；

图2为本申请实施例提供的一种更新数据表时的业务执行装置的结构示意图。

具体实施方式

在本申请实施例中，根据更新数据表对应的更新缓存区内的数据执行全部业务量中的测试业务量，根据原有缓存区中的数据执行全部业务量中其他业务量的，并逐渐增加该测试业务量直到该测试业务量等于业务总量为止，同时实时监测该测试业务量的业务是否正常执行，只要监测到有未正常执行的业务，就停止根据该更新数据表执行测试业务量的业务，并根据原有数据表执行全部业务。可见本申请所述的方法，可以有效地保证更新数据的正确性，同时降低更新数据表时该更新数据表对业务执行的影响。

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

图1为本申请实施例提供的更新数据表时的业务执行过程，具体包括以下步骤：

S101：接收更新数据表。

在本申请实施例中，先由工作人员在数据库中，根据在该数据库中保存的原有数据表，新建一个内容一致的数据表，再由工作人员手动向该新建的数据表中添加更新数据或者修改原有数据，最后得到更新数据表。而当该更新数据表上传至服务器时，服务器便可接收到该更新数据表。

例如，在数据库中有若干数据表，其中包括：存储账户标识的数据表、存储账户属性的数据表、存储账户对应的银行卡的银行标识代码(BankIdentification Number，BIN)的数据表等。在本申请实施例中，仅以存储银行卡的BIN的数据表(下面简称为BIN数据表)为例进行说明。

假设，工作人员需要针对数据库中的BIN数据表进行更新，那么就需要先根据该数据库中保存的原有BIN数据表，新建一个BIN数据表(其中，该原有BIN表与新建BIN表的关系，如表1所示)，并对该新建的BIN数据表中的数据进行数据添加或数据修改，当数据添加或修改完毕后便得到了当前的更新BIN数据表。其中该原有BIN数据表与更新BIN数据表的关系，如表2所示。

表1

在表1中，A、B、C、D、E为原有BIN数据表中的数据，可见该新建BIN表内的数据与原有BIN数据表中的数据一致。

原有BIN数据表	更新BIN数据表
		A、B、C、D、E	A、R、C、E、G、F

表2

在表2中，可见将该新建BIN数据表中的数据B、D、E修改为数据R、E、G，并且添加了一个新的数据F，当上述针对表1中的新建BIN数据表中的数据修改或添加完成时，便得到了如表2所示的更新BIN数据表。

另外，所述服务器可以是单独的一个服务器，也可以是由多个服务器组成的服务器集群，本申请并不做具体限定。

S102：新建更新缓存区。

现有技术中，业务在执行时一般是直接对数据库进行访问，并从该数据库中的数据表获取需要的数据，这就容易导致数据表锁死时，业务无法获访问该数据表，而使得业务无法正常执行。

在本申请实施例中，为了避免当出现大量的数据写入或者***数据表时，该数据表锁死，导致业务无法根据该数据表中的数据执行的情况出现，可在服务器的缓存区中划分出专门用于存储数据表中数据的缓存区，使得业务在执行时无需访问数据库，而是根据该缓存区中的数据进行业务的执行，以减少业务执行时对数据表的访问，使得即使该数据表被锁死时，业务也可以根据该缓存区中的数据正常执行。

于是，在本申请中当接收到更新数据表后，为了不影响业务的正常执行，服务器并不对原有数据表中的数据所在的原有缓存区进行修改、写入等操作，而是新建一个更新缓存区，以便后续可以将接收到的该更新数据表写入该新建的更新缓存区。

另外需要说明的是，在本申请中所述的原有缓存区和更新缓存区，具体可以是在服务器中专门用于存储数据表中数据的缓存区，以避免该数据表中的数据在写入该缓存区后遭到破坏。

继续沿用上例，由于原有缓存区内写入的数据就是数据库中原有BIN数据表中的数据，所以该原有缓存区内的数据为A、B、C、D、E，新建的更新缓存区内由于尚未写入数据所以其中没有任何内容。

S103：将所述更新数据表内的数据写入所述更新缓存区。

在本申请实施例中，当经过步骤S101和步骤S102后，便可将该更新数据表内的数据写入该更新缓存区，以便根据该更新缓存区内的数据执行业务。

具体的，由于一般情况下，将数据库中的数据表写入缓存区时，先通过固定的数据表的标识来确定数据表，再根据该标识将对应的数据表中的数据写入缓存区。于是在本申请中，为了避免对数据表中数据的大量修改，浪费数据库资源的问题，所以数据库在上传该更新数据表前，可先将所述更新数据表的标识与原有数据表的标识互换，使得服务器可以根据互换后该更新数据表的标识，将该更新数据表内的数据写入该更新缓存区。即，采用将该更新数据表的标识与原有数据表的标识互换的方式，避免了对数据表中数据的大量修改，从而避免了数据库资源的浪费。

继续沿用上例，假设原有BIN数据表的标识为i，而更新BIN数据表的标识为ii。并且，该服务器是通过标识i来确定数据表，再将该标识为i的数据表内的数据写入缓存区的，所以在本申请中，在数据库上传该更新BIN数据表之前，还需要将该更新BIN数据表与原有BIN数据表的标识互换，即使该更新BIN数据表的标识为i，则当服务器将更新BIN数据表写入缓存区时，通过标识i确定更新BIN数据表，再根据标识i将该更新BIN数据表中的数据写入更新缓存区。

S104：将业务总量拆分为测试业务量和正式业务量。

在本申请实施例中，由于此时尚不能确定更新数据表中的数据是否正确，也就不能确定根据该更新缓存区中的数据是否可以正常的执行业务，所以为了降低业务执行时的出错率，本申请并不直接根据该更新缓存区中的数据执行全部业务，而是需要分出一部分业务，先根据该更新缓存区中的数据执行，以测试是否可以根据该更新缓存区中的数据正常的执行业务，所以在根据该更新缓存区内的数据执行业务之前，还需要将业务总量拆分为测试业务量和正式业务量。

另外，将该业务总量拆分后，该测试业务量和正式业务量占业务总量的比例可以根据需求确定。

继续沿用上例，假设业务总量为100(即，一共有100个业务)，预设的初始测试业务量和正式业务量占业务总量的比例为10％和90％，即，初始测试业务量为10个业务、正式业务量为90个业务。

S105：根据所述更新缓存区中的数据，执行测试业务量的业务，根据原有缓存区中的数据，执行所述正式业务量的业务。

在本申请实施例中，当将总业务量分为测试业务量和正式业务量后，便可以根据更新缓存区中的数据，执行该测试业务量的业务，根据原有缓存区中的数据，执行该正式业务量的业务。其中，该原有缓存区中的数据为原有数据表内的数据。

另外，由于在根据缓存区中的数据执行业务时，执行业务所基于的数据通常需要一些路径标识、调用标识等标识信息来表示该数据的属性，使执行业务时可以根据数据的标识调用到对应的数据，而无需再去数据库中的数据表调用数据。并且，该数据可能还需要有一定的数据格式，以方便业务的使用(如，在数据前面加入特定格式的数字或者字母以表示该数据可以用于何种业务等)。所以在本申请中，根据该更新缓存区中的数据，执行测试业务量的业务之前，还可以采用原有缓存区中的数据格式，调整所述更新缓存区中的数据格式。

继续沿用上例，假设在原有缓存区中的各数据均有固定的数据格式，如在数据中加入前缀以表示该数据的属性，由于所述的各数据均是银行卡BIN数据，所以该前缀可以表示银行卡发行的属性。如，1表示α银行、2表示β银行、3表示γ银行。则原有缓存区中数据的数据格式可如表3所示。

表3

于是，在采用原有缓存区中的数据格式，调整该更新缓存区中的数据格式后，该更新缓存区中的数据格式，如表4所示。

表4

可见经过调整后，该更新缓存区中与原有缓存区中一致的数据，也加入了前缀以表示该数据的属性，同时新写入的数据(如，R、G、F)，因为是第一次出现所以尚未有对应的前缀。

当然，若在调整该更新缓存区中的数据时可以确定新写入的数据的属性，则也可以对该新写入的数据加入对应的前缀，如，若确定数据R、G、F均对应于α银行发行的银行卡，则调整后该更新缓存区中的数据格式，可如表5所示。

表5

需要说明的是，由于原有缓存区中的数据为原有数据表内的数据，所以根据该原有缓存区内的数据可以正常的执行业务。于是，即使当该更新缓存区中的数据有问题，导致执行业务出现错误时，根据该原有缓存区内的数据执行的业务也不会出错，可以保证大部分业务的正常执行，将该更新缓存中的错误数据对业务执行的影响降到最低。

S106：监测所述测试业务量的业务是否正常执行，若正常则执行步骤S107，若不正常则执行步骤S108。

在本申请实施例中，当根据该更新缓存区中的数据执行测试业务量的业务时，还需要实时监测该测试业务量的业务是否正常执行，以便判断该更新缓存区中的数据是否是正常可用的，即判断根据该更新缓存区中的数据是否可以正常的执行业务，若正常则执行步骤S107，若不正常则执行步骤S108。

另外，监测该测试业务量的业务是否正常执行，可以是监测一段时间内该测试业务量是否正常执行，或者是监测该测试业务量中一定比例的业务是否正常执行。并且，上述时间长度或者比例数值，可以通过预先保存的设定值来确定。当然，如何监测测试业务量的业务是否正常执行、预先保存的设定值具体为多少，本申请并不做具体限定。

继续沿用上例，假设服务器监测十分钟内该测试业务量是否正常执行，则从开始监测根据该更新缓存区中的数据执行测试业务量的业务后的十分钟内，若该测试业务量的业务均正常执行，则确定该测试业务量的业务正常执行，执行步骤S107。而当该测试业务量的业务在该十分钟内的任意时刻未正常执行时，确定该测试业务量的业务未正常执行，需要执行步骤S108。

S107：增加测试业务量，并返回步骤S106，直至测试业务量等于业务总量为止。

在本申请实施例中，当监测该测试业务量的业务正常执行后，便可以增加该测试业务量，即，使根据该更新缓存区中的数据执行的业务增加。并且，返回步骤S106继续监测该测试业务量的业务是否正常执行，直到测试业务量等于业务总量为止。

具体的，当每次监测到该测试业务量的业务正常执行后，便增加业务总量中测试业务量所占的比例。

继续沿用上例，当监测到该测试业务量的业务正常执行后，服务器便可增加测试业务量，并且增加的量可以是固定的，如每次都增加业务总量中的10％，则第一次增加测试业务量后，该测试业务量由业务总量的10％增加至业务总量的20％，第二次增加后该测试业务量为业务总量的30％，以此类推。

当然，为了更加快速完成测试，上述的增加的量也可是逐渐增加的，如第一次增加业务总量的10％，第二次增加业务总量的25％等等。则经过第一次增加后，测试业务量占业务总量的20％(即，10％+10％)，经过第二次增加后，测试业务量占业务总量的45％(即，20％+25％)。

另外，当每一次测试业务量增加之后，都要返回步骤S106再次监测该测试业务量增加后的业务是否正常执行，若有测试业务量的业务无法正常执行，则直接执行步骤S108，若该测试业务量的业务均可正常执行，便一直增加该测试业务量，直到该测试业务量等于业务总量为止。

进一步的，当该测试业务量等于业务总量时，即，当根据更新缓存区中的数据可以正常执行业务总量中的全部业务时，那么原有缓存区中的数据便可以清除掉以便留出空间用于他用，服务器开始使用更新缓存区中的数据执行全部业务，即，完成数据表更新的同时没有影响业务的执行。

S108：停止根据所述更新缓存区中的数据执行测试业务量的业务，并根据所述原有缓存区中的数据执行全部业务。

在本申请实施例中，当在步骤S106中监测到有测试业务量的业务未被正常执行后，便可以确定该更新缓存区中的数据是有错误的，所以该更新缓存区中的数据不可用，那么便需要停止根据该更新缓存区中的数据执行测试业务量的业务，转而根据该原有缓存区中的数据执行全部业务，以保证业务的正常执行。

另外，当出现测试业务量的业务未正常执行时，服务器可以输出一个更新数据错误的提示信息，使工作人员可以通过该提示信息了解更新数据表中的数据存在错误，可导致业务无法正常执行，方便工作人员后续可以根据该提示信息在更新数据表中排查错误数据。进一步的，该更新错误提示信息，还可以具体指出是根据哪个数据执行何种业务时出现的不能正常执行的情况，可以进一步的减轻工作人员后续排查错误数据的工作量。

继续沿用上例，假设在根据更新缓存区中的数据R执行业务时，该业务无法正常执行，则停止根据该更新缓存区中的数据执行任何业务，而根据原有缓存区中的数据执行全部业务，以保证业务的正常执行。同时该服务器还可以输出一个更新错误的提示信息，并且该更新错误提示信息还可以指出，是在根据该数据R执行业务时，出现的业务为正常执行的情况。如此，可以使工作人员通过该提示信息，可以了解更新数据表中的数据R存在问题，并且可以更有针对性的在更新数据表中排查错误数据。

通过图1所示的更新数据表时的业务执行方法，在更新数据表时，通过根据缓存区中存储的更新数据表的数据，执行由业务总量中分流出的测试业务量的业务，来对该更新缓存区中的数据进行测试，只有当该更新缓存区中的数据可以正常执行全部业务时，才确定该更新缓存区中的数据可以使用，并最终完成了数据表的更新。相对于现有方法，本方法根据用缓存区中的数据执行业务，减少了数据库被访问的量，使得在接收到更新数据表时不会因为大量的数据写入导致锁表，使得业务无法正常执行，并且还对该更新缓存区中的数据进行逐步的测试，可以避免出现大量的无法正常执行的业务的同时，确定该更新缓存区中数据是否可用，进一步的，一旦出现不能正常执行的业务时，服务器即可返回使用原有缓存区中的数据，避免了错误数据导致业务长时间不能正常执行的问题。通过本方法可以有效地降低更新数据表时该更新数据表对业务执行的影响、提高业务的执行效率。

另外，在步骤103之前，由于数据表中的数据的正确性直接关系到业务是否能够正常执行，而在接收到更新数据表时还不能确定该更新数据表中的数据是否可使业务正常执行，所以在将该更新数据表内的数据写入该更新缓存区之前，还需要先确定该更新数据表内的数据符合更新条件，即，该更新数据表内的数据是否有必要更新、有无明显的错误。

具体的，可先判断该更新数据表与预设的数据表模型是否匹配，由于通常该数据表的更新都是有一定规律的，所以可以根据该规律建立一个对应的数据模型，并根据该数据模型来判断该更新数据表是否匹配，若不匹配则确定该更新数据表不符合更新条件，不再进行此次数据表的更新，而若匹配则需继续进行后续的判断。

继续沿用上例，由于上述BIN数据表中的数据为银行卡BIN数据，而银行卡BIN是由国际标准化组织(International Organization for Standardization，ISO)分配给各从事跨行转接交换的银行卡组织的一组6位数字，所以该银行卡BIN数据是具有一定规律的6位数字，则可以根据该规律建立数据模型，并根据该数据模型来判断该更新数据表是否匹配。如，一段连续的银行卡BIN会分配给同一地区的银行卡组织，所以当一段连续的银行卡BIN中有个别银行卡BIN所属银行卡组织的地区，与其他银行卡BIN所属银行卡组织的地区不同，则可以确定这几个银行卡BIN是错误的银行卡BIN，则存储该银行卡BIN的数据表与数据模型不匹配，不符合更新条件。

进一步的，当判断该更新数据表与该数据模型匹配后，仍然需要确定该更新数据表与原有数据表的差异度满足预设的条件。由于数据表直接关系到业务是否能够正常执行，而每次更新该数据表都有可能造成业务不能正常执行，所以需要尽量控制该数据表的更新次数，但是同时，若数据表长时间不更新，也有可能导致需要根据新数据执行的业务无法正常执行，所以也不能长时间不进行数据表的更新，所以还需要在更新和不更新之间取得一个平衡点，该平衡点便是本申请所述的预设的条件。

具体的，在本申请中所述的该更新数据表与原有数据表的差异度，就是数据表中数据的变化程度，当该差异度达到一定的比例或者数量时，即认为若不更新该数据表则会导致需要根据新数据执行的业务无法正常执行，此时有必要更新该数据表，当该差异度未达到一定的比例或者数量时，则认为不更新该数据表更有利于业务的正常执行，即，由于该差异较小，没有必要花费资源进行更新。

需要说明的是，该预设条件可以通过大量的实验确定，或者通过人工经验设定，具体如何确定本申请并不做具体限定。

继续沿用上例，假设该更新数据表与原有数据表的差异度的预设条件为，满足差异度为10％，即该更新数据表中的数据有10％与该原有数据表中的数不一致。则根据表2可知，只要该更新BIN数据表中的数据与该原有BIN数据表中的数据有1个数据不同，则这两个数据表的差异度就大于10％，所以可以确定该更新BIN数据表中与原有BIN数据表的差异度满足预设条件。

更进一步的，步骤S107中，由于需要增加该测试业务量直至该测试业务量等于业务总量为止，所以可见这一过程较为漫长。而且此时由于同时需要根据更新缓存区和原有缓存区中的数据执行业务，所以对服务器的运行压力也较大，所以为了尽量使得步骤106～107的循环过程可以快速结束，在本申请步骤S107中，可以不等待该测试业务量等于业务总量，而是在增加测试业务量之后，判断该增加后的测试业务量是否超过预设业务量阈值，若是，则根据该更新缓存区中的数据执行全部业务，若否则，返回步骤S106继续监测该增加后的业务量的业务是否正常执行，直至测试业务量超过预设业务量阈值为止。即，当该测试业务量超过预设业务量阈值时，认为该更新缓存区中的数据可以正常执行全部的业务。

需要说明的是，该阈值可以通过大量的实验确定，也可由人工经验值来确定，具体如何确定本申请不做具体限定。

继续沿用上例，假设预设的阈值为业务总量的50％，当前根据更新缓存区中的数据执行测试业务量的业务为全部业务中40％的业务(即，测试业务量为业务总量的40％)，增加的测试业务量为20％。若监测当前测试业务量的业务可以正常执行后，由于该测试业务量并未达到预设的阈值，所以需要继续增加测试业务量。在增加测试业务量后，又由于此时测试业务量为60％(即，40％+20％)，达到了预设的阈值，于是可以根据该更新缓存区中的数据执行全部的业务。

基于图1所示的更新数据表时的业务执行过程，本申请实施例还提供了一种更新数据表时的业务执行装置，如图2所示。

图2是本申请实施例提供一种更新数据表时的业务执行装置的结构示意图，具体包括以：

接收模块201，用于接收更新数据表；

缓存模块202，用于新建更新缓存区；

写入模块203，用于将所述更新数据表内的数据写入所述更新缓存区；

拆分模块204，用于将业务总量拆分为测试业务量和正式业务量；

测试模块205，用于根据所述更新缓存区中的数据，执行测试业务量的业务，根据原有缓存区中的数据，执行所述正式业务量的业务；其中，所述原有缓存区中的数据为原有数据表内的数据；

监测执行模块206，用于监测所述测试业务量的业务是否正常执行；若正常则，增加测试业务量，并使所述监测模块继续监测测试业务量的业务是否正常执行，直至测试业务量等于业务总量为止；若不正常，则指示所述测试模块205停止根据所述更新缓存区中的数据执行测试业务量的业务，并根据所述原有缓存区中的数据执行全部业务。

所述写入模块203还用于，将所述更新数据表内的数据写入所述更新缓存区之前，确定所述更新数据表内的数据符合更新条件。

所述写入模块203具体用于，确定所述更新数据表与预设的数据表模型匹配，且，所述更新数据表与原有数据表的差异度满足预设的条件。

所述写入模块203具体用于，将所述更新数据表的标识与原有数据表的标识互换，根据互换后所述更新数据表的标识，将所述更新数据表内的数据写入所述更新缓存区。

所述测试模块205还用于，根据所述更新缓存区中的数据，执行测试业务量的业务之前，采用原有缓存区中的数据格式，调整所述更新缓存区中的数据格式。

所述监测执行模块206具体用于，增加测试业务量，判断增加后的测试业务量是否超过预设业务量阈值，若是，则根据所述更新缓存区中的数据执行全部业务，否则，使所述监测模块继续监测测试业务量的业务是否正常执行，直至测试业务量超过预设业务量阈值为止。

具体的，上述如图2所示的更新数据表时的业务执行装置可以位于服务器中，其中，该服务器可以是一个也可以是多个。当该服务器为多个的时候，具体还可以采用内容分发网络，建立多个服务器之间的联系，具体的实施方法本申请本不做限定。

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

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

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

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

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

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

Claims (12)

1.一种更新数据表时的业务执行方法，其特征在于，包括：

接收更新数据表；

新建更新缓存区；

将所述更新数据表内的数据写入所述更新缓存区；

将业务总量拆分为测试业务量和正式业务量；

根据所述更新缓存区中的数据，执行测试业务量的业务，根据原有缓存区中的数据，执行所述正式业务量的业务；其中，所述原有缓存区中的数据为原有数据表内的数据；

监测所述测试业务量的业务是否正常执行；

若正常，则增加测试业务量，并继续监测测试业务量的业务是否正常执行，直至测试业务量等于业务总量为止；

若不正常，则停止根据所述更新缓存区中的数据执行测试业务量的业务，并根据所述原有缓存区中的数据执行全部业务。

2.如权利要求1所述的方法，其特征在于，将所述更新数据表内的数据写入所述更新缓存区之前，所述方法还包括：

确定所述更新数据表内的数据符合更新条件。

3.如权利要求2所述的方法，其特征在于，确定所述更新数据表内的数据符合更新条件，具体包括：

确定所述更新数据表与预设的数据表模型匹配，且，所述更新数据表与原有数据表的差异度满足预设的条件。

4.如权利要求1所述的方法，其特征在于，将所述更新数据表内的数据写入所述更新缓存区，具体包括：

将所述更新数据表的标识与原有数据表的标识互换；

根据互换后所述更新数据表的标识，将所述更新数据表内的数据写入所述更新缓存区。

5.如权利要求1所述的方法，其特征在于，根据所述更新缓存区中的数据，执行测试业务量的业务之前，所述方法还包括：

采用原有缓存区中的数据格式，调整所述更新缓存区中的数据格式。

6.如权利要求1所述的方法，其特征在于，增加测试业务量，并继续监测测试业务量的业务是否正常执行，直至测试业务量等于业务总量为止，具体包括：

增加测试业务量；

判断增加后的测试业务量是否超过预设业务量阈值；

若是，则根据所述更新缓存区中的数据执行全部业务；

否则，继续监测测试业务量的业务是否正常执行，直至测试业务量超过预设业务量阈值为止。

7.一种更新数据表时的业务执行装置，其特征在于，包括：

接收模块，用于接收更新数据表；

缓存模块，用于新建更新缓存区；

写入模块，用于将所述更新数据表内的数据写入所述更新缓存区；

拆分模块，用于将业务总量拆分为测试业务量和正式业务量；

测试模块，用于根据所述更新缓存区中的数据，执行测试业务量的业务，根据原有缓存区中的数据，执行所述正式业务量的业务；其中，所述原有缓存区中的数据为原有数据表内的数据；

监测执行模块，用于监测所述测试业务量的业务是否正常执行；若正常则，增加测试业务量，并使所述监测模块继续监测测试业务量的业务是否正常执行，直至测试业务量等于业务总量为止；若不正常，则指示所述测试模块停止根据所述更新缓存区中的数据执行测试业务量的业务，并根据所述原有缓存区中的数据执行全部业务。

8.如权利要求7所述的装置，其特征在于，所述写入模块还用于，将所述更新数据表内的数据写入所述更新缓存区之前，确定所述更新数据表内的数据符合更新条件。

9.如权利要求8所述的装置，其特征在于，所述写入模块具体用于，确定所述更新数据表与预设的数据表模型匹配，且，所述更新数据表与原有数据表的差异度满足预设的条件。

10.如权利要求7所述的装置，其特征在于，所述写入模块具体用于，将所述更新数据表的标识与原有数据表的标识互换，根据互换后所述更新数据表的标识，将所述更新数据表内的数据写入所述更新缓存区。

11.如权利要求7所述的装置，其特征在于，所述测试模块还用于，根据所述更新缓存区中的数据，执行测试业务量的业务之前，采用原有缓存区中的数据格式，调整所述更新缓存区中的数据格式。

12.如权利要求7所述的装置，其特征在于，所述监测执行模块具体用于，增加测试业务量，判断增加后的测试业务量是否超过预设业务量阈值，若是，则根据所述更新缓存区中的数据执行全部业务，否则，使所述监测模块继续监测测试业务量的业务是否正常执行，直至测试业务量超过预设业务量阈值为止。