CN112445783A - 一种用于数据库更新的方法、装置和服务器 - Google Patents

Abstract

本申请提供了一种用于数据库更新的方法、装置和服务器。该方法包括：接收数据更新请求，所述数据更新请求中包括待更新数据的版本号、用户ID和待写入的业务数据；根据用户ID和待更新数据的版本号，确定是否接受该业务数据；在接受该业务数据的情况下，更新待更新数据的版本号，得到更新后的版本号，并向所述目标数据库发送该业务数据以及更新后的版本号。由于通过对比用户ID和待更新数据的版本号，确定是否接受数据更新请求，可以有效地降低在数据重发或者数据同步延迟的情况下出现数据混乱的可能，提高数据库的可靠性。

Description

一种用于数据库更新的方法、装置和服务器

技术领域

本申请涉及信息技术领域，更为具体地，涉及一种用于数据库更新的方法、装置和服务器。

背景技术

随着政企数据中台的建设不断完善，全国政企用户集中上收、一点维护，以政企用户中心作为数据中心，赋能省份销售触点。该数据中心可以由各地销售触点访问，比如更新业务数据、修改业务状态等。然而，在有些情况下，可能会出现数据混乱。

比如，触点A和触点B几乎同时对同一用户的业务数据进行更新。触点A的更新在前，触点B的更新在后。但由于触点A重复或同步延迟等原因，可能导致触点B可能并不是基于触点A更新后的业务数据进行的更新，由此导致数据混乱。

发明内容

本申请提供一种用于数据库更新的方法、装置和服务器，以期降低在数据重发或者数据同步延迟的情况下出现数据混乱的可能，提高数据库的可靠性。

第一方面，本申请提供了一种用于数据库更新的方法，该方法包括：

接收数据更新请求，所述数据更新请求中包括待更新数据的版本号、用户ID和待写入的业务数据，所述待更新数据是目标数据库中的数据，所述用户ID用于标识所述待更新数据所属的目标用户，所述业务数据用于对所述目标数据库中的所述待更新数据进行更新，所述待更新数据的版本号用于标识所述目标数据库中所述待更新数据的版本；

根据所述用户ID和所述待更新数据的版本号，确定是否接受所述业务数据；

在接受所述业务数据的情况下，更新所述待更新数据的版本号，得到更新后的版本号；

向所述目标数据库发送所述业务数据以及所述更新后的版本号。

本申请实施例通过对接收到的数据更新请求中的待更新数据的版本号与缓存库中的最新数据版本号进行比对，确定是否接受该数据更新请求。因此，可以有效地降低在数据重发或者数据同步延迟的情况下出现数据混乱的可能，提高数据库的可靠性。

可选地，所述数据更新请求中还包括业务类型标识，所述业务类型标识用于标识所述数据更新请求所涉及的业务类型。

可选地，所述根据所述用户ID和所述数据版本，确定是否接受所述业务数据，包括：

根据所述用户ID和所述数据版本号，从缓存库中查找所述目标用户的业务锁，所述业务锁与业务类型对应；

在所述数据更新请求所涉及的业务类型对应的业务锁处于开放状态的情况下，从所述缓存库中查找所述目标用户的数据版本号；

在所述目标用户的数据版本号与所述待更新数据的版本号相同的情况下，确定接受所述业务数据。

可选地，在所述数据更新请求所涉及的业务类型对应的业务锁处于锁定状态的情况下，确定不接受所述业务数据。

可选地，在所述目标用户的数据版本号与所述待更新数据的版本号不同的情况下，确定不接受所述业务数据。

可选地，所述业务锁包括以下一项或多项：订购锁、开机锁、变更锁、预销户锁和停机锁。

可选地，若所述目标用户为正在创建的新用户，所述目标用户的订购锁处于开放状态时，且所述目标用户的变更锁、停机锁和开机锁处于锁定状态。

可选地，若所述目标用户为已创建的用户，所述目标用户的订购锁、开机锁处于锁定状态，且所述目标用户的变更锁和停机锁处于开放状态。

可选地，若所述目标用户为停机用户，所述目标用户的开机锁处于开放状态，且所述目标用户的订购锁、停机锁和变更锁处于锁定状态。

应理解，所述待更新数据的版本号是从所述目标数据库中获取的版本号。

第二方面，本申请提供了一种用于数据库更新的装置，包括用于实现第一方面所述的用于数据库更新的方法的单元或模块。

第三方面，本申请提供了一种服务器，包括处理器，其中，所述处理器用于执行第一方面所述的用于数据库更新的方法。

第四方面，提供了一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机实现第一方面以及第一方面任一项中所述的方法。

第五方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当所述计算机程序被运行时，使得计算机执行第一方面以及第一方面任一项中所述的方法。

应当理解的是，本申请的第二方面至第五方面与本申请的第一方面的技术方案相对应，各方面及对应的可行实施方式所取得的有益效果相似，不再赘述。

附图说明

图1为适用于本申请提供的用于数据库更新的方法的网络架构；

图2为政企中台的架构图；

图3为本申请实施例提供的用于数据库更新的方法的示意性流程图；

图4为一种可能的存储一个用户的业务锁以及数据版本号的示意图；

图5为一种可能的存储多个用户的业务锁以及数据版本号的示意图；

图6为单触点数据并发的场景；

图7为多触点数据并发的场景；

图8为本申请实施例提供的用于数据库更新的装置的示意性框图；

图9为本申请实施例提供的用于数据库更新的装置的又一示意性框图。

具体实施方式

下面将结合附图，对本申请中的技术方案进行描述。

本申请提供的方法可以应用在多媒体数据库、移动数据库、空间数据库、信息检索系统、分布式信息检索、专家决策系统等多种领域的数据库更新中。其中，多媒体数据库主要存储与多媒体相关的数据，比如声音、图像和视频等数据；移动数据库可以是掌上计算机、笔记本电脑以及手机等通过无线数字通信网络传输的数据；空间数据库可以包括地理信息数据库(又称为地理信息系统)和计算机辅助设计(computer aided design，CAD)数据库(其中地理信息数据库一般存储与地图相关的信息数据；计算机辅助设计数据库一般存储设计信息的空间数据库，如机械、集成电路以及电子设备设计图等)；信息检索系统包括联机文档管理系统或联机图书目录等；分布式信息检索一般用于因特网及远距离计算机网络系统中，许多网络用户(如个人、公司或企业等)在自己的计算机中存储信息，同时希望通过网络使用发送电子邮件、文件传输、远程登录方式和别人共享这些信息；专家决策系统用于联机获取数据，使得企业通过这些数据可以对企业的发展做出更好的决策，以使企业更好地运行。

本申请提供的方法所涉及到的数据库可以是键-值(key-value，K-V)数据库，例如可以是关系型数据库，比如关系型数据库服务(relational database service，RDS)，也可以是非关系型数据库，比如远程字典服务(remote dictionary server，REDIS)等。本申请实施例对此不作限定。该数据库例如还可以但不限于是，微软关系型数据库管理系统Access、结构化查询语言服务器(structured query language server，SQLServer)、开放源代码的关系型数据库管理系统MySQL、甲骨文数据库(oracle database)以及轻型数据库(SQLite)等数据库。

为便于理解本申请实施例，首先结合图1详细说明适用于本申请提供的用于数据库更新的方法的网络架构。如图1所示，该网络架构100可以包括服务器110、数据库120和客户端131和132。其中，客户端131和132可通过服务器110提供的访问接口访问数据库120。所述访问接口例如可以是服务平台，客户端131和132可通过在服务平台中发起创建、修改和/或更新等请求，来实现对数据库120的访问。

应理解，图中仅为示意，本申请对服务器、客户端和数据库的数量均不作限定。比如，客户端也可以为一个或多个。服务器可以部署在一台物理设备中，也可以部署在多台物理设备中，形成服务器集群。数据库可以是一个，也可以是多个。该一个或多个数据库也可以部署在一台或多台物理设备中。或者，服务器和数据库还可以部署在云端。

如图1所示的架构例如可以用于政企中台中。图2示出了政企中台的架构图。如图2所示，其中，政企用户中心应用210可提供服务平台，例如可以由图1所示的服务器110来实现相应功能。目标数据库221和缓存库222可对应于图1所示的数据库120。目标数据库221和缓存库222可相互分离。各销售触点2301至230n，如图中所示的A省份销售触点2301、B省份销售触点2302、总部标准销售触点2303、移动端销售触点2304及其他销售触点230n等可对应于图1中的客户端131和132。

各销售触点2301至203n与政企用户中心应用210之间、政企用户中心应用210与目标数据库221之间、政企用户中心应用210与缓存库222之间、目标数据库221和缓存库222之间可以通信连接。

应理解，由于目标数据库221中存储了所有用户的业务数据，是各销售触点2301至230n访问的目标，因此为便于区分，将其命名为目标数据库。目标数据库221与缓存库222在本质上都是数据库，只是基于不同的功能定义了不同的名称。

在介绍本申请实施例之前，首先对本申请中涉及到的术语作简单说明。

1、销售触点：指品牌、产品、服务等在各个方面各个环节与用户的接触点。在本申请实施例中销售触点可以包括但不限于，移动端销售触点、省分门户、地市门户以及总部门户等。

2、用户标识(identifier，ID)：在数据库中也作为主关键字(primary key)，简称主键。用户ID可用于在数据库中能够唯一地标识一个用户。换言之，用户ID是全局唯一的。

3、数据版本号(version number)：是每个版本的标识号。在本申请实施例中，版本号可用于标识不同的数据版本。在本申请实施例中，可以为每个用户ID对应的业务数据设置版本号，业务数据每一次更新，所对应的版本号也会自动更新，比如自动加一。

在本申请实施例中，数据版本号可简称为版本号。

应理解，版本号仅为一种可能的命名，例如也可以称为批次号。本申请并不排除采用其他的命名来表达相同或相似含义的可能。

如图2中所示的政企中台，因多个销售触点都可以访问其数据库，例如可执行创建业务、更新业务数据等操作，因此可能因同步延迟等原因导致数据出现混乱。

本申请实施例提供了一种用于数据库更新的方法，以数据库中的用户为粒度，通过用户ID和数据版本号来判断是否接受对数据库的更新，从而可以使得每一次对数据库的更新都是基于最新版本的业务数据所进行的更新，避免数据出现混乱。

应理解，该用户ID可用于指示该业务数据所对应的用户。每个用户ID在数据库中是唯一的，可理解为上文所述的K-V数据库中的主键。当然，该用户ID也可以替换为其他可用于唯一指示一个用户的形式，本申请实施例对此不作限定。

为便于理解，下文结合图2所示的架构来描述本申请实施例所提供的方法。应理解，图3所示的方法可以由服务器来执行，具体可以是图2中所示的政企用户中心应用来执行。示例性地，服务器可通过部署在缓存库与目标数据库之间部署的判断逻辑来实现相应的功能。本质上说，该判断逻辑可通过服务器执行相应的代码来实现。

下面将结合图3详细说明本申请实施例提供的用于数据库更新的方法。

图3为本申请实施例提供的用于数据库更新的方法300的示意性流程图。如图3所示，该方法300可以包括步骤310至步骤360。

在步骤310中，服务器接收数据更新请求，该数据更新请求中包括用户ID、待更新数据的版本号和待写入的业务数据。

该数据更新请求可以是从客户端接收到的数据，该客户端可以是图2中所示的销售触点中的任意一个或多个。为了方便说明，本实施例中以接收到来自一个销售触点的数据更新请求为例来描述该方法。

其中，待更新数据具体可以是指目标数据库中的数据，如图2中所示的销售触点可以从目标数据库中读取到的数据，也就是销售触点去目标数据库读取数据时能够读取到的最新版本的数据。应理解，销售触点可以从目标数据库读取到数据，并不代表销售触点从目标数据库读取了数据。这里只是为了便于说明待更新数据的版本号，对待更新数据做了相应的说明。

业务数据可用于更新数据库中的待更新数据，待更新数据的版本号可用于标识该数据库中待更新数据的版本。

需要说明的是，由于数据一旦被写入数据库中，随时可能会被新接收到的数据更新，因此将其命名为待更新数据。待更新数据只是为了和新接收到的数据区分而命名，不应构成任何限定。

用户ID可用于标识待更新数据所属的目标用户。换言之，该待更新数据是该目标用户的数据。或者说，该待更新数据与目标用户ID相对应。

可选地，该方法还包括：步骤320，销售触点从目标数据库获取待更新数据的版本号。

示例性地，销售触点可以根据用户ID在目标数据库中查找待更新数据的版本号。

该待更新数据的版本号例如可以是自然数0、1、2等，每一次数据更新，版本号可自动加一。例如，当某一销售触点新增数据更新请求时，版本号可以为0；经过第一次更新数据后，版本号可以为1，经过第二次更新数据后，版本号可以为2等，以此类推。

应理解，此处仅为便于理解，示例性地示出了一种可能的版本号及其更新的方式，但这并不应对本申请构成任何限定。该版本号还可以是罗马数字、英文字母等，该版本号的更新也可以按照预定义的方式来实现，比如，罗马数字也可以基于每一次更新自动加一。本申请对此不作限定。

在步骤330中，服务器根据用户ID和待更新数据的版本号，确定是否接受该业务数据。

在一种可能的实现方式是，服务器可以根据用户ID，在缓存库中查找相应的数据版本号，并在缓存库中目标用户的数据版本号与待更新数据的版本号相同的情况下，确定接受该业务数据；缓存库中目标用户的数据版本号与待更新数据的版本号不同的情况下，确定不接受该业务数据。

需要说明的是，目标数据库中的数据的版本号可以由缓存库维护。缓存库中的数据版本号代表了目标数据库中最新数据的版本号。与目标数据库中的数据版本号相似，数据的每一次更新，数据版本号也随之更新。

若缓存库中的数据版本号与接收到的待更新数据的版本号相同，则表示该业务数据是基于目标数据库中最新版本的数据进行的更新。该更新是可以接受的，也即，该业务数据可以接受。

若缓存库中的数据版本号与接收到的待更新数据的版本号不同，则表示该业务数据不是基于目标数据库中最新版本的数据进行的更新。该更新是不可接受的，也即，该业务数据不可接受。

因此，基于对待更新数据的版本号和缓存库中的数据版本号的比对，便可以确定是否接受该业务数据。

一示例，当触点A和触点B几乎同时对同一用户的业务数据进行更新。触点A的更新在前，触点B的更新在后。但由于触点A重复或同步延迟等原因，可能导致触点B可能并不是基于触点A更新后的业务数据进行的更新，此时可能会出现触点B更改的业务数据与目标数据库中的最新数据不一致的情况，即触点B携带的待更新数据的版本号与缓存库中目标用户的数据版本号不一致的情况，则此时可以确定不接受来自触点B的业务数据。

可选地，当该数据更新请求用于新创建用户时，则服务器根据该用户ID，无法在缓存库中查找相应的数据版本号。换言之，在目标数据库中不存在该用户ID对应的数据。在这种情况下，一种可能的方法是，服务器可以向客户端或者客户端所在触点确定该用户是否为新创建，若是新创建用户，则在目标数据库中为该用户ID创建相应的数据版本号，例如可以是对应上文中序列号为0时，序列号、密钥以及固定位数随机数加密后的版本号。本申请实施例在此不作限定。

进一步地，该数据更新请求中还可携带业务类型标识，该业务类型标识用于标识该数据更新请求所涉及的业务类型。这里，数据更新请求所涉及的业务类型，具体可以是指，该数据更新请求中请求对目标数据库中业务数据的更新所涉及的业务类型，或者说，对待更新数据的更新所涉及的业务类型。

例如，该业务类型可以包括但不限于订购、开机、变更、预销户和停机等。该数据更新请求所涉及的业务类型包括以下一项或多项：订购、开机、变更、预销户和停机。

可选地，该业务类型标识可以直接以该业务类型本身，或者也可以是可用于唯一标识该业务类型的信息，比如，该业务类型的首字母、或者预定义的可用于标识该业务类型的数值等。本申请对此不作限定。

基于业务类型标识，步骤330的另一种可能的实现方式是：服务器根据用户ID和数据版本号，从缓存库中查找目标用户的业务锁。其中，该业务锁可以与业务类型对应。示例性地，该业务锁也可以包括以下一项或多项：订购锁、开机锁、变更锁、预销户锁和停机锁。

另外，业务锁的状态可以包括开放和锁定这两种状态。其中，开放状态的业务锁可表示所对应的业务可进行数据更新，锁定状态的业务锁可表示所对应的业务不可进行数据更新。

一种可能的设计是，当业务锁置为“0”时，可表示业务锁状态为开放状态，当业务锁置为“1”时，可表示业务锁状态为锁定状态。应理解，“0”和“1”仅为业务锁的两种不同状态的指示方式，而不应对本申请构成任何限定。比如还可以通过“on”和“off”或其他标识来区分每个业务锁的两种状态。

由于业务类型之间可能存在相关性，当业务处于某一阶段时，与之相关的一项或多项业务类型都可以进行数据更新，与之对应的一个或多个业务锁都可以处于开放状态。

下文示例性地给出了各种业务锁之间的关联关系以及所对应的应用场景。

例如，若目标用户为正在创建的新用户，该目标用户的订购锁处于开放状态时，且该目标用户的变更锁、停机锁和开机锁处于锁定状态。

当针对某一用户办理业务时，若业务锁还不存在，则可针对办理业务锁针对的用户，自动创建业务锁。此用户的业务锁中，订购锁处于开放状态、变更锁、停机所、开机锁处于锁定状态。此时只能办理产品订购。

又例如，若目标用户为已创建的用户，该目标用户的订购锁和开机锁可以处于锁定状态，且该目标用户的变更锁和停机锁可以处于开放状态。

当针对某一用户办理了产品订购后，该用户为已创建的用户，该用户的业务锁已存在。该用户的业务锁中，订购锁和开机锁可以处于锁定状态，停机锁和变更锁可以处于开放状态，并插入初始的数据版本号。

当针对某一用户办理完业务后，业务锁可以不变，数据版本号可以更新。

当针对某一用户办理了开机业务后，该用户的业务锁中，订购锁和开机锁可以处于锁定状态，停机锁和变更锁可以处于开放状态，数据版本号可以更新。

再例如，若目标用户为停机用户，该目标用户的开机锁处于开放状态，且该目标用户的订购锁、停机锁和变更锁处于锁定状态。

当针对某一用户办理了停机业务后，该用户的业务锁中，订购锁、停机锁和变更锁可以处于锁定状态，锁定、开机锁可以处于开放状态，数据版本号可以更新。

应理解，上文列举的各种不同场景下，各业务锁的开放状态和锁定状态仅为示例，不应对本申请构成任何限定。此外，除上述业务正规流程变更锁外，业务锁也可通过外围信控、规则等接口的实时通知锁状态变更，来实现特殊处理场景。比如，某用户为特殊号码，可将该用户的停机锁设置为锁定状态，该用户不会停机。

可选地，目标用户的业务数据每进行一次更新，所对应的版本号也会自动更新，比如自动加一。

应理解，以上仅为示例性地列举出几种可能的不同业务类型下业务锁的状态，而不应对本申请构成任何限定。

可选地，在信控规则等通知业务锁状态变更的情况下，上述业务锁可以根据该通知进行相应变更。

示例性地，若目标用户为特殊用户，且该目标用户的停机锁在任何业务类型下均为锁定状态，则该目标用户无法进行停机操作。应理解，此处仅为便于理解，而不应对本申请构成任何限定。

由于业务锁处于锁定状态时可以表示所对应的业务不可进行数据更新，也就可以表示数据库不接受对此类业务的数据更新。因此，在接收到数据更新请求后，可以先根据其中包括的业务类型标识，确定是否接受更新。例如可以基于用户ID在缓存库中查找到目标用户的业务锁，并进一步查找与该业务类型标识所标识的业务锁是否处于开放状态，若处于开放状态可进一步查找数据版本号，以确定是否接受该业务数据；若处于锁定状态可直接确定不接受该业务数据。

应理解，此处在缓存库中维护有目标用户的业务锁和数据版本号的目的在于快速判断是否接受该用户ID的数据。该业务锁和数据版本号也可以在目标数据库中进行维护，本申请在此不作限定。

为便于理解，下面结合图4和图5来说明业务锁和数据版本号。

示例性地，图4示出了缓存库中某一用户(此处以用户ID为A(记为用户ID_A，简称为用户A)的用户为例)的业务锁以及该用户的数据版本号的示意图。

由图4中的数据版本号“0”可以推断，用户A为新创建的用户，用户A的变更锁和停机锁处于开放状态，订购锁和开机锁处于锁定状态。图4仅为示例，对于业务锁，用“0”表示开放状态，“1”表示锁定状态。示例性地，图5示出了缓存库中的两个用户(此处以用户ID为A和B的两个用户(记为用户ID_A和用户ID_B，简称为用户A和用户B)为例)的业务锁以及每个用户的数据版本号的示意图。

由图5中两个用户的数据版本号“2”和“1”分别可以推断，用户A和B均为已创建的用户。另外，图5中用户A和B的业务锁仅为示例，可参考上文相关说明，为了简洁，此处不再赘述。

基于上述对用户ID、业务锁和数据版本号的相关说明可以看到，服务器在接收到数据更新请求时，首先基于数据更新请求中的用户ID去缓存库查找相同的用户ID。若查找不到该用户ID，则表示为新增用户的数据，可基于该数据更新请求创建用户，该新增用户的订购锁处于开放状态，且变更锁、停机锁和开机锁处于锁定状态，数据版本号可以为0；若查找到该用户ID，可以进一步根据数据更新请求中的业务类型标识，确定缓存库中相应的业务锁是否处于开放状态。若处于锁定状态，可确定不接受该业务数据；若处于开放状态，可进一步从缓存库中查找数据版本号。在数据版本号与数据更新请求中的待更新数据的版本号相同的情况下，确定接受该业务数据，在数据版本号与数据更新请求中的待更新数据的版本号不同的情况下，确定不接受该业务数据。

从另一个角度来说，数据版本号也可以视为与业务锁具有相同功能的锁。业务锁是从业务类型的角度来控制数据更新，数据版本号则是从数据版本的角度来控制数据更新。该数据版本号可以称为数据版本号锁。业务锁与数据版本号锁的结合使用可以称为多维锁。其中，一维锁是业务锁，二维锁是数据版本号锁。

基于上述判断，服务器在确定接受业务数据的情况下，可执行下述步骤340和步骤350；在确定不接受业务数据的情况下，可执行步骤360。

在步骤340中，更新待更新数据的版本号，得到更新后的版本号。

如前所述，数据版本号可以基于每一次数据更新也自动更新，比如自动加一。服务器可以将数据版本号更新后保存在缓存库中。在步骤350中，服务器向目标数据库发送业务数据以及更新后的版本号。

服务器可以将数据更新请求中的业务数据和更新后的版本号一同发送至目标数据库。也即，对目标数据库中该目标用户的业务数据(也即，上文所述的待更新数据)和数据版本号(也即，上文所述的待更新数据的版本号)进行刷新。

在步骤360中，服务器拦截该数据更新请求。

应理解，拦截，可以是指服务器接收到数据更新请求后，不再将其中的业务数据等发送至目标数据库，或者说，写入目标数据库，同时也不更新缓存库中的数据版本号。

可选地，该方法还包括：服务器发送失败提示。

服务器可以向发送上述数据更新请求的客户端(如，销售触点)返回失败提示，该设备提示例如可以是验证失败、更新失败、请重试等。应理解，此处对失败提示的示例仅为便于理解而示出，而不应对本申请构成任何限定。

因此，本申请实施例通过对接收到的数据更新请求中的待更新数据的版本号与缓存库中的最新数据版本号进行比对，确定是否接受该数据更新请求中的业务数据，可以有效地降低在数据重发或者数据同步延迟的情况下出现数据混乱的可能，提高数据库的可靠性。

另外，提高引入业务锁，将同一个用户的多个的业务类型相关联。业务锁和数据版本号可以从业务类型和数据版本这两个维度来控制数据更新。如果该业务更新请求所涉及的业务类型对应的业务锁处于锁定状态，则无需进一步对版本号进行比对，即可将该数据更新请求拦截。因此从整体而言，可以高效、有序地控制数据库的数据更新。

进一步地，为了避免数据的版本号被篡改，上文所述的待更新数据的版本号可以是加密的版本号。换言之，上述步骤320中销售触点从目标数据库获取到的待更新数据的版本号是加密的版本号。该加密的版本号可以是服务器基于缓存库中维护的最新的数据版本号进行加密后发送至目标数据库的。也就是说，该版本号可以以密文的形式保存在目标数据库中，并可基于销售触点的访问，被发送给销售触点。

一种可能的加密方式是，对序列号、密钥以及固定位数随机数进行加密。其中，序列号可以有一定的排序规律，例如可以是自然数。本申请实施例在此不作限定。例如，用户新增时，对序列号为0的版本号进行加密，每修改一次，对序列号自动加一之后的版本号进行加密。

基于上述设计，该待更新数据的版本号可能仅对服务器可见，对外不可见。服务器可以基于预定义的算法和/或密钥，对该版本号进行加密后发送至目标数据库保存。每一次数据更新，版本号都可以随之更新，每一次更新的版本号都可以经加密后被发送至目标数据库保存。可以理解的是，每一次更新后的版本号的密文被发送至目标数据库后，都可对前一次保存的版本号的密文进行刷写，或者说，每一次更新后的版本号用于替代前一次保存在目标数据库中的版本号。

应理解，对版本号进行加密可以有效地防止第三方通过对上述版本号的自动更新方式预测待更新数据的版本号，并篡改数据导致数据丢失，从而可以提高该目标数据库的安全性。

为了便于理解，下面结合图6和图7两个具体的场景来描述本申请实施例提供的方法。

图6为单触点数据并发的场景。如图6所示，示例性的给出了当销售触点A连续并发给服务器两条及以上的用户订购的情况。

当服务器第一次接收到某一用户的订购请求(即，数据更新请求的一例)后，确定该操作为用户订购，且查询不到该用户的用户ID，则可确定该用户为新增用户。服务器可以为该用户创建业务锁和版本号。在这种情况下，示例性地，缓存库中本地维护的该用户的业务锁和版本号如图4所示，订购锁、开机锁为锁定状态，变更锁、停机锁为开放状态。

当服务器第二次接收到针对同一用户的订购请求(即，数据更新请求的另一例)后，可根据用户ID查找到该用户的业务锁。由于该用户的订购锁已为锁定状态。服务器可以拦截该订购请求。可选地，服务器向客户端返回失败提示。

当服务器第三次接收到针对同一用户的产品变更请求(即，数据更新请求的又一例)时，可根据用户ID查找到该用户的业务锁。由于该用户的变更锁为开放状态，可继续查找该用户的数据版本号。如果该产品变更请求中携带的待更新数据的版本号与缓存库中查找到的数据版本号相同，则可接受该产品变更请求，数据版本号随之更新；如果该产品变更请求中携带的待更新数据的版本号与缓存库中查找到的数据版本号不同，则可以拦截该产品变更请求。

图7为多触点数据并发的场景，此处以两个触点为例。如图7所示，销售触点A和销售触点B同时向服务器发送针对用户A的产品变更的情况。

当服务器第一次接收到的产品变更请求(即，数据更新请求的一例)来自销售触点A时，假设缓存库中的变更锁处于开放状态，且该产品变更请求中的待更新数据的版本号与缓存库中的数据版本号相同。服务器确定可以接受该产品变更请求，则可基于该销售触点A的产品变更请求，将业务数据和更新后的版本号等发送至目标数据库。

当服务器接收到销售触点B发送的针对用户A的产品变更请求(即，数据更新请求的又一例)时，缓存库中的变更锁仍然处于开放状态，无法对该产品变更请求进行拦截。但由于销售触点A对该用户A的数据更新同步可能存在延迟，销售触点B发送的产品变更请求中待更新数据的版本号与为缓存库中该用户A的数据版本号不同，服务器可以拦截该产品变更请求。可选地，服务器向销售触点B返回失败提示。

应理解，上文仅为便于理解，示例性地给出了两种具体的场景来描述本申请实施例提供的方法，但这并不应对本申请实施例所适用的范围构成任何限定。

图8是本申请实施例提供的用于数据库更新的装置的示意性框图。如图8所示，该用于数据库更新的装置800可以包括处理单元810和通信单元820。

通信单元820可用于接收数据更新请求，所述数据更新请求中包括待更新数据的版本号、用户ID和待写入的业务数据，所述待更新数据是目标数据库中的数据，所述用户ID用于标识所述待更新数据所属的目标用户，所述业务数据用于对所述目标数据库中的所述待更新数据进行更新，所述待更新数据的版本号用于标识所述目标数据库中所述待更新数据的版本。

处理单元810可用于根据所述用户ID和所述待更新数据的版本号，确定是否接受所述业务数据，并在接受所述业务数据的情况下，更新所述待更新数据的版本号，得到更新后的版本号。

通信单元820可用于向所述目标数据库发送所述业务数据以及所述更新后的版本号。

可选地，所述数据更新请求中还包括业务类型标识，所述业务类型标识用于标识所述数据更新请求所涉及的业务类型。

可选地，该处理单元810具体用于：

根据所述用户ID和所述待更新数据的版本号，从缓存库中查找所述目标用户的业务锁，所述业务锁与业务类型对应；

在所述数据更新请求所涉及的业务类型对应的业务锁处于开放状态的情况下，从所述缓存库中查找所述目标用户的数据版本号；

在所述目标用户的数据版本号与所述待更新数据的版本号相同的情况下，确定接受所述业务数据。

可选地，该处理单元810还可用于在数据更新请求所涉及的业务类型对应的业务锁处于锁定状态的情况下，确定不接受所述业务数据。

可选地，该处理单元810还可用于在所述目标用户的数据版本号与所述待更新数据的版本号不同的情况下，确定不接受所述业务数据。

其中，所述业务锁包括以下一项或多项：订购锁、开机锁、变更锁、预销户锁和停机锁。

可选地，若所述目标用户为正在创建的新用户，所述目标用户的订购锁处于开放状态时，且所述目标用户的变更锁、停机锁和开机锁处于锁定状态。

可选地，若所述目标用户为已创建的用户，所述目标用户的订购锁、开机锁处于锁定状态，且所述目标用户的变更锁和停机锁处于开放状态。

可选地，若所述目标用户为停机用户，所述目标用户的开机锁处于开放状态，且所述目标用户的订购锁、停机锁和变更锁处于锁定状态。还应理解，所述待更新数据的版本号是从所述目标数据库中获取的版本号。

应理解，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。另外，在本申请各个实施例中的各功能单元可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

图9是本申请实施例提供的用于数据库更新的装置的又一示意性框图。

如图9所示，该装置900可以包括至少一个处理器910和通信接口930，用于实现本申请实施例提供的方法中服务器的功能。

示例性地，通信接口930可用于接收数据更新请求，还可用于向所述目标数据库发送所述业务数据以及所述更新后的版本号；处理器910可用于根据所述用户ID和所述待更新数据的版本号，确定是否接受所述业务数据，还可用于在接受所述业务数据的情况下，更新所述待更新数据的版本号，得到更新后的版本号。具体参见方法示例中的详细描述，此处不做赘述。

该装置900还可以包括至少一个存储器920，用于存储程序指令和/或数据。存储器920和处理器910耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器910可能和存储器920协同操作。处理器910可能执行存储器920中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。

该装置900还可以包括通信接口930，用于通过传输介质和其它设备进行通信，从而用于装置900中的装置可以和其它设备进行通信。示例性地，当该装置900用于实现实施例中服务器的功能时，该其它设备可以是客户端、缓存库或目标数据库。所述通信接口930例如可以是收发器、接口、总线、电路或者能够实现收发功能的装置。处理器910可利用通信接口930收发数据和/或信息，并用于实现图3对应的实施例中所述的用于数据库更新的方法。

本申请实施例中不限定上述处理器910、存储器920以及通信接口930之间的具体连接介质。本申请实施例在图9中以处理器910、存储器920以及通信接口930之间通过总线940连接。总线940在图9中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

在一种可能的设计中，上述结合图8和图9所示的装置可以是服务器，或者也可以是配置在服务器中的部件，如芯片、芯片系统等。本申请实施例对此不作限定。

本申请还提供一种计算机程序产品，所述计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当所述计算机程序被运行时，使得计算机执行图3所示实施例中的方法。

本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序(也可以称为代码，或指令)。当所述计算机程序被运行时，使得计算机执行图3所示实施例中的方法。

应理解，本申请实施例中的处理器可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(digitalsignal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

还应理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rateSDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(directrambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

本说明书中使用的术语“单元”、“模块”等，可用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各种说明性逻辑块(illustrative logical block)和步骤(step)，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。在本申请所提供的几个实施例中，应该理解到，所揭露的装置、设备和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

在上述实施例中，各功能单元的功能可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令(程序)。在计算机上加载和执行所述计算机程序指令(程序)时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种用于数据库更新的方法，其特征在于，包括：

接收数据更新请求，所述数据更新请求中包括待更新数据的版本号、用户ID和待写入的业务数据，所述待更新数据是目标数据库中的数据，所述用户ID用于标识所述待更新数据所属的目标用户，所述业务数据用于对所述目标数据库中的所述待更新数据进行更新，所述待更新数据的版本号用于标识所述目标数据库中所述待更新数据的版本；

根据所述用户ID和所述待更新数据的版本号，确定是否接受所述业务数据；

在接受所述业务数据的情况下，更新所述待更新数据的版本号，得到更新后的版本号；

向所述目标数据库发送所述业务数据以及所述更新后的版本号。

2.如权利要求1所述的方法，其特征在于，所述数据更新请求中还包括业务类型标识，所述业务类型标识用于标识所述数据更新请求所涉及的业务类型；以及

所述根据所述用户ID和所述待更新数据的版本号，确定是否接受所述业务数据，包括：

根据所述用户ID和所述待更新数据的版本号，从缓存库中查找所述目标用户的业务锁，所述业务锁与业务类型对应；

在所述数据更新请求所涉及的业务类型对应的业务锁处于开放状态的情况下，从所述缓存库中查找所述目标用户的数据版本号；

在所述目标用户的数据版本号与所述待更新数据的版本号相同的情况下，确定接受所述业务数据。

3.如权利要求2所述的方法，其特征在于，所述方法还包括：

在所述数据更新请求所涉及的业务类型对应的业务锁处于锁定状态的情况下，确定不接受所述业务数据。

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

在所述目标用户的数据版本号与所述待更新数据的版本号不同的情况下，确定不接受所述业务数据。

5.如权利要求2所述的方法，其特征在于，所述业务锁包括以下一项或多项：订购锁、开机锁、变更锁、预销户锁和停机锁。

6.如权利要求5所述的方法，其特征在于，若所述目标用户为正在创建的新用户，所述目标用户的订购锁处于开放状态时，且所述目标用户的变更锁、停机锁和开机锁处于锁定状态；

若所述目标用户为已创建的用户，所述目标用户的订购锁、开机锁处于锁定状态，且所述目标用户的变更锁和停机锁处于开放状态；

若所述目标用户为停机用户，所述目标用户的开机锁处于开放状态，且所述目标用户的订购锁、停机锁和变更锁处于锁定状态。

7.如权利要求1所述的方法，其特征在于，所述待更新数据的版本号是从所述目标数据库中获取的版本号。

8.一种用于数据库更新的装置，其特征在于，包括用于实现如权利要求1至7中任一项所述的方法的单元。

9.一种服务器，其特征在于，包括处理器，所述处理器用于执行权利要求1至7中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述存储介质存储有指令，当该指令在计算机上运行时，使得计算机执行权利要求1至7中任一项所述的方法。

Images