一种租户的资源管理方法及租户管理系统与流程

1.本技术涉及云计算领域，尤其涉及一种租户的资源管理方法及租户管理系统。


背景技术：

2.云服务涌现了很多改变传统it架构和运维方式的新技术，比如，虚拟机、容器、微服务等，但无论这些技术应用在哪些场景，降低成本、提升效率是云服务永恒的主题。基于此，多租共享资源平台(如，无服务器(serverless)云开发，也可称为serverless服务、serverless平台等)成为云服务的研究热点，相比传统开发模式，多租共享资源平台免去了开发者构建并维护后台服务的工作，无需构建维护后台的基础设施，从而可实现业务的快速上线和迭代，大幅减低了开发成本。按量收费是多租共享资源平台的特色，即只有开发者产生了实际的读写操作、存储等时，才需要交费，以serverless服务为例，当开发者开通serverless服务后，如果不操作或者用量很小(免费额度内)，不会产生任何费用，但会消耗serverless平台商的运营成本。因此，如何有效控制资源成本，支撑海量大型、小型，尤其是免费租户(如，应用程序(application，app))接入，是每个serverless平台商重点关注的问题。
3.业界管理租户在多租共享资源平台的资源一般有2种方式，方式1、租户资源不做预留，即按照各租户对资源的使用优先级对资源进行实时调度，优先级高的优先使用资源。方式2、提前给租户预留一定资源上限，租户公平使用资源。
4.然而，上述两种方式各有缺点：方式1虽然能够根据租户的当前需求，实时调整资源分配，但容易导致资源抢占，优先级低的租户可能长期处于排队等候的状态；而方式2虽然避免了租户间的资源抢占，但存在完全不活跃的僵尸租户对预留资源浪费的情况。


技术实现要素：

5.本技术实施例提供了一种租户的资源管理方法及租户管理系统，用于基于统计周期内租户的请求信息来计算租户在该统计周期内的活跃等级，并基于活跃等级实现对不同租户预留资源的动态差异化管理，本技术实施例能够根据租户的资源需求实时动态调整资源分配，从而避免出现不活跃租户(即僵尸租户)对预留资源浪费的情况，使得在相同系统资源的情况下，该资源多租共享平台能同时承载更多租户，提高了资源多租共享平台服务租户的能力，且最大化降低僵尸租户的运营成本。
6.基于此，本技术实施例提供以下技术方案：
7.第一方面，本技术实施例首先提供一种租户的资源管理方法，可用于云计算领域中，该方法包括：首先，获取租户在预设的周期时长内的请求信息(也可称为请求事件)，在预设周期时长内租户发送的请求信息可以是一个，也可以是多个，此处不做限定。需要说明的是，在本技术实施例中，租户向资源多租共享平台发送的信息都可称为请求信息，例如，请求接入的信息、请求订阅的信息、请求存储的信息等等，具体此处不做限定。在获取租户在周期时长内的一个或多个请求信息之后，将进一步基于预设的信息类型从获取到的这些
请求信息中确定目标请求信息(也可称为活跃事件)，确定的目标请求信息可以是一个，也可以是多个，具体本技术对此不做限定。在基于预设的信息类型从获取到的请求信息中确定出一个或多个目标请求信息之后，再根据目标请求信息确定该租户的目标活跃等级。在计算得到该租户的目标活跃等级后，如果该租户的当前活跃等级与该目标活跃等级不同，则根据计算得到的目标活跃等级调整该租户在资源多租共享平台上的资源，调整方式包括但不限于：资源升级、资源降级、冷备份后释放该租户在资源多租共享平台上的占用资源、热恢复后重新为该租户分配资源等。具体的调整方式由租户的当前活跃等级以及计算得到的目标活跃等级来确定。
8.在本技术上述实施方式中，基于统计周期内租户的请求信息来计算租户在该统计周期内的活跃等级，并基于活跃等级实现对不同租户预留资源的动态差异化管理，即基于租户在该统计周期内的活跃等级调整该租户在资源多租共享平台上的资源，调整方式包括但不限于：资源升级、资源降级、冷备份后释放该租户在资源多租共享平台上的占用资源、热恢复后重新为该租户分配资源等，本技术实施例能够根据租户的资源需求实时动态调整资源分配，从而避免出现不活跃租户(即僵尸租户)对预留资源浪费的情况，使得在相同系统资源的情况下，该资源多租共享平台能同时承载更多租户，提高了资源多租共享平台服务租户的能力，且最大化降低僵尸租户的运营成本。
9.在第一方面的一种可能的实现方式中，若计算得到的目标活跃等级为第一等级，且该租户当前的活跃等级为第一目标等级，则将该租户在资源多租共享平台上运行的数据库实例的数据在预设的备份节点上进行冷备份，得到备份数据，之后，再释放该租户在该资源多租共享平台上占用的资源(即释放该租户的数据库实例对象，例如，释放该租户的线程池、订阅缓存池、连接池等动态资源，使其不再占用数据库节点上的资源)。需要注意的是，数据库实例实质可看做是一个数据库进程，实例则是进程里面的一个database实例，根据数据库的架构不同数据库实例的表现形式会有所不同，此处不予赘述。这里需要说明的是，第一等级用于表示该租户处于不活跃状态，具体用于表征该租户在周期时长内与资源多租共享平台之间信息交互的数量没有达到第一预设阈值，该第一预设阈值就是判断租户是不活跃租户(即僵尸租户)还是活跃租户的分界线，未达到该第一预设阈值则判定为不活跃租户，达到该第一预设阈值则说明该租户不是不活跃租户，在本技术实施例中，达到该第一预设阈值的可以统称为第一目标等级，具体地，基于不同的划分方式，第一目标等级实际还可进一步划分为更小粒度的等级(如，第二等级、第三等级等)，其中，每个更小粒度的等级均各自对应段阈值区间，例如，阈值区间[y1，y2]对应一个细分等级，阈值区间[y2，y3]对应另一个细分等级，
……
，以此类推，可将第一目标等级又划分为多个等级，具体的划分方式可基于实际需求自定义，本技术对此不予赘述。
[0010]
在本技术上述实施方式中，由于在资源多租共享平台按量收费的情况下，很多不活跃租户(即僵尸租户)长期占用连接、缓存、database实例资源，最终制约该资源多租共享平台的租户数量，而不活跃租户也不能给平台提供商带来流量进而贡献流水，这极大的增加了平台提供商的运营成本，因此，本技术实施例可以根据租户的实际运行情况(即判定是否活跃)，动态调整资源多租共享平台的资源分配。在本技术实施例中，即不再在资源多租共享平台上为不活跃租户预留资源，或当租户降为不活跃状态时，收回该租户在资源多租共享平台上该租户的占用资源。因此在相同系统资源情况下，资源多租共享平台能为更多
租户提供服务，最大化降低不活跃租户的运营成本，此外，相比那种超期自动清库的方案，对租户业务又更友好、更适用。
[0011]
在第一方面的一种可能的实现方式中，若计算得到的目标活跃等级为第一目标等级，且该租户当前的活跃等级为第一等级，则将该租户的任务暂时挂起，以便对该租户实现热恢复操作，具体操作过程包括：在该资源多租共享平台创建一个新的数据库实例，并将存储于预设的备份节点上的该租户的备份数据(该备份数据是在之前某个周期内，该租户处于不活跃状态时冷备份得到的，具体该备份数据为距离当前时刻最近一次的备份数据)恢复到这个新创建的数据库实例中，并为该租户分配与该第一目标等级对应的资源多租共享平台的资源，即为该租户分配新的与该第一目标等级对应的线程池、订阅缓存池、连接池等动态资源，该资源可称为目标资源，最后，再基于目标资源运行该租户之前挂起的任务，即任务会重新路由到为该租户恢复的数据库节点上，自此热恢复完成。需要注意的是，在本技术实施例中，第一等级以及第一目标等级的含义与上述类似，此处不予赘述。
[0012]
在本技术上述实施方式中，当租户重新活跃时，则为该租户重新建联，并通过对备份节点上该租户的备份数据进行镜像热恢复，实现了快速上线以及租户的业务零感知，提升了用户体验。
[0013]
在第一方面的一种可能的实现方式中，若计算得到的目标活跃等级为第二等级，且该租户当前的活跃等级为第二目标等级，则对该租户在资源多租共享平台上占用的资源进行资源降级操作。这里需要说明的是，第二等级为高于上述第一等级的活跃等级，具体地，第二等级用于表征该租户在周期时长内与资源多租共享平台之间信息交互的数量达到了第一预设阈值但还没有达到第二预设阈值，该第二预设阈值也可自定义，可以是与该第一等级相邻的活跃等级，也可以是与该第一等级不相邻的活跃等级，具体本技术对此不作限定。还需要说明的是，第二目标等级为高于上述第二等级的活跃等级，具体地，第二目标等级用于表征该租户在周期时长内与资源多租共享平台之间信息交互的数量达到了第二预设阈值，在本技术实施例中，达到该第二预设阈值的可以统称为第二目标等级，具体地，基于不同的划分方式，第二目标等级实际还可进一步划分为更小粒度的等级(如，第二等级、第三等级等)，其中，每个更小粒度的等级均各自对应段阈值区间，每个更小粒度的等级与阈值区间的对应方式与上述第一目标等级类似，此处不予赘述。
[0014]
在本技术上述实施方式中，在租户的当前活跃等级和目标活跃等级都不为第一等级的情况下，通过对租户当前活跃等级与目标活跃等级的比较，实现租户在资源多租共享平台上占用资源的动态差异化配置，从而在能满足不同活跃程度租户的资源需求的情况下，节约资源多租共享平台的资源占用率，使得资源多租共享平台在相同的系统资源下能为更多活跃的租户提供服务。
[0015]
在第一方面的一种可能的实现方式中，若计算得到的目标活跃等级为第二目标等级，且该租户当前的活跃等级为第二等级，则对该租户在资源多租共享平台上占用的资源进行资源升级操作。同样需要说明的是，该调整方式中的第二等级为高于上述第一等级的活跃等级，具体地，第二等级用于表征该租户在周期时长内与资源多租共享平台之间信息交互的数量达到了第一预设阈值但还没有达到第二预设阈值，该第二预设阈值也可自定义，可以是与该第一等级相邻的活跃等级，也可以是与该第一等级不相邻的活跃等级，具体本技术对此不作限定。还需要说明的是，第二目标等级为高于上述第二等级的活跃等级，具
体地，第二目标等级用于表征该租户在周期时长内与资源多租共享平台之间信息交互的数量达到了第二预设阈值，在本技术实施例中，达到该第二预设阈值的可以统称为第二目标等级，具体地，基于不同的划分方式，第二目标等级实际还可进一步划分为更小粒度的等级(如，第二等级、第三等级等)，其中，每个更小粒度的等级均各自对应段阈值区间，每个更小粒度的等级与阈值区间的对应方式与上述第一目标等级类似，此处不予赘述。
[0016]
在本技术上述实施方式中，在租户的当前活跃等级和目标活跃等级都不为第一等级的情况下，通过对租户当前活跃等级与目标活跃等级的比较，实现租户在资源多租共享平台上占用资源的动态差异化配置，及时满足了活跃度升高的租户对所需资源增大的需求，相比于在线迁移的方式，降低了对租户业务的影响。
[0017]
在第一方面的一种可能的实现方式中，根据目标请求信息确定租户的目标活跃等级的具体实现方式可以是：首先，确定属于同一信息类型的目标请求信息的目标数量，例如，某个信息类型下的目标请求信息数量多，其对应的权重也大；之后，根据目标数量确定与每个信息类型各自对应的目标权重，一个信息类型对应一个目标权重；最后，根据目标数量与目标权重计算租户的目标活跃等级。
[0018]
在本技术上述实施方式中，具体阐述了是基于属于同一信息类型的目标请求信息的目标数量以及各自对应的目标权重来计算租户的目标活跃等级，具备可实现性。
[0019]
在第一方面的一种可能的实现方式中，还可以进一步将该目标活跃等级作为该租户新的当前活跃等级，重复执行上述步骤，直至达到预设条件，例如，可以是重复执行直至达到预设时长，也可以是重复执行直至达到预设迭代次数，具体本技术对此不做限定。
[0020]
在本技术实施例中，将目标活跃等级做该租户新的当前活跃等级，并重复执行上述步骤的好处在于：可周期性更新租户当前的活跃等级，从而实现了实时、动态调整租户在该资源多种共享平台的资源。
[0021]
在第一方面的一种可能的实现方式中，预设的信息类型至少包括如下任意一种：连接、查询、写入、订阅。其中，连接用于表征该租户在同一时刻(可以是当前时刻，也可以是过去某个时刻，此处不做限定)与资源多租共享平台的连接，作为一种示例，假设该租户为app1，用户a是该app1的用户，用户b也是该app1的用户，当用户a与用户b同时登入该app1时，那么该app1就会与该资源多租共享平台有2个连接，由于app1除了用户a和用户b之外，还可能有其他更多用户，因此，在同一时刻，用户登入到app1的数量就是该app1与该资源多租共享平台的连接的数量(可简称为连接数)。查询则用于表征该租户的读取操作，写入则用于表征该租户的删除操作、更新操作、创建操作中的至少一项，订阅则用于表征该租户建立的订阅条件。
[0022]
在本技术上述实施方式中，选取一些典型的信息类型作为预设的信息类型，具体可基于实际需求自定义，且可根据实际情况随时进行调整，具备灵活性和广泛实用性。
[0023]
在第一方面的一种可能的实现方式中，资源降级操作至少包括如下任意一种：减少所述租户的业务线程资源、减少所述租户的订阅缓存资源、减少所述租户的数据库连接资源。具体地，降级程度可基于目标活跃等级来确定，应准守的降级原则是：第二目标活跃等级越接近不活跃状态的第一等级，则减少程度越大，具体的降级方式则可基于这个降级原则自定义，此处不予赘述。
[0024]
在本技术上述实施方式中，具体阐述了几种资源降级操作的具体实现方式，具体
可基于实际需求自定义如何降级，具备可选择性。
[0025]
在第一方面的一种可能的实现方式中，资源升级操作至少包括如下任意一种：增加所述租户的业务线程资源、增加所述租户的订阅缓存资源、增加所述租户的数据库连接资源。类似地，升级程度也可基于第二目标活跃等级来确定，应准守的升级原则是：第二目标活跃等级与第二等级之间的等级差越大，则增加程度越大，具体的升级方式则可基于这个升级原则自定义，此处不予赘述。
[0026]
在本技术上述实施方式中，具体阐述了几种资源升级操作的具体实现方式，具体可基于实际需求自定义如何升级，具备可选择性。
[0027]
本技术实施例第二方面提供一种租户管理系统，该租户管理系统具有实现上述第一方面或第一方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
[0028]
本技术实施例第三方面提供一种租户管理系统，可以包括存储器、处理器以及总线系统，其中，存储器用于存储程序，处理器用于调用该存储器中存储的程序以执行本技术实施例第一方面或第一方面任意一种可能实现方式的方法。
[0029]
本技术实施例第四方面提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机可以执行上述第一方面或第一方面任意一种可能实现方式的方法。
[0030]
本技术实施例第五方面提供了一种计算机程序，当其在计算机上运行时，使得计算机执行上述第一方面或第一方面任意一种可能实现方式的方法。
[0031]
本技术实施例第六方面提供了一种芯片，该芯片包括至少一个处理器和至少一个接口电路，该接口电路和该处理器耦合，至少一个接口电路用于执行收发功能，并将指令发送给至少一个处理器，至少一个处理器用于运行计算机程序或指令，其具有实现如上述第一方面或第一方面任意一种可能实现方式的方法的功能，该功能可以通过硬件实现，也可以通过软件实现，还可以通过硬件和软件组合实现，该硬件或软件包括一个或多个与上述功能相对应的模块。此外，该接口电路用于与该芯片之外的其它模块进行通信。
附图说明
[0032]
图1为本技术实施例提供的系统架构的一个示意图；
[0033]
图2为本技术实施例提供的租户的资源管理方法的一个流程示意图；
[0034]
图3为本技术实施例提供的组件结构的一个示意图；
[0035]
图4为本技术实施例提供的资源升级场景的一个流程示意图；
[0036]
图5为本技术实施例提供的资源降级场景的一个流程示意图；
[0037]
图6为本技术实施例提供的资源释放以及数据冷备份场景的一个流程示意图；
[0038]
图7为本技术实施例提供的资源恢复以及数据热恢复场景的一个流程示意图；
[0039]
图8为本技术实施例提供的一种租户管理系统的结构示意图；
[0040]
图9为本技术实施例提供的租户管理系统的一种结构示意图。
具体实施方式
[0041]
本技术实施例提供了一种租户的资源管理方法及租户管理系统，用于基于统计周期内租户的请求信息来计算租户在该统计周期内的活跃等级，并基于活跃等级实现对不同租户预留资源的动态差异化管理，本技术实施例能够根据租户的资源需求实时动态调整资源分配，从而避免出现不活跃租户(即僵尸租户)对预留资源浪费的情况，使得在相同系统资源的情况下，该资源多租共享平台能同时承载更多租户，提高了资源多租共享平台服务租户的能力，且最大化降低僵尸租户的运营成本。
[0042]
本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本技术的实施例中对相同属性的对象在描述时所采用的区分方式。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。
[0043]
本技术实施例涉及了许多关于多租共享资源平台的相关知识，为了更好地理解本技术实施例的方案，下面先对本技术实施例可能涉及的相关术语和概念进行介绍。应理解的是，相关的概念解释可能会因为本技术实施例的具体情况有所限制，但并不代表本技术仅能局限于该具体情况，在不同实施例的具体情况可能也会存在差异，具体此处不做限定。
[0044]
(1)资源多租共享平台
[0045]
资源多租共享平台也可简称为多租共享平台，用于将服务器资源作为共享资源租给为不同租户使用，其给开发者提供的是一种零运维的服务，开发者开箱即用，无需构建维护后天的基础设施，只需按用量交费。
[0046]
(2)无服务器(serverless)云开发
[0047]
serverless云开发也可称为serverless服务、serverless平台等，属于资源多租共享平台的一种典型架构，serverless云开发把主机管理、操作系统管理、资源分配、扩容，甚至是应用逻辑的全部组件都外包出去，把它们看作某种形式的商品——serverless平台商提供服务，开发者掏钱购买。
[0048]
serverless是一种构建和管理基于微服务架构的完整流程，允许开发者在服务部署级别而不是服务器部署级别来管理应用部署。它与传统架构的不同之处在于：完全由第三方管理，由事件触发，存在于无状态(stateless)、暂存(可能只存在于一次调用的过程中)计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上，而无须管理和操作云端或本地的服务器或运行时。serverless真正做到了部署应用无需涉及基础设施的建设，自动构建、部署和启动服务。
[0049]
(3)多租
[0050]
指云数据库服务的多个开发者共享后台的服务器资源，包括cpu、内存、存储，在逻辑上做资源隔离。
[0051]
下面结合附图，对本技术的实施例进行描述。本领域普通技术人员可知，随着技术的发展和新场景的出现，本技术实施例提供的技术方案对于类似的技术问题，同样适用。
[0052]
首先，在介绍本技术实施例之前，先对本技术实施例涉及的系统架构进行介绍，使得后续便于理解本技术实施例。具体请参阅图1，图1为本技术实施例提供的系统架构的一
个示意图，本技术实施例提供的系统架构从上到下可以分为三个层级，分别为应用层(也可称为业务层)、控制层以及资源层，下面分别对着三个层级进行说明：
[0053]
(1)应用层
[0054]
应用层为资源多租共享平台的使用者，该使用者也可以称为租户，例如，每个app对资源多租共享平台而言是一个租户，例如，图1中的租户1、租户2、
……
、租户n，租户是通过统一的应用程序接口(application programming interface，api)接入到资源多租共享平台，这里需要注意的是，租户在请求接入时，资源多租共享平台需要对租户的接入请求进行鉴权认证，鉴权通过后才会被允许接入。
[0055]
(2)控制层
[0056]
控制层为资源多租共享平台的控制核心，用于控制整个平台的核心业务逻辑以及实现本技术实施例提供的租户的资源管理方法，例如，可用于实现：租户连接管理、租户请求信息的统计、租户活跃等级计算、租户资源调整等。
[0057]
为便于阐述，在本技术下述实施例中，该控制层以租户管理系统的形式实现本技术实施例提供的租户的资源管理方法的过程，以下不再赘述。
[0058]
(3)资源层
[0059]
资源层是资源多租共享平台存储租户物理数据的物理资源节点的集合，包括数据库节点和备份节点，其中，数据库节点为租用该资源多租共享平台的所有租户实际的数据存储的节点，其以库级别的粒度实现资源隔离，备份节点是在资源层新增的一个节点，用于存储不活跃租户(即在周期时长内与资源多租共享平台之间信息交互的数量未达到预先设定的阈值的租户可统称为不活跃租户，也可称为僵尸租户)的备份数据，该备份数据是从数据库节点上冷备份而来，冷备份完成后就将该不活跃租户在数据库节点上的数据删除，由于该备份节点的运营成本低，只为不活跃租户提供基本的存储，因此可降低数据库节点上存储不活跃租户数据的成本。
[0060]
这里需要说明的是，在图1中，本技术实施例提供的系统架构中的控制层和资源层都为资源多租共享平台的逻辑模块，但在本技术的另一些实施方式中，控制层也可以不部署在资源多租共享平台上，而部署在其他独立的服务器或计算机设备上，具体本技术实施例对控制层的部署方式不做限定，图1仅为示意。
[0061]
还需要说明的是，在图1中，额外新增的备份节点也是部署在资源多租共享平台内，但在本技术的另一些实施方式中，备份节点也可以不部署在资源多租共享平台上，而是独立部署，具体本技术实施例对备份节点的部署方式不做限定，图1仅为示意。
[0062]
还需要说明的是，在本技术的一些实施方式中，本技术实施例提供的系统架构也可以不是分为三个层级，而是可以分为更少(如，两层)或更多(如，四层、五层等)的层级，若是分为更少的层级，那么本质就是将三个层级中的某几个层级合并为了一个层级，若是分为更多的层级，那么本质就是阿静三个层级中的某些层级拆分为了更细的层级，具体本技术实施例对系统架构的层级划分的具体方式不做限定。
[0063]
基于上述所述的系统架构，下面对本技术实施例提供的租户的资源管理方法进行说明，具体请参阅图2，图2为本技术实施例提供的租户的资源管理方法的一个流程示意图，具体可以包括如下步骤：
[0064]
201、获取租户在周期时长内的一个或多个请求信息。
[0065]
首先，租户管理系统获取租户在预设的周期时长内的请求信息(也可称为请求事件)，在预设周期时长内租户发送的请求信息可以是一个，也可以是多个，此处不做限定。需要说明的是，在本技术实施例中，租户向资源多租共享平台发送的信息都可称为请求信息，例如，请求接入的信息、请求订阅的信息、请求存储的信息等等，具体此处不做限定。
[0066]
需要注意的是，在本技术实施例中，周期时长是预先设置的，也可称为统计周期，租户管理系统可基于实际需求自定义，例如，可以统计固定时间周期(如，每一天、每周一至周日、每个月等)内租户向资源多租共享平台发送的请求信息，也可以是以滑动窗口的方式统计某周期时长(如，1天、7天等)内租户向资源多租共享平台发送的请求信息，具体本技术对周期时长的选定方式不做限定。
[0067]
还需要注意的是，在本技术实施例中，租户管理系统获取租户在周期时长内的一个或多个请求信息具体可以是：若计算的是当前最新的活跃等级，则获取的是当前周期时长内的一个或多个请求信息；若计算的是之前某个周期时长对应的活跃等级，那么获取的是对应周期时长内的一个或多个请求信息，具体本技术对此不作限定。
[0068]
这里还需要注意的是，在本技术实施例中，为了保障对所有租户同时访问该资源多租共享平台的服务质量，该资源多租共享平台也需要为每个单个租户预先分配一定的资源(即资源预留)，例如，为每个租户预分配两个数据库连接，以保障所有租户同时并发访问时都能响应租户请求，以提供高效的服务。具体地，假设资源多租共享平台的总资源数为t，且单个租户预分配的资源包为tn，那么该资源多租共享平台可服务的租户数量n就为：n＝t/tn。
[0069]
202、基于预设的信息类型从请求信息中确定一个或多个目标请求信息。
[0070]
租户管理系统在获取租户在周期时长内的一个或多个请求信息之后，将进一步基于预设的信息类型从获取到的这些请求信息中确定目标请求信息(也可称为活跃事件)，确定的目标请求信息可以是一个，也可以是多个，具体本技术对此不做限定。
[0071]
需要说明的是，在本技术的一些实施方式中，信息类型是预先设定的，可基于实际需求自定义，例如，可基于租户的类型(如，内存密集型的租户对内存需求大)来设定信息类型，在本技术实施例中，预设的信息类型至少可以包括如下任意一种：连接、查询、写入、订阅等，其中，连接用于表征该租户在同一时刻(可以是当前时刻，也可以是过去某个时刻，此处不做限定)与资源多租共享平台的连接，作为一种示例，假设该租户为app1，用户a是该app1的用户，用户b也是该app1的用户，当用户a与用户b同时登入该app1时，那么该app1就会与该资源多租共享平台有2个连接，由于app1除了用户a和用户b之外，还可能有其他更多用户，因此，在同一时刻，用户登入到app1的数量就是该app1与该资源多租共享平台的连接的数量(可简称为连接数)。查询则用于表征该租户的读取操作，写入则用于表征该租户的删除操作、更新操作、创建操作中的至少一项，订阅则用于表征该租户建立的订阅条件。
[0072]
这里需要注意的是，为便于阐述，在本技术下述实施例中，以预设的信息类型包括连接、查询、写入和订阅为例进行说明，后续不再赘述。
[0073]
203、根据目标请求信息确定租户的目标活跃等级。
[0074]
租户管理系统在基于预设的信息类型从获取到的请求信息中确定出一个或多个目标请求信息之后，再根据目标请求信息确定该租户的目标活跃等级。
[0075]
具体地，假设预设的信息类型包括连接、查询、写入、订阅，那么根据该目标请求信
息可统计到该周期时长内的连接数(可用l表示)、查询量(可用q表示)、写入量(可用w表示)以及订阅量(可用s表示)，其中，连接数l就是指该租户同时与该资源多租共享平台的连接数量，查询量q指该租户的查询(如，读取操作)操作的数量，写入量w指该租户的写(如，删除操作、更新操作以及创建操作中的至少一项)操作的数量，订阅量s指该租户建立的订阅条件的数量。之后，基于如下式(1)所示的活跃算法计算该租户的活跃度取值：
[0076]
a＝f(l，q，w，s)
ꢀꢀꢀ
(1)
[0077]
其中，l、q、w、s为函数f的自变量，a为计算得到的该租户的活跃度的取值。
[0078]
需要说明的是，在本技术的一些实施方式中，该活跃算法具体可根据属于同一信息类型的目标请求信息的数量来得到对应该信息类型的权重，例如，某个信息类型下的目标请求信息数量多，其对应的权重也大，具体地，可基于如下式(2)所示的方式得到该租户的活跃度取值：
[0079]
a＝a1*l+a2*q+a3*w+a4*s
ꢀꢀꢀ
(2)
[0080]
其中，a1、a2、a3、a4分别为l、q、w、s的权重(可称为目标权重)，该目标权重的具体取值具体是根据属于同一信息类型的目标请求信息的数量(可称为目标数量)确定，即由式(2)中的l、q、w、s的取值确定，例如，属于同一信息类型的目标请求信息的数量越多，则对应的目标权重的取值相对就越大。一种信息类型对应一个目标权重，最后根据属于同一信息类型的目标请求信息的数量(即l、q、w、s的取值)以及对应的目标权重(即a1、a2、a3、a4)计算出该租户的活跃度的取值。需要注意的是，在本技术实施例中，a1、a2、a3、a4可以是归一化的权重，即a1+a2+a3+a4＝1。
[0081]
这里需要注意的是，上述都是以预设的信息类型包括连接、查询、写入和订阅为例说明如何计算该租户的活跃度，在本技术的另一些实施方式中，若预设的信息类型是其他，或者包括的是连接、查询、写入和订阅中的一项或多项，那么只需将式(1)或式(2)中对应的信息类型下目标请求信息的数量进行对应替换或删除即可，具体计算过程则是类似的，此处不予赘述。
[0082]
还需要说明的是，在根据上述式(1)或式(2)计算得到该租户的活跃度的取值后，即可基于预设设定的活跃度的取值区间与活跃等级之间的映射关系(即一个活跃度的取值区间对应一个活跃等级，不同取值区间之间无交集)，得到该租户与算得的活跃度取值对应的活跃等级。
[0083]
需要注意的是，在本技术实施例中，活跃等级可以划分为2个，也可以划分为3个、4个，或者更多个，具体根据实际需求进行划分，本技术实施例对活跃等级的具体划分方式不做限定。
[0084]
204、在租户的当前活跃等级与目标活跃等级不同的情况下，根据目标活跃等级调整租户在资源多租共享平台的资源。
[0085]
租户管理系统在计算得到该租户的目标活跃等级后，如果该租户的当前活跃等级与该目标活跃等级不同，则需要根据上述步骤203计算得到的目标活跃等级调整该租户在资源多租共享平台上的资源，调整方式包括但不限于：资源升级、资源降级、冷备份后释放该租户在资源多租共享平台上的占用资源、热恢复后重新为该租户分配资源等。具体的调整方式由租户的当前活跃等级以及计算得到的目标活跃等级来确定，具体可包括但不限于如下几种调整方式：
[0086]
一、当目标活跃等级为第一等级，且当前活跃等级为第一目标等级，则冷备份
[0087]
若租户管理系统计算得到的目标活跃等级为第一等级，且该租户当前的活跃等级为第一目标等级，则将该租户在资源多租共享平台上运行的数据库实例的数据在预设的备份节点上进行冷备份，得到备份数据，之后，再释放该租户在该资源多租共享平台上占用的资源(即释放该租户的数据库实例对象，例如，释放该租户的线程池、订阅缓存池、连接池等动态资源，使其不再占用数据库节点上的资源)。需要注意的是，数据库实例实质可看做是一个数据库进程，实例则是进程里面的一个database实例，根据数据库的架构不同数据库实例的表现形式会有所不同，此处不予赘述。
[0088]
这里需要说明的是，第一等级用于表示该租户处于不活跃状态，具体用于表征该租户在周期时长内与资源多租共享平台之间信息交互的数量没有达到第一预设阈值，该第一预设阈值就是判断租户是不活跃租户(即僵尸租户)还是活跃租户的分界线，未达到该第一预设阈值则判定为不活跃租户，达到该第一预设阈值则说明该租户不是不活跃租户，在本技术实施例中，达到该第一预设阈值的可以统称为第一目标等级，具体地，基于不同的划分方式，第一目标等级实际还可进一步划分为更小粒度的等级(如，第二等级、第三等级等)，其中，每个更小粒度的等级均各自对应段阈值区间，例如，阈值区间[y1，y2]对应一个细分等级，阈值区间[y2，y3]对应另一个细分等级，
……
，以此类推，可将第一目标等级又划分为多个等级，具体的划分方式可基于实际需求自定义，本技术对此不予赘述。
[0089]
还需要说明的是，在本技术的一些实施方式中，当目标活跃等级为第一等级且当前活跃等级为第一目标等级，除了可以冷备份之外，还可以是其他处理方法，包括但不限于：将不活跃租户整体迁移至运营成本更低的数据库节点(如，配置更低、容量更低)，从而降低单个租户的维护成本，把腾出来的优质资源提供给高活跃度的租户，满足其业务弹性需求，最终实现平台提供商的盈利以及可持续发展。
[0090]
综上所述，当租户管理系统计算得到的该租户的目标活跃等级为不活跃状态的第一等级，且该租户的当前活跃等级为高于该第一等级的任意一个等级(统称为第一目标等级)的情况下，租户管理系统对该租户在资源多租共享平台上的数据冷备份至备份节点，并释放该租户在资源多租共享平台上的占用资源。
[0091]
在本技术上述实施方式中，由于在资源多租共享平台按量收费的情况下，很多不活跃租户(即僵尸租户)长期占用连接、缓存、database实例资源，最终制约该资源多租共享平台的租户数量，而不活跃租户也不能给平台提供商带来流量进而贡献流水，这极大的增加了平台提供商的运营成本，因此，本技术上述实施方式可以根据租户的实际运行情况(即判定是否活跃)，动态调整资源多租共享平台的资源分配，在本技术实施例中，即不再在资源多租共享平台上为不活跃租户预留资源，或当租户降为不活跃状态时，收回该租户在资源多租共享平台上该租户的占用资源。因此在相同系统资源情况下，资源多租共享平台能为更多租户提供服务，最大化降低不活跃租户的运营成本，此外，相比那种超期自动清库的方案，对租户业务又更友好、更适用。
[0092]
二、当目标活跃等级为第一目标等级，且当前活跃等级为第一等级，则热恢复
[0093]
若租户管理系统计算得到的目标活跃等级为第一目标等级，且该租户当前的活跃等级为第一等级，则将该租户的任务暂时挂起，以便对该租户实现热恢复操作，具体操作过程包括：在该资源多租共享平台创建一个新的数据库实例，并将存储于预设的备份节点上
的该租户的备份数据(该备份数据是在之前某个周期内，该租户处于不活跃状态时冷备份得到的，具体该备份数据为距离当前时刻最近一次的备份数据)恢复到这个新创建的数据库实例中，并为该租户分配与该第一目标等级对应的资源多租共享平台的资源，即为该租户分配新的与该第一目标等级对应的线程池、订阅缓存池、连接池等动态资源，该资源可称为目标资源，最后，再基于目标资源运行该租户之前挂起的任务，即任务会重新路由到为该租户恢复的数据库节点上，自此热恢复完成。
[0094]
这里需要注意的是，第一等级以及第一目标等级与上述第一种调整方式中第一等级以及第二目标等级的说明是一样的，具体请参阅上述第一种调整方式中对第一等级以及第二目标等级的说明，此次不予赘述。
[0095]
综上所述，当该租户的当前活跃等级为不活跃状态的第一等级，且租户管理系统计算得到的目标活跃等级为高于该第一等级的任意一个等级(统称为第一目标等级)的情况下，租户管理系统对该租户在备份节点上的备份数据进行热恢复，并为该租户重新分配资源。
[0096]
在本技术上述实施方式中，当租户重新活跃时，则为该租户重新建联，并通过对备份节点上该租户的备份数据进行镜像热恢复，实现了快速上线以及租户的业务零感知，提升了用户体验。
[0097]
三、当目标活跃等级为第二等级，且当前活跃等级为第二目标等级，则资源降级
[0098]
若租户管理系统计算得到的目标活跃等级为第二等级，且该租户当前的活跃等级为第二目标等级，则对该租户在资源多租共享平台上占用的资源进行资源降级操作。租户管理系统执行的资源降级操作至少包括如下任意一项：减少该租户的业务线程资源、减少该租户的订阅缓存资源、减少该租户的数据库连接资源等。具体地，降级程度可基于第二目标活跃等级来确定，应准守的降级原则是：第二目标活跃等级越接近不活跃状态的第一等级，则减少程度越大，具体的降级方式则可基于这个降级原则自定义，此处不予赘述。
[0099]
这里需要说明的是，第二等级为高于上述第一等级的活跃等级，具体地，第二等级用于表征该租户在周期时长内与资源多租共享平台之间信息交互的数量达到了第一预设阈值但还没有达到第二预设阈值，该第二预设阈值也可自定义，可以是与该第一等级相邻的活跃等级，也可以是与该第一等级不相邻的活跃等级，具体本技术对此不作限定。
[0100]
为便于理解第二等级以及第二预设阈值的含义，下面举例进行示意：假设第一预设阈值为y1，则第一等级的阈值区间为[0，y1]，那么高于第一等级的阈值区间分别被划分为了[y1，y2](对应一个细分等级)、[y2，y3](对应另一个细分等级)，[y3，y4](对应另一个细分等级)，
……
，以此类推。假设该第二预设阈值是y2，那么对应的第二等级的阈值区间为[y1，y2]，在这种情况下，该第二等级是第一等级的相邻等级；假设该第二预设阈值是y3，那么对应的第二等级的阈值区间可以是[y1，y2]，也可以是[y2，y3]，若该第二等级的阈值区间为[y2，y3]，在这种情况下，该第二等级是第一等级的不相邻等级；假设该第二预设阈值是y4，那么对应的第二等级的阈值区间可以是[y1，y2]，也可以是[y2，y3]，还可以是[y3，y4]，若该第二等级的阈值区间为[y2，y3]或[y3，y4]，在这种情况下，该第二等级是第一等级的不相邻等级，
……
，以此类推，此处不予赘述。
[0101]
还需要说明的是，第二目标等级为高于上述第二等级的活跃等级，具体地，第二目标等级用于表征该租户在周期时长内与资源多租共享平台之间信息交互的数量达到了第
二预设阈值，在本技术实施例中，达到该第二预设阈值的可以统称为第二目标等级，具体地，基于不同的划分方式，第二目标等级实际还可进一步划分为更小粒度的等级(如，第二等级、第三等级等)，其中，每个更小粒度的等级均各自对应段阈值区间，每个更小粒度的等级与阈值区间的对应方式与上述第一目标等级类似，此处不予赘述。
[0102]
综上所述，当租户管理系统计算得到的该租户的目标活跃等级为高于第一等级(即不活跃状态)的第二等级，且该租户的当前活跃等级为高于该第二等级的任意一个等级(统称为第二目标等级)的情况下，租户管理系统对该租户在资源多租共享平台上的占用资源进行资源降级操作。
[0103]
在本技术上述实施方式中，在租户的当前活跃等级和目标活跃等级都不为第一等级的情况下，通过对租户当前活跃等级与目标活跃等级的比较，实现租户在资源多租共享平台上占用资源的动态差异化配置，从而在能满足不同活跃程度租户的资源需求的情况下，节约资源多租共享平台的资源占用率，使得资源多租共享平台在相同的系统资源下能为更多活跃的租户提供服务。
[0104]
四、当目标活跃等级为第二目标等级，且当前活跃等级为第二等级，则资源升级
[0105]
若租户管理系统计算得到的目标活跃等级为第二目标等级，且该租户当前的活跃等级为第二等级，则对该租户在资源多租共享平台上占用的资源进行资源升级操作。租户管理系统执行的资源升级操作至少包括如下任意一项：增加该租户的业务线程资源、增加该租户的订阅缓存资源、增加该租户的数据库连接资源等。类似地，升级程度也可基于第二目标活跃等级来确定，应准守的升级原则是：第二目标活跃等级与第二等级之间的等级差越大，则增加程度越大，具体的升级方式则可基于这个升级原则自定义，此处不予赘述。
[0106]
同样需要说明的是，与上述第三种调整方式类似，该调整方式中的第二等级为高于上述第一等级的活跃等级，具体地，第二等级用于表征该租户在周期时长内与资源多租共享平台之间信息交互的数量达到了第一预设阈值但还没有达到第二预设阈值，该第二预设阈值也可自定义，可以是与该第一等级相邻的活跃等级，也可以是与该第一等级不相邻的活跃等级，具体本技术对此不作限定。
[0107]
还需要说明的是，第二目标等级为高于上述第二等级的活跃等级，具体地，第二目标等级用于表征该租户在周期时长内与资源多租共享平台之间信息交互的数量达到了第二预设阈值，在本技术实施例中，达到该第二预设阈值的可以统称为第二目标等级，具体地，基于不同的划分方式，第二目标等级实际还可进一步划分为更小粒度的等级(如，第二等级、第三等级等)，其中，每个更小粒度的等级均各自对应段阈值区间，每个更小粒度的等级与阈值区间的对应方式与上述第一目标等级类似，此处不予赘述。
[0108]
综上所述，当租户的当前活跃等级为高于第一等级(即不活跃状态)的第二等级，且租户管理系统计算得到的该租户的目标活跃等级为高于该第二等级的任意一个等级(统称为第二目标等级)的情况下，租户管理系统对该租户在资源多租共享平台上的占用资源进行资源升级操作。
[0109]
在本技术上述实施方式中，在租户的当前活跃等级和目标活跃等级都不为第一等级的情况下，通过对租户当前活跃等级与目标活跃等级的比较，实现租户在资源多租共享平台上占用资源的动态差异化配置，及时满足了活跃度升高的租户对所需资源增大的需求，相比于在线迁移的方式，降低了对租户业务的影响。
[0110]
205、将目标活跃等级作为租户新的当前活跃等级，重复执行步骤201至步骤205。
[0111]
需要说明的是，在本技术的一些实施方式中，还可以包括步骤205，即租户管理系统将该目标活跃等级作为该租户新的当前活跃等级，重复执行步骤201至步骤205，直至达到预设条件，例如，可以是重复执行直至达到预设时长，也可以是重复执行直至达到预设迭代次数，具体本技术对此不做限定。
[0112]
在本技术实施例中，将目标活跃等级做该租户新的当前活跃等级，并重复执行步骤201至步骤205的好处在于：可周期性更新租户当前的活跃等级，从而实现了实时、动态调整租户在该资源多种共享平台的资源。
[0113]
为进一步理解本技术实施例提供的租户的资源管理方法，下面以一个具体的实例为例对本技术实施例方法进行说明，具体请参阅图3，图3为本技术实施例提供的组件结构的一个示意图，其中，在应用层，有接入响应模块、业务执行模块以及存储执行模块，这些模块均为已有模块，不涉及本技术发明，此处不予赘述。在控制层，则新增租户事件统计模块、租户活跃度计算模块、租户资源调度模块、业务资源控制模块、数据库资源控制模块，其中，网络资源控制模块为已有模块，网络资源控制模块主要用于管理应用层与资源层之间的通信连接资源，对多种通信协议进行连接管理；业务资源控制模块聚焦业务线程、订阅缓存管理以及与数据库连接资源等资源的调度；数据库资源控制模块负责数据库实例的冷备份、热恢复的调度管理；租户事件统计模块用于统计租户在周期时长内的请求信息(即请求事件)，并基于预设的信息类型从统计的请求信息中确定目标请求信息(即活跃事件)；租户活跃度计算模块用于根据目标请求信息计算租户的活跃度以及活跃等级，租户资源调度模块用于对租户在资源多租共享平台上的资源进行动态调节，比如释放连接资源、数据冷备份或者热恢复。在资源层，新增用于进行数据冷备/热恢复的备份池(即图1中所述的备份节点)，其中，通信连接池以及数据库连接池(即图1中所述的数据库节点)为已有模块，需要注意的是，数据库连接池进一步可以包括业务线程池、订阅缓存池、存储连接池。
[0114]
下面基于图3所示的组件结构，以划分的活跃等级为低(相当于上述所述的第一等级，也可称为inactive)、中(也可称为normal)、高(也可称为high)这3个等级为例，对几种主要的场景进行陈述。当租户活跃等级为低时，对租户触发冷备份；当租户从低等级又重新上升为中等级或高等级时，则对租户做热恢复。
[0115]
需要注意的是，在本技术实施例中，每个租户默认的活跃等级为中等级。还需要说明的是，在本技术实施例中，租户活跃等级变化限定是相邻等级进行变化(不相邻等级进行变化也是可以的，但缺点是可能会出现资源震荡的问题，相邻等级变化可保证资源调整的平滑过渡)。
[0116]
场景1、租户a资源升级(从中等级
→
高等级)调整步骤。
[0117]
具体请参阅图4，图4为本技术实施例提供的资源升级场景的一个流程示意图，具体可以包括如下步骤：
[0118]
401、租户事件统计模块在统计周期ts内统计租户a的请求信息，并采样得到属于不同信息类型的目标请求信息各自的数量。
[0119]
租户事件统计模块在统计周期ts内统计租户a所有的请求信息，并根据预设的信息类型，采样收集租户的连接数ln、查询量qn、写入量wn及订阅量sn(即属于不同信息类型的目标请求信息的数量，可简称为统计数据)。其中，租户a为在统计周期内租用该资源多租
共享平台的任意一个租户。
[0120]
402、租户事件统计模块将租户a的统计数据发送给租户活跃度计算模块。
[0121]
一个统计周期ts结束后，租户事件统计模块将租户a的统计数据发送给租户活跃度计算模块。
[0122]
403、租户活跃度计算模块计算租户a当前周期的目标活跃等级，并将该目标活跃等级的信息发送给租户资源调度模块。
[0123]
租户活跃度计算模块使用活跃算法an，计算租户a当前周期的目标活跃等级，假设计算得到的目标活跃等级为高等级(即high)，并将该目标活跃等级的信息发送给租户资源调度模块。
[0124]
需要注意的是，在本技术实施例中，活跃算法an具体可以是上述式(1)或式(2)所示的活跃算法，具体请参阅上述所述，此处不予赘述。
[0125]
404、租户资源调度模块读取租户a当前缓存的活跃等级，并将当前缓存的活跃等级与目标活跃等级进行比较，触发资源升级。
[0126]
租户资源调度模块读取租户a当前缓存的活跃等级(即当前活跃等级)为中等级(即normal)，与租户活跃度计算模块的更新信息进行比对，发现租户a最新的活跃度升高，则触发资源升级操作，如，分别增加租户a的业务线程资源、订阅缓存资源、数据库连接资源中的至少一项。
[0127]
租户a资源升级操作完成，触发执行下一轮迭代。
[0128]
场景2、租户a资源降级(从高等级
→
中等级)调整步骤。
[0129]
具体请参阅图5，图5为本技术实施例提供的资源降级场景的一个流程示意图，具体可以包括如下步骤：
[0130]
501、租户事件统计模块在统计周期ts内统计租户a的请求信息，并采样得到属于不同信息类型的目标请求信息各自的数量。
[0131]
租户事件统计模块在统计周期ts内统计租户a所有的请求信息，并根据预设的信息类型，采样收集租户的连接数ln、查询量qn、写入量wn及订阅量sn(即属于不同信息类型的目标请求信息的数量，可简称为统计数据)。其中，租户a为在统计周期内租用该资源多租共享平台的任意一个租户。
[0132]
502、租户事件统计模块将租户a的统计数据发送给租户活跃度计算模块。
[0133]
一个统计周期ts结束后，租户事件统计模块将租户a的统计数据发送给租户活跃度计算模块。
[0134]
503、租户活跃度计算模块计算租户a当前周期的目标活跃等级，并将该目标活跃等级的信息发送给租户资源调度模块。
[0135]
租户活跃度计算模块使用活跃算法an，计算租户a当前周期的目标活跃等级，假设计算得到的目标活跃等级为中等级(即normal)，并将该目标活跃等级的信息发送给租户资源调度模块。
[0136]
需要注意的是，在本技术实施例中，活跃算法an具体可以是上述式(1)或式(2)所示的活跃算法，具体请参阅上述所述，此处不予赘述。
[0137]
504、租户资源调度模块读取租户a当前缓存的活跃等级，并将当前缓存的活跃等级与目标活跃等级进行比较，触发资源降级。
[0138]
租户资源调度模块读取租户a当前缓存的活跃等级(即当前活跃等级)为高等级(即high)，与租户活跃度计算模块的更新信息进行比对，发现租户a最新的活跃度降低，则触发资源降级操作，如，分别减少租户a的业务线程资源、订阅缓存资源、数据库连接资源中的至少一项。
[0139]
租户a资源降级操作完成，触发执行下一轮迭代。
[0140]
场景3、租户a资源释放以及数据冷备份(从中等级
→
低等级)调整步骤。
[0141]
具体请参阅图6，图6为本技术实施例提供的资源释放以及数据冷备份场景的一个流程示意图，具体可以包括如下步骤：
[0142]
601、租户事件统计模块在统计周期ts内统计租户a的请求信息，并采样得到属于不同信息类型的目标请求信息各自的数量。
[0143]
租户事件统计模块在统计周期ts内统计租户a所有的请求信息，并根据预设的信息类型，采样收集租户的连接数ln、查询量qn、写入量wn及订阅量sn(即属于不同信息类型的目标请求信息的数量，可简称为统计数据)。其中，租户a为在统计周期内租用该资源多租共享平台的任意一个租户。
[0144]
602、租户事件统计模块将租户a的统计数据发送给租户活跃度计算模块。
[0145]
一个统计周期ts结束后，租户事件统计模块将租户a的统计数据发送给租户活跃度计算模块。
[0146]
603、租户活跃度计算模块计算租户a当前周期的目标活跃等级，并将该目标活跃等级的信息发送给租户资源调度模块。
[0147]
租户活跃度计算模块使用活跃算法an，计算租户a当前周期的目标活跃等级，假设计算得到的目标活跃等级为低等级(即inactive)，并将该目标活跃等级的信息发送给租户资源调度模块。
[0148]
需要注意的是，在本技术实施例中，活跃算法an具体可以是上述式(1)或式(2)所示的活跃算法，具体请参阅上述所述，此处不予赘述。
[0149]
604、租户资源调度模块读取租户a当前缓存的活跃等级，并将当前缓存的活跃等级与目标活跃等级进行比较，触发对租户a进行数据冷备份。
[0150]
租户资源调度模块读取租户a当前缓存的活跃等级(即当前活跃等级)为中等级(即normal)，与租户活跃度计算模块的更新信息进行比对，发现租户a最新的活跃度降低为不活跃状态，则触发对租户a进行数据冷备份处理，具体地，租户资源调度模块首先对数据库资源控制模块下发冷备租户a在数据库节点(即图3中的数据库资源池)上数据的备份指令，数据库资源控制模块再将租户a的数据库实例下达备份命令，将其数据全部备份至备份节点，之后释放租户a的数据库实例对象，使其不再占用数据库节点上的资源。
[0151]
605、租户资源调度模块释放租户a在数据库节点上占用的资源。
[0152]
最后，租户资源调度模块再分别释放租户a的线程池、订阅缓存池、连接池等动态资源。
[0153]
租户a资源释放以及数据冷备份操作完成，触发执行下一轮迭代。
[0154]
场景4、租户a资源恢复以及数据热恢复(从低等级
→
中等级)调整步骤。
[0155]
具体请参阅图7，图7为本技术实施例提供的资源恢复以及数据热恢复场景的一个流程示意图，具体可以包括如下步骤：
[0156]
701、租户事件统计模块在统计周期ts内统计租户a的请求信息，并采样得到属于不同信息类型的目标请求信息各自的数量。
[0157]
租户事件统计模块在统计周期ts内统计租户a所有的请求信息，并根据预设的信息类型，采样收集租户的连接数ln、查询量qn、写入量wn及订阅量sn(即属于不同信息类型的目标请求信息的数量，可简称为统计数据)。其中，租户a为在统计周期内租用该资源多租共享平台的任意一个租户。
[0158]
702、租户事件统计模块将租户a的统计数据发送给租户活跃度计算模块。
[0159]
一个统计周期ts结束后，租户事件统计模块将租户a的统计数据发送给租户活跃度计算模块。
[0160]
703、租户活跃度计算模块计算租户a当前周期的目标活跃等级，并将该目标活跃等级的信息发送给租户资源调度模块。
[0161]
租户活跃度计算模块使用活跃算法an，计算租户a当前周期的目标活跃等级，假设计算得到的目标活跃等级为中等级(即normal)，并将该目标活跃等级的信息发送给租户资源调度模块。
[0162]
需要注意的是，在本技术实施例中，活跃算法an具体可以是上述式(1)或式(2)所示的活跃算法，具体请参阅上述所述，此处不予赘述。
[0163]
704、租户资源调度模块读取租户a当前缓存的活跃等级，并将当前缓存的活跃等级与目标活跃等级进行比较，触发对租户a进行数据热恢复。
[0164]
租户资源调度模块读取租户a当前缓存的活跃等级(即当前活跃等级)为低等级(即inactive)，与租户活跃度计算模块的更新信息进行比对，发现租户a最新的活跃度由不活跃状态上升了，则触发对租户a进行数据热恢复处理。
[0165]
705、租户资源调度模块通知业务执行模块将租户a的任务挂起。
[0166]
706、租户资源调度模块对数据库资源控制模块下发租户a的热恢复指令。
[0167]
租户资源调度模块对数据库资源控制模块下发租户a的热恢复指令，并在数据库节点创建一个新的数据库实例，然后将备份节点上租户a的备份数据重新恢复到刚创建的数据库实例中。
[0168]
707、租户资源调度模块重新为租户a分配新的资源。
[0169]
租户资源调度模块重新为租户a分配新的线程池、订阅缓存池、连接池等动态资源至中等级的级别。
[0170]
708、租户资源调度模块通知业务执行模块将挂起的任务恢复。
[0171]
最后，租户资源调度模块通知业务执行模块将挂起的任务恢复，恢复后的任务会重新路由到为租户a恢复的数据库节点上。
[0172]
租户a资源恢复以及数据热恢复操作完成，触发执行下一轮迭代。
[0173]
为了对本技术实施例所带来的有益效果有更为直观的认识，以下对本技术实施例所带来的技术效果作进一步的对比，请参阅表1，表1给出了本技术实施例方法与现有技术下资源多租共享平台可支持的租户数量的效果对比。以集群内50％用户均为不活跃状态的僵尸租户(即第一等级或inactive)场景为例，现有技术下资源多租共享平台支持的租户数量为n，通过上述本技术实施例提供的方法可回收一半的数据库实例资源，能够为额外增加系统n/2可服务租户数量，大幅提升了集群能承载的租户数量，从而降低了单个租户的运营
成本。
[0174]
表1、本技术实施例方法与现有技术下系统可支持的租户数量的效果对比
[0175] 现有技术方法本技术实施例方法资源多租共享平台支持租户数量nn+n/2
[0176]
在上述实施例的基础上，为了更好的实施本技术实施例的上述方案，下面还提供用于实施上述方案的相关设备。具体参阅图8，图8为本技术实施例提供的一种租户管理系统的结构示意图，该租户管理系统800具体可以包括：统计模块801、确定模块802、计算模块803以及调整模块804，其中，统计模块801，用于获取租户在周期时长内的一个或多个请求信息；确定模块802，用于基于预设的信息类型从该请求信息中确定一个或多个目标请求信息；计算模块803，用于根据该目标请求信息确定该租户的目标活跃等级；调整模块804，用于在该租户的当前活跃等级与该目标活跃等级不同的情况下，根据该目标活跃等级调整该租户在资源多租共享平台的资源。
[0177]
在本技术上述实施方式中，租户管理系统800中的统计模块801、确定模块802以及计算模块803基于统计周期内租户的请求信息来计算租户在该统计周期内的活跃等级，调整模块804再基于活跃等级实现对不同租户预留资源的动态差异化管理，在本技术实施例中，即不再在资源多租共享平台上为不活跃租户预留资源，或当租户由活跃状态降级为不活跃状态时，收回该租户在资源多租共享平台上该租户的占用资源，最大化降低僵尸租户的运营成本。
[0178]
在一种可能的设计中，调整模块804，具体用于：在该目标活跃等级为第一等级且该当前活跃等级为第一目标等级的情况下，将该租户在该资源多租共享平台上运行的数据库实例的数据在预设备份节点上进行冷备份，得到备份数据，其中，该第一等级用于表征该租户在该周期时长内与该资源多租共享平台之间信息交互的数量未达到第一预设阈值，该第一目标等级用于表征该租户在该周期时长内与该资源多租共享平台之间的信息交互的数量达到该第一预设阈值；最后再释放该租户在该资源多租共享平台上占用的资源，即释放该租户的数据库实例对象，例如，释放该租户的线程池、订阅缓存池、连接池等动态资源，使其不再占用数据库节点上的资源。
[0179]
在本技术上述实施方式中，调整模块804可以根据租户的实际运行情况(即判定是否活跃)，动态调整资源多租共享平台的资源分配，在本技术实施例中，即不再在资源多租共享平台上为不活跃租户预留资源，或当租户降为不活跃状态时，收回该租户在资源多租共享平台上该租户的占用资源。因此在相同系统资源情况下，能为更多租户提供服务，最大化降低不活跃租户的运营成本，此外，相比那种超期自动清库的方案，对租户业务又更友好、更适用。
[0180]
在一种可能的设计中，调整模块804，具体还用于：在该目标活跃等级为第一目标等级且该当前活跃等级为第一等级的情况下，将该租户的任务挂起，并在该资源多租共享平台创建新的数据库实例，其中，该第一等级用于表征该租户在该周期时长内与该资源多租共享平台之间信息交互的数量未达到第一预设阈值，该第一目标等级用于表征该租户在该周期时长内与该资源多租共享平台之间信息交互的数量达到该第一预设阈值；之后，将存储于预设备份节点上的与该租户对应的备份数据恢复到该新的数据库实例中，并为该租户分配与该第一目标等级对应的该资源多租共享平台的目标资源；最后，基于该目标资源
运行该租户的任务。
[0181]
在本技术上述实施方式中，当租户重新活跃时，则调整模块804为该租户重新建联，并通过对备份节点上该租户的备份数据进行镜像热恢复，实现了快速上线以及租户的业务零感知，提升了用户体验。
[0182]
在一种可能的设计中，调整模块804，具体还用于：在该目标活跃等级为第二等级且该当前活跃等级为第二目标等级的情况下，对该租户在该资源多租共享平台上占用的资源进行资源降级操作，其中，该第二等级用于表征该租户在该周期时长内与该资源多租共享平台之间信息交互的数量达到第一预设阈值但未达到第二预设阈值，该第二目标等级用于表征该租户在该周期时长内与该资源多租共享平台之间信息交互的数量达到该第二预设阈值。
[0183]
在本技术上述实施方式中，在租户的当前活跃等级和目标活跃等级都不为第一等级的情况下，调整模块804通过对租户当前活跃等级与目标活跃等级的比较，实现租户在资源多租共享平台上占用资源的动态差异化配置，从而在能满足不同活跃程度租户的资源需求的情况下，节约资源多租共享平台的资源占用率，使得资源多租共享平台在相同的系统资源下能为更多活跃的租户提供服务。
[0184]
在一种可能的设计中，调整模块804，具体还用于：在该目标活跃等级为第二目标等级且该当前活跃等级为第二等级的情况下，对该租户在该资源多租共享平台上占用的资源进行资源升级操作，其中，该第二等级用于表征该租户在该周期时长内与该资源多租共享平台之间信息交互的数量达到第一预设阈值但未达到第二预设阈值，该第二目标等级用于表征该租户在该周期时长内与该资源多租共享平台之间信息交互的数量达到该第二预设阈值。
[0185]
在本技术上述实施方式中，在租户的当前活跃等级和目标活跃等级都不为第一等级的情况下，调整模块804通过对租户当前活跃等级与目标活跃等级的比较，实现租户在资源多租共享平台上占用资源的动态差异化配置，及时满足了活跃度升高的租户对所需资源增大的需求，相比于在线迁移的方式，降低了对租户业务的影响。
[0186]
在一种可能的设计中，计算模块803，具体用于：首先确定属于同一信息类型的目标请求信息的目标数量，并根据该目标数量确定与每个信息类型各自对应的目标权重，一个信息类型对应一个目标权重，最后根据该目标数量与该目标权重计算该租户的目标活跃等级。
[0187]
在本技术上述实施方式中，具体阐述了计算模块803是基于属于同一信息类型的目标请求信息的目标数量以及各自对应的目标权重来计算租户的目标活跃等级，具备可实现性。
[0188]
在一种可能的设计中，该租户管理系统800还包括触发执行模块805，用于：将该目标活跃等级作为该租户新的当前活跃等级，触发该统计模块801、该确定模块802、该计算模块803以及该调整模块804重复执行各自步骤。
[0189]
在一种可能的设计中，该预设的信息类型至少包括如下任意一种：连接、查询、写入、订阅。其中，连接用于表征该租户在同一时刻(可以是当前时刻，也可以是过去某个时刻，此处不做限定)与资源多租共享平台的连接，作为一种示例，假设该租户为app1，用户a是该app1的用户，用户b也是该app1的用户，当用户a与用户b同时登入该app1时，那么该
app1就会与该资源多租共享平台有2个连接，由于app1除了用户a和用户b之外，还可能有其他更多用户，因此，在同一时刻，用户登入到app1的数量就是该app1与该资源多租共享平台的连接的数量(可简称为连接数)。查询则用于表征该租户的读取操作，写入则用于表征该租户的删除操作、更新操作、创建操作中的至少一项，订阅则用于表征该租户建立的订阅条件。
[0190]
在本技术上述实施方式中，选取一些典型的信息类型作为预设的信息类型，具体可基于实际需求自定义，且可根据实际情况随时进行调整，具备灵活性和广泛实用性。
[0191]
在一种可能的设计中，资源降级操作至少包括如下任意一种：减少该租户的业务线程资源、减少该租户的订阅缓存资源、减少该租户的数据库连接资源。具体地，降级程度可基于目标活跃等级来确定，应准守的降级原则是：第二目标活跃等级越接近不活跃状态的第一等级，则减少程度越大，具体的降级方式则可基于这个降级原则自定义，此处不予赘述。
[0192]
在本技术上述实施方式中，具体阐述了几种资源降级操作的具体实现方式，具体可基于实际需求自定义如何降级，具备可选择性。
[0193]
在一种可能的设计中，资源升级操作至少包括如下任意一种：增加该租户的业务线程资源、增加该租户的订阅缓存资源、增加该租户的数据库连接资源。类似地，升级程度也可基于第二目标活跃等级来确定，应准守的升级原则是：第二目标活跃等级与第二等级之间的等级差越大，则增加程度越大，具体的升级方式则可基于这个升级原则自定义，此处不予赘述。
[0194]
在本技术上述实施方式中，具体阐述了几种资源升级操作的具体实现方式，具体可基于实际需求自定义如何升级，具备可选择性。
[0195]
需要说明的是，租户管理系统800中各模块/单元之间的信息交互、执行过程等内容，与本技术中上述方法实施例基于同一构思，具体内容可参见本技术前述所示的方法实施例中的叙述，此处不再赘述。
[0196]
接下来介绍本技术实施例提供的另一种租户管理系统，请参阅图9，图9为本技术实施例提供的租户管理系统的一种结构示意图，租户管理系统900上可以部署有图8对应实施例中所描述的租户管理系统800所涉及的模块，用于实现图8对应实施例中租户管理系统800的功能，具体的，租户管理系统900由一个或多个服务器实现，租户管理系统900可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，cpu)922和存储器932，一个或一个以上存储应用程序942或数据944的存储介质930(例如一个或一个以上海量存储设备)。其中，存储器932和存储介质930可以是短暂存储或持久存储。存储在存储介质930的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对租户管理系统900中的一系列指令操作。更进一步地，中央处理器922可以设置为与存储介质930通信，在租户管理系统900上执行存储介质930中的一系列指令操作。
[0197]
租户管理系统900还可以包括一个或一个以上电源926，一个或一个以上有线或无线网络接口950，一个或一个以上输入输出接口958，和/或，一个或一个以上操作系统941，例如windows servertm，mac os xtm，unixtm，linuxtm，freebsdtm等等。
[0198]
本技术实施例中，中央处理器922，用于执行图2对应实施例中的租户管理系统执
行的步骤。例如，中央处理器922可以用于：首先，获取租户在预设的周期时长内的请求信息(也可称为请求事件)，在预设周期时长内租户发送的请求信息可以是一个，也可以是多个，此处不做限定。需要说明的是，在本技术实施例中，租户向资源多租共享平台发送的信息都可称为请求信息，例如，请求接入的信息、请求订阅的信息、请求存储的信息等等，具体此处不做限定。在获取租户在周期时长内的一个或多个请求信息之后，将进一步基于预设的信息类型从获取到的这些请求信息中确定目标请求信息(也可称为活跃事件)，确定的目标请求信息可以是一个，也可以是多个，具体本技术对此不做限定。在基于预设的信息类型从获取到的请求信息中确定出一个或多个目标请求信息之后，再根据目标请求信息确定该租户的目标活跃等级。在计算得到该租户的目标活跃等级后，如果该租户的当前活跃等级与该目标活跃等级不同，则根据计算得到的目标活跃等级调整该租户在资源多租共享平台上的资源，调整方式包括但不限于：资源升级、资源降级、冷备份后释放该租户在资源多租共享平台上的占用资源、热恢复后重新为该租户分配资源等。具体的调整方式由租户的当前活跃等级以及计算得到的目标活跃等级来确定。
[0199]
需要说明的是，中央处理器922执行上述各个步骤的具体方式，与本技术中图2对应的方法实施例基于同一构思，其带来的技术效果也与本技术上述实施例相同，具体内容可参见本技术前述所示的方法实施例中的叙述，此处不再赘述。
[0200]
另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本技术提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。
[0201]
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本技术可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用cpu、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本技术而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，或者网络设备等)执行本技术各个实施例所述的方法。
[0202]
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。
[0203]
所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本技术实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、训练设备或数据中心通过有线
(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、训练设备或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的训练设备、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘(solid state disk，ssd))等。