CN115712670A

CN115712670A - 一种数据源管理系统

Info

Publication number: CN115712670A
Application number: CN202211465868.XA
Authority: CN
Inventors: 朱卫中; 王刚; 丘凌; 陈天明; 曹航瑞; 任伟权; 黄慧
Original assignee: Tianyi Digital Life Technology Co Ltd
Current assignee: Tianyi Digital Life Technology Co Ltd
Priority date: 2022-11-22
Filing date: 2022-11-22
Publication date: 2023-02-24

Abstract

本申请公开了一种数据源管理系统，数据源管理系统由若干应用客户端、数据层中间件和若干数据库类型不同的数据源构成，其中所述数据层中间件设置有统一接口并封装有事务请求和查询请求的通用处理逻辑。本申请通过在应用客户端和数据源之间架构数据层中间件，通过数据层中间件设置的统一接口以及封装的通用处理逻辑实现应用客户端对数据源的操作。应用客户端无需直接操作具体的数据源，应用客户端只需接入数据层中间件，通过数据层中间件提供统一的数据操作接口，可间接完成对数据源的操作，实现了应用客户端与数据源的解耦，无需基于不同的数据库类型进行数据源对接开发，简化了应用客户端操作多数据源的开发过程。

Description

一种数据源管理系统

技术领域

本申请涉及IT软件开发领域，更具体地说，涉及一种数据源管理系统。

背景技术

随着社会经济和网络技术高速发展的新时代，各种应用客户端数据交换频繁，数据交换量大。现代应用客户端后端服务在涉及到缓存、远程调用、统计分析等场景时，通常需要对多个数据源进行操作。

而在分布式、微服务应用场景中，应用客户端在操作多数据源时，需要考虑并发请求、事务操作的一致性问题。

如果对多数据源的一致性要求很高，那么后端程序往往需要很复杂的逻辑来处理并发请求、事务操作的一致性问题，而这些处理通常与业务逻辑关系不大，实现复杂，维护困难。在大多数情况下，会因为处理逻辑过于复杂，而放弃多数据源的强一致性保障，只满足更容易编码实现的弱一致性。

现有的一致性解决方案通常专注于通用的分布式应用场景，应用客户端需要在程序中嵌入某种解决方案，并手动实现想要达到的效果，在面对复杂的应用场景时，实现难度大、复杂、耦合度高。

基于上述情况，本申请提出了一种适用于应用客户端操作多数据源的数据源管理方案，以避免上述弊端。

发明内容

有鉴于此，本申请提供了一种数据源管理系统、方法、设备和可读存储介质，通过引入数据层中间件，该数据层中间件通过统一接口与各所述应用客户端对接，内部封装通用处理逻辑以完成对多数据源的一致性操作，实现了应用客户端与数据源的解耦。

一种数据源管理系统，包括：

若干应用客户端、数据层中间件和若干数据库类型不同的数据源；

所述数据层中间件设置有统一接口，通过所述统一接口与各所述应用客户端对接，接收各所述应用客户端下发的API请求；

所述数据层中间件封装有事务请求和查询请求的通用处理逻辑，按照所述通用处理逻辑对连接的各所述数据源进行与所述API请求匹配的一致性操作，实现所述应用客户端与所述数据源的解耦。

可选的，所述数据层中间件，包括服务层、事务层和数据层；

所述服务层用于通过设置的所述统一接口接收各所述应用客户端下发的API请求；

所述事务层封装有事务请求和查询请求的通用处理逻辑，用于按照所述通用处理逻辑对所述API请求进行分析；

所述数据层与各所述数据源连接，用于具体完成与所述API请求匹配的一致性操作。

可选的，所述事务请求的通用处理逻辑，包括分布式事务逻辑和分布式锁逻辑；

所述分布式事务逻辑为：

通过引入xid标识同一个分布式事务，并在后端采用匹配的模式选型执行分布式事务，以实现不同数据源的操作一致性；

所述分布式锁逻辑为：

通过引入lock-name标识同一个请求，并在后端可采用匹配的锁实现方式执行分布式锁，以控制并发请求的一致性。

可选的，所述事务请求的通用处理逻辑，还包括数据源等级与事务响应机制；

所述数据源等级与事务响应机制为：

按照所述API请求对应的事务响应等级确定请求的数据源数量；

按照预设的各所述数据源的数字等级以及所述请求的数据源数量，确定各目标数据源；

从低数字等级向高数字等级逐一对所述各目标数据源进行事务请求，并返回事务响应。

可选的，所述查询请求的通用处理逻辑，包括优先级查询逻辑；

所述优先级查询逻辑为：

按照预设的各所述数据源的数字等级，从高数字等级向低数字等级逐一对各所述数据源进行查询请求尝试，并返回第一个有数据的数据源。

可选的，所述查询请求的通用处理逻辑，还包括数据补充逻辑；

所述数据补充逻辑为：

在所述数据层中间件返回数据给所述应用客户端后，对异步对不存在的所述数据源进行数据补充，以提高多数据源的一致性，同时提高下次查询的性能。

可选的，所述数据层包括数据源等级设置单元和事务响应机制单元；

所述数据源等级设置单元，用于对各所述数据源的数字等级进行设置，以控制数据源的处理优先级；

所述事务响应机制单元，用于对所述API请求的事务响应等级进行设置，以控制所述分布式事务的一致性强弱。

可选的，所述数据源的数据库类型，包括MySQL、Redis、Cassandra、Memory和File。

可选的，所述模式选型，包括XA、AT、TCC和SAGA。

可选的，所述锁实现方式，包括Redisson、ZooKeeper和数据库。

从上述的技术方案可以看出，本申请实施例提供的一种数据源管理系统，数据源管理系统由若干应用客户端、数据层中间件和若干数据库类型不同的数据源构成，其中所述数据层中间件设置有统一接口，通过所述统一接口与各所述应用客户端对接，接收各所述应用客户端下发的API请求。所述数据层中间件封装有事务请求和查询请求的通用处理逻辑，按照所述通用处理逻辑对连接的各所述数据源进行与所述API请求匹配的一致性操作，实现所述应用客户端与所述数据源的解耦。

本申请通过在应用客户端和数据源之间架构数据层中间件，通过数据层中间件设置的统一接口以及封装的通用处理逻辑实现应用客户端对数据源的操作。应用客户端无需直接操作具体的数据源，应用客户端只需接入数据层中间件，通过数据层中间件提供统一的数据操作接口，可间接完成对数据源的操作，实现了应用客户端与数据源的解耦，无需基于不同的数据库类型进行数据源对接开发，简化了应用客户端操作多数据源的开发过程。

同时，数据层中间件封装了多数据源操作需要解决的一致性问题的复杂逻辑，即通用处理逻辑，如分布式事务逻辑、分布式锁逻辑等，基于通用处理逻辑可解决多数据源操作、并发请求导致的数据不一致的问题。此外，通用处理逻辑可灵活配置调整，以适应不同的业务场景下的需求。

附图说明

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

图1为本申请实施例公开的一种应用客户端在操作多数据源的一般实现方法的示意图；

图2为本申请实施例公开的一种数据源管理系统的结构示意图；

图3为本申请实施例公开的一种数据层中间件的结构示意图；

图4为本申请实施例公开的一种事务请求的通用处理逻辑的示意图；

图5为本申请实施例公开的一种查询请求的通用处理逻辑的示意图；

图6为本申请实施例公开的第一种应用场景的示意图；

图7为本申请实施例公开的第二种应用场景的示意图；

图8为本申请实施例公开的第三种应用场景的示意图；

图9为本申请实施例公开的第四种应用场景的示意图。

具体实施方式

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

在介绍本申请的数据源管理系统之前，首先对分布式、微服务应用场景中，应用客户端在操作多数据源时的一般实现方法进行介绍。

如图1所示，一般实现方法中，应用客户端在操作多数据源时，每一应用端需要分别与每一数据源进行对接，并分别下达操作指令，面对数据库类型不同的数据源，需要针对每一应用客户端与不同的数据库类型逐一进行应用客户端操作多数据源的开发，开发任务繁重且无法解决并发请求、事务操作的一致性问题。

如果对一致性要求很高，往往需要在系统内部引入分布式事务、分布式锁，而这些涉及到分布式的处理逻辑，往往与业务代码高度耦合，实现复杂，维护困难。

本申请实施例提供一种数据源管理系统，通过引入数据层中间件，该数据层中间件通过统一接口与各所述应用客户端对接，内部封装通用处理逻辑以完成对多数据源的一致性操作，实现了应用客户端与数据源的解耦。

图2为数据源管理系统的结构示意图。如图2所示，所述数据源管理系统，包括：

若干应用客户端、数据层中间件和若干数据库类型不同的数据源。

所述数据层中间件设置有统一接口，通过所述统一接口与各所述应用客户端对接，接收各所述应用客户端下发的API请求。

其中，所述数据源的数据库类型，可以包括MySQL、Redis、Cassandra、Memory和File。数据源类型是可拓展和配置的，在实际应用中包括但不限于上述的数据库类型，实际上取决于当前数据源管理系统已经实现支持了多少种数据源。

图2中设置有两个应用客户端，以及三个数据库类型分别为MySQL、Redis、Cassandra的数据源。两个应用客户端通过数据中间层的统一接口与数据层中间件连接，并通过数据层中间件对MySQL、Redis、Cassandra数据源进行对应的数据操作。

在本申请的一些实施例中，对所述数据层中间件的结构进行进一步介绍。

所述数据层中间件包括服务层、事务层和数据层。

所述服务层用于通过设置的所述统一接口接收各所述应用客户端下发的API请求。

所述事务层封装有事务请求和查询请求的通用处理逻辑，用于按照所述通用处理逻辑对所述API请求进行分析。

如图3所示的数据层中间件，数据层中间件的服务层设置有统一接口，可通过统一接口与各个应用客户端连接，接收各个应用客户端下发的API请求。事务层封装有事务请求和查询请求的通用处理逻辑，基于通用处理逻辑对所述API请求进行分析。最后，数据层对连接的各所述数据源具体完成与所述API请求匹配的一致性操作。

其中，所述数据层可以包括数据源等级设置单元和事务响应机制单元。

如图3中，分别对MySQL、Redis、Cassandra数据源设置为等级1至等级3。

可选的，所述事务请求的通用处理逻辑，可以包括以下三种，分别为：

①分布式事务逻辑

所述分布式事务逻辑为：

通过引入xid标识同一个分布式事务，并在后端采用匹配的模式选型执行分布式事务，以实现不同数据源的操作一致性。

其中，所述模式选型，包括XA、AT、TCC和SAGA。模式选型是可拓展和配置的，在实际应用中包括但不限于上述的模式选型，实际上取决于当前数据源管理系统已经实现支持了多少种模式选型。

②分布式锁逻辑

所述分布式锁逻辑为：

其中，所述锁实现方式，包括Redisson、ZooKeeper和数据库。锁实现方式是可拓展和配置的，在实际应用中包括但不限于上述的锁实现方式，实际上取决于当前数据源管理系统已经实现支持了多少种锁实现方式。

③数据源等级与事务响应机制

所述数据源等级与事务响应机制为：

图4为本申请实施例公开的一种事务请求的通用处理逻辑的示意图。以图4为例，分布式事务逻辑通过引入xid标识同一个分布式事务，并在后端采用匹配的模式选型执行分布式事务，后端可采用多种成熟的解决方案，如XA、、AT、TCC、SAGA等可配置方式以实现分布式事务。

分布式锁逻辑通过引入lock-name标识同一个请求，并在后端可采用匹配的锁实现方式执行分布式锁，以控制并发请求的一致性，如Redisson、ZooKeeper和数据库等可配置方式以实现分布式锁。

数据源等级与事务响应机制用于控制数据一致性强弱，在一致性和性能间做出平衡。在处理多数据源操作时，通过响应机制来决定何时返回应用客户端处理成功。对一致性要求高的场景，可提高响应机制，但性能会有所降低。对一致性要求低的场景，可降低响应机制，但性能会有所提升。

可选的，所述查询请求的通用处理逻辑，可以包括以下两种，分别为：

①优先级查询逻辑

所述优先级查询逻辑为：

②数据补充逻辑

所述数据补充逻辑为：

图5为本申请实施例公开的一种查询请求的通用处理逻辑的示意图。以图5为例，优先级查询逻辑按照预设的各所述数据源的数字等级，从高数字等级向低数字等级逐一对各所述数据源进行查询请求尝试，并返回第一个有数据的数据源。因为高数字等级的数据源通常是具有更高性能的数据库，如Redis，查询请求将从高数字等级向低数字等级尝试，并返回第一个有数据的数据源。该方案相当于封装了多级缓存的查询操作，可提高查询性能。

数据补充逻辑在所述数据层中间件返回数据给所述应用客户端后，对异步对不存在的所述数据源进行数据补充，以提高多数据源的一致性，同时提高下次查询的性能。

下面分别提供了本申请可应用四种的应用场景，可以理解的是，本申请的可应用场景应包括但不限于以下四种，下述应用场景的介绍是为进一步对本申请进行说明，体现本申请在多数据源场景下的优势。

第一种应用场景：

图6为本申请实施例公开的第一种应用场景的示意图。

如图6所示，本申请可应用于处理不同数据库类型的数据源，保证数据一致性的场景，如数据持久层和缓存同步、数据迁移、数据上报、数据备份等。

图6中数据层中间件可与五种不同数据库类型的数据源进行对接并进行数据操作，无需基于不同的数据库类型进行数据源对接开发，简化了应用客户端操作多数据源的开发过程。

第二种应用场景：

图7为本申请实施例公开的第二种应用场景的示意图。

如图7所示，本申请可应用于处理多个应用客户端、多个数据源间的数据解耦，保证数据一致性的场景，如服务间远程调用并操作数据库。

图7中设置有用户服务功能的应用客户端1以及家庭服务功能的应用客户端2，以及MySQL、Redis两种不同数据库类型的数据源，本申请可实现应用客户端1、应用客户端2对MySQL数据源1、Redis数据源2的数据操作。

第三种应用场景：

图8为本申请实施例公开的第三种应用场景的示意图。

如图8所示，本申请可应用于处理分布式数据存储系统，在集群内多个节点之间保证数据一致性的同步场景，如MySQL主从同步。

第四种应用场景：

图9为本申请实施例公开的第四种应用场景的示意图。

如图9所示，本申请可应用于处理分布式数据存储系统，在跨集群、多数据中心之间保证数据一致性的同步场景，如MySQL跨集群同步。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims

1.一种数据源管理系统，其特征在于，包括：

2.根据权利要求1所述的系统，其特征在于，所述数据层中间件，包括服务层、事务层和数据层；

3.根据权利要求1所述的系统，其特征在于，所述事务请求的通用处理逻辑，包括分布式事务逻辑和分布式锁逻辑；

所述分布式事务逻辑为：

所述分布式锁逻辑为：

4.根据权利要求3所述的系统，其特征在于，所述事务请求的通用处理逻辑，还包括数据源等级与事务响应机制；

所述数据源等级与事务响应机制为：

5.根据权利要求1所述的系统，其特征在于，所述查询请求的通用处理逻辑，包括优先级查询逻辑；

所述优先级查询逻辑为：

6.根据权利要求5所述的系统，其特征在于，所述查询请求的通用处理逻辑，还包括数据补充逻辑；

所述数据补充逻辑为：

7.根据权利要求4所述的系统，其特征在于，所述数据层包括数据源等级设置单元和事务响应机制单元；

8.根据权利要求1所述的系统，其特征在于，所述数据源的数据库类型，包括MySQL、Redis、Cassandra、Memory和File。

9.根据权利要求3所述的系统，其特征在于，所述模式选型，包括XA、AT、TCC和SAGA。

10.根据权利要求3所述的系统，其特征在于，所述锁实现方式，包括Redisson、ZooKeeper和数据库。