CN112905636A - 数据操作方法、服务器和计算机可读介质 - Google Patents

Abstract

本申请提供了一种数据操作方法、服务器和计算机可读介质。该方法包括：接收客户端发送的数据操作请求；从数据操作请求解析出令牌，并根据令牌获取与请求者相对应的租户ID；将租户ID放入执行线程的上下文中；基于数据操作请求和与数据操作请求相对应的业务映射器构建对应的数据操作方法，把待操作数据转换成数据操作方法的入参的查询对象，并调用数据操作方法；从执行线程的上下文中获取租户ID，并将租户ID合并到查询对象中；把查询对象转换成相应的数据库查询语句；以及调用数据库驱动来执行数据库查询语句。该方法以更低的购置成本、维护成本和开发成本实现了在按租户ID字段区分租户的多租户隔离的数据管理系统进行数据删除和读取。

Description

数据操作方法、服务器和计算机可读介质

技术领域

本申请主要涉及数据库技术领域，尤其涉及一种数据操作方法、服务器和计算机可读介质。

背景技术

在SaaS业务系统中，在一台或一组服务器上运行的SaaS系统可以为多个租户(客户)提供服务，多个租户在互联网环境下使用同一套程序。租户数据是集中存储的，因此需实现各租户间的数据隔离以保证数据的安全性。

为每个租户提供独立的数据库是SaaS多租户系统的数据隔离解决方案之一。这种方案的用户数据隔离级别最高，能够满足不同租户的独特需求，安全性最好且技术难度低。但由于该方案增多了数据库的安装数量，维护工作量大，开通租户时间长，且应用程序需要多部署，实现成本最高。

为每个租户提供独立的表空间是另一种SaaS多租户系统的数据隔离解决方案。这种方案的实现方式是所有租户共享同一个应用，应用后端只连接一个数据库系统，所有租户共享这个数据库系统，每个租户在数据库系统中拥有一个独立的表空间。也就是说，不同租户的数据存储在同一个数据库下，但使用不同的表。这种方案提供了一定程度的逻辑数据隔离，一个数据库系统可支持多个租户，隔离级别较高且技术难度较低。但该方案的维护工作量大，开通租户时间长，且应用程序需要多部署，实现成本较高。

因此，如何降低多租户隔离的数据管理系统的购置成本、维护成本和开发成本是本领域技术人员亟需解决的问题。

发明内容

本申请要解决的技术问题是提供一种数据操作方法、服务器和计算机可读介质，能够降低多租户隔离的数据管理系统的购置成本、维护成本和开发成本。

为解决上述技术问题，本申请提供了一种数据操作方法，适用于多租户隔离的数据管理系统，所述方法包括：接收客户端发送的数据操作请求，所述数据操作请求为数据删除请求或数据读取请求，并包含待操作数据和请求者的令牌；从所述数据操作请求解析出所述令牌，并根据所述令牌获取与所述请求者相对应的租户ID；将所述租户ID放入执行线程的上下文中；基于所述数据操作请求和与所述数据操作请求相对应的业务映射器构建对应的数据操作方法，把所述待操作数据转换成所述数据操作方法的入参的查询对象，并调用所述数据操作方法；从所述执行线程的上下文中获取所述租户ID，并将所述租户ID合并到所述查询对象中；把所述查询对象转换成相应的数据库查询语句；以及调用数据库驱动来执行所述数据库查询语句。

在本申请的一实施例中，所述从所述执行线程的上下文中获取所述租户ID，并合并到所述查询对象中的步骤、所述把所述查询对象转换成相应的数据库查询语句的步骤、以及所述调用数据库驱动来执行所述数据库查询语句的步骤，均由ORM框架执行，所述ORM框架在所述执行线程中进行操作。

在本申请的一实施例中，所述ORM框架为MyBatis。

在本申请的一实施例中，所述数据操作请求所对应的数据表所对应的对象继承预设的基础对象，所述基础对象适用于基于ORM框架的多租户隔离的数据管理系统。

在本申请的一实施例中，所述业务映射器继承预设的数据操作映射器，所述数据操作映射器适用于基于ORM框架的多租户隔离的数据系统并包含预设的数据操作接口，所述数据操作接口至少包括删除接口和读取接口。

在本申请的一实施例中，所述数据操作请求所对应的表所对应的对象与预设的元数据的映射关系通过预设的对象-关系映射对象记录。

在本申请的一实施例中，在所述将所述租户ID合并到所述查询对象的步骤之前，还包括：确认所述数据操作请求所对应的表所对应的对象是否继承预设的基础对象，所述基础对象适用于基于ORM框架的多租户隔离的数据系统。

在本申请的一实施例中，所述数据库查询语句为删除数据库查询语句或读取数据库查询语句；把所述查询对象转换成相应的数据库查询语句包括：

调用数据库查询构建器中与所述数据操作请求相对应的方法；所述数据库查询构建器根据所述查询对象构建相应的数据库查询语句；以及所述数据库查询构建器将所述数据库查询语句返回给所述业务映射器来代理。

本申请提供了一种服务器，用于多租户隔离的数据管理，所述服务器包括：存储器，用于存储可由处理器执行的指令；以及处理器，用于执行所述指令以实现如上所述的方法。

本申请提供了一种存储有计算机程序代码的计算机可读介质，所述计算机程序代码在由处理器执行时实现如上所述的方法。

与现有技术相比，本申请的数据操作方法、服务器和计算机可读介质根据令牌获取租户ID，然后通过上下文和业务映射器实现了租户ID的传递，从而以更低的购置成本、维护成本和开发成本实现了在按租户ID字段区分租户的多租户隔离的数据管理系统进行数据删除和读取。

附图说明

包括附图是为提供对本申请进一步的理解，它们被收录并构成本申请的一部分，附图示出了本申请的实施例，并与本说明书一起起到解释本申请原理的作用。附图中：

图1是根据本申请一实施例示出的一种多租户隔离的数据管理系统的结构示意图。

图2是根据本申请一实施例示出的数据操作方法的示意流程图。

图3是根据本申请一实施例提供的一种公共的对象继承体系示意图。

图4是根据本申请一实施例提供的一种统一的内存元数据管理示意图。

图5是根据本申请一实施例提供的一种标准的数据写入接口示意图。

图6是根据本申请一实施例示出的服务器的示意框图。

具体实施方式

为了更清楚地说明本申请的实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其他的步骤或元素。

除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本申请的范围。同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或下面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，或将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

按租户标识(又称租户ID)字段区分租户(又称按行记录隔离)是一种实现成本较低的SaaS多租户系统的数据隔离解决方案。这种方案的实现方式是多租户共享同一个数据库、同一个表空间，但在表中增加TenantID(租户ID)多租户的数据字段。这种方案具有程序部署简单、维护工作量小和租户开通时间短等诸多优点，其维护和购置成本比前两种解决方案低，允许每个数据库支持的租户数量最多，能够以最少的服务器为最多的租户提供服务。该方案每写入一条数据时都需要有一个租户的标识。这样才能在同一张表中区分出不同租户的数据。但这种方案需要系统开发人员需要关注SaaS数据隔离的细节才能进行开发，导致开发成本高且易出错。

本申请提供了一种数据删除和查询方法，适用于多租户隔离的数据管理系统，尤其适用于按租户ID字段区分租户的SaaS多租户隔离的数据管理系统。

图1是根据本申请一实施例示出的一种多租户隔离的数据管理系统的结构示意图。如图1所示，该多租户隔离的数据管理系统包括客户端101、应用服务器102和数据库(Database)103。

数据库103是建立在计算机存储设备上，按照一定数据结构来组织、存储和管理数据的仓库。在本申请实施例中，并不限定承载数据库103的计算机存储设备的实现形式，也不限定数据库103的类型和其采用的数据结构。例如，从数据结构来看，数据库103可以是层次式数据库、网络式数据库或关系式数据库；从存储格式来看，数据库103可以是行式数据库，也可以是列式数据库；从数据库语言来看，数据库103可以是SQL数据库，也可以是Cassandra数据库等。

应用在数据库103中的数据隔离解决方案是按租户标识(又称租户ID)字段区分租户(又称按行记录隔离)，多租户可以共享同一个数据库、同一个表空间。数据库每写入一条数据时都需要有一个租户标识。这样才能在同一张表中区分出不同租户的数据。租户通过客户端进行数据变更操作时，只能对租户本身的数据进行写入和编辑，且整个数据读取隔离过程对用户透明。

应用服务器(又称应用程序服务器)102介于客户端101和数据库103之间。通过应用服务器102可建立客户端101与数据库103之间的数据信息的交流。应用服务器102负责接收来自客户端的数据操作请求，并根据该数据库操作请求对数据库103进行相应操作。

客户端101与应用服务器102之间通信连接，该通信连接可以是有线或无线网络连接。应用服务器102可同时与多个客户端进行通信连接。可选地，客户端101可以与应用服务器102处于同一局域网内，也可以处于不同局域网内。

另外，应用服务器102与数据库103之间也建立通信连接，该通信连接可以是有线或无线网络连接。可选地，在部署实现上，应用服务器102与数据库103可以部署在同一物理设备上实现，也可以部署在不同物理设备上实现。当应用服务器102与数据库103部署在不同物理设备上实现时，两者可以部署同一局域网内，也可以部署在不同局域网内。

客户端101可以看作是数据库103面向用户提供的交互接口，允许用户通过该客户端101访问数据库103。当用户需要访问数据库103时，或者，客户端101有数据库访问需求时，客户端101可以向应用服务器102发送数据库访问请求；应用服务器102可以根据该数据库访问请求对数据库103进行相应操作。

在一种数据库数据操作场景中，客户端101可以向应用服务器102发送数据操作请求。应用服务器102根据接收到的数据操作请求通过数据库查询语句对数据库103进行数据删除(Delete)和读取(Read)操作。

在本申请一实施例中，本申请的数据操作方法可以实施在应用服务器上，由运行在应用服务器上的应用服务来执行。应用服务中可以包括ORM框架，ORM框架可以在应用服务执行线程中进行操作。在本申请的一实施例中，ORM框架可以为MyBatis。

在实施本申请的数据操作方法前，运行在应用服务器上的应用服务可以进行以下一项或多项基础准备：公共的对象继承体系、统一的内存元数据管理、标准的数据写入接口、统一的上下文管理以及公共数据读取拦截机制。

在公共的对象继承体系中，可以有一个或多个基础对象。图3是根据本申请一实施例提供的一种公共的对象继承体系示意图。

如图3所示，以公共的对象继承体系中有两个基础对象为例，第一基础对象CommonPO(Persistent Object，持久化对象)可以用来做系统字段定义，第二基础对象BasePO可以用来定义涉及租户隔离的数据表基础对象，第二基础对象BasePO继承第一基础对象CommonPO。业务数据表tenant_isolated_business_XXX_PO继承第二基础对象BasePO。第一基础对象CommonPO中的is_deleted可以用于表示该对象是否已被删除；id可以为数据的唯一标记，例如uuid；第二基础对象BasePO中的tenant_id可以为租户ID。对象继承体系是映射器继承的基础，也是做对象拦截并且写入租户ID的基础。通过对象继承体系可以简单地判断出哪些对象要做租户隔离。

统一的内存元数据管理是指，在公共的对象继承体系的基础上，应用服务可以在启动过程中记录把所有对象以及对象的字段信息加载至内存。图4是根据本申请一实施例提供的一种统一的内存元数据管理示意图。应用服务可以在内存中通过一个ORMapping对象记录Java对象和Table元数据的映射关系。Table(表)是由Column(字段)组成的，表和PO一一对应，字段和PO的属性一一对应。如图4所示，Column中的sqlName可以是字段在数据库中的名字；JavaName可以是字段在Java对象中的名字；nullable可以是指是否可以为空，插入时会根据是否为空来做验证，如果不能为空的字段的Java对象缺少值则会报错；defaultValue可以是默认值，即在Java对象转数据库查询语句时如果没有提供值时填入的默认值；sqlType可以是字段在数据库中类型，方便数据做类型转换；JavaType可以是字段在Java对象中类型，方便数据做类型转换。Table中的JavaName可以是表对应Java类型的全限定名称；sqlName可以是表在数据库中的名称；comment可以是表在数据库中的备注名称；columns可以是表下的所有字段集合。通过记录持久化对象类型(Class)和Table(表)元数据的关系，可以通过持久化对象类型获取到Table以及Table中的数据库字段，这些信息可以为insert和update语句提供表信息和字段信息。ORM框架的上层全部通过Java对象操作数据。ORMapping的实际类型可以为ConcurrentMap<Class<？>,Table>。

标准的数据写入接口可以由预设的映射器提供。每一个业务PO可以对应一个业务映射器。例如，业务数据表tenant_isolated_business_XXX_PO可以对应业务映射器tenant_isolated_business_XXX_Mapper。在本申请的一实施例中，业务映射器继承预设的数据操作映射器。数据操作映射器包含预设的数据操作接口。图5是根据本申请一实施例提供的一种标准的数据写入接口示意图。如图5所示，预设的数据操作映射器BaseMapper中定义了多个基础的接口：getById(id)可以为用于根据ID删除数据的接口，find(propName,propValue)可以为用于根据属性名和属性值读取数据的接口，findOne(propName,propValue)可以为用于根据属性名和属性值读取数据并返回一条的接口，find(criteria)可以为用于根据查询对象返回数据的接口，findOne(criteria)可以为用于根据查询对象返回数据并返回一条的接口，findPage(pageRequest,criteria)可以为用于根据查询对象返回数据并分页的接口，delete(criteria)可以为用于根据查询对象删除数据的接口，deleteById(id)可以为用于根据ID删除数据的接口。这几类数据操作能满足几乎所有的数据操作需求，绝大部分情况下使用中只需要声明接口，不需要在接口中声明额外的方法。继承了预设的数据操作映射器BaseMapper的业务映射器tenant_isolated_business_XXX_Mapper的接口和PO一一对应，数据写入方法可以全部直接使用父类接口方法。通过标准接口实现数据库操作功能，能极大地减少自定数据库查询语句的必要。因此，在通用接口基础上构建的多租户隔离的数据管理系统的开销和使用成本更低。

统一的上下文管理是指通过将用户的登录信息(例如用户的令牌)从应用入口一直传递至应用服务执行线程的线程变量中，在任何时候均能从线程变量中获取上下文，然后从中获取租户ID。

公共数据读取拦截机制是指判断数据操作请求所对应的表所对应的Java对象是否继承自预设的基础对象，如果是的话调用合并方法来把租户ID添加到查询对象之中。

图2是根据本申请一实施例示出的数据操作方法的示意流程图。如图2所示，该数据操作方法包括以下步骤201-207：

步骤201，当请求者在客户端执行数据删除或数据读取操作时，客户端发送相应的数据操作请求至应用服务器。应用服务接收客户端发送的数据操作请求。数据操作请求为数据删除(Delete)请求或数据读取(Read)请求。数据操作请求至少包含待操作数据和请求者的令牌(可以是请求者的登录令牌)。

步骤202，应用服务从数据操作请求解析出令牌(Token)，并根据令牌获取与请求者相对应的租户ID(TenantID)。在一个示例中，应用服务可以根据令牌从用户档案中获取包括租户ID在内的用户信息并生成Session(会话)。应用服务记录Session信息，并维护Token->Session的映射关系。通过根据令牌来获取租户ID，使得请求者不需要提供租户ID就能进行数据删除或读取操作。

步骤203，应用服务将获取到的租户ID放入应用服务执行线程的上下文中。通过将租户ID放入执行线程的上下文中，使得在该执行线程中操作的后续步骤可以随时获取到上下文中的租户ID。

步骤204，应用服务基于数据操作请求和与数据操作请求相对应的业务映射器构建对应的数据操作方法。在本申请的一实施例中，业务映射器可以继承预设的数据操作映射器，数据操作映射器可以适用于基于ORM框架的多租户隔离的数据系统并包含预设的数据操作接口。数据操作接口可以至少包括删除接口和读取接口。然后，应用服务，把待操作数据转换成数据操作方法的入参的查询对象，并调用数据操作方法。通过使用业务映射器来构建数据操作方法，能够简化流程和降低开发人员的开发成本。

在本申请的一实施例中，数据操作请求所对应的数据表所对应的对象继承预设的基础对象，基础对象适用于基于ORM框架的多租户隔离的数据管理系统。应用服务处理数据操作请求的过程会需要解析数据操作请求所对应的数据表所对应的对象的类型，这个对象和数据库表一一对应。应用服务可以基于数据操作请求所对应的数据表所对应的对象的类型来判定其是否为基础对象的子类，然后判定该租户是否需要进行租户隔离。

在本申请的一实施例中，数据操作请求所对应的表所对应的对象与预设的元数据的映射关系通过预设的对象-关系映射(ORMapping)对象记录。，数据操作请求所对应的表所对应的对象与预设的元数据的映射关系可以用来获取该对象对应的数据库表信息，可以用来构建最终生成的SQL语句。

步骤205，应用服务从执行线程的上下文中获取租户ID，并将租户ID合并到查询对象中。查询对象里面可以有数据操作请求中的条件参数以及参数值对。将租户ID合并到查询对象中可以是在查询对象中额外添加一个条件参数“tenant_id”，参数值为当前线程中的租户ID。

在本申请的一实施例中，在步骤205之前，还包括：应用服务确认数据操作请求所对应的表所对应的对象是否继承预设的基础对象，基础对象适用于基于ORM框架的多租户隔离的数据系统。

步骤206，应用服务把查询对象转换成相应的数据库查询语句。

应用服务把查询对象转换成相应的数据库查询语句。因为查询对象中包含有租户ID，所以数据库查询语句中也包含有租户ID。在本申请的一实施例中，数据库查询语句可以为删除数据库查询语句或读取数据库查询语句。当数据操作请求为数据删除请求时，数据库查询语句可以为删除数据库查询语句；当数据操作请求为数据读取请求时，数据库查询语句可以为读取数据库查询语句。

在本申请的一实施例中，步骤206可以包括以下步骤：应用服务调用数据库查询构建器中与数据操作请求相对应的方法；数据库查询构建器根据查询对象构建相应的数据库查询语句；以及数据库查询构建器将数据库查询语句返回给业务映射器来代理。

步骤207，应用服务调用数据库驱动来执行数据库查询语句。然后，数据库执行相应的数据库删除或读取操作。在一个示例中，数据库驱动可以是Java数据库连接(JavaDatabase Connectivity，简称JDBC)。

在本申请的一实施例中，步骤205-207可以均由ORM框架执行。ORM框架可以在应用服务执行线程中进行操作。在本申请的一实施例中，ORM框架可以为MyBatis。通过使用ORM框架对上述步骤进行封装，可以让普通应用开发人员不用过于关注数据隔离的相关细节，降低开发成本。

综上所述，本申请的数据操作方法根据令牌获取租户ID，然后通过上下文和业务映射器实现了租户ID的传递，从而以更低的购置成本、维护成本和开发成本实现了在按租户ID字段区分租户的多租户隔离的数据管理系统进行数据删除和读取。

本申请提供了一种服务器，用于多租户隔离的数据管理。服务器包括：存储器，用于存储可由处理器执行的指令；以及处理器，用于执行所述指令以实现如上所述的数据操作方法。

图6是根据本申请一实施例示出的服务器的示意框图。服务器600可包括内部通信总线601、处理器(Processor)602、只读存储器(ROM)603、随机存取存储器(RAM)604、以及通信端口605。当应用在个人计算机上时，服务器600还可以包括硬盘607。内部通信总线601可以实现服务器600组件间的数据通信。处理器602可以进行判断和发出提示。在一些实施例中，处理器602可以由一个或多个处理器组成。通信端口605可以实现服务器600与外部的数据通信。在一些实施例中，服务器600可以通过通信端口605从网络发送和接受信息及数据。服务器600还可以包括不同形式的程序储存单元以及数据储存单元，例如硬盘607，只读存储器(ROM)603和随机存取存储器(RAM)604，能够存储计算机处理和/或通信使用的各种数据文件，以及处理器602所执行的可能的程序指令。处理器执行这些指令以实现方法的主要部分。处理器处理的结果通过通信端口传给用户设备，在用户界面上显示。

上述的数据操作方法可以实施为计算机程序，保存在硬盘607中，并可记载到处理器602中执行，以实施本申请中的任一数据操作方法。

本申请提供了一种存储有计算机程序代码的计算机可读介质，所述计算机程序代码在由处理器执行时实现如上所述的数据操作方法。

数据操作方法实施为计算机程序时，也可以存储在计算机可读存储介质中作为制品。例如，计算机可读存储介质可以包括但不限于磁存储设备(例如，硬盘、软盘、磁条)、光盘(例如，压缩盘(CD)、数字多功能盘(DVD))、智能卡和闪存设备(例如，电可擦除可编程只读存储器(EPROM)、卡、棒、键驱动)。此外，本文描述的各种存储介质能代表用于存储信息的一个或多个设备和/或其它机器可读介质。术语“机器可读介质”可以包括但不限于能存储、包含和/或承载代码和/或指令和/或数据的无线信道和各种其它介质(和/或存储介质)。

应该理解，上文所描述的实施例仅是示意。本文描述的实施例可在硬件、软件、固件、中间件、微码或者其任意组合中实现。对于硬件实现，处理单元可以在一个或者多个特定用途集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器和/或设计为执行本文所述功能的其它电子单元或者其结合内实现。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述申请披露仅仅作为示例，而并不构成对本申请的限定。虽然此处并没有明确说明，本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示例性实施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

本申请的一些方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。处理器可以是一个或多个专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理器件(DAPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器或者其组合。此外，本申请的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。例如，计算机可读介质可包括，但不限于，磁性存储设备(例如，硬盘、软盘、磁带……)、光盘(例如，压缩盘CD、数字多功能盘DVD……)、智能卡以及闪存设备(例如，卡、棒、键驱动器……)。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个申请实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

虽然本申请已参照当前的具体实施例来描述，但是本技术领域中的普通技术人员应当认识到，以上的实施例仅是用来说明本申请，在没有脱离本申请精神的情况下还可做出各种等效的变化或替换，因此，只要在本申请的实质精神范围内对上述实施例的变化、变型都将落在本申请的权利要求书的范围内。

Claims (10)

1.一种数据操作方法，适用于多租户隔离的数据管理系统，所述方法包括：

接收客户端发送的数据操作请求，所述数据操作请求为数据删除请求或数据读取请求，并包含待操作数据和请求者的令牌；

从所述数据操作请求解析出所述令牌，并根据所述令牌获取与所述请求者相对应的租户ID；

将所述租户ID放入执行线程的上下文中；

基于所述数据操作请求和与所述数据操作请求相对应的业务映射器构建对应的数据操作方法，把所述待操作数据转换成所述数据操作方法的入参的查询对象，并调用所述数据操作方法；

从所述执行线程的上下文中获取所述租户ID，并将所述租户ID合并到所述查询对象中；

把所述查询对象转换成相应的数据库查询语句；以及

调用数据库驱动来执行所述数据库查询语句。

2.如权利要求1所述的方法，其特征在于，所述从所述执行线程的上下文中获取所述租户ID，并合并到所述查询对象中的步骤、所述把所述查询对象转换成相应的数据库查询语句的步骤、以及所述调用数据库驱动来执行所述数据库查询语句的步骤，均由ORM框架执行，所述ORM框架在所述执行线程中进行操作。

3.如权利要求2所述的方法，其特征在于，所述ORM框架为MyBatis。

4.如权利要求1所述的方法，其特征在于，所述数据操作请求所对应的数据表所对应的对象继承预设的基础对象，所述基础对象适用于基于ORM框架的多租户隔离的数据管理系统。

5.如权利要求1所述的方法，其特征在于，所述业务映射器继承预设的数据操作映射器，所述数据操作映射器适用于基于ORM框架的多租户隔离的数据系统并包含预设的数据操作接口，所述数据操作接口至少包括删除接口和读取接口。

6.如权利要求1所述的方法，其特征在于，所述数据操作请求所对应的表所对应的对象与预设的元数据的映射关系通过预设的对象-关系映射对象记录。

7.如权利要求1所述的方法，其特征在于，在所述将所述租户ID合并到所述查询对象的步骤之前，还包括：

确认所述数据操作请求所对应的表所对应的对象是否继承预设的基础对象，所述基础对象适用于基于ORM框架的多租户隔离的数据系统。

8.如权利要求1所述的方法，其特征在于，所述数据库查询语句为删除数据库查询语句或读取数据库查询语句；把所述查询对象转换成相应的数据库查询语句包括：

调用数据库查询构建器中与所述数据操作请求相对应的方法；

所述数据库查询构建器根据所述查询对象构建相应的数据库查询语句；以及

所述数据库查询构建器将所述数据库查询语句返回给所述业务映射器来代理。

9.一种服务器，用于多租户隔离的数据管理，所述服务器包括：

存储器，用于存储可由处理器执行的指令；以及

处理器，用于执行所述指令以实现如权利要求1-8任一项所述的方法。

10.一种存储有计算机程序代码的计算机可读介质，所述计算机程序代码在由处理器执行时实现如权利要求1-8任一项所述的方法。

Images