CN115422210A

CN115422210A - 一种多活架构下保障业务操作数据有效性的方法及系统

Info

Publication number: CN115422210A
Application number: CN202211390820.7A
Authority: CN
Inventors: 陶彦男; 刘海龙; 冯世伟
Original assignee: Beijing Ruirong Tianxia Technology Co ltd
Current assignee: Beijing Ruirong Tianxia Technology Co ltd
Priority date: 2022-11-08
Filing date: 2022-11-08
Publication date: 2022-12-02

Abstract

本发明提供一种多活架构下保障业务操作数据有效性的方法及系统，涉及数据安全技术领域，包括：在各数据中心的数据库中新增数据同步控制表，包含业务类型、操作用户或操作员编号、操作版本和更新时间；在缓存数据库中存放与数据同步控制表相同的结构信息；操作用户或操作员发起业务操作时，对操作用户或操作员编号加分布式锁；判断缓存数据库操作版本与数据中心数据库中的操作版本是否相同；若相同，则进行业务操作，并在业务操作完成后更新缓存数据库中对应的业务类型、操作用户或操作员编号、操作版本及数据中心的数据同步控制表。本发明解决了多活架构下，对数据要求高度一致的业务，因网络延迟导致的数据有效性、一致性的问题，保证数据安全。

Description

一种多活架构下保障业务操作数据有效性的方法及系统

技术领域

本发明涉及数据安全技术领域，尤其涉及一种多活架构下保障业务操作数据有效性的方法及系统。

背景技术

数据中心多活是出于数据库机房灾备方面的考虑，为了防止一个数据库机房出现灾难性的事故导致无法提供服务，在同城或者异地建立多个数据中心，传统主备模式是一个业务只在一个数据中心运行，企业结合灾备等级需求和业务需求，在备份中心部署了大量的备份服务器，但备份中心仅为该业务提供灾备服务，只有当发生灾难、生产数据中心瘫痪的时候，灾备中心的业务才启动这些服务器，造成备份中心服务器资源浪费，广域网链路也无法得到充分的利用。

多活的优势：是为了可以最大化的利用资源，避免了一个数据中心常年处于闲置装备而造成浪费。通过资源整合，多活数据中心的服务能力是双倍或者是多倍的，哪怕是断了一个数据中心，其他的数据中心还在运行，对用户来说是不可感知的；而一个灾备中心的模式，如果生产数据中心瘫痪，需要半个小时、甚至两个小时、甚至更长时间才能启动灾备中心，在启动灾备中心的时间里，用户的交易会严重受损。

多活的问题：数据中心多活可以保证在极端的情况下业务都不受影响，但是数据高度一致的服务（例如支付、转账等交易）无法实现多活业务，核心的问题就是网络延迟，网络延迟会导致最新的数据无法第一时间同步到各自中心，无法判断各自中心的数据是否为有效数据，容易造成系统出错及混乱。

现有技术采用在数据库层同步中间件层解决，每张表新增一个timestamp字段，由数据库中间件同步数据的时候比较两边数据复制的timestamp是否和目标机房的一致，如果不一致，就不允许目标机房的数据库写入流量，如果一直再允许写入；这种方法对整体数据库表的改动太大，如果生产环境数据库表很多，并且内部的数据量都很大，这个改动量相对来说，是非常大的，且一旦数据库中间件异常终止，可能会导致目标数据库无法写入流量，导致业务下线，造成更加严重的数据安全问题。。

发明内容

针对上述问题，本发明提供了一种多活架构下保障业务操作数据有效性的方法及系统，更好的解决网络延迟导致的多活数据中心数据有效性的、一致性的问题。

为实现上述目的，本发明提供了一种多活架构下保障业务操作数据有效性的方法，包括：在各数据中心的数据库中均新增数据同步控制表，所述数据同步控制表的结构信息包含业务类型、操作用户或操作员编号、操作版本和更新时间；

在所有数据中心共用的缓存数据库中存储与所述数据同步控制表中对应的业务类型、操作用户或操作员编号、操作版本；

操作用户或操作员基于任一数据中心发起业务操作时，对所述操作用户或操作员编号加分布式锁，使当前时刻只有该操作用户或操作员进行操作；

判断该业务所属业务类型，获取并判断该业务类型在所述缓存数据库中对应的操作版本与在该数据中心的数据库中对应的操作版本是否相同；

若相同，则该数据中心的数据库已更新至当前最新数据，开始进行业务操作，并在业务操作完成后更新所述缓存数据库中存储的业务类型、操作用户或操作员编号、操作版本，以及更新该数据中心数据库中的所述数据同步控制表。

作为本发明的进一步改进，所述业务类型为多活架构下需解决数据延迟或数据一致性问题的业务类型，包括支付业务、转账业务。

作为本发明的进一步改进，

若不同，则该数据中心的数据库未更新至当前最新数据，放弃业务操作或轮巡数据库操作版本进行判断，直至所述缓存数据库版本与数据库版本相同。

作为本发明的进一步改进，在业务操作完成后，将该业务所属业务类型在所述缓存数据库中对应的操作版本值加1，完成对所述缓存数据库中存储的操作版本的更新。

作为本发明的进一步改进，业务操作完成后释放所述分布式锁。

本发明还提供了一种多活架构下保障业务操作数据有效性的系统，包括：分布式锁实现模块、数据有效性判断模块、业务处理模块和数据更新模块；

所述分布式锁实现模块，用于：

操作用户或操作员基于任一数据中心发起业务操作时，对所述操作用户或操作员编号加分布式锁；

所述数据有效性判断模块，用于：

判断该业务所属业务类型，获取并判断该业务类型在缓存数据库中对应的操作版本与在该数据中心数据库中对应的操作版本是否相同；

所述业务处理模块，用于：

若相同，则该数据中心的数据库已更新至当前最新数据，开始进行业务操作；

所述数据更新模块，用于：

在业务操作完成后更新所述缓存数据库中存储的业务类型、操作用户或操作员编号、操作版本，以及更新该数据中心数据库中的所述数据同步控制表。

作为本发明的进一步改进，

作为本发明的进一步改进，所述分布式锁实现模块，还用于：

业务操作完成后释放所述分布式锁。

与现有技术相比，本发明的有益效果为：

本发明通过在数据库增加数据同步控制表，及通过数据同步控制表存放需解决数据延迟问题的业务类型及相关信息，在操作用户或操作员发起涉及该业务类型的操作时，先比对缓存数据库与数据同步控制表中数据的一致性，若一致则有效，再进行业务操作，解决了数据延迟对该类业务类型的影响，保证了系统数据的安全性。

本发明以最小的改变和代价解决了数据中心多活架构下网络延迟导致的多活数据中心数据有效性和一致性的问题。

本发明与现有技术方案相比，降低数据库表改动的范围，提升了业务层对于数据同步延时的感知，可以人为选择最适合自己的方案去做发现数据无效之后的处理，增强了系统对业务使用的把控（可以根据version去观察每个业务触发的频率等），在提升系统的可用性，扩展性同时，低成本解决了数据同步延时导致的数据有效性、一致性问题。

附图说明

图1为本发明一种实施例公开的多活架构下保障业务操作数据有效性的方法流程图；

图2为本发明一种实施例公开的多活架构下保障业务操作数据有效性的系统示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例，实施例中的步骤S1、S2、S3……并不代表唯一的执行步骤。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

下面结合附图对本发明做进一步的详细描述：

如图1所示，本发明提供的一种多活架构下保障业务操作数据有效性的方法，包括：

S1、在各数据中心的数据库中均新增数据同步控制表DB_AA_SNYC，数据同步控制表的结构信息包含业务类型、操作用户或操作员编号、操作版本和更新时间；

其中，

业务类型为多活架构下需解决数据延迟或数据一致性问题的业务类型，包括支付业务、转账业务；

一般初始操作版本默认为0，初始的数据同步控制表DB_AA_SNYC如表1所示：

表1

业务数据更新一次后，数据同步控制表DB_AA_SNYC对应业务类型，更新该次操作的操作用户或操作员编号，操作版本号自增1，并记录更新时间，示例如表2所示：

表2

S2、在所有数据中心共用的缓存数据库中存储与数据同步控制表中对应的业务类型、操作用户或操作员编号、操作版本；

其中，

在多活架构下，多个数据中心同时提供数据服务，且多个数据中心共用一个缓存数据库，如采用redis缓存数据库，操作用户或操作员发起业务操作，根据业务类型、服务支撑规则等，为该业务操作分配后台支撑的数据中心，基于该数据中心的数据库完成业务操作，业务操作完成后，业务操作过程中变更的数据最先存储在缓存数据库中，之后保存至提供后台支撑的数据中心的数据库中，最后，该数据中心向其他各数据中心通过中间件等实现数据同步存储。

进一步的，

初始时，缓存数据库中存储的操作版本也默认为0，在经过一次业务操作后，缓存数据库的操作版本值加1。

S3、操作用户或操作员基于任一数据中心发起业务操作时，对操作用户或操作员编号加分布式锁，使当前时刻只有该操作用户或操作员进行操作；

其中，

对于要求数据高度一致的业务，如支付业务和转账业务，若多操作用户同时操作，会造成数据混乱，无法保证数据的准确性。

S4、判断该业务所属业务类型，获取并判断该业务类型在缓存数据库中对应的操作版本与在该数据中心数据库中对应的操作版本是否相同；

其中，

若该业务类型属于数据同步控制表DB_AA_SNYC中记载的任一中业务类型，即需解决数据延迟或数据一致性问题的业务类型，则继续获取该业务类型在缓存数据库中对应的操作版本与在该数据中心数据库中对应的操作版本。

进一步的，

未记载在数据同步控制表DB_AA_SNYC中的业务类型不属于本申请解决数据延迟及数据一致性问题的范畴。

S5、若相同，则该数据中心的数据库已更新至当前最新数据，开始进行业务操作，并在业务操作完成后更新缓存数据库中存储的业务类型、操作用户或操作员编号、操作版本，以及更新该数据中心数据库中的数据同步控制表。

其中，

若相同，则说明该业务类型的上一次业务操作完成后，变更的数据已由其他数据中心同步至本数据中心，即：本数据中心的数据库关于该业务类型的数据已更新至当前最新数据，基于本数据中心的数据进行本次业务操作，不会使业务数据混乱；也即，规避了数据延迟的问题。

若不同，则该数据中心的数据库未更新至当前最新数据，放弃业务操作或轮巡数据库操作版本进行判断，直至缓存数据库版本与数据库版本相同。

进一步的，

在业务操作完成后，将该业务所属业务类型在缓存数据库中对应的操作版本值加1，完成对缓存数据库中存储的操作版本的更新。

S6、业务操作完成后释放分布式锁。

其中，

释放分布式锁后，其他操作用户或操作员可以对该业务类型继续进行业务操作。

如图2所示，本发明还提供了一种多活架构下保障业务操作数据有效性的系统，包括：分布式锁实现模块、数据有效性判断模块、业务处理模块和数据更新模块；

分布式锁实现模块，用于：

操作用户或操作员基于任一数据中心发起业务操作时，对操作用户或操作员编号加分布式锁，使当前时刻只有该操作用户或操作员进行操作；

业务操作完成后释放分布式锁。

其中，

对于要求数据高度一致的业务，如支付业务和转账业务，若多操作用户同时操作，会造成数据混乱，无法保证数据的准确性；因此，本发明中业务类型为多活架构下需解决数据延迟或数据一致性问题的业务类型，包括支付、转账交易。

数据有效性判断模块，用于：

其中，

若该业务类型属于数据同步控制表DB_AA_SNYC中记载的任一中业务类型，即需解决数据延迟或数据一致性问题的业务类型，则继续获取该业务类型在缓存数据库中对应的操作版本与在该数据中心数据库中对应的操作版本；

进一步的，

业务处理模块，用于：

若相同，则该数据中心的数据库已更新至当前最新数据，开始进行业务操作。

其中，

若相同，说明该业务类型的上一次业务操作完成后，变更的数据已由其他数据中心同步至本数据中心，即：本数据中心的数据库关于该业务类型的数据已更新至当前最新数据，基于本数据中心的数据进行本次业务操作，不会使业务数据混乱；也即，规避了数据延迟的问题；

数据更新模块，用于：

在业务操作完成后更新缓存数据库中存储的业务类型、操作用户或操作员编号、操作版本，以及更新该数据中心数据库中的数据同步控制表。

其中，

实施例：

在各数据中心的数据库中均新增一个表DB_AA_SNYC，表结构信息包含：用来存放所需解决数据延时问题、数据一致性问题的业务类型、操作用户或者操作员编号信息、以及对应的操作version(初始默认是0)、更新时间等；

各数据中心共用的缓存数据库（该实施例采用的是redis缓存数据库）中也需要存放和DB_AA_SNYC中数据一一对应的业务类型:编号:version的数据，此处使用AtomicLong类型存储。

方案详细流程：

步骤1、操作用户编码为01的操作用户对支付业务发起业务操作，多活架构平台为其提供数据中心A支撑其业务操作；

支付业务属于数据同步控制表中记载的需解决数据延迟或数据一致性问题的业务类型。

步骤2、先对操作用户编01加分布式锁，保证当前时间仅该操作用户在操作。

步骤3、获取到分布式锁之后，获取并判断缓存数据库的操作版本（redis.version为3）是否等于数据中心A数据库的操作版本（database.version为3），两操作版本相同，就代表数据中心A数据库中的数据已更新至目前最新版本，即为有效数据；

另一种情况：数据中心A中数据库的操作版本不等于缓存数据库的操作版本使，就代表有其他数据中心操作的数据还没有同步到数据中心A，可以放弃本次支付业务操作或者间隔一秒一次轮询数据中心A数据库的操作版本（database.version）不停做判断（即：等待其他数据中心操作的数据同步到数据中心A），等到一致为止，再继续进行业务操作，不一致的这段时间，数据中心A的数据都不是最新的，即数据是无效的。

步骤4、判断redis.version=database.version之后开始进行业务处理，完成支付业务，得到支付过程相关数据及支付后的数据，这些数据最先更新在缓存数据库中，受网络延迟影响，之后再更新在数据中心A中。

步骤5、业务完成之后，更新redis中存储的支付业务的操作用户或操作员编号，操作版本的值加1得到4，并且将加1之后的结果以及更新的时间同步更新到数据中心的数据库中，如表3所示：

表3

步骤6、释放分布式锁，使其他操作用户或操作员可对支付业务继续进行操作。

本发明的优点：

本发明通过在各数据中心的数据库增加数据同步控制表，并在数据同步控制表中存放需解决数据延迟问题的业务类型及相关信息，在操作用户或操作员发起涉及该业务类型的操作时，先比对缓存数据库与支撑该业务操作的数据中心数据同步控制表中数据的一致性，若一致则有效，再进行业务操作，解决了数据延迟对该类业务类型的影响，保证了系统数据的安全性。

本发明与现有技术方案相比，降低数据中心数据库表改动的范围，提升了业务层对于数据同步延时的感知，可以人为选择最适合自己的方案去做发现数据无效之后的处理，增强了系统对业务使用的把控（可以根据version去观察每个业务触发的频率等），在提升系统的可用性，扩展性同时，低成本解决了数据同步延时导致的数据有效性、一致性问题。

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

Claims

1.一种多活架构下保障业务操作数据有效性的方法，其特征在于，包括：

在各数据中心的数据库中均新增数据同步控制表，所述数据同步控制表的结构信息包含业务类型、操作用户或操作员编号、操作版本和更新时间；

2.根据权利要求1所述的多活架构下保障业务操作数据有效性的方法，其特征在于：所述业务类型为多活架构下需解决数据延迟或数据一致性问题的业务类型，包括支付业务、转账业务。

3.根据权利要求1所述多活架构下保障业务操作数据有效性的方法，其特征在于：

4.根据权利要求1所述多活架构下保障业务操作数据有效性的方法，其特征在于：在业务操作完成后，将该业务所属业务类型在所述缓存数据库中对应的操作版本值加1，完成对所述缓存数据库中存储的操作版本的更新。

5.根据权利要求1所述多活架构下保障业务操作数据有效性的方法，其特征在于：业务操作完成后释放所述分布式锁。

6.一种多活架构下保障业务操作数据有效性的系统，其特征在于，包括：分布式锁实现模块、数据有效性判断模块、业务处理模块和数据更新模块；

所述分布式锁实现模块，用于：

所述数据有效性判断模块，用于：

所述业务处理模块，用于：

所述数据更新模块，用于：

在业务操作完成后更新所述缓存数据库中存储的业务类型、操作用户或操作员编号、操作版本，以及更新该数据中心数据库中的数据同步控制表。

7.根据权利要求6所述的多活架构下保障业务操作数据有效性的系统，其特征在于：所述业务类型为多活架构下需解决数据延迟或数据一致性问题的业务类型，包括支付业务、转账业务。

8.根据权利要求6所述的多活架构下保障业务操作数据有效性的系统，其特征在于：

9.根据权利要求6所述的多活架构下保障业务操作数据有效性的系统，其特征在于：在业务操作完成后，将该业务所属业务类型在所述缓存数据库中对应的操作版本值加1，完成对所述缓存数据库中存储的操作版本的更新。

10.根据权利要求6所述的多活架构下保障业务操作数据有效性的系统，其特征在于：所述分布式锁实现模块，还用于：

业务操作完成后释放所述分布式锁。