业务数据的处理方法、装置及电子设备

技术领域

本申请涉及数据处理技术领域，尤其涉及一种业务数据的处理方法、装置及电子设备。

背景技术

基于集群的业务系统中，业务数据存储在业务数据库中。集群中的各节点均可以访问业务数据库，并对业务数据进行查询、修改、删除等操作。实际应用中，经常出现多个节点对同一业务数据进行修改的情况，导致不同节点对业务数据的修改相互覆盖。

相关技术中，可以采用数据库乐观锁的方式对业务数据进行版本控制。具体的，在业务数据库中为每个业务数据维护一个最新版本标识。每个节点在对业务数据进行修改之前，先从业务数据库中查询得到业务数据的当前版本标识，然后再对业务数据进行修改。在对修改内容进行保存之前，再次从业务数据库中查询业务数据的当前版本标识，在本次查询到的版本标识与上次查询到的版本标识一致的情况下，才对修改内容进行保存。

然而，发明人在实现本申请的过程中发现，在集群场景中业务数据修改的并发性较高，采用上述数据库乐观锁的方式，会导致业务数据库的访问频次较高，消耗较多的数据库资源，进而降低整个集群业务系统的业务性能，甚至导致整个集群业务系统崩溃。

发明内容

本申请提供一种业务数据的处理方法、装置及电子设备，用以降低业务数据库的资源消耗，提升集群业务系统的业务性能。

第一方面，本申请提供一种业务数据的处理方法，应用于集群业务系统中的第一节点，所述方法包括：

接收终端设备发送的修改请求，所述修改请求包括：待修改的第一业务数据的标识、所述第一业务数据的修改内容、以及对所述第一业务数据的修改所基于的第一版本标识；

根据所述第一业务数据的标识，从所述第一节点对应的缓存数据库中获取所述第一业务数据对应的第二版本标识，所述集群业务系统中不同节点对应的缓存数据库不同；

若确定所述第一版本标识与所述第二版本标识相同，则将所述第一业务数据的修改内容更新至业务数据库中。

一种可能的实现方式中，将所述第一业务数据的修改内容更新至业务数据库中，包括：

将所述第一业务数据的状态设置为已锁定状态；

将所述第一业务数据的修改内容更新至业务数据库中；

将所述第一业务数据的状态设置为未锁定状态。

一种可能的实现方式中，将所述第一业务数据的状态设置为已锁定状态，包括：

若所述第一业务数据的状态为未锁定状态，则将所述第一业务数据的状态设置为已锁定状态。

一种可能的实现方式中，所述方法还包括：

若所述第一业务数据的状态为已锁定状态，则生成第一提示信息，所述第一提示信息用于提示用户所述第一业务数据正在被其他节点修改；

向所述终端设备发送所述第一提示信息。

一种可能的实现方式中，所述方法还包括：

若确定所述第一版本标识与所述第二版本标识不同，则生成第二提示信息，所述第二提示信息用于指示用户所述第一业务数据的内容已被其他节点修改；

向所述终端设备发送所述第二提示信息。

一种可能的实现方式中，将所述第一业务数据的修改内容更新至业务数据库中之后，还包括：

生成所述第一业务数据对应的第三版本标识；

将所述缓存数据库中存储的所述第二版本标识更新为所述第三版本标识。

一种可能的实现方式中，将所述缓存数据库中存储的所述第二版本标识更新为所述第三版本标识之后，还包括：

根据所述修改请求的类型，生成所述修改请求对应的响应消息，当所述修改请求的类型为预设类型时，所述响应消息中包括所述第三版本标识；

向所述终端设备发送所述响应消息。

一种可能的实现方式中，接收终端设备发送的修改请求之前，还包括：

接收所述终端设备发送的查询请求，所述查询请求包括所述第一业务数据的标识；

根据所述第一业务数据的标识，从所述业务数据库中或者从所述缓存数据库中获取所述第一业务数据的当前内容；

根据所述第一业务数据的标识，从所述缓存数据库中获取所述第一业务数据的当前版本标识；

向所述终端设备发送所述第一业务数据的当前内容和所述第一业务数据的当前版本标识。

一种可能的实现方式中，所述第一节点中部署有拦截程序和业务应用程序，接收终端设备发送的修改请求，包括：

通过所述拦截程序拦截所述终端设备发送的修改请求；

根据所述第一业务数据的标识，从所述第一节点对应的缓存数据库中获取所述第一业务数据对应的第二版本标识，包括：

通过所述拦截程序根据所述第一业务数据的标识，从所述第一节点对应的缓存数据库中获取所述第一业务数据对应的第二版本标识；

若确定所述第一版本标识与所述第二版本标识相同，则将所述第一业务数据的修改内容更新至业务数据库中，包括：

若通过所述拦截程序确定所述第一版本标识与所述第二版本标识相同，则通过所述业务应用程序将所述第一业务数据的修改内容更新至业务数据库中。

第二方面，本申请提供一种业务数据的处理装置，应用于集群业务系统中的第一节点，所述装置包括：

接收模块，用于接收终端设备发送的修改请求，所述修改请求包括：待修改的第一业务数据的标识、所述第一业务数据的修改内容、以及对所述第一业务数据的修改所基于的第一版本标识；

获取模块，用于根据所述第一业务数据的标识，从所述第一节点对应的缓存数据库中获取所述第一业务数据对应的第二版本标识，所述集群业务系统中不同节点对应的缓存数据库不同；

处理模块，用于若确定所述第一版本标识与所述第二版本标识相同，则将所述第一业务数据的修改内容更新至业务数据库中。

一种可能的实现方式中，所述处理模块具体用于：

将所述第一业务数据的状态设置为已锁定状态；

将所述第一业务数据的修改内容更新至业务数据库中；

将所述第一业务数据的状态设置为未锁定状态。

一种可能的实现方式中，所述处理模块具体用于：若所述第一业务数据的状态为未锁定状态，则将所述第一业务数据的状态设置为已锁定状态。

一种可能的实现方式中，所述处理模块还用于：若所述第一业务数据的状态为已锁定状态，则生成第一提示信息，所述第一提示信息用于提示用户所述第一业务数据正在被其他节点修改；

所述装置还包括发送模块，用于向所述终端设备发送所述第一提示信息。

一种可能的实现方式中，所述处理模块还用于：若确定所述第一版本标识与所述第二版本标识不同，则生成第二提示信息，所述第二提示信息用于指示用户所述第一业务数据的内容已被其他节点修改；

所述装置还包括发送模块，用于向所述终端设备发送所述第二提示信息。

一种可能的实现方式中，所述处理模块还用于：

生成所述第一业务数据对应的第三版本标识；

将所述缓存数据库中存储的所述第二版本标识更新为所述第三版本标识。

一种可能的实现方式中，所述处理模块还用于：根据所述修改请求的类型，生成所述修改请求对应的响应消息，当所述修改请求的类型为预设类型时，所述响应消息中包括所述第三版本标识；

所述装置还包括：发送模块，用于向所述终端设备发送所述响应消息。

一种可能的实现方式中，所述接收模块还用于：接收所述终端设备发送的查询请求，所述查询请求包括所述第一业务数据的标识；

所述获取模块还用于：根据所述第一业务数据的标识，从所述业务数据库中或者从所述缓存数据库中获取所述第一业务数据的当前内容；根据所述第一业务数据的标识，从所述缓存数据库中获取所述第一业务数据的当前版本标识；

所述装置还包括：发送模块，用于向所述终端设备发送所述第一业务数据的当前内容和所述第一业务数据的当前版本标识。

一种可能的实现方式中，所述第一节点中部署有拦截程序和业务应用程序，所述接收模块具体用于：通过所述拦截程序拦截所述终端设备发送的修改请求；

所述获取模块具体用于：通过所述拦截程序根据所述第一业务数据的标识，从所述第一节点对应的缓存数据库中获取所述第一业务数据对应的第二版本标识；

所述处理模块具体用于：若通过所述拦截程序确定所述第一版本标识与所述第二版本标识相同，则通过所述业务应用程序将所述第一业务数据的修改内容更新至业务数据库中。

第三方面，本申请提供一种电子设备，包括：存储器和处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序实现如第一方面任一项所述的方法。

第四方面，本申请提供一种计算机可读存储介质，包括：计算机程序，所述计算机程序被处理器执行时实现如第一方面任一项所述的方法。

第五方面，本申请提供一种计算机程序产品，包括：计算机程序，所述计算机程序被处理器执行时实现如第一方面任一项所述的方法。

本申请提供的业务数据的处理方法、装置及电子设备，可应用于集群业务系统中的第一节点，该方法包括：接收终端设备发送的修改请求，所述修改请求包括：待修改的第一业务数据的标识、第一业务数据的修改内容、以及对第一业务数据的修改所基于的第一版本标识；根据第一业务数据的标识，从第一节点对应的缓存数据库中获取第一业务数据对应的第二版本标识，集群业务系统中不同节点对应的缓存数据库不同；若确定第一版本标识与第二版本标识相同，则将第一业务数据的修改内容更新至业务数据库中。上述过程中，每个节点在需要查询业务数据的最新版本标识时，可以从各自对应的缓存数据库中查询，而无需通过业务数据库查询，减少了对业务数据库的访问次数，降低业务数据库的资源消耗。进一步的，由于不同节点对应的缓存数据库不同，使得版本标识的查询压力分散到不同的缓存数据库中，降低每个缓存数据库的资源消耗。即使其中一个缓存数据库出现故障，也只会影响其对应的节点，而不会对其他节点造成影响，从而不会出现整个集群业务系统崩溃的问题，提高了集群业务系统的性能。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为一种集群业务系统的架构示意图；

图2为本申请实施例提供的一种集群业务系统的示意图；

图3为本申请实施例提供的一种业务数据的处理方法的流程示意图；

图4为本申请实施例提供的另一种业务数据的处理方法的流程示意图；

图5为本申请实施例提供的一种业务数据修改场景的示意图；

图6为本申请实施例提供的另一种业务数据修改场景的示意图；

图7为本申请实施例提供的又一种业务数据修改场景的示意图；

图8为本申请实施例提供的又一种业务数据的处理方法的流程示意图；

图9为本申请实施例提供的一种业务数据的处理装置的结构示意图；

图10为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

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

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先对本申请实施例中涉及的技术术语进行解释。

乐观锁：相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本(Version)记录机制实现。何谓数据版本？即，为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号等于数据库表当前版本号，则予以更新，否则认为是过期数据。

悲观锁：具有强烈的独占和排他特性。它指的是对数据被外界(包括本系统当前的其他事务，以及来自外部系统的事务处理)修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据)。

自定义注解：注解也可以称为标注，是JDK5.0版本开始支持加入源代码的特殊语法元数据。Java语言中的类、方法、变量、参数和包等都可以被标注。和Javadoc不同，Java标注可以通过反射获取标注内容。在编译器生成类文件时，标注可以被嵌入到字节码中。Java虚拟机可以保留标注内容，在运行时可以获取到标注内容。当然它也支持自定义Java标注。

切面：对于一个已经封装好的类，可以在编译期间或在运行期间，对其进行切割，把立方体切开，在原有的方法里面添加(织入)一些新的代码，对原有的方法代码进行一次增强处理。而那些增强部分的代码，就被称之为切面。

注解类：是工具封装的特殊方法，只可以调用，它的构造函数是被封装起来的。

@Retention：spring的一种注解，定义被它所注解的注解保留多久。

@Target：spring的一种注解，注解的作用目标，可以是类，方法等等。

Redis：一种基于键值对(key-value)的存储系统，是跨平台的非关系型数据库。

incr方法：Redis的原子性自增操作。

为了便于理解本申请的技术方案，首先结合图1对集群业务系统的架构进行介绍。

图1为一种集群业务系统的架构示意图，如图1所示，该集群业务系统中包括多个节点和业务数据库。业务数据库用于存储业务数据。终端设备与集群业务系统可以通信连接。集群业务系统中的每个节点可以向终端设备提供服务。其中，终端设备可以包括但不限于：智能手机、平板电脑、笔记本电脑、台式电脑、智能穿戴设备、智能家居设备、车载设备等。

一些场景中，集群业务系统中的节点可以称为服务器或者节点服务器。集群业务系统中的不同节点可以对应不同的服务，或者，集群业务系统中的各节点也可以对应相同的服务。

应理解的，上述集群业务系统可以应用于多种业务场景中，例如，电商业务场景、金融业务场景、社交业务场景等。本实施例对此不作限定。

一些业务场景中，业务数据是可被用户配置的业务数据。如图1所示，用户可以通过终端设备访问集群业务系统，并对业务数据进行查询、修改、删除等操作。

示例性的，用户A通过终端设备1发送业务数据修改请求，集群业务系统中的节点1对该修改请求进行处理，节点1可以根据修改请求对业务数据库中的对应业务数据进行修改。用户B通过终端设备2发送业务数据修改请求，集群业务系统中的节点2对该修改请求进行处理，节点2可以根据修改请求对业务数据库中的对应业务数据进行修改。用户C通过终端设备3发送业务数据修改请求，集群业务系统中的节点3对该修改请求进行处理，节点3可以根据修改请求对业务数据库中的对应业务数据进行修改。

可选的，集群业务系统中还可以设置有负载均衡节点，当接收到用户发送的业务数据修改请求后，按照负载均衡原则，从多个节点中选择出目标节点，由目标节点对该业务数据修改请求进行处理。

实际应用中，经常出现多个节点对同一业务数据进行修改的情况，导致不同节点对业务数据的修改相互覆盖，使得业务数据库中的数据与预期不一致。

一种相关技术中，可以采用数据库乐观锁的方式对业务数据进行版本控制。具体的，在业务数据库中为每个业务数据维护一个最新的版本标识。每个节点在对业务数据进行修改之前，先从业务数据库中查询得到业务数据的当前版本标识，然后再对业务数据进行修改。在对修改内容进行保存之前，再次从业务数据库中查询业务数据的当前版本标识，在本次查询到的版本标识与上次查询到的版本标识一致的情况下，才对修改内容进行保存。这样可以避免不同节点同时对同一业务数据进行修改导致的修改内容相互覆盖的问题。

然而，发明人在实现本申请的过程中发现，在集群场景中业务数据修改的并发性较高，采用上述数据库乐观锁的方式，每次对业务数据进行修改，均需要至少访问两次业务数据库以查询业务数据的版本标识。这样在高并发场景下，会导致业务数据库的访问频次较高，消耗较多的业务数据库资源，进而降低整个集群系统的业务性能。进一步的，当业务数据库由于资源消耗较多导致故障时，会使得整个集群业务系统崩溃，无法正常工作。

为了解决上述技术问题，本申请提供一种业务数据的处理方法、装置及电子设备。下面结合图2对本申请技术方案的发明构思进行说明。

图2为本申请实施例提供的一种集群业务系统的示意图。如图2所示，在图1所示集群业务系统的基础上，为每个节点设置缓存数据库。缓存数据库用于存储业务数据的最新版本标识。业务数据库用于存储业务数据，而无需再维护业务数据的最新版本标识。

其中，缓存数据库可以是设置在节点中，还可以是设置在独立于节点的电子设备中，本实施例对此不作限定。

本申请技术方案中，每个节点在需要查询业务数据的最新版本标识时，可以从各自对应的缓存数据库中查询，而无需通过业务数据库查询，减少了对业务数据库的访问次数，降低业务数据库的资源消耗。进一步的，由于不同节点对应的缓存数据库不同，使得版本标识的查询压力分散到不同的缓存数据库中，降低每个缓存数据库的资源消耗。即使其中一个缓存数据库出现故障，也只会影响其对应的节点，而不会对其他节点造成影响，从而不会出现整个集群业务系统崩溃的问题，提高了集群业务系统的性能。

下面以具体地实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图3为本申请实施例提供的一种业务数据的处理方法的流程示意图。本实施例的方法可由集群业务系统中的任意一个节点执行，为了描述方便，后续将本实施例的执行主体称为第一节点。如图3所示，本实施例的方法包括：

S301：接收终端设备发送的修改请求，所述修改请求包括：待修改的第一业务数据的标识、所述第一业务数据的修改内容、以及对所述第一业务数据的修改所基于的第一版本标识。

本实施例中，以第一节点对第一业务数据的修改过程为例进行描述。第一业务数据可以是业务数据库中的任意一个业务数据。

本实施例的应用场景中，用户确定需要修改第一业务数据时，可以先通过终端设备向第一节点发送查询请求，以获取第一业务数据的当前内容，以及第一业务数据的当前版本标识。

一个示例中，终端设备接收到第一业务数据的当前内容后，在展示界面中显示第一业务数据的当前内容，以便用户通过展示界面对第一业务数据进行修改。终端设备接收到第一业务数据的当前版本标识后，可以将第一业务数据的当前版本标识作为第一版本标识。即第一版本标识为本次修改所基于的版本标识。

用户对第一业务数据修改完成后，终端设备向第一节点发送修改请求，用于请求第一节点将第一业务数据的修改内容更新至业务数据库中。终端设备在修改请求中携带下述内容：第一业务数据的标识、第一业务数据的修改内容、第一业务数据的修改所基于的第一版本标识。

S302：根据所述第一业务数据的标识，从第一节点对应的缓存数据库中获取所述第一业务数据对应的第二版本标识，所述集群业务系统中不同节点对应的缓存数据库不同。

S303：若确定所述第一版本标识与所述第二版本标识相同，则将所述第一业务数据的修改内容更新至业务数据库中。

本实施例中，为集群业务系统中的每个节点设置缓存数据库。不同节点对应的缓存数据库不同。缓存数据库用于存储业务数据的最新版本标识。可选的，缓存数据库除了用于存储业务数据的最新版本标识之外，还可用于存储业务数据。

其中，本实施例中的业务数据的版本标识是指用于标识业务数据的不同版本的信息。本实施例对于业务数据的版本标识的表示形式不作限定，例如，可以是字符串形式，也可以是数值形式，还可以是时间戳形式。

通过采用缓存数据库存储业务数据的最新版本标识，使得业务数据库中无需再对业务数据的最新版本标识进行维护，在需要查询业务数据的最新版本标识时，不需要访问业务数据库，而可以直接从节点对应的缓存数据库中查询即可，可以有效减少业务数据库的访问次数，降低业务数据库的资源消耗。

一些示例中，集群业务系统中的各节点提供的服务可以是对等的，这样，集群业务系统接收到终端设备的修改请求后，可以按照负责均衡原则将修改请求分配给某个节点。该场景中，每个节点对应的缓存数据库可用于对所有业务数据的最新版本标识进行维护。并且，不同缓存数据库之间具有同步机制，当其中一个缓存数据库对第一业务数据的版本标识进行更新后，可以将更新后的版本标识同步给其他的缓存数据库。这样，后续无论通过哪个节点查询第一业务数据的版本标识，均能保证获取到的版本标识的准确性。

另一些示例中，集群业务系统中的各节点提供的服务可以是不对等的。例如，不同节点负责对不同的业务数据进行处理。这样，每个节点对应的缓存数据库可用于对该节点所负责的业务数据的最新版本标识进行维护即可。

可选的，缓存数据库可以为远程字典服务(Remote Dictionary Server，Redis)数据库。Redis数据库是一种支持网络、可基于内存亦可持久化的日志型、采用键值对(Key-Value)形式存储的数据库。

当缓存数据库采用Redis数据库时，可以采用Key-Value形式对各业务数据的最新版本标识进行存储。其中，Key可以对应业务数据的标识，Value可以对应业务数据的最新版本标识。

这样，第一节点接收到修改请求后，可以根据修改请求中携带的第一业务数据的标识，从第一节点对应的缓存数据库中获取第一业务数据的最新版本标识。为了以示区分，本实施例中，将第一节点接收到查询请求后，第一节点第一次从缓存数据库中查询到的第一业务数据的最新版本标识称为第一版本标识。将第一节点接收到修改请求后，第一节点第二次从缓存数据库中查询到的第一业务数据的最新版本标识称为第二版本标识。

能够理解的是，若在第一节点的第一次查询和第二次查询之间，不存在其他节点对第一业务数据进行修改，则第一次查询到的第一版本标识与第二次查询到的第二版本标识相同。若在第一节点的第一次查询和第二次查询之间，存在其他节点对第一业务数据进行修改，由于其他节点对第一业务数据修改后，会在缓存数据库中更新第一业务数据的最新版本标识，则第一次查询到的第一版本标识与第二次查询到的第二版本标识不同。

因此，本申请实施例中，在确定第一版本标识与第二版本标识相同时，说明第一次查询与第二次查询之间不存在其他节点对第一业务数据进行修改，即，本次修改请求对第一业务数据的修改内容是有效的，因此，可以将第一业务数据的修改内容更新至业务数据库中。从而，完成对第一业务数据的修改过程。

通过在确定第一版本标识和第二版本标识相同的情况下，将第一业务数据的修改内容更新至业务数据库中，能够避免不同节点对第一业务数据的修改内容相互覆盖的问题。

本实施例提供的业务数据的处理方法，应用于集群业务系统中的任一节点，该方法包括：接收终端设备发送的修改请求，所述修改请求包括：待修改的第一业务数据的标识、第一业务数据的修改内容、以及对第一业务数据的修改所基于的第一版本标识；根据第一业务数据的标识，从节点对应的缓存数据库中获取第一业务数据对应的第二版本标识，集群业务系统中不同节点对应的缓存数据库不同；若确定第一版本标识与第二版本标识相同，则将第一业务数据的修改内容更新至业务数据库中。上述过程中，每个节点在需要查询业务数据的最新版本标识时，可以从各自对应的缓存数据库中查询，而无需通过业务数据库查询，减少了对业务数据库的访问次数，降低业务数据库的资源消耗。进一步的，由于不同节点对应的缓存数据库不同，使得版本标识的查询压力分散到不同的缓存数据库中，降低每个缓存数据库的资源消耗。即使其中一个缓存数据库出现故障，也只会影响其对应的节点，而不会对其他节点造成影响，从而不会出现整个集群业务系统崩溃的问题，提高了集群业务系统的性能。

在上述实施例的基础上，下面结合一个更具体的实施例对本申请技术方案进行详细描述。

图4为本申请实施例提供的另一种业务数据的处理方法的流程示意图。如图4所示，本实施例的方法包括：

S401：终端设备发送查询请求，查询请求包括第一业务数据的标识。

示例性的，用户确定需要修改第一业务数据时，可以先通过终端设备向第一节点发送查询请求，以获取第一业务数据的当前内容，以及第一业务数据的当前版本标识。

相应的，集群业务系统中的第一节点接收终端设备发送的查询请求。

S402：第一节点根据第一业务数据的标识，从业务数据库或者从第一节点对应的缓存数据库中获取第一业务数据的当前内容。

本实施例中，业务数据库中存储有业务数据。缓存数据库中可以存储业务数据，也可以不存储业务数据。当缓存数据库中存储有业务数据时，可以优先从缓存数据库中获取第一业务数据的当前内容。当缓存数据库中未存储业务数据时，从业务数据库中获取第一业务数据的当前内容。

S403：第一节点根据第一业务数据的标识，从第一节点对应的缓存数据库中获取第一业务数据的当前版本标识。

S404：第一节点向终端设备发送第一业务数据的当前内容和第一业务数据的当前版本标识。

一个示例中，终端设备接收到第一业务数据的当前内容后，在展示界面中显示第一业务数据的当前内容，以便用户通过展示界面对第一业务数据进行修改。终端设备接收到第一业务数据的当前版本标识后，可以将第一业务数据的当前版本标识作为第一版本标识。即第一版本标识为本次修改所基于的版本标识。

S405：终端设备发送修改请求，修改请求包括：第一业务数据的标识、第一业务数据的修改内容、以及对第一业务数据的修改所基于的第一版本标识。

本实施例中，用户对第一业务数据修改完成后，终端设备向第一节点发送修改请求，用于请求第一节点将第一业务数据的修改内容更新至业务数据库中。终端设备在修改请求中携带下述内容：第一业务数据的标识、第一业务数据的修改内容、第一业务数据的修改所基于的第一版本标识

能够理解的是，对第一业务数据的修改所基于的第一版本标识，即为S403中从缓存数据库中查询得到的当前版本标识。

相应的，第一节点从终端设备接收修改请求。

S406：第一节点根据第一业务数据的标识，从第一节点对应的缓存数据库中获取第一业务数据对应的第二版本标识。

S407：第一节点判断第一版本标识与第二版本标识是否相同。

应理解的是，S406和S407的具体实现方式可以参考图3所示实施例，此处不作赘述。

若相同，则执行S408至S415。

若不同，则执行S416至S417。

S408：第一节点获取第一业务数据的状态。

本实施例中，每个业务数据的状态包括：未锁定状态和已锁定状态。若一个业务数据的状态为未锁定状态，则说明该业务数据当前未被任何节点修改。若一个业务数据的状态为已锁定状态，则说明该业务数据当前正在被某个节点修改。

S409：若第一业务数据的状态为未锁定状态，则第一节点将第一业务数据的状态设置为已锁定状态。

S410：第一节点将第一业务数据的修改内容更新至业务数据库中。

也就是说，只有在第一业务数据的状态为未锁定状态时，本实施例才将第一业务数据的修改内容更新至业务数据库中，并在更新前将第一业务数据的状态设置为已锁定状态，从而使得第一业务数据不能再被其他用户修改。

S411：第一节点将第一业务数据的状态设置为未锁定状态。

对第一业务数据更新完成后，将第一业务数据的状态设置为未锁定状态，使得后续其他用户可以对第一业务数据进行修改。

S412：第一节点生成第一业务数据对应的第三版本标识，并将缓存数据库中存储的第二版本标识更新为第三版本标识。

本实施例中，对业务数据库中的第一业务数据更新完成后，还需要在缓存数据库中对第一业务数据的当前版本标识进行更新(即，将第二版本标识更新为第三版本标识)，保证缓存数据库中存储的是第一业务数据的最新版本标识，以便于后续对第一业务数据的版本控制过程。

可选的，当缓存数据库采用redis数据库，且版本标识采用数值形式时，可以采用redis incr命令对第一业务数据的版本标识进行更新。

S413：第一节点根据修改请求的类型，生成修改请求对应的响应消息，当修改请求的类型为预设类型时，响应消息中包括第三版本标识。

S414：第一节点向终端设备发送响应消息。

应理解的是，一些应用场景中，终端设备向第一节点发送修改请求后，终端设备希望获取第一业务数据更新后的版本标识。而另一些应用场景中，终端设备向第一节点发送修改请求后，终端设备不需要获取第一业务数据更新后的版本标识。本实施例的预设类型可以是指如下类型：终端设备希望获取第一业务数据更新后的版本标识。在修改请求的类型为预设类型时，第一节点在向终端设备发送的响应消息中携带第三版本标识。在修改请求的类型不是预设类型时，第一节点在向终端设备发送的响应消息中不携带第三版本标识。

S415：若第一业务数据的状态为已锁定状态，则生成第一提示信息，所述第一提示信息用于提示用户所述第一业务数据正在被其他节点修改。

S416：第一节点向终端设备发送第一提示信息。

本实施例中，当第一业务数据的状态为已锁定状态时，说明第一业务数据正在被其他节点修改。该情况下，如果第一节点也对第一业务数据进行修改的话，可能会覆盖其他节点的修改内容，或者第一节点的修改内容可能被其他节点覆盖。因此，本实施例中，当第一业务数据的状态为已锁定状态时，不对业务数据库中的第一业务数据进行更新，而是向终端设备发送第一提示信息，以提示用户第一业务数据正在被其他节点修改。示例性的，第一提示信息可以为“当前数据正在被操作，请稍后”。

S417：第一节点生成第二提示信息，所述第二提示信息用于提示用户第一业务数据的内容已被其他节点修改。

S418：第一节点向终端设备发送第二提示信息。

本实施例中，当所述第一版本标识与所述第二版本标识不同时，说明在S403至S406执行期间，第一业务数据已被其他节点修改过。该情况下，第一节点如果依然基于第一版本标识对第一业务数据进行修改的话，可能会覆盖其他节点的修改内容。因此，本实施例中，当第一版本标识与第二版本标识不同时，不对业务数据库中的第一业务数据进行更新，而是向终端设备发送第二提示信息，以提示用户第一业务数据已被其他节点修改。示例性的，第二提示信息可以为“当前数据已被编辑，请刷新”。

本实施例中，S409和S411对第一业务数据的加解锁控制过程，可以采用redis缓存数据库的并发锁机制实现，还可以采用数据库悲观锁机制实现，本实施例对此不作具体限定。

下面结合几个具体的示例进行举例说明。

示例一，图5为本申请实施例提供的一种业务数据修改场景的示意图。如图5所示，假设用户A需要对第一业务数据进行修改。用户A先对第一业务数据进行查询，获取到第一业务数据的当前内容，以及第一业务数据的当前版本标识，假设为V1。用户A对查询到的第一业务数据进行修改，在修改完成后，用户A通过终端设备向第一节点发送修改请求，修改请求中携带第一业务数据的修改内容以及对第一业务数据的修改所基于的版本标识(即V1)。

第一节点接收到修改请求后，在将第一业务数据的修改内容更新至业务数据库中之前，先从缓存数据库中获取第一业务数据的版本标识，假设依然为V1，则第一节点确定缓存数据库中的第一业务数据的版本标识与修改请求中携带的版本标识相同，则锁定第一业务数据(即，判断第一业务数据的状态是否为未锁定状态，若是未锁定状态，则第一节点将第一业务数据的状态更新为已锁定状态，并确定第一业务数据的锁定权限获取成功)。在第一节点对第一业务数据锁定成功后，第一节点将第一业务数据的修改内容更新至业务数据库中，并对第一业务数据解除锁定。进而，第一节点将缓存数据库中第一业务数据的版本标识更新为V2。从而，用户A完成对第一业务数据的修改过程。

示例二，图6为本申请实施例提供的另一种业务数据修改场景的示意图。如图6所示，假设用户A和用户B均需要对第一业务数据进行修改。用户A对第一业务数据进行查询，获取到第一业务数据的当前内容，以及第一业务数据的当前版本标识，假设为V1。用户B对第一业务数据进行查询，获取到第一业务数据的当前内容，以及第一业务数据的当前版本标识，假设为V1。

用户A对查询到的第一业务数据进行修改。并且，用户B对查询到的第一业务数据进行修改。假设用户A比用户B先修改完成。

在用户A修改完成后，用户A通过终端设备向第一节点发送修改请求，修改请求中携带第一业务数据的修改内容以及对第一业务数据的修改所基于的版本标识(即V1)。第一节点接收到用户A发送的修改请求后，根据修改请求完成对第一业务数据的更新过程(具体修改过程与示例一类似，此处不作赘述)。

在第一节点根据用户A的修改请求完成对第一业务数据的更新过程之后，假设用户B对第一业务数据修改完成，用户B通过终端设备向第一节点发送修改请求，修改请求中携带第一业务数据的修改内容以及第一业务数据的修改所基于的版本标识(即V1)。第一节点接收到用户B发送的修改请求后，先从缓存数据库中获取第一业务数据的版本标识，此时为V2(由于用户A已对第一业务数据进行修改过，版本标识已更新为V2)，则第一节点确定缓存数据库中的第一业务数据的版本标识与修改请求中携带的版本标识不同。该情况下，第一节点向终端设备发送提示信息“当前数据已被编辑，请刷新”，提示用户B对第一业务数据刷新，并基于刷新后的第一业务数据进行修改，从而避免用户B对用户A的修改内容覆盖。

示例三，图7为本申请实施例提供的又一种业务数据修改场景的示意图。如图7所示，假设用户A和用户C均需要对第一业务数据进行修改。用户A对第一业务数据进行查询，获取到第一业务数据的当前内容，以及第一业务数据的当前版本标识，假设为V1。用户C对第一业务数据进行查询，获取到第一业务数据的当前内容，以及第一业务数据的当前版本标识，假设为V1。

用户A对查询到的第一业务数据进行修改。并且，用户C对查询到的第一业务数据进行修改。假设用户A比用户C先修改完成。

在用户A修改完成后，用户A通过终端设备向第一节点发送修改请求，修改请求中携带第一业务数据的修改内容以及对第一业务数据的修改所基于的版本标识(即V1)。第一节点接收到用户A发送的修改请求后，根据修改请求完成对第一业务数据的更新过程(具体修改过程与示例一类似，此处不作赘述)。

在第一节点对第一业务数据锁定之后，并在对业务数据库中的第一业务数据更新完成之前，假设用户C对第一业务数据修改完成，用户C通过终端设备向第二节点发送修改请求，修改请求中携带第一业务数据的修改内容以及第一业务数据的修改所基于的版本标识(即V1)。第二节点接收到用户C发送的修改请求后，先从缓存数据库中获取第一业务数据的版本标识，此时为V1(由于用户A还未对第一业务数据更新完成，版本标识依然为V1)，则第二节点确定缓存数据库中的第一业务数据的版本标识与修改请求中携带的版本标识相同。第二节点请求锁定第一业务数据，而由于此时第一业务数据已被第一节点锁定，因此，第二节点对第一业务数据锁定失败。该情况下，第二节点向终端设备发送提示信息“当前数据正在被操作，请稍后”，提示用户C稍后对第一业务数据进行刷新，并基于刷新后的第一业务数据进行修改，从而避免用户C对用户A的修改内容覆盖。

本实施例中，只有在第一节点确定第一版本标识和第二版本标识相同，且第一业务数据未被其他节点锁定的情况下，才将第一业务数据的修改内容更新至业务数据库中；在第一节点确定出第一版本标识和第二版本标识不同，或者，第一业务数据已被其他节点锁定的情况下，第一节点不将第一业务数据的修改内容更新至业务数据库中，而是向终端设备输出相应的提示信息。这样，避免不同节点同时操作第一业务数据导致修改内容相互覆盖的问题，保证了第一业务数据的准确性。另外，用户根据提示信息可以直观获知本次失败的原因以及需要进行的操作，提升了用户使用体验。

上述各实施例描述了对业务数据的处理过程，一个业务数据的处理过程包括：对业务数据库中的业务数据的更新过程，以及对业务数据的版本控制过程。本申请的一些可能的实现方式中，还可以将上述两个过程解耦，从而可以在不对业务系统的代码进行修改的情况下，实现对业务数据的版本控制过程。下面结合图8进行描述。

图8为本申请实施例提供的又一种业务数据的处理方法的流程示意图。本实施例中，每个节点部署有拦截程序和业务应用程序。其中，业务应用程序是指用以实现业务系统的功能的程序。拦截程序用以实现业务数据的版本控制功能。

如图8所示，本实施例的方法包括：

S801：通过拦截程序拦截终端设备发送的修改请求，所述修改请求中包括：待修改的第一业务数据的标识、所述第一业务数据的修改内容、以及对所述第一业务数据的修改所基于的第一版本标识。

本实施例中，终端设备向第一节点发送修改请求，第一节点可以通过业务应用程序接收到修改请求。第一节点在通过业务应用程序接收到拦截请求时，可以通过拦截程序拦截该修改请求，由拦截程序执行对第一业务数据的版本控制过程。

可选的，拦截程序可以是采用自定义注解切面编程方式实现。

示例性的，可以利用注解@Retention和@Target完成自定义注解类的建立。该自定义注解类可以被使用在任意符合条件的方法上面。自定义注解类定义了缓存前缀、业务数据的标识、版本字段、是否版本检验、版本不对提示、是否加锁、锁获取不到提示、是否回填版本等属性字段。

其中，缓存前缀和业务数据的标识可用于指示业务数据的版本标识在缓存数据库中对应的key值。版本字段默认值为“version”；是否版本检验默认值为“false”；版本不对提示默认值为“当前数据已被编辑，请刷新”；是否加锁默认值为“false”；锁获取不到提示默认值为“当前数据正在被操作，请稍后”；是否回填版本默认值为“false”。在切面代码中可以根据具体业务应用对上述各属性字段的值进行更新。

可以为业务应用程序中用于接收修改请求的接口方法添加注解。当通过拦截程序拦截到修改请求后，可以根据该注解执行对应的切面代码。

S802：通过拦截程序根据所述第一业务数据的标识，从第一节点对应的缓存数据库中获取所述第一业务数据对应的第二版本标识。

本实施例中，可以为业务应用程序中用于接收修改请求的接口方法添加注解。在拦截到修改请求后，可以通过拦截程序执行该注解对应的切面代码，根据修改请求中携带的参数对自定义注解类中的各属性字段进行解析。通过反射机制获取缓存前缀以及第一业务数据的标识，通过对缓存前缀和第一业务数据的标识进行拼接处理，得到第一业务数据在缓存数据库中对应的key值。进而，根据该key值，从缓存数据库中获取第一业务数据对应的第二版本标识。

S803：若通过拦截程序确定所述第一版本标识与所述第二版本标识相同，则通过业务应用程序将所述第一业务数据的修改内容更新至业务数据库中。

可选的，若通过拦截程序确定第一版本标识与第二版本标识不同，则通过拦截程序根据自定义注解类中的“版本不对提示”属性字段，生成第二提示信息，并向终端设备发送第二提示信息。

可选的，在通过拦截程序确定第一版本标识与第二版本标识相同的情况下，还可以通过拦截程序对第一业务数据进行锁定，若锁定失败，则通过拦截程序根据自定义注解类中的“锁获取不到提示”属性字段，生成第一提示信息，并向终端设备发送第一提示信息。

可选的，在通过业务应用程序将第一业务数据的修改内容更新至业务数据库中之后，还可以通过拦截程序生成第一业务数据的第三版本标识，并将缓存数据库中存储的第一业务数据的第二版本标识更新为第三版本标识。

本实施例中，通过采用自定义注解编程方式实现拦截程序，由拦截程序实现对业务数据的版本控制功能，从而使得对业务数据的版本控制过程与业务系统完全解耦，在不需要对业务系统的代码进行修改的情况下，实现对业务数据的版本控制过程。

图9为本申请实施例提供的一种业务数据的处理装置的结构示意图。该装置可以为软件和/或硬件的形式。该装置可以部署在集群业务系统的第一节点中。如图9所示，本实施例提供的业务数据的处理装置900，可以包括：接收模块901、获取模块902、处理模块903。

其中，接收模块901，用于接收终端设备发送的修改请求，所述修改请求包括：待修改的第一业务数据的标识、所述第一业务数据的修改内容、以及对所述第一业务数据的修改所基于的第一版本标识；

获取模块902，用于根据所述第一业务数据的标识，从所述第一节点对应的缓存数据库中获取所述第一业务数据对应的第二版本标识，所述集群业务系统中不同节点对应的缓存数据库不同；

处理模块903，用于若确定所述第一版本标识与所述第二版本标识相同，则将所述第一业务数据的修改内容更新至业务数据库中。

一种可能的实现方式中，所述处理模块903具体用于：

将所述第一业务数据的状态设置为已锁定状态；

将所述第一业务数据的修改内容更新至业务数据库中；

将所述第一业务数据的状态设置为未锁定状态。

一种可能的实现方式中，所述处理模块903具体用于：若所述第一业务数据的状态为未锁定状态，则将所述第一业务数据的状态设置为已锁定状态。

一种可能的实现方式中，所述处理模块903还用于：若所述第一业务数据的状态为已锁定状态，则生成第一提示信息，所述第一提示信息用于提示用户所述第一业务数据正在被其他节点修改；

所述装置还包括发送模块(未示出)，用于向所述终端设备发送所述第一提示信息。

一种可能的实现方式中，所述处理模块903还用于：若确定所述第一版本标识与所述第二版本标识不同，则生成第二提示信息，所述第二提示信息用于指示用户所述第一业务数据的内容已被其他节点修改；

所述装置还包括发送模块(未示出)，用于向所述终端设备发送所述第二提示信息。

一种可能的实现方式中，所述处理模块903还用于：生成所述第一业务数据对应的第三版本标识；将所述缓存数据库中存储的所述第二版本标识更新为所述第三版本标识。

一种可能的实现方式中，所述处理模块903还用于：根据所述修改请求的类型，生成所述修改请求对应的响应消息，当所述修改请求的类型为预设类型时，所述响应消息中包括所述第三版本标识；

所述装置还包括发送模块(未示出)，用于向所述终端设备发送所述响应消息。

一种可能的实现方式中，所述接收模块901还用于：接收所述终端设备发送的查询请求，所述查询请求包括所述第一业务数据的标识；

所述获取模块902还用于：根据所述第一业务数据的标识，从所述业务数据库中或者从所述缓存数据库中获取所述第一业务数据的当前内容；根据所述第一业务数据的标识，从所述缓存数据库中获取所述第一业务数据的当前版本标识；

所述装置还包括发送模块(未示出)，用于向所述终端设备发送所述第一业务数据的当前内容和所述第一业务数据的当前版本标识。

一种可能的实现方式中，所述第一节点中部署有拦截程序和业务应用程序，所述接收模块901具体用于：通过所述拦截程序拦截所述终端设备发送的修改请求；

所述获取模块902具体用于：通过所述拦截程序根据所述第一业务数据的标识，从所述第一节点对应的缓存数据库中获取所述第一业务数据对应的第二版本标识；

所述处理模块903具体用于：若通过所述拦截程序确定所述第一版本标识与所述第二版本标识相同，则通过所述业务应用程序将所述第一业务数据的修改内容更新至业务数据库中。

本实施例提供的业务数据的处理装置，可用于执行上述任一方法实施例中的业务数据的处理方法，其实现原理和技术效果类似，此处不作赘述。

图10为本申请实施例提供的一种电子设备的结构示意图。该电子设备可以作为集群业务系统中的任一节点。如图10所示，该电子设备1000，包括：处理器1001以及存储器1002。

其中，存储器1002，用于存储计算机程序；处理器1001，用于执行存储器中存储的计算机程序，以实现上述实施例中业务数据的处理方法中的一个或者多个步骤。具体可以参见前述方法实施例中的相关描述，其实现原理和技术效果类似，本实施例此处不再赘述。

可选地，存储器1002既可以是独立的，也可以跟处理器1001集成在一起。

当所述存储器1002是独立于处理器1001之外的器件时，所述电子设备1000还可以包括：总线1003，用于连接所述存储器1002和处理器1001。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质包括计算机程序，所述计算机程序用于实现如上任一方法实施例提供的业务数据的处理方法中的一个或者多个步骤，其实现原理和技术效果类似，此处不作赘述。

本申请实施例还提供一种芯片，包括：存储器和处理器，所述存储器中存储有计算机程序，所述处理器运行所述计算机程序执行上述任一方法实施例提供的业务数据的处理方法中的一个或者多个步骤，其实现原理和技术效果类似，此处不作赘述。

本申请实施例还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现上述任一方法实施例提供的业务数据的处理方法中的一个或者多个步骤，其实现原理和技术效果类似，此处不作赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

另外，在本申请各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个单元中。上述模块成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本申请各个实施例所述方法的部分步骤。

应理解，上述处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application Specific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits，简称：ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备或主控设备中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。