Processing method and system for tenant data isolation and sharing of multi-service system

Abstract

The invention relates to a tenant data isolation and sharing processing method and system oriented to a multi-service system, and belongs to the technical field of service data processing, and the method comprises the steps: obtaining the average occupancy rate of historical resources of tenants, screening initial core tenants and shared tenants, distributing initial exclusive physical nodes to the initial core tenants, and distributing the shared tenants to the initial core tenants; distributing an initial shared physical node to the initial shared tenant; an initial slice mapping table of the initial shared physical node is constructed, and tenant ID binding is carried out; monitoring the tenant activeness of the initial exclusive physical node and the shared physical node and the slice utilization rate of the shared physical node; according to the tenant activeness, updating the core tenants and the shared tenants, and updating the exclusive physical nodes and the shared physical nodes; and collecting the current resource occupancy rate of the shared tenant on the new shared physical node, and updating the slice mapping table of the new shared physical node in combination with the slice utilization rate. The method and the device have the beneficial effects of improving the resource utilization rate and adapting to dynamic business changes.

Description

Technical Field

[0001] This application relates to the technical field of business data processing, and in particular to a processing method and system for tenant data isolation and sharing in multi-business systems. Background Technology

[0002] With the rapid development of cloud computing technology, the SaaS (Software as a Service) model has been widely adopted in the enterprise software service field due to its advantages such as resource sharing, low cost, and ease of maintenance. As the core architecture of the SaaS model, multi-tenant systems require a single codebase to serve multiple tenants while ensuring the security, independence, and business isolation of each tenant's data; that is, each tenant has its own independent data space and can only operate on its own data. In this context, achieving a balance between resource sharing and data isolation has become a key challenge in the design of multi-tenant systems, especially in meeting the stringent data privacy and compliance requirements of different industries (such as finance and healthcare).

[0003] In related technologies, multi-tenant data isolation solutions are mainly divided into three categories: independent databases, shared databases with independent schemas, and shared data tables differentiated by field. Among these, the shared database with independent schema solution is widely adopted. It achieves data isolation by assigning each tenant an independent database schema (logical namespace) and utilizes multi-tenant plugins in tools like MyBatis-Plus to automatically add tenant ID filtering conditions during SQL execution, ensuring the accuracy of data access. For example, a SaaS company uses this solution to provide tenants with independent schemas, while also supporting custom fields and modular plugins to meet basic customization needs. In addition, some systems combine physical node partitioning, statically classifying tenants into core tenants (such as large customers) and non-core tenants (such as small and medium-sized customers), deploying them on dedicated servers and shared server clusters respectively.

[0004] Existing isolation schemes based on static classification have the following significant drawbacks: Low resource utilization and waste: Static division of core / non-core tenants results in fixed resource allocation. Core tenants may have exclusive nodes that are idle for a long time, while non-core tenants share physical nodes and are prone to resource contention due to business fluctuations, making dynamic and elastic scheduling impossible. Unable to adapt to dynamic business changes: Tenant activity and resource demand change over time (e.g., promotional activities lead to a surge in resource demand from non-core tenants). Static classification cannot adjust resource allocation strategies in real time, which may result in a decline in service quality for high-priority tenants or idle resources for low-priority tenants. Summary of the Invention

[0005] To improve resource utilization and adapt to dynamic business changes, this application provides a method and system for handling tenant data isolation and sharing in multi-business systems.

[0006] Firstly, this application provides a method for handling tenant data isolation and sharing in multi-service systems, employing the following technical solution: A method for handling tenant data isolation and sharing in multi-service systems includes: Obtain the historical average resource utilization rate for each tenant; Based on the historical average resource utilization rate, initial core tenants and initial shared tenants are screened, and initial dedicated physical nodes are allocated to the initial core tenants and initial shared physical nodes are allocated to the initial shared tenants. Construct an initial slice mapping table corresponding to the initial shared physical node, and bind it to the corresponding shared tenant ID; Real-time monitoring of tenant activity of the initial dedicated physical node and the initial shared physical node, as well as slice utilization of the initial shared physical node; Based on the tenant activity level, update the core tenants and shared tenants, as well as the exclusive physical nodes and shared physical nodes; Collect the current resource utilization rate of shared tenants on the new shared physical node; The slice mapping table of the new shared physical node is dynamically updated based on the slice utilization rate and the current resource occupancy rate.

[0007] By adopting the above technical solution, and collecting historical average resource utilization rates of tenants, tenants are divided into initial core tenants and non-core tenants (initial shared tenants) and deployed on initial dedicated physical nodes and initial shared physical nodes respectively, resource waste can be effectively avoided. Core tenants obtain dedicated resources to ensure their service quality, while non-core tenants share resources to improve overall utilization. By binding tenant IDs to the slice mapping table of shared physical nodes, tenant data is isolated at the physical layer; at the same time, shared physical nodes support resource sharing among shared tenants, balancing efficiency and security. By monitoring tenant activity in real time, tenants are dynamically reclassified as core or non-core, and their resource allocation strategies are adjusted accordingly to ensure that highly active tenants receive priority resource response. By monitoring the slice utilization rate of shared physical nodes and dynamically adjusting the slice mapping table, dynamic resource rebalancing and load optimization are achieved.

[0008] Optionally, the step of constructing the initial slice mapping table corresponding to the initial shared physical node includes: Receive the initial shared physical node cluster and physical resource type set; Obtain the shared physical node load of each shared physical node in the initial shared physical node cluster; Slicing rules are generated based on the load of the shared physical nodes and the historical average resource utilization of each shared tenant; Based on the slicing rules, an initial slice mapping table corresponding to the initial shared physical node is constructed.

[0009] By adopting the above technical solution, the initial shared physical node cluster and physical resource type set are received, providing comprehensive basic information for resource slicing. Slicing rules are generated based on the node load of each shared physical node and the historical average resource utilization rate of each shared tenant. This helps to divide physical resources according to the actual carrying capacity of nodes and the real needs of tenants, avoiding blind resource allocation and thus improving the rationality of resource allocation. For shared tenants, their resource needs are relatively less urgent and critical; using shared physical nodes is itself intended to improve resource utilization. The initial slice mapping table constructed through the above steps can allocate the resources of shared physical nodes more precisely to each shared tenant, reducing resource idleness and waste, and further improving the resource utilization rate of shared physical nodes. The node load of each shared physical node is considered when generating slicing rules. This means that when constructing the initial slice mapping table, the resource needs of tenants will be allocated to nodes with relatively low load or sufficient carrying capacity, thereby helping to balance the load of the entire shared physical node cluster and preventing performance bottlenecks or failures on some nodes due to excessive load, ensuring the overall stability of the system.

[0010] Optionally, the steps of updating core tenants and shared tenants, as well as updating dedicated physical nodes and shared physical nodes, based on the tenant activity level include: Determine whether the tenant's activity level remains above a set activity threshold within a preset sliding window; If so, update the core tenants and shared tenants based on tenant activity levels; Collect the current resource utilization rate of core tenants; Obtain the independent node load of the exclusive physical node; Based on the current resource utilization rate and the load of the independent nodes, dedicated physical nodes are reallocated to core tenants, and shared physical nodes are reallocated to shared tenants.

[0011] By adopting the above technical solution, a preset sliding window is used to monitor whether tenant activity consistently exceeds a threshold, avoiding misjudgments caused by short-term fluctuations and ensuring the accuracy of core tenant identification. Combining the current resource utilization of active tenants with the load of independent nodes, node resources are reallocated to prevent service degradation due to insufficient resources for core tenants, while also preventing shared tenants from excessively consuming shared physical node resources. After core tenants are reallocated to dedicated physical nodes, resource competition with other tenants is avoided, ensuring low latency and high availability for critical business operations (such as financial transactions and real-time data analysis). The entire process from activity monitoring to node allocation requires no manual intervention, reducing the workload of operations and maintenance personnel.

[0012] Optionally, the step of determining whether the tenant activity level continuously exceeds a set activity threshold within a preset sliding window further includes: If not, obtain the number of times each tenant acts as a core tenant and the interval duration; Tenants are classified by importance based on the number of times and the interval duration. Update core tenants and shared tenants based on the tenant activity level and the tenant's importance level.

[0013] By adopting the above technical solution and combining historical data with real-time activity levels, decision-making biases caused by a single indicator can be avoided. For example, if a tenant has served as a core member few times (once), but their activity level has recently surged and the interval between occurrences is short (2 months), their potential can be identified through importance grading, and core resources can be allocated to them preferentially.

[0014] Optionally, the step of dynamically updating the slice mapping table of the new shared physical node based on the slice utilization rate and the current resource occupancy rate includes: Determine whether the utilization rate of the slice corresponding to the new shared physical node is less than the set utilization rate; If not, then based on the current resource occupancy rate, retrieve an idle slice from the shared resource pool; Based on the available slices, expand the slices of the corresponding shared tenants and update the slice mapping table; If so, then a portion of the slices corresponding to the shared tenant will be reclaimed and returned to the shared resource pool; Determine whether the remaining slice resources meet the current resource occupancy rate; If the conditions are not met, the number of slices is adjusted according to the current resource utilization rate, and the slice mapping table is updated.

[0015] By adopting the above technical solution, idle slice resources under low load conditions can be proactively identified and reclaimed by judging whether the slice utilization rate is less than a set threshold, avoiding waste caused by long-term idle resources. For example, when a shared tenant's business is in a slump, the utilization rate of some of its slices drops significantly, and the system can automatically release excess slices to the shared resource pool for other tenants to use. After reclaiming slices, the system checks whether the remaining slice resources meet the current resource utilization rate to ensure that the tenant's core business is not affected. If the remaining slices cannot support the current load, slices are dynamically added according to the actual resource usage; if the slice utilization rate is not lower than the set value but the tenant's resource demand increases, the system can directly call up idle slices for expansion, achieving real-time matching of resource supply and business demand. Using "whether the remaining slices meet the current resource utilization rate" as a constraint before reclaiming slices can prevent the performance degradation of tenant businesses caused by blindly reclaiming resources, ensuring that shared tenants can still obtain stable resource support in the shared mode. Through the dual-indicator adjustment mechanism of "utilization-triggered reclamation + occupancy-driven expansion", the system can quickly call up idle slices to complete expansion when tenant business traffic suddenly increases, shortening resource response latency and improving tenant experience. The recycling and redistribution of idle slices forms an internal resource circulation mechanism, enabling the physical resources of shared physical nodes (such as computing, storage, and bandwidth) to flow efficiently among multiple tenants, maximizing resource reuse and reducing overall infrastructure costs.

[0016] Optionally, after collecting the current resource utilization rate of the initial shared tenant, the steps before dynamically updating the slice mapping table of the new shared physical node based on the slice utilization rate and the current resource utilization rate include: Obtain the number of resources whose current utilization rate exceeds the utilization rate threshold; Determine whether the number of items exceeding the limit is greater than the limit threshold; If so, then obtain the excess deviation value, which is the difference between the current resource occupancy rate and the occupancy rate threshold; Migrate shared tenant data whose out-of-limit deviation values ​​are less than the deviation threshold to a backup shared physical node; The slice mapping table of the new shared physical node is dynamically updated based on the slice utilization rate and current resource occupancy rate of the remaining shared tenants.

[0017] By adopting the above technical solution, and by collecting the current resource utilization rate in real time and calculating the "exceedance count" (the number of tenants exceeding the utilization rate threshold), resource bottlenecks in shared physical nodes can be quickly located, preventing the entire node from crashing due to excessive resource consumption by a single tenant. A secondary judgment based on whether the "exceedance count exceeds the excess threshold" distinguishes between occasional overload and systemic overload, reducing ineffective intervention and improving resource management efficiency. Only tenants with "exceedance deviation values ​​less than the deviation threshold" are migrated to backup nodes, avoiding a "one-size-fits-all" migration that impacts high-priority non-core tenants and ensuring service continuity for most shared tenants. Overloaded tenants are distributed through backup shared physical nodes, achieving dynamic reallocation of physical resources and ensuring that the load on both the original shared physical nodes and backup nodes remains within safe thresholds.

[0018] Optionally, the step of determining whether the number of items exceeding the limit is greater than the limit threshold further includes: If not, then search the historical slice mapping library for the first historical slice utilization rate and the first historical resource utilization rate that match the slice utilization rate and the current resource utilization rate; Retrieve the historical slice mapping set that matches the first historical slice utilization rate and the first historical resource occupancy rate; Determine whether a similar first historical slice mapping table exists in the historical slice mapping set; If so, the slice mapping table of the new shared physical node is dynamically updated according to the first historical slice mapping table.

[0019] By adopting the above technical solution, matching data is searched from the historical slice mapping library. If a similar historical slice mapping table exists, it is directly reused or adjusted, avoiding the large computational overhead of generating a new mapping table from scratch each time. This significantly shortens the decision-making time, thereby improving the system's response speed and overall operating efficiency. Through reasonable slice mapping, it is ensured that different slice services can obtain the necessary resources.

[0020] Optionally, the step of determining whether a similar first historical slice mapping table exists in the historical slice mapping set further includes: If not, calculate the average slice utilization and average resource utilization of the historical slice mapping set; Filter the historical slice utilization rate and the second historical resource utilization rate from the historical slice mapping set that are similar to the average slice utilization rate and the average resource utilization rate; Retrieve the second historical slice mapping table that matches the second historical slice utilization rate and the second historical resource occupancy rate; Based on the second historical slice mapping table, the slice mapping table of the new shared physical area is dynamically updated.

[0021] By adopting the above technical solutions, existing mapping sets are used for rapid adaptation and incremental updates, reducing the frequency of generating new mapping tables and the need for full reconfiguration. This significantly reduces the risk of service interruption and related business migration overhead caused by frequent switching of mapping strategies, ensuring the continuity and stability of network services. Through matching historical data and filtering by average values, current resource needs can be predicted and matched more accurately, avoiding over-allocation or under-allocation of resources, improving the utilization rate of physical node resources, reducing unnecessary resource waste, and ultimately lowering overall network operating costs.

[0022] Secondly, this application provides a processing system for tenant data isolation and sharing in multi-service systems, employing the following technical solution: A processing system for tenant data isolation and sharing in multi-service systems, comprising: The data acquisition module is used to obtain the historical average resource utilization rate of each tenant and to collect the current resource utilization rate of shared tenants on the new shared physical node; The node allocation module is used to screen initial core tenants and initial shared tenants based on the historical average resource utilization rate, and to allocate initial dedicated physical nodes to the initial core tenants and initial shared physical nodes to the initial shared tenants. The slice mapping module is used to construct an initial slice mapping table corresponding to the initial shared physical node and bind it to the corresponding shared tenant ID. The monitoring module is used to monitor the tenant activity of the initial exclusive physical node and the initial shared physical node, as well as the slice utilization rate of the initial shared physical node in real time. The node update module is used to update the core tenants and shared tenants, as well as the exclusive physical nodes and shared physical nodes, based on the tenant activity level. The slice mapping update module is used to dynamically update the slice mapping table of the new shared physical node based on the slice utilization rate and the current resource occupancy rate.

[0023] In summary, this application has at least the following beneficial effects: By collecting historical average resource utilization data from tenants and classifying them into initial core tenants and non-core tenants (initial shared tenants), and deploying them on initial dedicated physical nodes and initial shared physical nodes respectively, resource waste can be effectively avoided. Core tenants receive dedicated resources to ensure their service quality, while shared tenants share resources to improve overall utilization. By binding tenant IDs to the slice mapping table of shared physical nodes, tenant data is isolated at the physical layer; at the same time, shared physical nodes support resource sharing among shared tenants, balancing efficiency and security. By monitoring tenant activity in real time, their core or non-core status is dynamically adjusted, and their resource allocation strategies are adjusted accordingly to ensure that highly active tenants receive priority resource response. By monitoring the slice utilization of shared physical nodes and dynamically adjusting the slice mapping table, dynamic resource rebalancing and load optimization are achieved. Attached Figure Description

[0024] Figure 1 This is a first flowchart of an embodiment of the method of this application; Figure 2 This is a second flowchart of an embodiment of the method of this application; Figure 3 This is a third flowchart of an embodiment of the method of this application; Figure 4 This is the fourth flowchart of an embodiment of the method of this application; Figure 5 This is the fifth flowchart of an embodiment of the method of this application; Figure 6 This is the sixth flowchart of an embodiment of the method of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the appendices in the embodiments of the present invention will be described below. Figure 1 -Appendix Figure 6 The technical solutions in the embodiments of the present invention are clearly and completely described herein. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] The first embodiment of this application discloses a method for handling tenant data isolation and sharing in a multi-service system. (Refer to...) Figure 1 The processing method may include S110-S170: S110, obtain the historical average resource utilization rate for each tenant; S120: Based on the historical average resource utilization rate, screen out the initial core tenants and the initial shared tenants, and allocate initial dedicated physical nodes to the initial core tenants and initial shared physical nodes to the initial shared tenants. S130, construct the initial slice mapping table corresponding to the initial shared physical node, and bind it with the corresponding shared tenant ID; S140, real-time monitoring of tenant activity of initial dedicated physical nodes and initial shared physical nodes, as well as slice utilization of initial shared physical nodes; S150 updates core tenants and shared tenants, as well as exclusive physical nodes and shared physical nodes, based on tenant activity. S160, collect the current resource utilization rate of shared tenants on the new shared physical node; S170: Dynamically update the slice mapping table of the new shared physical node based on slice utilization and current resource occupancy.

[0027] Specifically, for S110-S120, monitoring systems (such as Prometheus, Zabbix, Telegraf, etc.) can be used to collect resource usage data for each tenant over a period of time (e.g., the past 30 days), including various dimensions such as CPU, memory, disk I / O, and network bandwidth. Time-series aggregation calculations are then performed on the collected data to derive the average resource utilization rate for each tenant across each dimension.

[0028] Set thresholds (such as average CPU utilization > 70% or average memory utilization > 60%) as the core tenant screening criteria. Tenants exceeding the threshold are identified as "initial core tenants" and given priority in being allocated dedicated physical nodes; the remaining tenants are classified as "initial shared tenants" and uniformly allocated to a shared physical node pool, and run in isolation through virtualization technologies (such as KVM, Docker).

[0029] Reference Figure 2 For S130, the steps for constructing the initial slice mapping table corresponding to the initial shared physical nodes include S210-S240: S210, receives the initial shared physical node cluster and physical resource type set; S220, Obtain the shared physical node load of each shared physical node in the initial shared physical node cluster; S230 generates slicing rules based on the load of shared physical nodes and the historical average resource utilization rate of each shared tenant; S240, Based on the slicing rules, construct the initial slice mapping table corresponding to the initial shared physical nodes.

[0030] Specifically, shared physical node cluster information can be obtained in batches through cluster management system APIs (such as Kubernetes API and OpenStack Nova API), including metadata such as node ID, IP address, hardware configuration (number of CPU cores, memory capacity, disk type and size, network bandwidth), where physical nodes can be understood as servers. At the same time, a standardized dimension is defined for the set of physical resource types, such as {CPU, memory, disk IOPS, network throughput}, and the units for each type (such as number of CPU cores, GB of memory, IOPS / second, Gbps bandwidth) are preset through configuration files or a database. Deploy node-level monitoring agents (such as Prometheus Node Exporter, Telegraf) to collect real-time load data, including CPU utilization (%), memory utilization (%), disk I / O utilization (%), and network bandwidth utilization (%). Calculate the current average load value for each node by performing a sliding window average on the collected data from the past hour. Combine this with the node hardware configuration to calculate a normalized load index, for example: Load Index = (CPU utilization × weight 1 + memory utilization × weight 2 + ...) / total weight. The weights can be configured according to business priorities (e.g., setting the CPU weight to 0.4 for CPU-intensive tasks). Nodes with load indices below a threshold (e.g., 60%) are prioritized for slicing to avoid overloaded nodes. Based on the historical average utilization rate of tenants obtained from S110, a basic slice quota is allocated to each tenant. For example, if tenant A's historical average CPU utilization is 0.5 cores, the basic quota is set to 0.6 cores (with a 20% buffer). A dynamic step-size slicing strategy is adopted, for example, CPU slices are in units of 0.1 cores, and memory slices are in units of 256MB. The step size can be defined using `slice(start=0, stop=total node resources, step=minimum unit)`, referring to the `step` parameter in Python slicing operations to control resource allocation precision. The total slice quota of all tenants on the same node does not exceed 80% of the node's available resources (with a 20% elasticity reserve). The slice mapping table uses a two-dimensional dictionary structure, serializes the mapping table, and stores it in a distributed database (e.g., etcd, MongoDB), binding it to the corresponding shared tenant ID; and idempotency is ensured through version control (e.g., timestamp + node ID).

[0031] For S140, real-time monitoring components (such as Grafana + Prometheus + Node Exporter) can be deployed to collect tenant activity (such as number of requests, online time, API call frequency) and resource usage data; for shared physical nodes, the actual resource usage of each slice (CPU utilization, memory usage, etc.) can be monitored, and the slice utilization rate = (actual resource usage of the slice / resource allocation of the slice) × 100%.

[0032] Reference Figure 3 For S150, the steps for updating core tenants and shared tenants, as well as exclusive physical nodes and shared physical nodes based on tenant activity, include S310-S380: S310, determine whether the tenant's activity level is continuously greater than the set activity threshold within the preset sliding window; S320, if so, then update the core tenant and shared tenant based on tenant activity; S330, if not, obtain the number of times each tenant acts as a core tenant and the interval duration; S340 classifies tenants by importance based on frequency and interval duration; S350 updates core tenants and shared tenants based on tenant activity and tenant importance level; S360 collects the current resource utilization rate of core tenants; S370, obtain the independent node load of the exclusive physical node; S380 reallocates dedicated physical nodes to core tenants and shared physical nodes to shared tenants based on current resource utilization and independent node load.

[0033] Specifically, a time-based sliding window algorithm (such as Sliding Window Log or Fixed WindowCounter) can be used to count the request frequency, API call count, or business operation count of each tenant within a specified time window (e.g., 5 minutes). The activity threshold can be set to requests per minute > N, where N is a threshold set based on historical data or business needs. A real-time stream processing system (such as Flink, Kafka Streams, or Spark Streaming) is introduced to calculate activity metrics in real time. A rule engine (such as Drools, Easy Rules) or a machine learning classification model (such as SVM, XGBoost) is used to classify tenants. Classification criteria include: activity level, historical resource usage trends, SLA level, and payment level. A dynamic tagging mechanism is adopted to label tenants that meet the criteria as "core tenants," and the rest as "shared tenants." Core tenants are preferentially allocated to low-load, high-performance, and highly available physical node clusters, while shared tenants are scheduled to nodes with moderate load and high resource utilization using a shared resource pool mechanism.

[0034] When a tenant's activity level is determined to be less than or equal to a set activity threshold within a preset sliding window, the system retrieves historical tenant scheduling information from the database and incorporates time-series analysis logic to calculate the frequency (e.g., number of times per month) and interval (e.g., the time interval between the tenant's last time as a core tenant) of becoming a core tenant. A tenant importance scoring model is then constructed, with the following formula: Importance score = α * (number of core scheduling attempts / total number of scheduling attempts) + β * (reciprocal of the most recent scheduling interval), where α and β are weighting coefficients and are adjustable. A tiered strategy is used to classify tenants into four levels: S (very important), A (important), B (moderate), and C (low priority). Then, based on tenant activity and their respective importance level, core tenants and shared tenants are updated. This can be determined using a decision tree or rule engine, for example: high activity and high importance → core tenant; high activity and low importance → temporarily promoted to shared tenant, with subsequent performance observed; low activity but high importance → retained as a shared tenant and evaluated periodically.

[0035] Reference Figure 4 For S170, the steps for dynamically updating the slice mapping table of the new shared physical node based on slice utilization and current resource occupancy include S410-S470: S410, determine whether the slice utilization rate corresponding to the new shared physical node is less than the set utilization rate; S420, if not, then retrieve an idle slice from the shared resource pool based on the current resource utilization rate; S430: Based on the available slices, expand the slices of the corresponding shared tenant and update the slice mapping table; S440, if so, then reclaim a portion of the slices corresponding to the shared tenant to the shared resource pool; S450, determine whether the remaining slice resources meet the current resource utilization rate; S460, if not, adjust the number of slices according to the current resource utilization rate and update the slice mapping table; S470, if so, update the slice mapping table based on the remaining slice resources.

[0036] Specifically, if the slice utilization rate exceeds the set utilization rate, it indicates that the current resources of the shared physical node are strained. Therefore, the resource pool management module can be called to query the list of available slice resources and match suitable idle slices based on tenant priority, QoS level, and slice type. Then, the API interface is used to obtain slice resource information (such as slice ID, resource configuration, availability status, etc.) from the shared resource pool. The obtained idle slices are allocated to the corresponding shared tenants, and their slice resource quotas are updated. A virtualization orchestrator (such as Kubernetes or NFV Orchestrator) is used to instantiate the slices and deploy them to the target nodes, and the slice mapping table is updated to record information such as the tenant, physical node, and startup time of the new slices.

[0037] If the utilization rate is not greater than the set utilization rate, it indicates that there is resource waste in the shared physical node. Therefore, future resource demand can be assessed through load prediction models (such as time series forecasting or machine learning models) to identify reclaimable slices. Slices with low priority, low QoS requirements, or idle status are selected for reclamation. The slice destruction interface is called to release the physical resources it occupies, and the slice status is marked as "idle". It is then added to the shared resource pool for other shared tenants to use as needed.

[0038] Calculate the remaining capacity of the nodes after reclaiming some slices (such as remaining CPU capacity, memory bandwidth, etc.) and determine whether the remaining slice resources meet the current resource utilization rate. If yes, perform a slice mapping table update operation, clean up invalid slice records, and update the ownership relationship and resource allocation of new slices. If no, resources can be reallocated through resource scheduling algorithms (such as proportional allocation, priority scheduling, weighted fair queue), dynamically increasing the number of slices for high-priority tenants or decreasing the number of slices for low-priority tenants to update the slice mapping table and meet the current resource utilization rate.

[0039] In addition, refer to Figure 5 and Figure 6 The steps following S160 and preceding S170 may include S510-S630: S510, Get the number of resources whose current utilization rate exceeds the utilization rate threshold; S520, determine whether the number of items exceeding the limit is greater than the threshold for exceeding the limit; S530, if so, then obtain the excess deviation value, which is the difference between the current resource utilization rate and the utilization rate threshold; S540 migrates shared tenant data with deviation values ​​less than the deviation threshold to a standby shared physical node. S550 dynamically updates the slice mapping table of new shared physical nodes based on the slice utilization rate and current resource occupancy rate of the remaining shared tenants. S560, if not, then find the first historical slice utilization rate and the first historical resource utilization rate that match the slice utilization rate and the current resource utilization rate from the historical slice mapping library; S570, retrieve the historical slice mapping set that matches the first historical utilization rate and the first historical resource occupancy rate; S580, Determine whether a similar first historical slice mapping table exists in the historical slice mapping set; S590, if so, then dynamically update the slice mapping table of the new shared physical node according to the first historical slice mapping table; S600, if not, calculate the average slice utilization and average resource utilization of the historical slice mapping set; S610, filter out the second historical slice utilization rate and second historical resource utilization rate that are similar to the average slice utilization rate and average resource utilization rate from the historical slice mapping set; S620, retrieve the second historical slice mapping table that matches the second historical slice utilization rate and the second historical resource occupancy rate; S630: Dynamically update the slice mapping table of the new shared physical node based on the second historical slice mapping table.

[0040] If there is no second historical slice utilization rate and second historical resource utilization rate similar to the average slice utilization rate and the average resource utilization rate, then execute S170.

[0041] Specifically, if a tenant's utilization of a certain resource exceeds the occupancy threshold (e.g., CPU utilization > 85%), it is counted as an "over-limit event". The number of all over-limit events is counted as the "over-limit quantity"; the occupancy threshold can be dynamically adjusted based on historical load analysis. By judging whether the "over-limit quantity" within the statistical period exceeds the over-limit threshold, it is determined whether to enter the resource optimization process. For example, if the over-limit quantity > 3, a further processing process is triggered (S530); otherwise, the historical matching process is entered (S560). For S530, a weighted comprehensive over-limit deviation value is calculated for different resource dimensions. For tenants with over-limit deviation values ​​less than the over-limit threshold, a lightweight migration operation is performed, for example: using Kubernetes' Pod scheduling mechanism or virtual machine migration tools (such as vMotion) to migrate the tenant's containers or virtual machines to a standby node, and using a load balancer (such as Nginx or HAProxy) to switch traffic during the migration process.

[0042] For S560, an index model of slice utilization and resource occupancy is established in the historical database. Similarity matching algorithms (such as cosine similarity and Euclidean distance) are used to find the historical record closest to the current system state. More specifically, the slice utilization and resource occupancy of the current system are extracted; records are traversed in the historical mapping database, and similarity is calculated; the record with the highest similarity is selected as the "first historical match". The slice mapping table corresponding to the found "first historical match" is retrieved from the historical mapping database to form a historical mapping set; this mapping table may contain information such as the mapping relationship between slices and physical nodes, resource allocation strategies, and scheduling rules. Cluster analysis or similarity comparison is performed on the slice mapping tables in the retrieved historical mapping set to determine whether there are mapping tables with highly similar structures and resource allocation strategies. More specifically, hash value comparison of the slice mapping structure is used to perform structured vectorization processing on the mapping table content, and clustering algorithms (such as K-Means) are used for classification; if the similarity is higher than a set threshold, it is considered that "a similar mapping table exists". Using the matched historical slice mapping table as a template, and combining it with the current system state (such as the addition of physical nodes or changes in resource capacity), the Policy Engine is used to fine-tune the process and generate a new mapping table.

[0043] If no similar first historical slice mapping table exists, a weighted average of the slice utilization and resource occupancy of all records in the historical mapping set is calculated as the "average slice utilization" and "average resource occupancy," respectively. The weights can be set based on dimensions such as time freshness and the stability of historical utilization. Using K-Nearest Neighbors (KNN) or a similarity-based filtering mechanism, records close to the average slice utilization and average resource occupancy are selected from the historical mapping set. More specifically, the difference between each record and the average is calculated, and a similarity threshold is set (e.g., difference < 5%). Records meeting the criteria are selected as "second historical matches." The best-matching slice mapping table from the "second historical matches" is chosen as the base template for updating the current system mapping. For example, more recent historical records or those with resource scheduling strategies consistent with the current system are prioritized. The selected second historical slice mapping table is then merged with the current system state to generate a slice mapping table adapted to the current physical node resource state.

[0044] The implementation principle of this embodiment is as follows: Obtain the historical average resource utilization rate for each tenant, and based on the historical average resource utilization rate, screen out the initial core tenants and the initial shared tenants, and allocate initial dedicated physical nodes to the initial core tenants and initial shared physical nodes to the initial shared tenants. Receive the initial shared physical node cluster and physical resource type set, obtain the shared physical node load of each shared physical node in the initial shared physical node cluster, generate slicing rules based on the shared physical node load and the historical average resource utilization rate of each shared tenant, and construct an initial slice mapping table corresponding to the initial shared physical nodes based on the slicing rules. The initial slice mapping table is bound to the corresponding shared tenant ID. Real-time monitoring of tenant activity on initial dedicated physical nodes and initial shared physical nodes, as well as slice utilization on initial shared physical nodes; Determine if the tenant activity level consistently exceeds a set activity threshold within a preset sliding window. If so, re-evaluate core tenants and shared tenants based on tenant activity. If not, obtain the number of times each tenant has served as a core tenant and the interval between those times and the intervals. Classify tenants by importance based on the number of times and the intervals. Update core tenants and shared tenants based on tenant activity and their respective importance levels. Collect the current resource utilization rate of core tenants and the independent node load of dedicated physical nodes. Then, based on the current resource utilization rate and independent node load, reallocate dedicated physical nodes to core tenants and shared physical nodes to shared tenants. Collect the current resource utilization rate of shared tenants on the new shared physical node, and obtain the number of excess resources whose current resource utilization rate exceeds the utilization rate threshold; determine whether the number of excess resources exceeds the excess threshold. If so, obtain the excess deviation value between the current resource utilization rate and the utilization rate threshold, and migrate the data of shared tenants whose excess deviation value is less than the deviation threshold to the standby shared physical node. Based on the slice utilization rate and current resource utilization rate of the remaining shared tenants, dynamically update the slice mapping table of the new shared physical node. If not, search the historical slice mapping library for the first historical slice utilization rate and the first historical resource utilization rate that match the slice utilization rate and the current resource utilization rate. Then, retrieve the historical slice mapping set that matches the first historical utilization rate and the first historical resource utilization rate. Determine if a similar first historical slice mapping table exists in the historical slice mapping set. If yes, dynamically update the slice mapping table corresponding to the new shared physical node based on the first historical slice mapping table. If not, calculate the average slice utilization rate and the average resource utilization rate of the historical slice mapping set. Filter the historical slice mapping set for second historical slice utilization rates and second historical resource utilization rates that are similar to the average slice utilization rate and the average resource utilization rate, and retrieve the second historical slice mapping table that matches the second historical slice utilization rate and the second historical resource utilization rate. Dynamically update the slice mapping table corresponding to the new shared physical node based on the second historical slice mapping table. If no second historical slice utilization rate and second historical resource utilization rate are similar to the average slice utilization rate and the average resource utilization rate, dynamically update the slice mapping table of the new shared physical node based on the slice utilization rate and the current resource utilization rate.

[0045] Based on the above method embodiments, the second embodiment of this application discloses a processing system for tenant data isolation and sharing in multi-service systems. The processing system for tenant data isolation and sharing in multi-service systems of this application embodiment can implement any of the above-described methods for processing tenant data isolation and sharing in multi-service systems, and the specific working process of each module in the processing system for tenant data isolation and sharing in multi-service systems can be referred to the corresponding process in the above method embodiments.

[0046] For ease of understanding, an example is given below: A processing system for tenant data isolation and sharing in a multi-service system includes: The data acquisition module is used to obtain the historical average resource utilization rate of each tenant and to collect the current resource utilization rate of shared tenants on the new shared physical node; The node allocation module is used to screen initial core tenants and initial shared tenants based on the historical average resource utilization rate, and to allocate initial dedicated physical nodes to initial core tenants and initial shared physical nodes to initial shared tenants. The slice mapping module is used to construct an initial slice mapping table corresponding to the initial shared physical node and bind it to the corresponding shared tenant ID. The monitoring module is used to monitor the tenant activity of the initial dedicated physical node and the initial shared physical node, as well as the slice utilization of the initial shared physical node in real time. The node update module is used to update core tenants and shared tenants, as well as exclusive physical nodes and shared physical nodes, based on tenant activity. The slice mapping update module is used to dynamically update the slice mapping table of new shared physical nodes based on slice utilization and current resource occupancy.

[0047] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is only one example of a series of equivalent or similar features.

Claims

1. A method for handling tenant data isolation and sharing in a multi-service system, characterized in that, include: Obtain the historical average resource utilization rate for each tenant; Based on the historical average resource utilization rate, initial core tenants and initial shared tenants are screened, and initial dedicated physical nodes are allocated to the initial core tenants and initial shared physical nodes are allocated to the initial shared tenants. Construct an initial slice mapping table corresponding to the initial shared physical node, and bind it to the corresponding shared tenant ID; Real-time monitoring of tenant activity of the initial dedicated physical node and the initial shared physical node, as well as slice utilization of the initial shared physical node; Based on the tenant activity level, update the core tenants and shared tenants, as well as the exclusive physical nodes and shared physical nodes; Collect the current resource utilization rate of shared tenants on the new shared physical node; The slice mapping table of the new shared physical node is dynamically updated based on the slice utilization rate and the current resource occupancy rate.

2. The method for tenant data isolation and sharing in a multi-service system according to claim 1, characterized in that, The steps for constructing the initial slice mapping table corresponding to the initial shared physical node include: Receive the initial shared physical node cluster and physical resource type set; Obtain the shared physical node load of each shared physical node in the initial shared physical node cluster; Slicing rules are generated based on the load of the shared physical nodes and the historical average resource utilization of each shared tenant; Based on the slicing rules, an initial slice mapping table corresponding to the initial shared physical node is constructed.

3. The method for tenant data isolation and sharing in a multi-service system according to claim 1, characterized in that, The steps for updating core tenants and shared tenants, as well as exclusive physical nodes and shared physical nodes, based on the tenant activity level include: Determine whether the tenant's activity level remains above a set activity threshold within a preset sliding window; If so, update the core tenants and shared tenants based on tenant activity levels; Collect the current resource utilization rate of core tenants; Obtain the independent node load of the exclusive physical node; Based on the current resource utilization rate and the load of the independent nodes, dedicated physical nodes are reallocated to core tenants, and shared physical nodes are reallocated to shared tenants.

4. The method for tenant data isolation and sharing in a multi-service system according to claim 3, characterized in that, The step of determining whether the tenant activity level remains above a set activity threshold within a preset sliding window further includes: If not, obtain the number of times each tenant acts as a core tenant and the interval duration; Tenants are classified by importance based on the number of times and the interval duration. Update core tenants and shared tenants based on the tenant activity level and the tenant's importance level.

5. The method for tenant data isolation and sharing in a multi-service system according to claim 1, characterized in that, The steps for dynamically updating the slice mapping table of the new shared physical node based on the slice utilization rate and the current resource occupancy rate include: Determine whether the utilization rate of the slice corresponding to the new shared physical node is less than the set utilization rate; If not, then based on the current resource occupancy rate, retrieve an idle slice from the shared resource pool; Based on the available slices, expand the slices of the corresponding shared tenants and update the slice mapping table; If so, then a portion of the slices corresponding to the shared tenant will be reclaimed and returned to the shared resource pool; Determine whether the remaining slice resources meet the current resource occupancy rate; If the conditions are not met, the number of slices is adjusted according to the current resource utilization rate, and the slice mapping table is updated.

6. The method for tenant data isolation and sharing in a multi-service system according to claim 5, characterized in that, After collecting the current resource utilization rate of the initial shared tenant, the steps before dynamically updating the slice mapping table of the new shared physical node based on the slice utilization rate and the current resource utilization rate include: Obtain the number of resources whose current utilization rate exceeds the utilization rate threshold; Determine whether the number of items exceeding the limit is greater than the limit threshold; If so, then obtain the excess deviation value, which is the difference between the current resource occupancy rate and the occupancy rate threshold; Migrate shared tenant data whose out-of-limit deviation values ​​are less than the deviation threshold to a backup shared physical node; The slice mapping table of the new shared physical node is dynamically updated based on the slice utilization rate and current resource occupancy rate of the remaining shared tenants.

7. The method for tenant data isolation and sharing in a multi-service system according to claim 6, characterized in that, The step of determining whether the number of items exceeding the limit is greater than the limit threshold further includes: If not, then search the historical slice mapping library for the first historical slice utilization rate and the first historical resource utilization rate that match the slice utilization rate and the current resource utilization rate; Retrieve the historical slice mapping set that matches the first historical slice utilization rate and the first historical resource occupancy rate; Determine whether a similar first historical slice mapping table exists in the historical slice mapping set; If so, the slice mapping table of the new shared physical node is dynamically updated according to the first historical slice mapping table.

8. The method for tenant data isolation and sharing in a multi-service system according to claim 7, characterized in that, The step of determining whether a similar first historical slice mapping table exists in the historical slice mapping set further includes: If not, calculate the average slice utilization and average resource utilization of the historical slice mapping set; Filter the historical slice utilization rate and the second historical resource utilization rate from the historical slice mapping set that are similar to the average slice utilization rate and the average resource utilization rate; Retrieve the second historical slice mapping table that matches the second historical slice utilization rate and the second historical resource occupancy rate; Based on the second historical slice mapping table, the slice mapping table of the new shared physical node is dynamically updated.

9. A processing system for tenant data isolation and sharing in a multi-service system, characterized in that, The method for tenant data isolation and sharing in a multi-service system as described in any one of claims 1-8 includes: The data acquisition module is used to obtain the historical average resource utilization rate of each tenant and to collect the current resource utilization rate of shared tenants on the new shared physical node; The node allocation module is used to screen initial core tenants and initial shared tenants based on the historical average resource utilization rate, and to allocate initial dedicated physical nodes to the initial core tenants and initial shared physical nodes to the initial shared tenants. The slice mapping module is used to construct an initial slice mapping table corresponding to the initial shared physical node and bind it to the corresponding shared tenant ID. The monitoring module is used to monitor the tenant activity of the initial exclusive physical node and the initial shared physical node, as well as the slice utilization rate of the initial shared physical node in real time. The node update module is used to update the core tenants and shared tenants, as well as the exclusive physical nodes and shared physical nodes, based on the tenant activity level. The slice mapping update module is used to dynamically update the slice mapping table of the new shared physical node based on the slice utilization rate and the current resource occupancy rate.

Images