A multi-tenant system dynamic resource allocation and performance optimization method

Abstract

The application provides a multi-tenant system dynamic resource allocation and performance optimization method, which can correspondingly increase or decrease the number of server instances according to the relationship between the resource demand score of a tenant and a preset expansion threshold, and the resource demand score is calculated by simultaneously considering the real-time changes of traffic, CPU and memory, so that the expansion or contraction of the server can be dynamically adjusted according to the real-time changes of the traffic, CPU and memory of the tenant, the dynamic changes of the traffic mode of the tenant are met, the possibility of resource waste or performance bottleneck caused by static configuration is reduced, and the resource utilization and system response capability are effectively improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of multi-tenant system resource allocation and performance optimization, and particularly relates to a multi-tenant system dynamic resource allocation and performance optimization method. BACKGROUND

[0002] In the field of cloud computing, multi-tenant SaaS (Software as a Service) systems have been widely applied in enterprise services, education, medical treatment and other fields due to their efficient resource sharing and flexible scalability. The core of SaaS systems lies in providing services for multiple tenants through a single application instance while ensuring data isolation and performance stability among tenants. In existing multi-tenant SaaS systems, resource allocation and performance optimization usually rely on static configuration or simple dynamic adjustment methods.

[0003] For example, in a typical SaaS architecture, server resource allocation usually adopts a pre-allocated mode, that is, fixed computing resources (such as CPU and memory) and database instances are pre-configured according to the number of tenants and expected traffic. When traffic surges, the system increases server instances through automatic expansion mechanisms. In addition, load balancing techniques are used to distribute traffic, but are usually based on simple round-robin or least connection algorithms without considering the specific needs of tenants. At the database level, a single master architecture is often used, with all read and write operations concentrated on the same instance, or simple read-write separation is achieved through master-slave replication, but lacks dynamic adjustment capabilities.

[0004] The existing technology still has the following defects and deficiencies in the process of resource allocation and performance optimization in multi-tenant SaaS systems:

[0005] 1) Lack of flexibility in server scaling: Automatic expansion mechanisms based on static thresholds (such as scaling when CPU usage exceeds 80%) cannot adapt to the dynamic changes in tenant traffic patterns, which may lead to resource waste or performance bottlenecks. For example, when the traffic of a certain tenant surges while the traffic of other tenants is low, overall scaling will cause unnecessary resource idling.

[0006] 2) Load balancing does not consider tenant characteristics: Existing load balancing algorithms (such as round-robin or least connection) do not distinguish traffic priorities based on tenant ID, resulting in requests from high-value tenants and high-load tenants not being prioritized, affecting user experience.

[0007] 3) Lack of traffic limitation: There is a lack of traffic limitation mechanism for individual tenants, which may occupy too many system resources when a certain tenant generates abnormally high traffic, affecting the normal service of other tenants.

[0008] 4) Database performance bottleneck: single master database or simple master-slave replication architecture cannot cope with the dynamic changes of read and write requests, especially in high concurrency scenarios, the pressure on the master database is too large or the synchronization delay of the slave database will cause performance degradation.

[0009] 5) Database instance adjustment lag: the existing solution does not realize the dynamic expansion and contraction of the database instance, and cannot adjust the instance number or configuration according to the actual demand of the tenant, resulting in low resource utilization or service interruption risk.

[0010] Therefore, there is an urgent need for a new solution to solve the above-mentioned defects and deficiencies in the prior art. SUMMARY

[0011] In order to solve the defects and deficiencies in the prior art, the present application provides a multi-tenant system dynamic resource allocation and performance optimization method.

[0012] The specific scheme provided by the present application is:

[0013] A multi-tenant system dynamic resource allocation and performance optimization method, characterized in that it comprises the following steps:

[0014] S100: Initialize the resource management center, record the service data of each tenant in real time through the tenant resource pool, monitor the tenant traffic data in real time through the traffic monitoring module, analyze the performance of the tenant through the performance analysis module, and at the same time allocate a unique ID corresponding to each tenant and initialize its basic resource configuration;

[0015] S200: Real-time calculation of resource demand score of each tenant, and according to the relationship between the resource demand score of each tenant calculated and the preset expansion threshold, the number of server instances is increased or decreased correspondingly;

[0016] S300: Extract the tenant ID by ID identification method, match the preset priority rules and resource allocation strategy according to the tenant ID, and distribute the traffic to the corresponding server instance according to the priority rules and resource allocation strategy;

[0017] S400: Set the traffic upper limit for each tenant and control the traffic of the tenant;

[0018] S500: Distribute the write request to the data master according to the tenant ID, and distribute the read request to multiple data slaves according to the load balancing strategy;

[0019] S600: Real-time monitoring of actual indicators of tenants, and comparison of actual indicators with preset threshold, and dynamic adjustment of database instances according to comparison results.

[0020] As a further preferred embodiment of the present application, in the step S100, the tenant service data at least includes resource allocation between the tenant and the server and the database instance; the analysis of the tenant performance at least includes analysis of the CPU, memory and database connection number of the tenant; and the basic resource configuration at least includes the number of server instances and the database connection pool parameters.

[0021] As a further preferred embodiment of the present application, in the step S200, the resource demand score of each tenant is calculated according to the following formula:

[0022] Z = a x L + b x C + g x N

[0023] wherein,

[0024] Z is the resource demand score of each tenant;

[0025] L is the traffic growth rate;

[0026] C is the CPU usage rate;

[0027] N is the memory occupancy rate;

[0028] a, b and g are weight coefficients corresponding to the traffic growth rate, the CPU usage rate and the memory occupancy rate, respectively.

[0029] As a further preferred embodiment of the present application, in the step S200,

[0030] when the resource demand score of the tenant exceeds the preset expansion threshold and the duration exceeds the preset time, the number of server instances corresponding to the tenant is increased;

[0031] when the resource demand score of the tenant does not exceed the preset expansion threshold and the duration exceeds the preset time, the number of server instances corresponding to the tenant is reduced;

[0032] The newly added or reduced server instances are quickly deployed through containerization technology and added to the tenant resource pool corresponding to the tenant in the resource management center.

[0033] As a further preferred embodiment of the present application, in the step S300, the ID identification method includes the following steps:

[0034] S301: At the front-end request entrance of the system, the tenant ID is extracted by parsing the custom field in the HTTP request header or the tenant identification in the URL parameter;

[0035] S302: The tenant ID information is carried by the JWT token, and the legality of the token is verified through the key at the gateway layer to further verify the tenant ID;

[0036] S303: store the extracted tenant ID in the request context and pass it to the load balancer;

[0037] S304: the load balancer queries the tenant priority table pre-stored in the in-memory database according to the tenant ID in the request context to obtain the priority rule and resource allocation strategy of the tenant.

[0038] As a further preferred embodiment of the present application, in the step S400:

[0039] The traffic upper limit is set for each tenant based on the subscription package or historical traffic peak value;

[0040] The traffic control is performed on the tenant through the following judgment process: when the instantaneous traffic of the tenant exceeds the preset upper limit, the traffic of the tenant is throttled or the traffic request exceeding the part of the tenant is discarded, and a prompt information is returned.

[0041] As a further preferred embodiment of the present application, in the step S500, the following steps are included:

[0042] S501: real-time collection of node state and update of routing rule;

[0043] S502: implementation of read-write separation control in the database, so that the master database only processes write operation, the slave database only processes read operation, and dynamic addition or removal of the slave database can be realized;

[0044] S503: distribution of write request to the data master database according to the tenant ID, and distribution of read request to multiple data slave databases according to the load balancing strategy.

[0045] As a further preferred embodiment of the present application, in the step S500,

[0046] For read request: the weight is allocated according to the load state of the storage node, and the load state at least includes CPU usage, connection number and response delay; at the same time, a load upper limit threshold is set, when the load of the storage node exceeds the upper limit threshold, the weight is dynamically reduced, and the request is distributed to other nodes;

[0047] For write request: the master storage node ensures data consistency through a preset protocol, sends the write request to the corresponding master storage node partition according to the tenant ID, if the load of the master storage node exceeds the preset threshold, triggers the dynamic expansion mechanism, adds a master storage node and migrates data shards.

[0048] As a further preferred embodiment of the present application, in the step S600, the real-time monitored tenant actual indicators at least include the database connection number, query response time and master-slave synchronization delay of the tenant.

[0049] As a further preferred embodiment of the present application, in the step S600,

[0050] When the actual index of the tenant exceeds the preset threshold, a new master database instance is added and the tenant data is migrated through data sharding;

[0051] When the number of slave databases is lower than the preset threshold, the slave database instance is dynamically increased and the data is synchronized;

[0052] After the adjustment is completed, the database configuration in the tenant resource pool is updated.

[0053] Compared with the prior art, the present application can achieve the following technical effects:

[0054] 1) The present application provides a multi-tenant system dynamic resource allocation and performance optimization method, which can increase or decrease the number of server instances according to the relationship between the resource demand score of the tenant and the preset expansion threshold, and the resource demand score is calculated by considering the real-time changes of traffic, CPU and memory at the same time, so that the expansion or contraction of the server can be dynamically adjusted according to the real-time changes of tenant traffic, CPU and memory, to meet the dynamic changes of tenant traffic mode, reduce the possibility of resource waste or performance bottleneck caused by static configuration, and effectively improve resource utilization and system response capability.

[0055] 2) The present application provides a multi-tenant system dynamic resource allocation and performance optimization method, which matches the preset priority rules and resource allocation strategies according to the tenant ID, and allocates traffic to the corresponding server instance according to the priority rules and resource allocation strategies, so as to realize personalized load balancing of traffic based on tenant ID, prioritize processing of requests of high-value tenants and high-load tenants, and improve the service quality of high-priority tenants.

[0056] 3) The present application provides a multi-tenant system dynamic resource allocation and performance optimization method, which sets a traffic upper limit for each tenant to control the traffic of the tenant, thereby limiting the traffic of a single tenant and avoiding abnormal traffic affecting the overall system stability.

[0057] 4) The present application provides a multi-tenant system dynamic resource allocation and performance optimization method, which distributes write requests to a data master according to the tenant ID, and distributes read requests to multiple data slaves according to a load balancing strategy, so as to realize efficient read-write separation at the database level, optimize the database performance in high-concurrency scenarios, and effectively improve the resource utilization.

[0058] 5) The present application provides a multi-tenant system dynamic resource allocation and performance optimization method, which monitors the actual index of the tenant in real time, compares the actual index with the preset threshold, and dynamically adjusts the database instance according to the comparison result, to realize dynamic expansion and contraction of the database instance, improve the flexibility of resource allocation and the horizontal expansion capability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 Shown is a flow chart of the steps of the method provided by the present invention. DETAILED DESCRIPTION

[0060] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0061] In the description of the present invention, it should be noted that the terms "upper," "lower," "inner," "outer," "front end," "rear end," "both ends," "one end," "the other end," and the like, indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings and are intended solely to facilitate and simplify the description of the present invention. They are not intended to indicate or imply that the devices or components referred to must have, be constructed, or operate in a specific orientation, and therefore should not be construed as limiting the present invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0062] In the description of the present invention, it should be noted that, unless otherwise expressly specified or limited, the terms "installed," "provided with," "connected," etc., should be understood in a broad sense. For example, "connected" may refer to a fixed connection, a detachable connection, or an integral connection; it may refer to a mechanical connection or an electrical connection; it may refer to a direct connection or an indirect connection through an intermediate medium; it may refer to internal communication between two components. Those skilled in the art will be able to understand the specific meanings of the above terms in the present invention based on the specific circumstances.

[0063] [First embodiment]

[0064] like Figure 1 The first embodiment of the present invention is shown, which provides a method for dynamic resource allocation and performance optimization of a multi-tenant system, including the following steps:

[0065] S100: Initialize the resource management center, record each tenant's service data in real time through the tenant resource pool, monitor tenant traffic data in real time through the traffic monitoring module, and analyze tenant performance through the performance analysis module. At the same time, assign a unique ID to each tenant and initialize its basic resource configuration;

[0066] In this step, the tenant service data at least includes resource allocation between tenants and server and database instances; analyzing tenant performance at least includes analyzing tenant CPU, memory and database connection number; and the basic resource configuration at least includes the number of server instances and database connection pool parameters.

[0067] S200: Real-time calculation of resource demand scores of each tenant, and according to the relationship between the calculated resource demand scores of each tenant and the preset expansion threshold, the number of server instances is increased or decreased correspondingly;

[0068] In this step, the resource demand score of each tenant is calculated according to the following formula:

[0069] Z = a x L + b x C + g x N

[0070] Wherein,

[0071] Z is the resource demand score of each tenant;

[0072] L is the traffic growth rate;

[0073] C is the CPU usage rate;

[0074] N is the memory occupancy rate;

[0075] a, b, g are weight coefficients corresponding to the traffic growth rate, CPU usage rate and memory occupancy rate respectively; the traffic growth rate L can be calculated based on the tenant traffic data collected by the traffic monitoring module in real time; and the CPU usage rate and the memory occupancy rate can be obtained through the analysis results of the performance analysis module on the tenant performance.

[0076] The traffic growth rate L, the CPU usage rate C and the memory occupancy rate N are selected as the three items for calculating the resource demand score of the tenant, which is based on the comprehensive consideration of the core demand and performance bottleneck of the resource allocation of the multi-tenant in the SaaS system. Among them,

[0077] The traffic growth rate L reflects the current traffic trend of the tenant, especially in the high concurrency scenario, the traffic surge is the main signal to trigger resource expansion. The contribution of the traffic growth rate L to the resource demand score is to predict future resource demand, especially in the case of burst traffic, a higher traffic growth rate L will significantly increase the resource demand score Z of each tenant, prompting the system to expand in advance to avoid performance degradation;

[0078] The CPU usage rate C represents the current load level of the computing resource, and the CPU is the core component for processing tenant requests. When the CPU usage rate C is high, it indicates that the computing capacity is insufficient, which directly affects the system response speed. The CPU usage rate C directly improves the resource demand score Z of each tenant, reflecting the immediate resource pressure.

[0079] Memory usage (N) measures memory resource utilization. Insufficient memory can lead to cache failure or data swapping, impacting query performance and user experience. While N has a relatively stable impact on each tenant's resource requirement score (Z), its weight can be more significant in memory-intensive tasks such as AI inference or big data processing.

[0080] The weight coefficients α, β, and γ in the formula determine the relative importance of each item to the resource requirement score. Their corresponding size depends on the specific application scenario and system design goals. Generally, the above weight coefficients can be flexibly set according to user needs and system characteristics. For example:

[0081] In traffic-sensitive applications (such as during e-commerce promotions), α can be set larger than β and γ because the traffic growth rate is the primary concern;

[0082] In computationally intensive tasks (such as AI model training), β can be set larger than α and γ to prioritize CPU load.

[0083] In memory-sensitive scenarios (such as database cache scenarios), γ can be set to be larger than α and β;

[0084] The values ​​of the weight coefficients α, β, and γ can be determined based on the tenant's business characteristics, historical data analysis, and performance bottleneck identification. For example, if historical data shows that traffic surges are the primary cause of resource shortages, α can be set to a higher value (such as 0.5), while β and γ can be set to lower values ​​(such as 0.25 and 0.25). In some scenarios, the weight coefficients α, β, and γ can be set equal (for example, α = β = γ = 1 / 3) and dynamically adjusted through large AI models or machine learning optimization.

[0085] In this embodiment, the initial values ​​of the weight coefficients α, β, and γ are determined through historical data statistics or expert experience, and the weights can be adjusted in the subsequent use process in combination with the prediction results of the AI ​​large model (such as based on time series analysis) to achieve an adaptive weight optimization process. In actual use, the weight coefficients α, β, and γ can be customized and adjusted in real time according to user needs or actual load characteristics during system operation. This flexibility ensures that the formula is applicable to diverse multi-tenant scenarios to maximize the accuracy of resource allocation.

[0086] After calculating the resource requirement score, make the following judgments:

[0087] When a tenant's resource demand score exceeds the preset expansion threshold and the duration exceeds the preset time, the number of server instances corresponding to the tenant will be increased accordingly;

[0088] When the resource demand score of the tenant does not exceed the preset expansion threshold and the duration exceeds the preset time, the number of server instances corresponding to the tenant is reduced;

[0089] By comparing the duration with the preset time, the abnormal judgment result caused by instantaneous short-time fluctuation can be eliminated.

[0090] The newly added or reduced server instances are quickly deployed and added to the tenant resource pool corresponding to the tenant in the resource management center through containerization technology (such as Docker), and the newly added or reduced server instances are quickly deployed and added to the tenant resource pool corresponding to the tenant by using the containerization technology Docker, which specifically includes the following steps:

[0091] 1) Create a Docker image for the application, and the image content at least includes application code, running environment, dependent library and configuration file;

[0092] 2) Pull the latest image from the image warehouse through the container orchestration tool, start a new container based on the configuration file, and the kubernetes scheduler allocates the new Pod to the node (server) with sufficient resources in the cluster to ensure load balancing.

[0093] According to the relationship between the resource demand score of the tenant and the preset expansion threshold, the number of server instances is increased or decreased, and the resource demand score is calculated by simultaneously considering the real-time changes of traffic, CPU and memory, so that the expansion or contraction of the server can be dynamically adjusted according to the real-time changes of tenant traffic, CPU and memory, to meet the dynamic changes of tenant traffic mode, reduce the possibility of resource waste or performance bottleneck caused by static configuration, and effectively improve the resource utilization and system response ability.

[0094] S300: Extract tenant ID by using ID identification method, match preset priority rules and resource allocation strategies according to tenant ID, and allocate traffic to corresponding server instances according to priority rules and resource allocation strategies; according to the priority rules (for example, the priority rules can be set as: high priority of high-paying tenants) and the resource allocation strategy matched by the preset priority rules and the resource allocation strategy, the traffic is allocated to the corresponding server instance, so as to realize the individualized load balancing of the traffic based on the tenant ID, preferentially process the requests of high-value tenants and high-load tenants, and improve the service quality of high-priority tenants;

[0095] In this step, the ID identification method includes the following steps:

[0096] S301: At the front-end request entry of the system (for example, at the API gateway), the tenant ID is extracted by parsing the custom field (for example, "X-Tenant-ID") in the HTTP request header or the tenant identification in the URL parameter (for example, tenantId in " / api / v1 / tenant / {tenantId}");

[0097] S302: To ensure security, the tenant ID needs to be checked. The tenant ID information can be carried by a JWT (JSON Web Token) token, and the legality of the token is verified by a key at the gateway layer to check the tenant ID, so as to prevent forgery;

[0098] S303: The extracted tenant ID is stored in the request context (Context) and passed to the load balancer;

[0099] S304: The load balancer queries the tenant priority table pre-stored in the in-memory database (for example, Redis) according to the tenant ID in the request context, obtains the tenant priority rule and resource allocation strategy, and thus realizes individualized traffic distribution.

[0100] The tenant priority rule and resource allocation strategy refer to: different server node resources and database computing and storage resources are allocated to tenants according to their different priorities; on this basis, different expansion thresholds can also be set for tenants according to their different priorities. For example, when the high-priority tenants and low-priority tenants are simultaneously expanded, the expansion threshold of the high-priority tenants can be set to a lower value, for example, the expansion is performed when the resource occupancy rate reaches 60%, while the expansion threshold of the low-priority tenants is set to a higher value, for example, the expansion is performed when the resource occupancy rate reaches 80%, so as to ensure that resources are preferentially allocated to high-priority tenants.

[0101] The priority of a tenant can be determined according to at least one or more factors such as payment degree, cooperation record, and data acquisition record. For example, a tenant with more cooperation times and good reputation (i.e., a cooperation record) can be marked as a high-priority tenant, while a tenant that uses a crawler to maliciously grab data (i.e., a data acquisition record) can be marked as a low-priority tenant. Correspondingly, less resources are provided to low-priority tenants, and additional restrictions are imposed on the traffic of low-priority tenants.

[0102] S400: Setting a traffic upper limit for each tenant to control the traffic of the tenant, so as to limit the traffic of a single tenant and avoid abnormal traffic affecting the stability of the overall system;

[0103] In this step,

[0104] Set traffic caps for each tenant based on subscription packages or historical traffic peaks;

[0105] Tenant traffic is controlled through the following judgment process: When a tenant's instantaneous traffic exceeds the preset upper limit, the tenant's traffic is limited or the excess traffic request is discarded, and a prompt message is returned, such as "Service is busy, please try again later." This is the Token Bucket algorithm, which implements traffic control and ensures system stability while limiting the request rate. Its core ideas are as follows:

[0106] Token bucket concept:

[0107] There is a "bucket" with a fixed capacity, into which tokens are added at a fixed rate (e.g., r per second). (This means that there is a preset upper limit on the tenant's instantaneous traffic.) Each request consumes a token to be processed (this means that each tenant's instantaneous traffic needs to be compared with the preset upper limit).

[0108] Its workflow is:

[0109] If there are enough tokens in the bucket, the request is processed immediately after consuming the tokens (that is, the tenant's instantaneous traffic does not exceed the preset upper limit at this time, and no traffic control is performed).

[0110] If there are insufficient tokens in the bucket, the request is rejected or waited (that is, the tenant's instantaneous traffic exceeds the preset upper limit and traffic control is required, such as limiting the flow or discarding the request).

[0111] S500: Distributes write requests to the data master based on tenant IDs, and distributes read requests to multiple data slaves based on load balancing policies. This achieves efficient read-write separation at the database level, optimizes database performance in high-concurrency scenarios, and effectively improves resource utilization.

[0112] In this step,

[0113] For read requests, a weighted round-robin algorithm is used to assign weights based on the load status of the slave storage node. The load status includes at least CPU usage, number of connections, and response latency. For example, if the response latency of slave storage node A is 100ms and the response latency of slave storage node B is 200ms, the weight of slave storage node A is set to 2 and the weight of slave storage node B is set to 1. Read requests are weighted in a 2:1 ratio. A load upper threshold is also set (for example, the number of connections does not exceed 80%). When the load of a slave storage node exceeds the upper threshold, its weight is dynamically reduced and the request is distributed to other nodes.

[0114] For write requests: The primary storage node ensures data consistency through a preset protocol (such as the Paxos protocol) and sends write requests to the corresponding primary storage node partition based on the tenant ID. If the primary storage node load exceeds the preset threshold (for example, the number of primary storage node connections > 90%), the dynamic expansion mechanism is triggered, a new primary storage node is added, and data shards are migrated.

[0115] The specific steps include:

[0116] S501: Use database middleware (such as MySQL Proxy or ShardingSphere) to collect node status in real time and update routing rules to ensure the efficiency and stability of read-write separation;

[0117] S502: Implement read-write separation control in the database, so that the master database only processes write operations and the slave database only processes read operations, and can dynamically add or remove slave databases; implement transparent management of read-write separation through database middleware, and support dynamic addition or removal of slave databases.

[0118] S503: Distribute write requests to the data master database according to the tenant ID, and distribute read requests to multiple data slave databases according to the load balancing strategy.

[0119] S600: Monitors tenants' actual metrics in real time, compares them with preset thresholds, and dynamically adjusts database instances based on the comparison results.

[0120] In this step, the tenant's actual indicators monitored in real time include at least the tenant's database connection number, query response time, and master-slave synchronization delay.

[0121] When a tenant's actual metrics exceed the preset threshold (for example, the number of master database connections exceeds 90% or the slave database latency exceeds 500ms), a new master database instance is added and the tenant's data is migrated through data sharding.

[0122] When the number of slave databases falls below the preset threshold, dynamically increase the number of slave database instances and synchronize data;

[0123] After the adjustment is complete, update the database configuration in the tenant resource pool.

[0124] It will be apparent to those skilled in the art that the application is not limited to the details of the above-exemplified embodiments and that the present application can be implemented in other particular forms without departing from the spirit or essential characteristics of the present application. The embodiments should therefore be considered in all respects as illustrative and not restrictive, the scope of the application being indicated by the appended claims rather than by the above description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. No reference signs in the claims should be considered as limiting the scope of the claims with respect to the figures of the patent document.

Claims

1. A method for dynamic resource allocation and performance optimization of a multi-tenant system, characterized by: The following steps are involved: S100: Initialize the resource management center, record each tenant's service data in real time through the tenant resource pool, monitor tenant traffic data in real time through the traffic monitoring module, and analyze tenant performance through the performance analysis module. At the same time, assign a unique ID to each tenant and initialize its basic resource configuration; S200: Calculating the resource demand score of each tenant in real time, and increasing or decreasing the number of server instances accordingly based on the relationship between the calculated resource demand score of each tenant and a preset expansion threshold; S300: extracting the tenant ID using an ID identification method, matching the preset priority rules and resource allocation policies according to the tenant ID, and allocating traffic to the corresponding server instance according to the priority rules and resource allocation policies; S400: Set a traffic limit for each tenant and control the traffic of the tenant; S500: Distribute write requests to the data master database based on the tenant ID, and distribute read requests to multiple data slave databases based on the load balancing strategy; S600: Monitors tenants' actual metrics in real time, compares them with preset thresholds, and dynamically adjusts database instances based on the comparison results. In step S100, the tenant service data includes at least the resource allocation between the tenant and the server and database instance; the tenant performance analysis includes at least the analysis of the tenant CPU, memory and number of database connections; the basic resource configuration includes at least the number of server instances and database connection pool parameters; In step S200, the resource demand score of each tenant is calculated according to the following formula: Z = α × L + β × C + γ × N in, Z is the resource demand score of each tenant; L is the flow rate growth rate; C is the CPU usage; N is the memory usage; α, β, and γ are the weight coefficients corresponding to the traffic growth rate, CPU usage, and memory usage, respectively.

2. A multi-tenant system dynamic resource allocation and performance optimization method according to claim 1, characterized in that: In the step S200, When a tenant's resource demand score exceeds the preset expansion threshold and the duration exceeds the preset time, the number of server instances corresponding to the tenant will be increased accordingly; When a tenant's resource demand score does not exceed the preset expansion threshold and the duration exceeds the preset time, the number of server instances corresponding to the tenant will be reduced accordingly; New or reduced server instances are quickly deployed through containerization technology and added to the tenant resource pool corresponding to the tenant within the resource management center.

3. A multi-tenant system dynamic resource allocation and performance optimization method according to claim 1, characterized in that: In step S300, the ID identification method includes the following steps: S301: At the front-end request entry of the system, the tenant ID is extracted by parsing the custom field in the HTTP request header or the tenant identifier in the URL parameter; S302: Use the JWT token to carry the tenant ID information, and verify the legitimacy of the token using the key at the gateway layer to verify the tenant ID; S303: Store the extracted tenant ID in the request context and pass it to the load balancer; S304: The load balancer queries the tenant priority table pre-stored in the memory database according to the tenant ID in the request context, and obtains the tenant's priority rule and resource allocation strategy.

4. A multi-tenant system dynamic resource allocation and performance optimization method according to claim 1, characterized in that: In step S400: Set traffic caps for each tenant based on subscription packages or historical traffic peaks; The tenant's traffic is controlled through the following judgment process: when the tenant's instantaneous traffic exceeds the preset upper limit, the tenant's traffic is limited or the tenant's traffic request exceeding the upper limit is discarded, and a prompt message is returned.

5. The method for dynamic resource allocation and performance optimization of a multi-tenant system according to claim 1, characterized in that: The step S500 includes the following steps: S501: Collect node status in real time and update routing rules; S502: Implement read-write separation control in the database, so that the master database only processes write operations and the slave database only processes read operations, and can dynamically add or remove slave databases; S503: Distribute write requests to the data master database according to the tenant ID, and distribute read requests to multiple data slave databases according to the load balancing strategy.

6. A multi-tenant system dynamic resource allocation and performance optimization method according to claim 1, characterized in that: In the step S500, For read requests: weights are assigned based on the load status of the slave storage node, which includes at least CPU usage, number of connections, and response latency. A load upper threshold is also set. When the load of a slave storage node exceeds the upper threshold, its weight is dynamically reduced and the request is distributed to other nodes. For write requests: The primary storage node ensures data consistency through a preset protocol and sends write requests to the corresponding primary storage node partition based on the tenant ID. If the primary storage node load exceeds the preset threshold, the dynamic expansion mechanism is triggered, a new primary storage node is added, and data shards are migrated.

7. A multi-tenant system dynamic resource allocation and performance optimization method according to claim 1, characterized in that: In step S600, the tenant's actual indicators monitored in real time include at least the tenant's database connection number, query response time, and master-slave synchronization delay.

8. The method for dynamic resource allocation and performance optimization of a multi-tenant system according to claim 1, characterized in that: In the step S600, When a tenant's actual metrics exceed the preset threshold, a new master database instance is added and the tenant's data is migrated through data sharding. When the number of slave databases falls below the preset threshold, dynamically increase the number of slave database instances and synchronize data; After the adjustment is complete, update the database configuration in the tenant resource pool.

Images