A method, device, equipment and medium for ensuring business continuity of a cloud resource pool

Abstract

The present disclosure provides a method, device, equipment and medium for ensuring business continuity of cloud resource pool, which comprises: at the hardware layer, multiple physical hard disks are grouped into multiple RAID groups and integrated to form a unified storage pool, and a logical volume is created based on the unified storage pool to perform secondary striping processing; and multiple physical network devices are virtualized into a single logical unit by using network device cluster technology, and the business traffic is automatically switched when the physical network device fails; at the system software layer, database instances are deployed in at least two data centers and a synchronous replication cluster supporting multiple master writes is established; and a scheduling module based on intelligent load balancing algorithm is configured, and the newly arrived business request is distributed to the service instance with the shortest current response time in real time based on the scheduling module. According to the embodiment of the present disclosure, the running stability and business continuity of the cloud resource pool under the conditions of high load, hardware failure and network anomaly can be systematically enhanced.

Description

Technical Field

[0001] This disclosure relates to the field of cloud computing resource management technology, and in particular to a method, apparatus, equipment and medium for ensuring business continuity of cloud resource pools. Background Technology

[0002] With the deepening of digital transformation, cloud resource pools have become a crucial infrastructure for supporting core business operations. To ensure business continuity, existing technologies typically employ independent optimization measures at the hardware, system software, and application software levels.

[0003] At the hardware level, common solutions include building storage systems using single-level striping technology and networking using stacked or cascaded network devices. At the system software level, database master-slave hot standby or periodic cold standby solutions are typically used, with hardware load balancers or simple round-robin strategies for traffic distribution. At the application software level, common practices include optimizing parts of the SQL (Structured Query Language) statements or introducing caching.

[0004] While existing methods for ensuring business continuity in cloud resource pools can solve some problems at each individual level, the lack of cross-layer collaborative design between the hardware layer, system software layer, and application software layer results in insufficient overall system performance and fault response capabilities when dealing with large-scale, high-concurrency scenarios, making it difficult to effectively guarantee business continuity. Summary of the Invention

[0005] This disclosure provides a method, apparatus, device, and medium for ensuring the business continuity of cloud resource pools, which solves the problem that existing methods for ensuring the business continuity of cloud resource pools typically employ independent optimization measures at the hardware, system software, and application software levels, resulting in insufficient overall system performance and fault response capabilities when dealing with large-scale, high-concurrency scenarios, making it difficult to effectively ensure business continuity.

[0006] Firstly, this disclosure provides a method for ensuring service continuity in a cloud resource pool, the method comprising:

[0007] At the hardware layer, multiple physical hard drives are assembled into multiple independent disk redundant array (RAID) groups and integrated into a unified storage pool. Logical volumes are created based on the unified storage pool to perform secondary striping processing. Additionally, network device clustering technology is used to virtualize multiple physical network devices into a single logical unit and automatically switch service traffic when physical network devices fail.

[0008] At the system software layer, database instances are deployed in at least two data centers and a synchronous replication cluster supporting multi-master writes is formed, so that multiple database instances in the synchronous replication cluster can process write operations simultaneously, and other instances can take over the business when a database instance fails; and a scheduling module based on an intelligent load balancing algorithm is configured to distribute newly arrived business requests to the service instance with the shortest current response time in real time based on the scheduling module.

[0009] At the application software layer, deep learning models are used to predict the collected user behavior data, and the data corresponding to the prediction results are cached. In addition, a thread pool is created to asynchronously and concurrently process user requests, and nested subqueries are reconstructed and views are encapsulated for inefficient structured query language (SQL) queries.

[0010] Furthermore, the step of assembling multiple physical hard drives into multiple independent redundant disk arrays (RAID) groups and integrating them into a unified storage pool, and creating logical volumes based on the unified storage pool to perform secondary striping processing, specifically includes:

[0011] Multiple physical hard drives can be configured into multiple RAID groups using a RAID card;

[0012] Consolidate multiple RAID groups into a unified storage pool;

[0013] Based on the unified storage pool, logical volumes are created using preset LVM commands. When creating a logical volume, the LVM commands specify the number of stripes as N and the stripe block size as MKB, so that the data corresponding to the I / O request is divided into data blocks of size MKB when it is written, and is written to N underlying RAID groups in a round-robin fashion for parallel processing, where N is an integer greater than 2.

[0014] Furthermore, the adoption of network device clustering technology to virtualize multiple physical network devices into a single logical unit and automatically switch service traffic when physical network devices fail specifically includes:

[0015] Select one physical network device from multiple physical network devices as the command device;

[0016] Configure the remaining physical network devices (excluding the command device) as node devices and initiate registration with the command device.

[0017] The command device runs a cluster management protocol to collect the topology and status information of all registered node devices, forming a unified control plane.

[0018] When any node device failure is detected, the forwarding table entry is updated in the control plane to switch service traffic to the normal node device.

[0019] Furthermore, the step of deploying database instances in at least two data centers and forming a synchronous replication cluster supporting multi-master writes, enabling multiple database instances in the synchronous replication cluster to process write operations simultaneously, and allowing other instances to take over the service in the event of a database instance failure, specifically includes:

[0020] Deploy database instances in at least two data centers;

[0021] Configure group replication parameters for database instances so that they can discover each other and form a synchronous replication cluster that supports multi-master writes;

[0022] At the application layer, read / write splitting rules are configured through database middleware to distribute write requests to database instances in different data centers according to a set ratio, thereby achieving load balancing of write operations.

[0023] When any database instance in the synchronous replication cluster fails, the remaining normal database instances directly take over the service.

[0024] Furthermore, the configuration includes a scheduling module based on an intelligent load balancing algorithm. This scheduling module distributes newly arriving service requests in real time to the service instance with the shortest current response time, specifically including:

[0025] Configure a scheduling module based on an intelligent load balancing algorithm in the load balancer;

[0026] The scheduling module continuously monitors the average response time of each upstream service instance to historical requests.

[0027] When a new business request arrives, the scheduling module is used to query the average response time of each upstream service instance and distribute the new business request to the service instance with the shortest average response time.

[0028] Furthermore, the step of using a deep learning model to predict the collected user behavior data and caching the data corresponding to the prediction results specifically includes:

[0029] Collect user attribute information and behavioral event data to generate user-service interaction feature vectors;

[0030] The user-service interaction feature vector is input into the deep learning model, and the predicted rating of the user for each function item is output.

[0031] Select the top L functional items with the highest predicted scores, asynchronously trigger the corresponding data query operation in the background, and store the query result set in the remote dictionary service Redis cache, where L is a positive integer.

[0032] Furthermore, the asynchronous concurrent processing of user requests by creating a thread pool specifically includes:

[0033] A thread pool is created using the ThreadPoolExecutor class, which is configured with a core number of threads, a maximum number of threads, a thread idle lifespan, and a bounded work queue.

[0034] The user request is encapsulated as a task object and submitted to the thread pool, and the corresponding task is executed asynchronously using the idle threads in the thread pool.

[0035] Furthermore, the process of reconstructing nested subqueries and encapsulating views on the identified inefficient Structured Query Language (SQL) queries specifically includes:

[0036] SQL statements whose execution time exceeds a preset duration or whose resource consumption exceeds a preset threshold are identified by database performance analysis tools and are classified as inefficient SQL statements.

[0037] The nested subqueries in the inefficient SQL statements are refactored into JOIN join queries to optimize the query.

[0038] For complex queries involving multiple table joins after optimization, they are encapsulated as database views for application layer calls.

[0039] Secondly, this disclosure provides an apparatus for ensuring service continuity of a cloud resource pool, the apparatus comprising:

[0040] The hardware layer optimization module is used to, at the hardware layer, assemble multiple physical hard drives into multiple independent disk redundant array (RAID) groups and integrate them into a unified storage pool, create logical volumes based on the unified storage pool to perform secondary striping processing; and, adopt network device clustering technology to virtualize multiple physical network devices into a single logical unit, and automatically switch service traffic when physical network devices fail.

[0041] The system software layer optimization module, connected to the hardware layer optimization module, is used to deploy database instances in at least two data centers and build a synchronous replication cluster that supports multi-master writes at the system software layer, so that multiple database instances in the synchronous replication cluster can process write operations simultaneously, and other instances can take over the business when a database instance fails; and to configure a scheduling module based on an intelligent load balancing algorithm, which distributes newly arrived business requests to the service instance with the shortest current response time in real time.

[0042] The application software layer optimization module, connected to the system software layer optimization module, is used to predict the collected user behavior data using a deep learning model at the application software layer, cache the data corresponding to the prediction results, and perform asynchronous concurrent processing of user requests by creating a thread pool, and perform nested subquery reconstruction and view encapsulation on the identified inefficient structured query language (SQL) queries.

[0043] Thirdly, this disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, and the one or more computer programs are executed by the at least one processor to enable the at least one processor to perform the method for ensuring the business continuity of a cloud resource pool as described in the first aspect.

[0044] Fourthly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method for ensuring the business continuity of a cloud resource pool as described in the first aspect.

[0045] The methods, apparatus, devices, and media provided in this disclosure for ensuring the business continuity of cloud resource pools, through deep collaboration between the hardware layer, system software layer, and application software layer, rely on the secondary striping processing and network device clustering capabilities of the hardware layer, the multi-master synchronous replication database dual-active architecture and response time-based intelligent load balancing scheduling of the system software layer, and the user behavior prediction caching, thread pool asynchronous concurrent processing, and inefficient SQL query optimization of the application software layer. These features can significantly improve the parallel processing capability of storage I / O in large-scale, high-concurrency scenarios, enabling rapid automatic failover of physical network devices and database instances. Simultaneously, write operations are evenly distributed across multiple database instances, user requests are dynamically scheduled to the fastest-responding service instance, and hot data access latency is reduced to sub-millisecond levels through pre-loading caching. Combined with thread pool reuse and inefficient SQL query optimization, this further improves system throughput and resource utilization, thereby systematically enhancing the operational stability and business continuity of cloud resource pools under high load, hardware failure, and network anomaly conditions. The existing methods for ensuring business continuity in cloud resource pools typically employ independent optimization measures at the hardware, system software, and application software levels. This results in insufficient overall system performance and fault response capabilities when dealing with large-scale, high-concurrency scenarios, making it difficult to effectively guarantee business continuity. Attached Figure Description

[0046] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings:

[0047] Figure 1 A flowchart illustrating a method for ensuring service continuity in a cloud resource pool, as provided in this embodiment of the disclosure;

[0048] Figure 2 An architecture diagram of a cloud resource pool service continuity assurance system provided in this embodiment of the disclosure;

[0049] Figure 3 A schematic diagram comparing the IOPS performance of secondary striping and traditional solutions provided in this embodiment of the disclosure;

[0050] Figure 4 This is a schematic diagram of the network cluster construction process provided in the embodiments of this disclosure;

[0051] Figure 5 This is a schematic diagram of the dual-active database configuration process provided in this embodiment of the disclosure;

[0052] Figure 6 This is a schematic diagram of a database active-active architecture deployment provided in an embodiment of this disclosure;

[0053] Figure 7 This is a schematic diagram of the deep learning model structure provided in the embodiments of this disclosure;

[0054] Figure 8 This is a schematic diagram comparing page opening times provided in an embodiment of the present disclosure;

[0055] Figure 9 A block diagram of an apparatus for ensuring service continuity of a cloud resource pool, provided in an embodiment of this disclosure;

[0056] Figure 10 This is a block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0057] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0058] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0059] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0060] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0061] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0062] Figure 1 A flowchart illustrating a method for ensuring service continuity in a cloud resource pool, as provided in this embodiment of the disclosure. (Refer to...) Figure 1 The method includes:

[0063] Step S101: At the hardware layer, multiple physical hard drives are grouped into multiple RAID (Redundant Array of Independent Disks) groups and integrated into a unified storage pool. Logical volumes are created based on the unified storage pool to perform secondary striping processing. Additionally, network device clustering technology is used to virtualize multiple physical network devices into a single logical unit and automatically switch service traffic when physical network devices fail.

[0064] Specifically, the hardware layer, as the foundational support layer of the cloud resource pool, aims to improve data I / O processing efficiency and network device availability. The secondary striping process breaks through the performance bottleneck of traditional single-level striping, enabling parallel distribution of data I / O requests. The network device clustering technology eliminates single points of failure in physical network devices, achieving seamless switching during failures through virtualization integration. Together, they ensure the stable and efficient operation of the hardware layer. The secondary striping process refers to further distributing data across multiple underlying RAID groups in smaller blocks using the striping function of the Logical Volume Manager (LVM) after the basic storage units are constructed using hardware RAID groups. This allows the data corresponding to a single I / O request to be divided into multiple data blocks, which are written in parallel to different RAID groups, thus achieving a balanced distribution of I / O load across multiple storage units. Compared to solutions relying solely on single-level RAID striping, secondary striping effectively eliminates local performance bottlenecks caused by sequential writes or concentrated hot data, significantly improving the aggregate throughput of the entire storage system. The network device clustering technology refers to the technology of logically merging multiple independent physical network devices (such as switches) into a single virtual device through a dedicated cluster management protocol (such as Huawei Stack protocol or H3C IRF protocol).

[0065] In some embodiments, the step of assembling multiple physical hard drives into multiple independent redundant disk arrays (RAID) groups and integrating them into a unified storage pool, and creating logical volumes based on the unified storage pool to perform secondary striping processing, specifically includes:

[0066] Multiple physical hard drives can be configured into multiple RAID groups using a RAID card;

[0067] Consolidate multiple RAID groups into a unified storage pool;

[0068] Based on the unified storage pool, logical volumes are created using preset LVM commands. When creating a logical volume, the LVM commands specify the number of stripes as N and the stripe block size as MKB, so that the data corresponding to the I / O request is divided into data blocks of size MKB when it is written, and is written to N underlying RAID groups in a round-robin fashion for parallel processing, where N is an integer greater than 2.

[0069] Specifically, firstly, based on the performance, capacity, and reliability requirements of the physical hard drives, multiple physical hard drives are grouped into multiple independent RAID groups using a RAID card. Each RAID group can contain the same number of physical hard drives (e.g., 8 physical hard drives forming one RAID group). Then, LVM commands are used to initialize the multiple RAID groups into physical volumes, and the physical volumes are then integrated into a volume group to form a unified storage pool, enabling centralized management of storage resources. When creating logical volumes based on this unified storage pool, the number of stripes N and the stripe block size M specified by LVM commands can be adjusted according to the I / O characteristics of the actual business (e.g., M can be 64, 128, etc., and N can be 3, 4, 5, etc., integers greater than 2). By dividing the data into fixed-size data blocks and writing them to multiple RAID groups in a round-robin fashion, it is ensured that each RAID group can participate in data processing, achieving parallel distribution of I / O requests.

[0070] In some embodiments, the use of network device clustering technology to virtualize multiple physical network devices into a single logical unit and automatically switch service traffic when a physical network device fails specifically includes:

[0071] Select one physical network device from multiple physical network devices as the command device;

[0072] Configure the remaining physical network devices (excluding the command device) as node devices and initiate registration with the command device.

[0073] The command device runs a cluster management protocol to collect the topology and status information of all registered node devices, forming a unified control plane.

[0074] When any node device failure is detected, the forwarding table entry is updated in the control plane to switch service traffic to the normal node device.

[0075] Specifically, a core switch can be selected as the cluster command device. The stacked physical member ports are configured via CLI (Command Line Interface), along with the cluster identifier and device priority, completing the initial configuration of the command device. The remaining member switches similarly complete their physical port configurations, enable the cluster function, and register with the command device as node devices via the stacking cables. The command device runs the cluster management protocol, using private heartbeat messages to synchronize and collect the topology information and operating status of all registered node devices in real time, thus forming a unified cluster control plane. The entire network device cluster is virtualized as a logical whole with a single management address. When the heartbeat mechanism detects a fault in a node device (e.g., with a heartbeat timeout set to 100–200ms), the cluster can promptly update the forwarding table entries in the control plane, rerouting service traffic to normally functioning node devices within milliseconds, achieving seamless switching of network services.

[0076] Step S102: At the system software layer, deploy database instances in at least two data centers and form a synchronous replication cluster that supports multi-master writes, so that multiple database instances in the synchronous replication cluster can process write operations simultaneously, and other instances can take over the business when a database instance fails; and configure a scheduling module based on an intelligent load balancing algorithm, so that newly arrived business requests are distributed in real time to the service instance with the shortest current response time based on the scheduling module.

[0077] Specifically, the multi-master synchronous replication database cluster refers to organizing database instances deployed in different data centers or multiple nodes into a peer-to-peer cluster through the database's own group replication protocol. Each instance can independently handle write operations, and the consistency of data across all instances within the cluster is ensured through a synchronous replication mechanism. When any instance in the cluster fails, other normal instances, having synchronized the latest data and remaining active, can continue to provide services without a failover operation, thus achieving rapid fault takeover at the database level. The intelligent load balancing algorithm refers to the load balancer dynamically allocating each new business request to the service instance with the shortest current response time based on the real-time response time of the backend service instances, avoiding the accumulation of business requests on service instances with degraded processing performance, thereby effectively optimizing the overall response efficiency of business requests.

[0078] In some embodiments, the step of deploying database instances in at least two data centers and forming a synchronous replication cluster supporting multi-master writes, enabling multiple database instances in the synchronous replication cluster to process write operations simultaneously, and allowing other instances to take over the service when a database instance fails, specifically includes:

[0079] Deploy database instances in at least two data centers;

[0080] Configure group replication parameters for database instances so that they can discover each other and form a synchronous replication cluster that supports multi-master writes;

[0081] At the application layer, read / write splitting rules are configured through database middleware to distribute write requests to database instances in different data centers according to a set ratio, thereby achieving load balancing of write operations.

[0082] When any database instance in the synchronous replication cluster fails, the remaining normal database instances directly take over the service.

[0083] Specifically, the group replication parameters include, but are not limited to, enabling the global transaction identifier, loading the group replication plugin, configuring the cluster member address list, and configuring the node's own communication address. For example, for a MySQL database, you can configure gtid_mode=ON, enforce_gtid_consistency=ON, and plugin_load_add='group_replication.so', specifying the node's local communication address and the cluster seed address list respectively, and then create a cluster through a bootstrap command or have the node automatically join an existing cluster. When configuring read / write separation rules at the application layer, database middleware (such as ShardingSphere or MyCat) can be used to distribute write requests to database instances in different data centers according to a preset ratio (e.g., 60% to the primary data center and 40% to the backup data center), thereby achieving load balancing in multi-master write scenarios. Simultaneously, when a database instance in any data center in the cluster fails, an instance in another data center, being already active and with real-time data synchronization, can immediately take over all services, achieving second-level or even instantaneous fault recovery of the database service.

[0084] In some embodiments, the configuration is based on a scheduling module using an intelligent load balancing algorithm. This scheduling module distributes newly arriving service requests in real time to the service instance with the shortest current response time, specifically including:

[0085] Configure a scheduling module based on an intelligent load balancing algorithm in the load balancer;

[0086] The scheduling module continuously monitors the average response time of each upstream service instance to historical requests.

[0087] When a new business request arrives, the scheduling module is used to query the average response time of each upstream service instance and distribute the new business request to the service instance with the shortest average response time.

[0088] Specifically, the scheduling module based on the intelligent load balancing algorithm can be compiled or integrated into load balancing software, such as the nginx-upstream-fair module of Nginx. This module maintains statistical values ​​based on historical request response times for each upstream service instance. When a new business request arrives, the scheduling module queries the average response time of each upstream service instance and selects the service instance with the smallest average response time as the target node for request distribution. Compared with static scheduling strategies such as round-robin and fixed weight, this scheduling method can dynamically adapt to fluctuations in the operating performance of service instances and continuously schedule new business requests to the service instance with the best processing efficiency.

[0089] Step S103: At the application software layer, a deep learning model is used to predict the collected user behavior data, and the data corresponding to the prediction results is cached; and a thread pool is created to perform asynchronous concurrent processing of user requests, and nested subqueries are reconstructed and views are encapsulated for the identified inefficient structured query language (SQL) queries.

[0090] Specifically, deep learning models are used to learn latent patterns in users' historical behavior data, thereby inferring the functions users are most likely to access in the future. Based on the prediction results, relevant data is pre-queried from persistent storage and loaded into a memory-level cache. This allows the application to quickly return data directly from the cache when a user actually makes a request, reducing response latency from tens to hundreds of milliseconds for database queries to sub-millisecond levels for memory reads and writes. The thread pool technology refers to pre-creating a certain number of persistent working threads, encapsulating user requests as independent tasks, and submitting them to a task queue. Idle threads in the thread pool are automatically scheduled for execution, and the main thread can return without waiting for the task to complete, thereby improving the system's concurrency processing capabilities and resource utilization efficiency. The optimization of inefficient SQL queries involves analyzing the database execution plan, identifying inefficient SQL statements with high execution costs and long execution times, and using query rewriting to convert the original inefficient statements into logically equivalent and more efficient SQL forms.

[0091] It should be noted that the steps of the hardware layer, system software layer and application software layer work together to form a bottom-up positive support link and a top-down reverse optimization link.

[0092] In some embodiments, the step of using a deep learning model to predict collected user behavior data and caching the data corresponding to the prediction results specifically includes:

[0093] Collect user attribute information and behavioral event data to generate user-service interaction feature vectors;

[0094] The user-service interaction feature vector is input into the deep learning model, and the predicted rating of the user for each function item is output.

[0095] Select the top L functional items with the highest predicted scores, asynchronously trigger the corresponding data query operation in the background, and store the query result set in the Redis (Remote Dictionary Server) cache, where L is a positive integer.

[0096] Specifically, user attribute information may include static features such as region and age, while behavioral event data may include dynamic events such as clicks, page views, and dwell time. After cleaning and aggregation, the collected raw data generates a fixed-dimensional feature vector (e.g., 256-dimensional) to represent the interaction pattern between the user and the service. The deep learning model can be built on, for example, the PyTorch framework. Its network structure may include fully connected layers, one-dimensional convolutional layers, batch normalization layers, and non-linear activation functions (e.g., Mish). Training enables the model to output a predicted score for each functional item. During training, the Adam optimizer can be used, and an orthogonal trial-and-error method can be used to select appropriate hyperparameter combinations (such as the number of hidden layer neurons, learning rate, and batch size). Model performance is evaluated using metrics such as hit rate (HR@10). During prediction, the top L functional items with the highest scores are selected (L can be determined by actual business needs, such as 3 or 5). A background thread asynchronously executes the data query operations corresponding to these functions, stores the query result set in a Redis cache, and sets a reasonable expiration time. When users subsequently access these functions, the application prioritizes retrieving data from Redis. If the cache is hit, the data can be returned directly, thereby reducing the response latency from tens to hundreds of milliseconds (database queries) to sub-millisecond levels (memory reads).

[0097] In some embodiments, the asynchronous concurrent processing of user requests by creating a thread pool specifically includes:

[0098] A thread pool is created using the ThreadPoolExecutor class, which is configured with a core number of threads, a maximum number of threads, a thread idle lifespan, and a bounded work queue.

[0099] The user request is encapsulated as a task object and submitted to the thread pool, and the corresponding task is executed asynchronously using the idle threads in the thread pool.

[0100] Specifically, the ThreadPoolExecutor class is a standard thread pool implementation class provided by the java.util.concurrent package in Java. The core thread count determines the basic number of threads the thread pool maintains long-term; these threads will not be reclaimed even if they are idle. The maximum thread count limits the scalable thread limit of the thread pool when handling high-concurrency tasks. The thread idle lifespan specifies the maximum time an idle thread exceeding the core thread count can wait for a new task before being reclaimed. The bounded work queue is used to temporarily store user request tasks awaiting execution. By properly configuring the above parameters (e.g., a core thread count of 10, a maximum thread count of 50, an idle lifespan of 60 seconds, and a queue capacity of 100), resources can be saved when the system load is low, and threads can be dynamically expanded to improve concurrent processing capabilities during peak load periods. After encapsulating each user request as a task object implementing the Runnable or Callable interface, the submit or execute method is called to submit the task to the thread pool. The thread pool automatically allocates an idle thread to execute the task's run() method. The main thread returns immediately after submitting the task, thus achieving asynchronous concurrent processing of user requests.

[0101] In some embodiments, the step of performing nested subquery reconstruction and view encapsulation on the identified inefficient Structured Query Language (SQL) queries specifically includes:

[0102] SQL statements whose execution time exceeds a preset duration or whose resource consumption exceeds a preset threshold are identified by database performance analysis tools and are classified as inefficient SQL statements.

[0103] The nested subqueries in the inefficient SQL statements are refactored into JOIN join queries to optimize the query.

[0104] For complex queries involving multiple table joins after optimization, they are encapsulated as database views for application layer calls.

[0105] Specifically, database performance analysis tools such as MySQL's EXPLAIN command or SQL Server's Profiler can be used to scan and collect SQL statements that have long execution times or high resource consumption. For identified nested queries containing correlated subqueries or using IN or EXISTS operators, they can be rewritten into corresponding join queries based on query semantics. For example, if the original query needs to return the intersection of the main query and the subquery, the subquery can be rewritten as INNER JOIN; if the original query needs to return data that exists in the left table but not in the right table (logically equivalent to NOT EXISTS), the subquery can be rewritten as LEFT JOIN with a condition that the primary key of the right table is null added to the WHERE clause. This query rewriting method allows the database optimizer to execute queries using indexes and more efficient join algorithms, avoiding the performance loss caused by executing subqueries row by row. For complex queries that still involve multi-table joins after refactoring and are frequently called by the application layer, the CREATE VIEW statement can be used to encapsulate them into a database view. The application layer only needs to execute a simple single-table query (such as SELECT * FROM view_name) to obtain the results of complex join queries, which simplifies the application code, avoids repeatedly writing lengthy join statements, and improves the maintainability and reusability of the code.

[0106] It should be noted that the method for ensuring the business continuity of cloud resource pools provided in this disclosure can systematically improve the business continuity of cloud resource pools in high-concurrency, hardware failure and network anomaly scenarios by coordinating and optimizing three layers: hardware infrastructure, system software platform and application software services. Specifically, it is reflected in the optimization effects on I / O performance, fault recovery speed, resource utilization efficiency and request response latency.

[0107] In one specific embodiment, the method for ensuring service continuity of cloud resource pools can be based on Figure 2 The architecture diagram of the cloud resource pool business continuity assurance system shown is used to implement this, as follows: Figure 2 As shown, this cloud resource pool business continuity assurance system is based on multi-layered collaborative optimization, comprising three layers: hardware, system software, and application software. The hardware layer includes a storage optimization module implemented through secondary striping and a network disaster recovery module implemented through clustered deployment. The system software layer includes a database high availability module implemented through dual-active architecture backup and an intelligent load balancing module implemented through response time strategies. The application software layer includes a user behavior prediction module implemented through deep learning models and an application optimization module implemented through multi-threaded asynchronous processing and SQL join query optimization. Its specific implementation includes the following steps:

[0108] S1: Hardware Layer Implementation

[0109] S1.1: Storage System Optimization

[0110] This step is performed through the storage optimization module, and the specific process is as follows:

[0111] (1) Physical volume creation: Using 80 physical hard drives with SAS interfaces, 8 hard drives are used to form a RAID 10 group through a hardware RAID card, resulting in a total of 10 RAID groups. In the Linux operating system, the command pvcreate / dev / sd[bk] (assuming the device names corresponding to the RAID groups are sdb to sdk) is used to initialize these 10 RAID groups into 10 physical volumes.

[0112] (2) Volume group creation: Use the command vgcreate vg_cloud / dev / sd[bk] to integrate the above 10 PVs into a volume group named vg_cloud to form a unified storage pool.

[0113] (3) Logical volume and secondary striping creation: Use the command lvcreate -i 4 -I 64k -L 10T -n lv_datavg_cloud to create a logical volume.

[0114] -i 4: Explicitly specifies the number of stripes as 4, meaning the data will be distributed across 4 different PVs.

[0115] -I 64k: Explicitly specifies the stripe block size as 64KB.

[0116] This command is the core of "secondary striping". It makes any data written to lv_data split into 64KB blocks and written to the four underlying RAID groups in a round-robin fashion, thereby achieving I / O load balancing across RAID groups.

[0117] (4) File system creation and mounting: Use the command mkfs.xfs / dev / vg_cloud / lv_data to create an XFS file system on the LV, and mount it to the business directory using the mount command.

[0118] Testing with the Orion tool verified that the IOPS performance of this solution is significantly improved compared to traditional single-level striping. Figure 3 The diagram illustrates a performance comparison of IOPS between secondary striping and a traditional approach. The test environment uses 80 hard drives, arranged in RAID 10 groups of 8 drives each, for a total of 10 RAID groups. Figure 3It can be seen that the IOPS performance of the double-striping scheme is significantly better than that of the traditional single-striping scheme. In the 12-thread 8k random read test, the single-striping scheme shows a clear performance degradation trend. The first disk group maintains high IOPS performance, but as the disk group number increases, the IOPS value drops sharply, and the performance of the later disk groups is almost zero. In contrast, the double-striping scheme has a more even distribution of IOPS performance across all disk groups, and all disk groups maintain a stable high performance state with no performance bottlenecks. In the 12-thread 8k random write test, the single-striping scheme also shows a serious performance imbalance problem. The performance of the first disk group is acceptable, but the performance of the later disk groups deteriorates significantly. The double-striping scheme achieves a more even distribution of write performance across all disk groups, and each disk group maintains a high IOPS value.

[0119] S1.2: Network System Optimization

[0120] This step is performed through the network disaster recovery module. Clustering technology is used to build multiple network devices into a unified logical unit. A schematic diagram of the specific network cluster construction process is shown below. Figure 4 As shown, first, a network device is selected as the manager. Then, other devices can initiate node registration with the manager. After registration, the cluster status information is updated, the configuration file is loaded, and the node device is started. The system will continuously check if there are any new nodes that need to join the cluster. If so, the above steps are also executed. Detailed explanation is as follows:

[0121] (1) Command device election and configuration: Select a core switch as the cluster command device. Configure the physical member ports of the stack by entering commands such as interface stack-port 1 / 1 and port member-group interface ten-gigabitethernet 1 / 0 / 1 through the CLI command line. Then execute stack-related commands to set the cluster ID and priority, making it the command device.

[0122] (2) Node device registration: On other member switches, perform similar physical port configuration and execute the stack enable command to enable it to register with the command device as a node device through the stack cable.

[0123] (3) Cluster management and status synchronization: Command devices run cluster management protocols (such as Huawei's Stack or H3C's IRF) to collect topology and status information of all node devices in real time through private heartbeat messages, forming a unified control plane.

[0124] (4) Service traffic takeover: The cluster is virtualized into a single IP address management unit. When the heartbeat detects a node failure (the timeout is usually set to 100-200ms), the cluster protocol will immediately update the forwarding table entries at the control plane, and reroute the service traffic to the normal node device within milliseconds, achieving seamless switching.

[0125] S2: System Software Layer Implementation

[0126] S2.1: High Availability of Database

[0127] This step is performed using the database high availability module. Taking MySQL as an example, its Group Replication plugin is used to build a dual-active cluster. A diagram illustrating the specific dual-active database configuration process is shown below. Figure 5 As shown: First, confirm the logical and physical network topology. Then, verify whether the IP address planning meets the network plane requirements. If not, return to modify the physical network topology until the conditions are met. Next, check whether the data center network plane requirements meet the dual-active synchronization conditions. If not, return to modify the physical network topology again. After verification, the system performs automatic key addition, user synchronization, and enables the BinLog logging function. Finally, configure replication tasks, including one-way replication and reverse replication, to achieve real-time data synchronization and business load sharing between the two data centers. Detailed explanation is as follows:

[0128] (1) Instance Configuration: Deploy MySQL 8.0 instances on servers in two different data centers. Modify the my.cnf configuration file for each instance. Key parameters are shown in the following example:

[0129] # Configuration of Data Center A Instance

[0130] server_id=1

[0131] gtid_mode=ON

[0132] enforce_gtid_consistency=ON

[0133] binlog_checksum=NONE

[0134] plugin_load_add='group_replication.so'

[0135] group_replication_start_on_boot=ON

[0136] group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"

[0137] group_replication_local_address="Internal IP address of data center node A: 33061"

[0138] group_replication_group_seeds = "Internal IP address of data center node A: 33061, Internal IP address of data center node B: 33061"

[0139] (2) Cluster Bootstrapping and Joining: On the instance in data center A, after executing `SET GLOBAL group_replication_bootstrap_group=ON`, execute `START GROUP_REPLICATION` to bootstrap the cluster creation. On the instance in data center B, directly execute `START GROUP_REPLICATION`; it will automatically discover and join the cluster through the configured `group_replication_group_seeds`. Through group replication, a database cluster supporting multiple master nodes is formed. The database active-active architecture deployment diagram is shown below. Figure 6 As shown, in the data synchronization mechanism of the dual-active database architecture, the business data center and the off-site backup center maintain data consistency through bidirectional data synchronization. Specifically, the business data center captures business change data in the central database through log parsing and writes the changes to the off-site backup database using SQL. Simultaneously, the off-site backup center captures business change data in the backup database using the same log parsing method and writes it to the business data center using SQL. Furthermore, the system uses the Beedup component to capture data changes in the master and slave databases in real time, distributing synchronized data to the target database and maintaining foreign key values ​​in the foreign key tables. This ensures that the data in the two data centers maintains real-time synchronization and reference integrity, forming a complete bidirectional data synchronization loop.

[0140] (3) Read / write splitting and load balancing: In the database connection configuration at the application layer, middleware such as ShardingSphere or MyCat is used to configure read / write splitting rules. For example, 60% of write request SQL is sent to the database instance in the primary data center and 40% of write request SQL is sent to the database instance in the backup data center to achieve load balancing of write operations.

[0141] S2.2: Intelligent Load Balancing

[0142] This step is executed through the intelligent load balancing module, and its specific technical implementation is as follows:

[0143] (1) Software compilation and installation: Download the Nginx source code from the official source and obtain the source code of the third-party nginx-upstream-fair module. Use the command . / configure --add-module= / path / to / nginx-upstream-fair to compile the fair scheduling module into Nginx, and then perform make && make install.

[0144] (2) Key configuration: In the nginx.conf configuration file of Nginx, define the upstream server group and enable the fair scheduling algorithm. The configuration example is as follows:

[0145] http {

[0146] upstream backend_servers {

[0147] fair; # Enable fair scheduling algorithm

[0148] server 192.168.1.10:8080;

[0149] server 192.168.1.11:8080;

[0150] server 192.168.1.12:8080;

[0151] }

[0152] server {

[0153] location / {

[0154] proxy_pass http: / / backend_servers;

[0155] }

[0156] }

[0157] }

[0158] (3) Dynamic scheduling process: Nginx continuously monitors the average response time of each upstream server to requests through its embedded fair module. When a new request arrives, the scheduler no longer uses round-robin or static weights, but directly queries its maintained response time metrics and distributes the new request to the server with the shortest currently calculated response time.

[0159] S3: Application Software Layer Implementation

[0160] S3.1: User Behavior Prediction and Data Preloading

[0161] This step is performed through the user behavior prediction module, and the specific process is as follows:

[0162] (1) Data Acquisition and Feature Engineering: On the client side (with user authorization), the JavaScript SDK was used to collect user attributes (region, age) and behavioral events (click, pageview, dwell_time). On the server side, Apache Spark was used to clean and aggregate the raw data, generating a 256-dimensional user-service interaction feature vector. .

[0163] (2) Model Training and Prediction: A deep learning model was built using the PyTorch framework. Feature Vectors The input is first fed into a fully connected layer (input dimension 256, output dimension 512), followed by a hidden layer (512 dimensions) and the Sigmoid activation function is applied. Perform a nonlinear transformation to obtain the output. :

[0164]

[0165] Subsequently, a one-dimensional convolutional layer (Conv1d, kernel size = 3, stride = 1) is introduced for local feature extraction. After passing through batch normalization layers and Mish activation function Finally, a fully connected layer and a sigmoid function are used to output the predicted score. :

[0166]

[0167] During model training, the Adam optimizer was used to optimize the hyperparameters (number of hidden layer neurons [256, 512, 1024], learning rate [0.001, 0.0001], batch size [32, 64]) using orthogonal trial and error. The best model was selected and saved based on the hit rate (HR@10).

[0168] The schematic diagram of the deep learning model structure is as follows: Figure 7 As shown, in this deep learning model for user behavior prediction, user preference data is presented as feature vectors. The input to the neural network is first performed by upscaling the features through a fully connected layer, followed by a non-linear transformation through a hidden layer. Then, a convolutional layer is introduced to further extract local features, and the final predicted score is generated through another hidden layer and the Mish activation function. .

[0169] (3) Data Prediction and Preloading: Based on the L highest-rated functional items predicted by the model, the Web application service asynchronously triggers data query operations corresponding to these functionalities in the background, stores the result sets in a Redis cache, and sets a reasonable expiration time. When users subsequently access these functionalities, the page data is directly retrieved from the Redis cache, significantly reducing latency. A comparison diagram of page opening times is shown below. Figure 8 As shown, by Figure 8 It can be seen that before applying the behavior analysis algorithm, although some pages could meet the requirement of opening time of less than 3000ms, many pages could not. After applying the behavior analysis algorithm, the first page is the homepage. At this time, the recommendation algorithm has not yet been involved, and it can be seen that the opening time is still relatively long. After the recommendation algorithm is involved, some data is preloaded, which greatly improves the page opening speed.

[0170] S3.2: Multi-threaded asynchronous processing

[0171] This step is executed through the application optimization module. Its core lies in using the ThreadPoolExecutor class provided in the java.util.concurrent package to create and manage a fixed-size thread pool to achieve asynchronous concurrent processing of user requests, thereby improving CPU resource utilization and system throughput. The specific technical implementation is as follows:

[0172] (1) Thread pool creation and parameter configuration: When the application starts, a custom thread pool is created by directly instantiating the ThreadPoolExecutor class. The key parameter configurations for this thread pool are as follows:

[0173] import java.util.concurrent.*;

[0174] / / Create a custom thread pool

[0175] ThreadPoolExecutor requestExecutor = new ThreadPoolExecutor(

[0176] 10, / / Core Threads (corePoolSize): The number of threads that the thread pool maintains long-term; these threads will not be reclaimed even if they are idle.

[0177] 50, / / Maximum number of threads (maximumPoolSize): The maximum number of threads the thread pool can hold.

[0178] 60L, TimeUnit.SECONDS, / / Thread idle lifespan (keepAliveTime): Idle threads exceeding the core thread count will be reclaimed after this time.

[0179] new LinkedBlockingQueue<>(100) / / Work queue (workQueue): A blocking queue used to store tasks to be executed, with a capacity of 100. );

[0181] Rationale for Technology Selection: As shown in Table 1, compared to solutions such as "inheriting the Thread class" or "implementing the Runnable interface," which require frequent creation and destruction of threads, the ThreadPoolExecutor solution (i.e., the concrete implementation of the thread pool using the ExecutorService and Executors utility classes) has the following advantages: it can reuse already created threads, avoid the performance overhead caused by thread lifecycle, and flexibly control the number of concurrent threads according to system load, thus making it more suitable for high-concurrency business scenarios. The disadvantage of "requiring manual destruction" is avoided in this solution by calling the requestExecutor.shutdown() method when the system shuts down.

[0182] Table 1: Comparison of Multithreaded Algorithms

[0183]

[0184] (2) Task Submission and Asynchronous Execution: Encapsulate user requests that require asynchronous processing into task objects that implement the Runnable interface. A configuration example is as follows:

[0185] / / 1. Define a task that implements the Runnable interface

[0186] public class BusinessTask implements Runnable {

[0187] private String requestData;

[0188] public BusinessTask(String data) {

[0189] this.requestData = data;

[0190] }

[0191] @Override

[0192] public void run() {

[0193] / / Write the specific business logic here

[0194] System.out.println("Processing: " + this.requestData + " onthread: " + Thread.currentThread().getName());

[0195] }

[0196] }

[0197] / / 2. Submit the task to the thread pool for execution.

[0198] public void handleUserRequest(String userInput) {

[0199] / / Create task

[0200] BusinessTask task = new BusinessTask(userInput);

[0201] / / Submit the task to the thread pool, and the thread pool will automatically allocate a thread to execute the task's run() method.

[0202] requestExecutor.submit(task);

[0203] / / The main thread returns immediately after submission, without waiting for the task to complete, thus achieving asynchronous processing.

[0204] }

[0205] By calling the `requestExecutor.submit(task)` method, the task is placed in the thread pool's work queue. An idle thread in the thread pool retrieves the task from the queue and executes its `run()` method. The main thread returns immediately after submitting the task to continue processing other requests, thus achieving asynchronous request processing and efficient utilization of system resources.

[0206] S3.3: SQL Query Optimization

[0207] This step is executed through the application optimization module. Its core lies in refactoring inefficient nested subqueries into efficient JOIN joins using a specific set of relational algebra-based query rewriting rules, and encapsulating complex queries with a view. The specific technical implementation is as follows:

[0208] (1) Identification of inefficient SQL: Use the database's built-in performance analysis tools (such as the EXPLAIN command in MySQL or the SQL Server Profiler in SQL Server) to scan and identify SQL statements that take too long to execute or consume too many resources. Analyze their execution plans and highlight those containing correlated subqueries or nested query statements that use the IN or EXISTS operators.

[0209] (2) Reconstruction rules for nested subqueries to JOIN joins: According to the appendix Figure 9 Based on the connection types and their semantics shown, formulate and implement the following specific rewrite strategies:

[0210] Rule 1: Convert to inner join

[0211] Applicable scenarios: When nested subqueries are used to determine existence (such as using IN or EXISTS), and only the intersection of the main query and the subquery needs to be returned.

[0212] Technical action: Rewrite the subquery as an INNER JOIN.

[0213] Code example:

[0214] / * Before optimization: using nested subqueries with IN * /

[0215] SELECT * FROM tableA A WHERE A.key IN (SELECT B.key FROM tableB B);

[0216] / * Optimized version: Rewritten as INNER JOIN * /

[0217] SELECT A.* FROM tableA A INNER JOIN tableB B ON A.key = B.key;

[0218] Rule 2: Convert to left join

[0219] Applicable scenarios: When you need to retrieve all records from the left table and their matching records from the right table, and the original logic includes the requirement to "query data unique to the left table".

[0220] Technical action: Use LEFT JOIN and filter the key values ​​of the right table using the IS NULL condition in the WHERE clause.

[0221] Code example:

[0222] / * Before optimization: Query data that exists in A but not in B (logically equivalent to NOT EXISTS) * /

[0223] SELECT * FROM tableA A WHERE NOT EXISTS (SELECT 1 FROM tableB B WHEREA.key = B.key);

[0224] / * Optimized version: Rewritten as LEFT JOIN and filters for unique data * /

[0225] SELECT A.* FROM tableA A LEFT JOIN tableB B ON A.key = B.key WHEREB.key IS NULL;

[0226] Selection Strategy: The choice of specific connection method must strictly follow the appendix. Figure 9 The semantics shown are as follows:

[0227] INNER JOIN: Retrieves the intersection data of two tables.

[0228] LEFT JOIN: Retrieves all data from the left table and the matching data from the right table.

[0229] FULL OUTER JOIN: Retrieves the union of two tables (suitable for querying data unique to each table, as shown in the last row of Table 2 below).

[0230] Table 2: Examples of SQL Connection Strategies

[0231]

[0232] (3) View encapsulation of complex queries: For multi-table join queries that are still relatively complex after the above optimization or are frequently called in the application layer, use the database's CREATE VIEW statement to encapsulate them as views.

[0233] Technical maneuvers:

[0234] CREATE VIEW vw_complex_order_details AS

[0235] SELECT

[0236] O.order_id,

[0237] C.customer_name,

[0238] P.product_name,

[0239] OD.quantity

[0240] FROM orders O

[0241] INNER JOIN customers C ON O.customer_id = C.customer_id

[0242] INNER JOIN order_details OD ON O.order_id = OD.order_id

[0243] INNER JOIN products P ON OD.product_id = P.product_id;

[0244] Purpose: To solidify and abstract query logic at the database layer. Application layer code no longer needs to write lengthy JOIN statements; it only needs to execute `SELECT * FROM vw_complex_order_details`, greatly simplifying the call, avoiding duplication of SQL code in the application, and improving code reusability and maintainability.

[0245] It should be noted that this technical solution forms a unified business continuity assurance system through the collaboration and closed-loop feedback of hardware, system software, and application software. Its overall technical effect is not a simple summation of independent optimization measures at each level, but rather a synergistic performance improvement achieved through cross-layer linkage. The specific implementation mechanism is as follows:

[0246] 1. Explanation of the collaborative optimization mechanism

[0247] This solution forms a closed-loop protection logic through cross-level collaborative design, and its working mechanism is as follows:

[0248] (1) Positive support link (bottom to top):

[0249] The hardware layer provides a stable and high-performance foundation for the upper layers: through secondary striping, it provides a high-throughput, low-latency I / O channel for the dual-active database in the system software layer, ensuring that data synchronization is bottleneck-free; through millisecond-level failover achieved by network clusters, it provides a stable network plane for intelligent load balancing, ensuring that services are always available.

[0250] The system software layer supports hardware capabilities and serves applications: the dual-active database leverages the high I / O performance of the underlying layer to achieve rapid data synchronization across data centers, providing a highly consistent and available data source for application layer data preloading; intelligent load balancing utilizes the rapid disaster recovery capabilities of the network layer to dynamically and accurately distribute application requests to the healthiest server nodes.

[0251] (2) Reverse optimization of the link (top-down):

[0252] The application software layer proactively optimizes the underlying workload: by predicting user behavior and preloading data using deep learning models, the majority of read requests are handled at the application layer, reducing the query pressure on the system software layer's database and indirectly lowering the I / O load on the hardware layer's storage system. This is a "predictive" proactive optimization, unlike traditional "responsive" passive optimization.

[0253] This two-way closed loop transforms the three layers from being independent to forming a mutually empowering and optimizing whole. For example, application-layer preloading (reverse optimization) improves database and storage performance, which in turn ensures the stability and responsiveness of upper-layer services (positive support). This cross-layer, two-way virtuous cycle is the fundamental reason why this solution systematically improves business continuity, and it is also the core difference between this solution and the simple superposition of existing technologies.

[0254] It should be noted that this solution directly and systematically achieves the various technical effects of this application through the following specific technical means:

[0255] (1) Improve I / O performance:

[0256] Implementation method: Secondary striping is achieved in S1.1 using the command lvcreate -i 4 -I 64k.

[0257] Implementation path: This command forces data I / O requests to be evenly distributed across four different underlying RAID groups for parallel processing, eliminating the performance bottleneck of "hotspot" disks in traditional single-level striping. For example... Figure 2 As shown, this method achieves linear performance improvement and load balancing across storage units, ensuring high I / O performance from the hardware level.

[0258] (2) Improve fault recovery speed:

[0259] Implementation method: S1.2 network device cluster and S2.1 dual-active database architecture.

[0260] Implementation Path: The network cluster, through heartbeat detection and protocol-level table updates, completes traffic rerouting within milliseconds when a device failure is detected, achieving rapid network layer recovery. The dual-active database, through multi-master synchronous replication, ensures that if one data center instance fails, the other instance, being a live node with synchronized data, can immediately take over all services, achieving second-level or even instantaneous fault recovery for the database service. Together, these two components constitute an end-to-end rapid disaster recovery system from network to data.

[0261] (3) Improve resource utilization efficiency:

[0262] Implementation methods: database write load balancing in S2.1, intelligent load balancing in S2.2, and asynchronous processing using thread pools in S3.2.

[0263] Implementation path: Write load balancing enables all instances of the dual-active database to handle write requests, breaking the traditional idle mode of the standby database and significantly improving the resource utilization of the database cluster; Intelligent load balancing ensures that the request load of the entire application server cluster is evenly distributed through dynamic scheduling based on response time, avoiding local overload and local idle, and achieving global optimization of computing resources; Thread pool technology reduces thread lifecycle overhead by reusing threads and controlling the number of concurrent threads, significantly improving the utilization efficiency of single-machine CPU resources.

[0264] (4) Improve request response latency:

[0265] Implementation method: User behavior prediction and Redis cache preloading based on a specific deep learning model in S3.1.

[0266] Implementation path: Before a user initiates a request, the system predicts the user's intent through a model and asynchronously queries the database and loads the data into an in-memory Redis cache. When the user's actual request arrives, the page data does not need to go through a time-consuming database query, but is directly obtained from Redis, thereby reducing the response latency from tens to hundreds of milliseconds for database queries to sub-millisecond levels for memory read and write.

[0267] It should be noted that, to evaluate the actual effectiveness of this solution, rigorous tests were conducted on three key indicators—system service response time, failover time, and concurrent access capacity—according to a pre-defined testing procedure. Test results show that this solution successfully achieved all pre-defined performance targets: service response time was optimized to below 3000ms; system failover time was significantly reduced to below 3000ms; and system concurrent access capacity was effectively increased to over 5000 users. The measured data for each performance indicator met or exceeded the expected targets, fully demonstrating the effectiveness of the technical measures adopted in this solution and providing a replicable and scalable complete solution for ensuring the business continuity of the cloud resource pool.

[0268] The method for ensuring business continuity of cloud resource pools provided in this disclosure, through deep collaboration among the hardware layer, system software layer, and application software layer, relies on the secondary striping processing and network device clustering capabilities of the hardware layer, the multi-master synchronous replication database dual-active architecture and response time-based intelligent load balancing scheduling of the system software layer, and the user behavior prediction caching, thread pool asynchronous concurrent processing, and inefficient SQL query optimization of the application software layer. This significantly improves storage I / O parallel processing capabilities in large-scale, high-concurrency scenarios, enabling rapid automatic failover of physical network devices and database instances. Simultaneously, it evenly distributes write operations across multiple database instances, dynamically schedules user requests to the fastest-responding service instance, and reduces hot data access latency to sub-millisecond levels through pre-loading caching. Combined with thread pool reuse and inefficient SQL query optimization, it further improves system throughput and resource utilization, thereby systematically enhancing the operational stability and business continuity of the cloud resource pool under high load, hardware failure, and network anomaly conditions. The existing methods for ensuring business continuity in cloud resource pools typically employ independent optimization measures at the hardware, system software, and application software levels. This results in insufficient overall system performance and fault response capabilities when dealing with large-scale, high-concurrency scenarios, making it difficult to effectively guarantee business continuity.

[0269] It is understood that the various method embodiments mentioned above in this disclosure can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0270] Figure 9 A block diagram of an apparatus for ensuring service continuity of a cloud resource pool, provided in an embodiment of this disclosure.

[0271] Reference Figure 9 This disclosure provides an apparatus for ensuring the service continuity of a cloud resource pool, used to perform the aforementioned method for ensuring the service continuity of a cloud resource pool. The apparatus includes:

[0272] The hardware layer optimization module 11 is used to, at the hardware layer, assemble multiple physical hard drives into multiple independent disk redundant array RAID groups and integrate them into a unified storage pool, create logical volumes based on the unified storage pool to perform secondary striping processing; and, adopt network device clustering technology to virtualize multiple physical network devices into a single logical unit, and automatically switch service traffic when physical network devices fail.

[0273] The system software layer optimization module 12, connected to the hardware layer optimization module 11, is used to deploy database instances in at least two data centers and form a synchronous replication cluster that supports multi-master writes at the system software layer, so that multiple database instances in the synchronous replication cluster can process write operations simultaneously, and other instances can take over the business when a database instance fails; and to configure a scheduling module based on an intelligent load balancing algorithm, which distributes newly arrived business requests to the service instance with the shortest current response time in real time based on the scheduling module.

[0274] The application software layer optimization module 13, connected to the system software layer optimization module 12, is used to predict the collected user behavior data using a deep learning model at the application software layer, cache the data corresponding to the prediction results, and perform asynchronous concurrent processing of user requests by creating a thread pool, and perform nested subquery reconstruction and view encapsulation on the identified inefficient structured query language (SQL) queries.

[0275] Optionally, the hardware layer optimization module 11 includes:

[0276] A RAID unit is used to combine multiple physical hard drives into multiple RAID groups using a RAID card.

[0277] Integration unit, used to integrate multiple RAID groups into a unified storage pool;

[0278] The logical volume creation unit is used to create logical volumes based on the unified storage pool using preset LVM commands. When creating the logical volume, the LVM commands specify the number of stripes as N and the stripe block size as MKB, so that the data corresponding to the I / O request is divided into data blocks of size MKB when it is written, and is written to N underlying RAID groups in a round-robin fashion for parallel processing, where N is an integer greater than 2.

[0279] Optionally, the hardware layer optimization module 11 further includes:

[0280] The command device selection unit is used to select one physical network device from multiple physical network devices as the command device.

[0281] A node device configuration unit is used to configure the remaining physical network devices (excluding the command device) among multiple physical network devices as node devices and initiate registration with the command device.

[0282] The control plane forming unit is used to run the cluster management protocol through the command device, collect the topology and status information of all registered node devices, and form a unified control plane.

[0283] The fault node switching unit is used to update the forwarding table entries in the control plane and switch the service traffic to the normal node device when any node device is detected to be faulty.

[0284] Optionally, the system software layer optimization module 12 includes:

[0285] A database instance deployment unit is used to deploy database instances in at least two data centers.

[0286] The group replication unit is used to configure group replication parameters for database instances, enabling each database instance to discover each other and form a synchronous replication cluster that supports multi-master writes.

[0287] The write operation load balancing unit is used to configure read-write separation rules at the application layer through database middleware, and distribute write requests to database instances in different data centers according to a set ratio to achieve write operation load balancing.

[0288] The fault takeover unit is used to allow the remaining normal database instances to directly take over the business when any database instance in the synchronous replication cluster fails.

[0289] Optionally, the system software layer optimization module 12 further includes:

[0290] The scheduling module configuration unit is used to configure a scheduling module based on the intelligent load balancing algorithm in the load balancer.

[0291] The average response time monitoring unit is used to continuously monitor the average response time of each upstream service instance to historical requests based on the scheduling module.

[0292] The business request distribution unit is used to query the average response time of each upstream service instance using the scheduling module when a new business request arrives, and then distribute the new business request to the service instance with the shortest average response time.

[0293] Optionally, the application software layer optimization module 13 includes:

[0294] The feature vector generation unit is used to collect user attribute information and behavioral event data to generate user-service interaction feature vectors.

[0295] The prediction rating acquisition unit is used to input the user-service interaction feature vector into the deep learning model and output the user's predicted rating for each function item.

[0296] The query result set caching unit is used to select the top L functional items with the highest predicted scores, asynchronously trigger the corresponding data query operation in the background, and store the query result set in the remote dictionary service Redis cache, where L is a positive integer.

[0297] Optionally, the application software layer optimization module 13 further includes:

[0298] The thread pool creation unit is used to create a thread pool using the ThreadPoolExecutor class. The thread pool is configured with the core number of threads, the maximum number of threads, the thread idle lifespan, and a bounded work queue.

[0299] An asynchronous execution unit is used to encapsulate user requests into task objects and submit them to the thread pool, and then use idle threads in the thread pool to execute the corresponding tasks asynchronously.

[0300] Optionally, the application software layer optimization module 13 further includes:

[0301] The inefficient SQL statement identification unit is used to identify SQL statements whose execution time exceeds a preset duration or whose resource consumption exceeds a preset threshold through database performance analysis tools, and these are identified as inefficient SQL statements.

[0302] The query restructuring and optimization unit is used to restructure the nested subqueries in the inefficient SQL statement into JOIN join queries in order to complete the query optimization;

[0303] The database view encapsulation unit is used to encapsulate complex queries involving multiple table joins into database views for application layer calls.

[0304] Figure 10 This is a block diagram of an electronic device provided in an embodiment of the present disclosure.

[0305] Reference Figure 10 This disclosure provides an electronic device, which includes: at least one processor 701; at least one memory 702; and one or more I / O interfaces 703 connected between the processor 701 and the memory 702; wherein the memory 702 stores one or more computer programs that can be executed by the at least one processor 701, and the one or more computer programs are executed by the at least one processor 701 to enable the at least one processor 701 to perform the above-described method for ensuring the continuity of cloud resource pool services.

[0306] This disclosure also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the aforementioned method for ensuring service continuity of a cloud resource pool. The computer-readable storage medium may be volatile or non-volatile.

[0307] In summary, the methods, apparatus, devices, and media provided in this disclosure for ensuring the business continuity of cloud resource pools, through deep collaboration between the hardware layer, system software layer, and application software layer, rely on the secondary striping processing and network device clustering capabilities of the hardware layer, the multi-master synchronous replication database dual-active architecture and response time-based intelligent load balancing scheduling of the system software layer, and the user behavior prediction caching, thread pool asynchronous concurrent processing, and inefficient SQL query optimization of the application software layer. This significantly improves the parallel processing capability of storage I / O in large-scale, high-concurrency scenarios, enabling rapid automatic failover of physical network devices and database instances. Simultaneously, it evenly distributes write operations across multiple database instances, dynamically schedules user requests to the fastest-responding service instance, and reduces the latency of hot data access to sub-millisecond levels through pre-loading caching. Combined with thread pool reuse and inefficient SQL query optimization, it further improves system throughput and resource utilization, thereby systematically enhancing the operational stability and business continuity of the cloud resource pool under high load, hardware failure, and network anomaly conditions. The existing methods for ensuring business continuity in cloud resource pools typically employ independent optimization measures at the hardware, system software, and application software levels. This results in insufficient overall system performance and fault response capabilities when dealing with large-scale, high-concurrency scenarios, making it difficult to effectively guarantee business continuity.

[0308] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0309] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0310] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0311] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0312] This disclosure has disclosed exemplary embodiments, and although specific terminology has been used, it is for general illustrative purposes only and should not be construed as limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A method for ensuring service continuity in a cloud resource pool, characterized in that, The method includes: At the hardware layer, multiple physical hard drives are assembled into multiple independent disk redundant array (RAID) groups and integrated into a unified storage pool. Logical volumes are created based on the unified storage pool to perform secondary striping processing. Additionally, network device clustering technology is used to virtualize multiple physical network devices into a single logical unit and automatically switch service traffic when physical network devices fail. At the system software layer, database instances are deployed in at least two data centers and a synchronous replication cluster supporting multi-master writes is formed, so that multiple database instances in the synchronous replication cluster can process write operations simultaneously, and other instances can take over the business when a database instance fails; and a scheduling module based on an intelligent load balancing algorithm is configured to distribute newly arrived business requests to the service instance with the shortest current response time in real time based on the scheduling module. At the application software layer, deep learning models are used to predict the collected user behavior data, and the data corresponding to the prediction results are cached. In addition, a thread pool is created to asynchronously and concurrently process user requests, and nested subqueries are reconstructed and views are encapsulated for inefficient structured query language (SQL) queries.

2. The method according to claim 1, characterized in that, The process of assembling multiple physical hard drives into multiple independent redundant disk arrays (RAID) groups and integrating them into a unified storage pool, and then creating logical volumes based on the unified storage pool to perform secondary striping processing, specifically includes: Multiple physical hard drives can be configured into multiple RAID groups using a RAID card; Consolidate multiple RAID groups into a unified storage pool; Based on the unified storage pool, logical volumes are created using preset LVM commands. When creating a logical volume, the LVM commands specify the number of stripes as N and the stripe block size as MKB, so that the data corresponding to the I / O request is divided into data blocks of size MKB when it is written, and is written to N underlying RAID groups in a round-robin fashion for parallel processing, where N is an integer greater than 2.

3. The method according to claim 1, characterized in that, The method of using network device clustering technology to virtualize multiple physical network devices into a single logical unit and automatically switch service traffic when physical network devices fail includes: Select one physical network device from multiple physical network devices as the command device; Configure the remaining physical network devices (excluding the command device) as node devices and initiate registration with the command device. The command device runs a cluster management protocol to collect the topology and status information of all registered node devices, forming a unified control plane. When any node device failure is detected, the forwarding table entry is updated in the control plane to switch service traffic to the normal node device.

4. The method according to claim 1, characterized in that, The step of deploying database instances in at least two data centers and forming a synchronous replication cluster that supports multi-master writes, enabling multiple database instances in the synchronous replication cluster to process write operations simultaneously, and allowing other instances to take over the service in the event of a database instance failure, specifically includes: Deploy database instances in at least two data centers; Configure group replication parameters for database instances so that they can discover each other and form a synchronous replication cluster that supports multi-master writes; At the application layer, read / write splitting rules are configured through database middleware to distribute write requests to database instances in different data centers according to a set ratio, thereby achieving load balancing of write operations. When any database instance in the synchronous replication cluster fails, the remaining normal database instances directly take over the service.

5. The method according to claim 1, characterized in that, The configuration is based on a scheduling module using an intelligent load balancing algorithm. This module distributes newly arriving service requests in real-time to the service instance with the shortest current response time, specifically including: Configure a scheduling module based on an intelligent load balancing algorithm in the load balancer; The scheduling module continuously monitors the average response time of each upstream service instance to historical requests. When a new business request arrives, the scheduling module is used to query the average response time of each upstream service instance and distribute the new business request to the service instance with the shortest average response time.

6. The method according to claim 1, characterized in that, The process of using a deep learning model to predict collected user behavior data and caching the data corresponding to the prediction results specifically includes: Collect user attribute information and behavioral event data to generate user-service interaction feature vectors; The user-service interaction feature vector is input into the deep learning model, and the predicted rating of the user for each function item is output. Select the top L functional items with the highest predicted scores, asynchronously trigger the corresponding data query operation in the background, and store the query result set in the remote dictionary service Redis cache, where L is a positive integer.

7. The method according to claim 1, characterized in that, The method of asynchronously and concurrently processing user requests by creating a thread pool specifically includes: A thread pool is created using the ThreadPoolExecutor class, which is configured with a core number of threads, a maximum number of threads, a thread idle lifespan, and a bounded work queue. The user request is encapsulated as a task object and submitted to the thread pool, and the corresponding task is executed asynchronously using the idle threads in the thread pool.

8. The method according to claim 1, characterized in that, The process of reconstructing nested subqueries and encapsulating views for the identified inefficient Structured Query Language (SQL) queries specifically includes: SQL statements whose execution time exceeds a preset duration or whose resource consumption exceeds a preset threshold are identified by database performance analysis tools and are classified as inefficient SQL statements. The nested subqueries in the inefficient SQL statements are refactored into JOIN join queries to optimize the query. For complex queries involving multiple table joins after optimization, they are encapsulated as database views for application layer calls.

9. An apparatus for ensuring service continuity of a cloud resource pool, characterized in that, The device includes: The hardware layer optimization module is used to, at the hardware layer, assemble multiple physical hard drives into multiple independent disk redundant array (RAID) groups and integrate them into a unified storage pool, create logical volumes based on the unified storage pool to perform secondary striping processing; and, adopt network device clustering technology to virtualize multiple physical network devices into a single logical unit, and automatically switch service traffic when physical network devices fail. The system software layer optimization module, connected to the hardware layer optimization module, is used to deploy database instances in at least two data centers and build a synchronous replication cluster that supports multi-master writes at the system software layer, so that multiple database instances in the synchronous replication cluster can process write operations simultaneously, and other instances can take over the business when a database instance fails; and to configure a scheduling module based on an intelligent load balancing algorithm, which distributes newly arrived business requests to the service instance with the shortest current response time in real time. The application software layer optimization module, connected to the system software layer optimization module, is used to predict the collected user behavior data using a deep learning model at the application software layer, cache the data corresponding to the prediction results, and perform asynchronous concurrent processing of user requests by creating a thread pool, and perform nested subquery reconstruction and view encapsulation on the identified inefficient structured query language (SQL) queries.

10. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores one or more computer programs that can be executed by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the method for ensuring the business continuity of the cloud resource pool as described in any one of claims 1-8.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method for ensuring service continuity of the cloud resource pool as described in any one of claims 1-8.

Images