Method and apparatus for controlling module in cloud platform, electronic device and storage medium

Abstract

This application relates to a control method, apparatus, electronic device, and storage medium for modules in a cloud platform. The method includes: after a candidate module in the cloud platform sends an election request to other modules, determining whether the candidate module is a master module based on a composite decision-making method; after selecting a master module, obtaining a first load state of other slave modules in the cloud platform and a second load state of the overall internal load of the cloud platform through the master module; and adjusting the operating state of the slave modules in real time and scheduling resources among the slave modules based on the first and second load states. This application solves the problem in existing cloud platforms where resource scheduling based on a single load threshold easily leads to uneven system resource utilization.

Description

Technical Field

[0001] This application relates to the field of cloud platform technology, and in particular to a control method and apparatus, electronic device and storage medium for modules in a cloud platform. Background Technology

[0002] Currently, to reduce resource waste, cloud platforms typically pause some modules or reduce their operating frequency during low-load scenarios, or achieve resource scheduling through dynamic scaling. However, these methods are mostly based on a single load threshold and lack a global coordination mechanism. They are difficult to adaptively optimize based on the real-time operating status of the system. Especially in scenarios with large fluctuations in business traffic, it is easy for some modules in the cloud platform to run at high load for a long time, while other modules have idle resources, resulting in an uneven utilization of system resources. Summary of the Invention

[0003] This application provides a control method and device, electronic device and storage medium for modules in a cloud platform, to solve the problem that the existing cloud platform uses a single load threshold for resource scheduling, which easily leads to uneven system resource utilization.

[0004] Firstly, this application provides a method for controlling modules in a cloud platform, including: After a candidate module in the cloud platform sends an election request to other modules, a composite decision-making method is used to determine whether the candidate module is the main module. The candidate module is any one of multiple modules in the cloud platform. The composite decision-making method means that the log integrity and term number of the candidate module are first verified, and the candidate module with the highest resource surplus is selected as the main module after the verification is passed. After selecting the main module, the first load status of other slave modules in the cloud platform and the second load status of the overall internal load of the cloud platform are obtained through the main module. The operating status of the slave modules is adjusted in real time by combining the first load status and the second load status, and resources among the slave modules are scheduled.

[0005] Optionally, after a candidate module in the cloud platform sends an election request to other modules, determining whether the candidate module is the main module based on a composite decision-making method includes: Verify the log integrity and term number of the candidate module; wherein, the term number represents the election round of the main module; If the log term number of the candidate module is greater than the log term number of other modules, or if the log term number is equal to the log term number of other modules and the log sequence number of the candidate module is greater than or equal to the log sequence number of other modules, the resource redundancy of the candidate module that has passed the verification is obtained. The candidate module with the highest resource surplus is selected from the verified candidate modules as the main module.

[0006] Optionally, adjusting the operating status of the slave module in real time by combining the first load status and the second load status includes: If the overall load index of the first load state is less than a first preset threshold and the average CPU utilization rate in the second load state is lower than a second preset threshold for N consecutive cycles, the operating state of the slave module is downgraded; wherein, the overall load index is the weighted sum of CPU utilization rate, memory utilization rate and task queue length after normalization; N is a positive integer; After the running state of the slave module is downgraded, if the time for maintaining the current state exceeds the first preset duration, and the average CPU utilization rate in the second load state is lower than the third preset threshold and the total task queue backlog length in the second load state is lower than the fourth preset threshold, the running state of the slave module will continue to be downgraded, wherein the third preset threshold is less than the second preset threshold.

[0007] Optionally, the operating state of the slave module may be downgraded, including: The running state of the module is downgraded from running state to standby state, or from standby state to hibernation state.

[0008] Optionally, the operating status of the slave module is adjusted in real time by combining the first load status and the second load status, including: After downgrading the operating status of the module, the next peak operating time window of the cloud platform's load is predicted based on the second load status obtained from historical periodic data. A wake-up command is sent to the slave module in hibernation or standby mode at a preset time point before the peak time window. The wake-up command is used to upgrade the operating status of the slave module.

[0009] Optionally, sending a wake-up command to the slave module in hibernation or standby mode at a preset time point before the peak time window includes: The preset time point is determined based on the historical measured time and preset redundancy time of the module upgrading from the current state to the next state. The wake-up command is sent to the slave module in sleep or standby mode according to the sorting result of the historical measured duration from largest to smallest.

[0010] Optionally, scheduling resources among the slave modules in combination with the first load state and the second load state includes: If the external request arrival rate per unit time in the second load state is greater than the fifth preset threshold, for slave modules of the same type, resource balancing scheduling is performed based on their respective first load states so that the difference between the first load states of slave modules of the same type is less than the sixth preset threshold.

[0011] Secondly, this application provides a control device for a module in a cloud platform, comprising: The first processing module is used to determine whether a candidate module is the main module based on a composite decision-making method after a candidate module in the cloud platform sends an election request to other modules. The candidate module is any one of multiple modules in the cloud platform. The composite decision-making method means that the log integrity and term number of the candidate module are first verified, and the candidate module with the highest resource surplus is selected as the main module after the verification is passed. The second processing module is used to obtain the first load status of other slave modules in the cloud platform and the second load status of the overall internal load of the cloud platform through the main module after the main module is selected. The control module is used to adjust the operating status of the slave modules in real time by combining the first load status and the second load status, and to schedule resources among the slave modules.

[0012] Thirdly, this application provides an electronic device, comprising: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor connected to the at least one bus; and at least one memory connected to the at least one bus, wherein the processor is configured to execute the control method for a module in a cloud platform as described in the first aspect of this application.

[0013] Fourthly, this application also provides a computer storage medium storing computer-executable instructions, which are used to execute the control method of the module in the cloud platform described in the first aspect of this application.

[0014] Compared with the prior art, the technical solution provided in this application has the following advantages: The method provided in this application, after a candidate module in the cloud platform sends an election request to other modules, determines whether the candidate module is the master module based on a composite decision-making method; after selecting the master module, it obtains the first load status of other slave modules in the cloud platform and the second load status of the overall internal load of the cloud platform through the master module, and then combines the first and second load statuses to adjust the operating status of the slave modules in real time and schedule resources among the slave modules. Therefore, this application, starting from electing a reliable and efficient master module, continuously senses the load, dynamically adjusts the module status, and balances task allocation, ultimately enabling the cloud platform to maximize resource utilization and energy efficiency while ensuring service quality. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0018] Figure 1 A flowchart illustrating a module control method in a cloud platform, provided as an embodiment of this application; Figure 2 One of the optional flowcharts for a module control method in a cloud platform provided in this application embodiment; Figure 3 A second optional flowchart of a module control method in a cloud platform provided in an embodiment of this application; Figure 4 A third optional flowchart of a module control method in a cloud platform provided in an embodiment of this application; Figure 5 A flowchart illustrating a cloud platform resource scheduling method with module election and hibernation mechanism provided in this application embodiment; Figure 6 A schematic diagram of a cloud platform resource scheduling system structure with a module election and hibernation mechanism provided in this application embodiment; Figure 7 This is a schematic diagram of the structure of the control device for a module in a cloud platform provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] The following disclosure provides numerous different embodiments or examples for implementing various structures of the invention. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of the invention. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0021] To address the problem of uneven system resource utilization caused by the use of a single load threshold for resource scheduling in existing cloud platforms, this application provides a module control method for cloud platforms, such as... Figure 1 As shown, the steps of this method include: Step 101: After the candidate module in the cloud platform sends an election request to other modules, determine whether the candidate module is the main module based on a composite decision-making method. The candidate module is any module among multiple modules in the cloud platform. The composite decision-making method means that the log integrity and term number of the candidate module are first verified, and the candidate module with the highest resource surplus is selected as the main module after the verification is passed. In this embodiment, the cloud platform may include multiple modules such as a device access module, a data parsing module, a computing and processing module, and a resource monitoring module. The number and type of modules can be determined according to the specific application scenario. Therefore, in the cloud platform, any functional module (such as a device access module, data parsing module, computing and processing module, or resource monitoring module) is called a candidate module when initiating or participating in an election. Candidate modules can actively send election requests or passively accept voting inquiries from other modules. Furthermore, in this embodiment, the master module is a module with unified scheduling authority, generated through election. The master module is used to send heartbeats to slave modules, collect load status, decide on state transitions, and allocate tasks. The master module role is not fixedly assigned to a certain type of module; any functional module can be elected as long as it meets the election conditions.

[0022] In this embodiment, log integrity refers to whether the distributed logs (recording historical operations such as task scheduling and state switching) stored locally by the module contain all log entries that have been confirmed and committed by a majority of nodes in the cluster. Only modules with complete logs can ensure that the new master module will not lose the records of committed operations after the master module fails, thereby guaranteeing the consistency of the cluster state. Additionally, the term number is a monotonically increasing integer used in distributed consensus algorithms (such as Raft) to mark election rounds. Each time a new election begins, the term number is incremented by 1. The term number is used to distinguish between old and new logs and to reject commands from expired master modules.

[0023] Furthermore, the resource redundancy in this embodiment is a comprehensive indicator reflecting the sufficiency of the module's current idle resources. It is typically calculated based on CPU utilization, memory utilization, and task queue length; the lower these three indicators, the higher the resource redundancy. A module with higher resource redundancy is more suitable to serve as the main module because it has more computing and storage resources to handle scheduling tasks, avoiding delays in scheduling decisions due to its own resource constraints.

[0024] In this specific example, the cloud platform deploys three computing modules (A, B, and C) and two data parsing modules (D and E). Upon system startup, all modules are candidate modules. Each candidate module sends an election request to the other modules, carrying its log integrity certificate and current term number. Other modules first verify whether the candidate modules' logs are complete (i.e., whether they possess all previously submitted scheduling records) and whether their term number is not less than their own current term. Only candidate modules that pass both verifications are considered legitimate candidates. Among all candidate modules, their resource availability is compared. For example, module A has a CPU utilization of 30%, a memory utilization of 40%, and a queue length of 20; module B has a CPU utilization of 70%, a memory utilization of 65%, and a queue length of 80; and module C has a CPU utilization of 50%, a memory utilization of 55%, and a queue length of 50. Through comprehensive calculation, candidate module A has the highest resource availability and is therefore selected as the primary module. As can be seen, in this embodiment of the application, by first verifying the integrity of the logs and the term number, the new main module is guaranteed to have a complete system state, avoiding state rollback or incorrect scheduling due to missing logs; by selecting the module with the most abundant resources as the main module, it is ensured that the main module itself will not become a scheduling bottleneck due to resource shortage, thereby improving the timeliness of scheduling response.

[0025] Step 102: After selecting the main module, obtain the first load status of other slave modules in the cloud platform and the second load status of the overall internal load of the cloud platform through the main module. In this embodiment, the first load state refers to the real-time operating metrics of each slave module, including but not limited to CPU utilization, memory utilization, task queue backlog length, and data processing throughput. These metrics reflect the busy / idle status of individual modules and are the direct basis for the master module to perform state transitions and task allocation. The second load state refers to the overall load status of the cloud platform, such as the average CPU utilization of all modules, the total task queue backlog length, and the external request arrival rate per unit time. The second load state is used to determine whether the system as a whole is idle or busy, thereby deciding whether to allow modules to enter a lower power consumption state or whether it is necessary to wake up more modules in advance.

[0026] In this specific example, the master module (module A) sends a heartbeat request to all slave modules (modules B, C, D, and E) every 30 seconds. The slave modules respond with their respective first load status: for example, module C reports a CPU utilization of 75%, a memory utilization of 60%, and a queue length of 120; module D (the data parsing module) reports a CPU utilization of 10%, a memory utilization of 20%, and a queue length of 5. Simultaneously, the master module itself calculates its second load status: the average CPU utilization of all modules ((30%+75%+50%+10%+15%) / 5=36%), the total queue backlog (20+80+50+5+10=165), and the external request arrival rate (500 device messages per second). It is evident that the master module can monitor the workload of each module and the overall system load level in real time, providing a quantitative basis for subsequent status adjustments and task allocation.

[0027] Step 103: Combine the first load state and the second load state to adjust the running status of the slave module in real time and schedule resources among the slave modules.

[0028] In this embodiment, real-time adjustment refers to the main module dynamically changing the running state (running, standby, or hibernation) of the slave modules based on changes in the first and second load states, ensuring that system resource allocation always closely aligns with current business needs. Resource scheduling refers to the main module assigning newly arriving tasks (such as device data parsing requests or business calculation requests) to appropriate slave modules for execution, and achieving load balancing among multiple modules of the same type to prevent some modules from being overloaded while others remain idle.

[0029] As can be seen, through steps 101 to 103 above, after the candidate module in the cloud platform sends an election request to other modules, a composite decision-making method is used to determine whether the candidate module is the master module. After the master module is selected, it obtains the first load status of other slave modules in the cloud platform and the second load status of the overall internal load of the cloud platform. Then, it combines the first and second load statuses to adjust the running status of the slave modules in real time and schedule resources among the slave modules. Thus, this application starts from electing a reliable and efficient master module, continuously senses the load, dynamically adjusts the module status, and balances the allocation of tasks, ultimately enabling the cloud platform to maximize resource utilization and energy efficiency while ensuring service quality.

[0030] In the optional implementations of this application, such as Figure 2 As shown, the method of determining whether a candidate module is the main module based on a composite decision-making approach after the candidate module in the cloud platform sends an election request to other modules in step 101 above can further include: Step 11: Verify the log integrity and term number of the candidate module; where the term number represents the election round of the main module. Step 12: If the log term number of the candidate module is greater than the log term number of other modules, or if the log term number is equal to the log term number of other modules and the log sequence number of the candidate module is greater than or equal to the log sequence number of other modules, obtain the resource redundancy of the candidate module that has passed the verification. The log sequence number refers to the sequential number (also known as the log index) of each log entry in the module's local log file, starting from 1 and increasing monotonically. The larger the log sequence number, the later the log entry was written within the same term.

[0031] Step 13: Select the candidate module with the highest resource surplus from the verified candidate modules as the main module.

[0032] For steps 11 to 13 above, in this specific example, assume there are three modules in the cloud platform: Module A, Module B, and Module C. The current master module has just failed, and a new master module needs to be elected. Module A and Module B initiate election requests and become candidate modules. Module C, as a voting node, needs to determine which candidate module better meets the conditions for becoming the master module. The log status of each module is shown in Table 1.

[0033] Table 1

[0034] Based on Table 1, voting node C first verifies whether the logs of candidate modules A and B are complete, i.e., whether they contain all committed log entries. Here, it is assumed that all are complete, and the focus is on comparing the term number and the log sequence number. The comparison rule is: the term number of the candidate module's log is greater than the term number of the voting node's log, or (the term number is equal to and the log sequence number is greater than or equal to) the log sequence number of the voting node.

[0035] Verification of Module A: Since both A and C have the same term number (5), their log sequence numbers need to be compared. A's log sequence number is 100, and C's is 95. Therefore, 100 ≥ 95, and the condition is met. Thus, Module A passes verification.

[0036] Module B was verified: B's term number = 4, C's term number = 5. It is clear that 4 is not greater than 5 and they are not equal, so the condition is not met. Therefore, module B failed the verification.

[0037] After the first verification step, only module A passed the verification. If multiple candidate modules pass the verification at this point, their resource availability is compared. In this example, only module A passed, therefore module A is directly selected as the new main module.

[0038] As can be seen, in this embodiment, verifying that the log term number of the candidate module is greater than that of other modules ensures that the logs of the newly elected main module originate from the updated election round, avoiding the risk of submitted logs being overwritten due to the incorrect election of nodes in the old term. Equal term numbers and log sequence numbers greater than or equal to the log sequence numbers of other modules indicate that, within the same term, the newly elected main module ensures that it contains at least all the logs of the voting nodes, guaranteeing no log loss, while allowing nodes with identical logs to participate in the election, avoiding deadlock. Furthermore, if the verification passes, the module with the most abundant resources is selected as the main module, giving the scheduling center stronger processing capabilities and reducing scheduling delays caused by resource constraints in the main module.

[0039] In optional embodiments of this application, such as Figure 3 As shown, the real-time adjustment of the slave module's operating status by combining the first load status and the second load status involved in step 103 above includes: Step 21: If the comprehensive load index of the first load state is less than the first preset threshold and the average CPU utilization rate in the second load state is lower than the second preset threshold within N consecutive cycles, the running state of the slave module is downgraded; where the comprehensive load index is the weighted sum of normalized CPU utilization rate, memory utilization rate and task queue length; N is a positive integer. In this embodiment, the comprehensive load index is a weighted sum calculated by normalizing the three indicators of CPU utilization, memory utilization, and task queue length (mapping them to between 0 and 1) and then calculating them according to preset weights. The closer the comprehensive load index is to 0, the more idle the module is, and the closer it is to 1, the more busy the module is.

[0040] In addition, the main module collects load data at fixed time intervals (e.g., 30 seconds), and only when the conditions are met after N consecutive sampling results are triggered will the state adjustment be activated. N is a positive integer, such as 3. This mechanism is used to avoid erroneous switching caused by instantaneous load fluctuations.

[0041] Step 22: After the running state of the slave module is downgraded, if the time for maintaining the current state exceeds the first preset duration, and the average CPU utilization rate in the second load state is lower than the third preset threshold and the total task queue backlog length in the second load state is lower than the fourth preset threshold, the running state of the slave module is downgraded again, wherein the third preset threshold is less than the second preset threshold.

[0042] Degrading the running state of a module means downgrading the running state of a module from running state to standby state, or from standby state to hibernation state.

[0043] As can be seen, in this embodiment, degradation refers to switching the module's operating state from a high-power, high-response state to a low-power, low-response state. This embodiment defines three states: running state (full functionality), standby state (core processes retained), and hibernation state (heartbeat only maintained). In standby state, the module retains its core processes, suspends non-critical service thread pools, reduces CPU utilization to below 30% of the normal operating average, and keeps memory resident but allows swapping to disk. The module can quickly (within seconds) recover to running state in this state. In hibernation state, the module only maintains the heartbeat sending thread (heartbeat cycle ≤ 2 minutes), releases all business processing threads and most memory cache, with CPU utilization ≤ 5% and memory utilization ≤ 10%. The module consumes very little power in this state, but recovering to running state takes a relatively long time (e.g., 30-60 seconds).

[0044] Furthermore, the first preset threshold is used to determine the upper limit of the overall load index for judging whether a single module is idle. When the overall load index of a module is lower than this threshold, the module is considered to have a low current load and can be considered for degradation. The second preset threshold is used to determine the upper limit of the average CPU utilization rate for judging whether the entire system is idle. When the average CPU utilization rate of all modules is lower than this threshold, the cloud platform is considered to be in a low-load state, and module degradation is allowed. The first preset duration refers to the minimum time that a module needs to remain in the standby state after being degraded from the running state. Only if this duration is exceeded and the entire system is still idle can further degradation to the hibernation state be allowed, for example, a value of 30 minutes. The third preset threshold is used to determine whether the entire system is idle enough to allow entering the hibernation state, with an upper limit of the average CPU utilization rate. This threshold is less than the second preset threshold, indicating that entering the hibernation state requires the system to be even more idle. For example, the second preset threshold is 15%, and the third preset threshold is 10%. The fourth preset threshold is used to determine the upper limit of the total task queue backlog length for judging whether the entire system is idle. When the total queue backlog length is lower than this threshold (e.g., 100 tasks), it indicates that there is no task backlog, and further degradation is allowed.

[0045] In the specific example of steps 21 and 22 above, the cloud platform deploys multiple modules: device access modules (2), data parsing modules (3), and computing processing modules (4). The main module is one of the computing processing modules.

[0046] Scenario 1: Degrading from running state to standby state Time: 10:30 PM. Most of the office building's air conditioning equipment has been turned off, and the reporting frequency has decreased from 500 reports per second to 30 reports per second. The monitoring data consists of three consecutive cycles, each lasting 30 seconds. Based on this: Data parsing module D1: CPU utilization 8%, memory utilization 15%, queue length 5, therefore, the overall load index is approximately 0.12; Data parsing module D2: CPU utilization 6%, memory utilization 12%, queue length 3, therefore, the overall load index is approximately 0.09; Data parsing module D3: CPU utilization 10%, memory utilization 18%, queue length 7, therefore, the overall load index is approximately 0.15; Second load condition: Average CPU utilization of all modules = 12% (lower than the second preset threshold of 15%). As can be seen, within three consecutive cycles, the combined load index of modules D1, D2, and D3 is less than the first preset threshold (e.g., 0.2), and the overall average CPU is lower than the second preset threshold. The main module's judgment condition is met, and it sends a degradation instruction to D1, D2, and D3, switching them from the running state to the standby state.

[0047] In standby mode, the module suspends non-critical services (such as real-time statistical report generation) but retains the core parsing thread, reducing CPU usage to approximately 3%~5% while keeping memory resident. When new data arrives, full functionality can be restored within 2~3 seconds.

[0048] Scenario 2: Further downgrade from standby mode to hibernation mode; Time: 01:00 AM, device reporting frequency dropped to 5 messages per second, system had virtually no tasks. Monitoring data: D1, D2, and D3 have been in standby mode for 2.5 hours (exceeding the first preset duration of 30 minutes).

[0049] Second load status: Average CPU utilization = 5% (below the third preset threshold of 10%), total task queue backlog length = 0 (below the fourth preset threshold of 100).

[0050] As can be seen, the module remained in standby mode for more than 30 minutes, and the average CPU usage in the second load state was below 10% with a total queue backlog of 0. The main module's condition was met, and it sent further degradation instructions to D1, D2, and D3, switching them from standby to hibernation mode. In hibernation mode, the module released all business processing threads, stopped memory caching, and only retained the heartbeat report every 2 minutes. CPU utilization dropped below 1%, and memory utilization dropped below 5%. However, the wake-up time was approximately 45 seconds.

[0051] As can be seen, in this embodiment, by employing a two-level degradation strategy, placing non-core modules in standby mode during low-load periods can significantly save power, while placing them in hibernation mode during extremely low-load periods can further save power. The standby mode retains core processes, allowing full functionality to be restored within seconds, avoiding the cold start delay caused by direct hibernation. Hibernation mode, as a deep energy-saving measure, is only activated during prolonged periods of idle time and is restored before peak hours through a pre-wake-up mechanism. Furthermore, in this embodiment, multiple anti-jitter designs (continuous cycle, duration, and lag interval) ensure smooth state transitions, avoiding unnecessary migrations caused by minor load fluctuations and reducing computational overhead and network message volume associated with state changes. Additionally, after degradation, the computing resources released by idle modules can be used for other tasks (such as offline data analysis) or the nodes can be added to a resource pool in a containerized environment for other services to request, improving the overall resource reuse rate of the cloud platform.

[0052] In the embodiments of this application, such as Figure 3 As shown, the method of adjusting the operating status of the slave module in real time by combining the first load state and the second load state involved in step 103 above can further include: Step 31: After downgrading the running status of the sub-module, predict the next peak running time window of the cloud platform load based on the second load status obtained from historical periodicity. Step 32: At a preset time point before the peak time window, send a wake-up command to the slave module that is in hibernation or standby mode. The wake-up command is used to upgrade the running status of the slave module.

[0053] As can be seen, in this embodiment, historical periodic acquisition refers to the main module continuously recording the second load state at fixed time intervals (e.g., 1 minute) to form a time-series database. Analysis of this historical data can identify regular load patterns such as daily and weekly cycles (e.g., a commercial air conditioning system experiences two peak load reports each morning and evening). The peak operating time window refers to the time interval within which the future load peak is predicted based on historical periodic analysis. Since load peaks are usually not precise to a single second but rather a continuous time period (e.g., 7:45 AM to 8:15 AM), a time window description is more accurate. The start time, end time, and width of the window can be determined using statistical methods (e.g., half-peak full width).

[0054] Furthermore, the preset time point refers to the moment when the wake-up command is triggered ahead of the predicted peak time window. This time point needs to be calculated based on the module's cold start time (the time required to recover from hibernation or standby to operation) and the system's safety redundancy. For example, if it takes 45 seconds for a module to recover from hibernation to operation, then the preset time point should be the peak window start time minus 45 seconds (plus a small amount of redundancy).

[0055] In a specific example, for steps 31 and 32 above, the cloud platform manages the air conditioning equipment in a large office park. Historical data shows that 7:45-8:15 AM and 5:45-6:15 PM on weekdays are the two peak times for device reporting and data processing. At night (11:00 PM to 6:00 AM), the system is under extremely low load, and the main module has degraded most non-core modules (such as data parsing and computation processing modules) to hibernation or standby mode through a degradation mechanism.

[0056] Based on this, the main module records the secondary load status (request arrival rate per unit time, average CPU utilization, etc.) at a 1-minute granularity every day. After 7 days of accumulation, the main module identified a clear daily cycle: the peak request arrival rate reached 5000 requests / second from 7:45 to 8:15 am on weekdays, and the peak reached 4500 requests / second from 5:45 to 6:15 pm; there was no obvious peak on weekends.

[0057] The current time is 7:00 AM (Tuesday). Based on the second-highest historical load status over the past 7 days, the main module uses time series analysis (such as Fourier transform or autocorrelation function) to predict the next peak time window as 7:45 AM to 8:15 AM. Window start time = 7:45 AM, window end time = 8:15 AM, window width = 30 minutes.

[0058] The main module checks the list of modules currently in hibernation or standby mode, including: data parsing module D1 (hibernation, historical cold start time 45 seconds), data parsing module D2 (hibernation, historical cold start time 50 seconds), and calculation processing module C1 (standby, cold start time 5 seconds).

[0059] The main module calculates the preset wake-up time for each module (peak window start time minus module cold start time, minus preset redundancy duration, e.g., redundancy set to 15 seconds): D1: 7:45:00 - 45 seconds - 15 seconds = 7:44:00; D2: 7:45:00 - 50 seconds - 15 seconds = 7:43:55; C1: 7:45:00 - 5 seconds - 15 seconds = 7:44:40 (but wake-up from standby is extremely fast, and can be uniformly set to 7:44:00).

[0060] The main module sends wake-up commands according to the calculated time points: 7:43:55 Wake up D2; 7:44:00 Wake up D1 and C1.

[0061] After receiving the wake-up command, each module begins the upgrade from sleep / standby state to running state: D2 reached running state at 7:44:45 (+50 seconds); D1 reached the running state at 7:44:45 (+45 seconds); C1 reaches the running state at 7:44:05 (+5 seconds).

[0062] By 7:45:00 when the peak began, all modules were already running and able to process massive amounts of device data immediately without delay.

[0063] Based on the degradation process described above, we can see that, for example, the system degrades the module to a dormant state the previous night (to save energy). That morning, it actively wakes up before peak hours to restore processing capacity. After the peak period (e.g., 8:30 AM), the main module detects a decrease in load again, which may trigger the degradation conditions again, degrading the module back to standby or dormant state. This forms a complete closed loop: degradation for energy saving → predictive wake-up → peak processing → further degradation.

[0064] As can be seen, in this embodiment, the pre-wake-up mechanism ensures that modules are already running when peak load arrives, data processing has zero latency, and the task queue is not backed up. Furthermore, pre-wake-up avoids request timeouts or failures caused by cold starts, improving user experience and system stability. Based on this, all necessary modules are online and warmed up during peak periods, allowing the system to handle requests at full power, thereby increasing peak throughput.

[0065] Furthermore, the method of sending a wake-up command to the slave module in sleep or standby mode at a preset time point before the peak time window involved in step 32 above can further include: Step 41: Determine the preset time point based on the historical measured time of the module upgrading from the current state to the next state and the preset redundancy time; Step 42: Send a wake-up command to the slave module in sleep or standby mode according to the historical measured duration sorted from largest to smallest.

[0066] In this embodiment, the historical measured duration (i.e., the historical measured duration from the current state to the next state of the module) refers to the time consumed by the module in past actual operation to switch from a low-power state (such as sleep state or standby state) to a higher energy-efficiency state (such as standby state or running state). For example: Upgrading from dormant to running state requires reloading the business process, rebuilding the connection, restoring the cache, etc., which typically takes 30 to 60 seconds.

[0067] Upgrading from standby to running state: only requires activating the paused thread pool, which takes 2-5 seconds.

[0068] Upgrading from hibernation to standby: This usually falls somewhere in between, but in this application, the wake-up command usually points directly to the final target (running state), so the actual measured duration refers to the complete cold start time.

[0069] Based on this, the main module calculates the average value or sliding window average value through historical records (such as the actual time spent on the last 10 wake-ups) as the historical measured duration of the module.

[0070] In this application and embodiments, the preset redundancy duration is an additional safety period added on top of the historical measured duration to cope with uncertainties such as network jitter, system scheduling delays, and occasional slow starts of the module itself. For example, if the historical measured cold start time of a module is 45 seconds, and the redundancy duration is set to 15 seconds, then the actual reserved time is 60 seconds. The redundancy duration can be dynamically adjusted according to system stability (e.g., 30~300 seconds), or it can be configured by maintenance personnel.

[0071] Therefore, the preset time point = peak window start time - historical measured duration - preset redundancy duration. For example, if the peak window starts at 07:45:00, and the measured cold start of a certain module is 45 seconds with a redundancy of 15 seconds, then the preset time point is 07:44:00 (i.e., 60 seconds in advance), which can ensure that the module is fully ready at 07:45:00.

[0072] The sorting result based on historical test duration from longest to shortest means that all modules that need to be woken up are sorted according to their historical test duration from longest to shortest (i.e., the one with the longest required time is placed first), and then wake-up commands are sent in this order. The purpose of this is to ensure that the module with the slowest cold start is notified first, so that all modules can complete the upgrade as simultaneously as possible.

[0073] As can be seen, in this embodiment, each module is woken up in advance according to its actual startup time, and with the addition of redundant time, it is ensured that all necessary modules are in running state at the start of peak hours, eliminating cold start delay. Furthermore, to avoid unnecessary energy consumption caused by waking up modules too early (due to excessive advance), on-demand waking minimizes the time window during which modules wait for peak hours after becoming ready (typically only tens of seconds within the redundant time), thereby saving energy. In addition, through sorting optimization, all modules become ready almost simultaneously, avoiding the total time extension caused by serial waiting (such as waking up slow modules first and then waking up fast modules after they complete), and also avoiding prolonged idle time due to fast modules waking up too early.

[0074] In the embodiments of this application, such as Figure 4 As shown, the method of scheduling resources among slave modules by combining the first load state and the second load state in step 103 above can further include: Step 51: If the external request arrival rate per unit time in the second load state is greater than the fifth preset threshold, for slave modules of the same type, resource balancing scheduling is performed based on their respective first load states so that the difference between the first load states of slave modules of the same type is less than the sixth preset threshold.

[0075] In this embodiment, the external request arrival rate per unit time refers to the number of task requests sent to the cloud platform from external sources (such as terminal devices or user applications) per second. For example, the number of data entries reported per second by an air conditioning unit, or the number of queries initiated per second by a user app. This metric is a key signal for determining whether the system has entered a busy state.

[0076] Furthermore, in this embodiment, the fifth preset threshold is used as a critical value for the external request arrival rate to determine whether the system is under high load. When the request arrival rate exceeds this threshold, it indicates that the system is facing significant processing pressure and a resource scheduling mechanism needs to be activated. The sixth preset threshold is used to measure the upper limit of the load imbalance between modules of the same type. When the maximum difference between the first load states (such as the comprehensive load index) of each module exceeds this threshold, the load distribution is considered unbalanced, and a scheduling operation needs to be triggered.

[0077] Furthermore, resource-balanced scheduling refers to the master module dynamically adjusting the task allocation strategy based on the current load status of each slave module, so that the load among modules of the same type is as even as possible. Specifically, new tasks are assigned to the module with the lowest current load; if some modules are overloaded, their backlogged tasks can be migrated to modules with lower load.

[0078] As can be seen, in this embodiment, task allocation is actively balanced under high load to avoid some modules being overloaded while others are idle, thus fully utilizing the overall processing capacity of the cluster and improving throughput. By migrating tasks from high-load modules to low-load modules, the waiting time of tasks in the queue is reduced, and end-to-end latency is significantly decreased.

[0079] The present application will be further explained below with reference to specific embodiments, which provide a cloud platform resource scheduling method with module election and hibernation mechanisms, such as... Figure 5 As shown, the steps of this method include: Step 501, Module initialization and device connection; After the system powers on and starts up, the first step is to build a functional module architecture on the cloud platform side, such as... Figure 6 As shown, it specifically includes: a device access module for handling protocol conversion and data reception of heterogeneous devices; a data parsing module for structuring raw messages; a calculation processing module for executing business logic operations; and a resource monitoring module for collecting performance indicators of each node.

[0080] After initialization, each module reports metadata information to the system registry center, including at least its unique identifier, initial resource occupancy, and availability status. In an IoT application environment, taking a centralized commercial air conditioning management system as an example, the air conditioning equipment deployed on-site connects to the cloud platform via an edge gateway. The device access module establishes a long-term connection with the gateway, receives raw data streams reported by the devices, such as temperature, humidity, operating power, and fault codes, parses them using a protocol to form a standardized data format, and maintains a real-time updated module resource information table, providing a data foundation for subsequent scheduling decisions.

[0081] Step 502, Main Module Election; This application, based on a distributed master-slave collaborative mechanism, introduces resource weights to participate in the election of the master module, incorporating node resource capacity into the election weight calculation. During the election phase, candidate modules, when sending election requests, attach a real-time resource profile of their node, including metrics such as CPU utilization, memory usage percentage, and network I / O throughput. The remaining online module nodes, acting as voting nodes, execute a composite decision-making logic upon receiving the election request: first, verifying the log integrity and term number of the candidate nodes; second, comparing the resource redundancy of each candidate node. During peak air conditioning data processing periods, the system tends to elect the computational processing module with the lighter resource load as the master module to ensure real-time response to scheduling commands. This mechanism effectively avoids scheduling delays caused by the election of high-load nodes.

[0082] Step 503, Module operation status monitoring; The master module sends heartbeat probe messages to each slave module at preset time intervals (e.g., 30 seconds). Upon receiving the heartbeat request, each slave module reports its current operating status information back to the master module, including key operating indicators such as device data reception frequency, data processing volume per unit time, task queue backlog length, CPU utilization, memory usage, and network communication status. The master module continuously collects and analyzes the operating status reports from each slave module, dynamically sensing module load change trends and providing a basis for subsequent module state switching, resource scheduling, and task allocation.

[0083] For example, in a centralized management scenario for commercial air conditioning systems, the data processing pressure on the data parsing module increases significantly when a large number of devices come online simultaneously during peak start-up and shutdown times in the morning and evening. The main module, through periodic status monitoring, can promptly identify high-load modules and provide status references for subsequent task migration, module wake-up, or resource expansion, thereby ensuring the overall stability of the system and the efficiency of task response.

[0084] Step 504, Module status classification and dynamic adjustment; Based on real-time load levels, this invention defines three module states: normal operation state—the module operates at full capacity, handling routine business loads; standby state—the module retains core processes, reducing the consumption of non-critical service resources; and dormant state—the module maintains only minimal heartbeat communication, releasing computing resources.

[0085] In low-power operation scenarios at night, the reporting frequency of the air conditioning device decreases, the main module triggers a state transition instruction, switches some computing and processing modules to sleep mode, and retains only the basic listening capability of the device access module, thereby achieving energy consumption optimization on the cloud platform side.

[0086] Step 505, Load prediction and pre-wake-up processing; This application introduces a load forecasting model based on time series analysis. The main module analyzes historical data reporting patterns to identify periodic load patterns. For typical application scenarios of commercial air conditioning systems, before the start of daily office hours (e.g., 7:30), the system anticipates a surge in data traffic due to batch device startups and sends pre-wake-up commands to computing modules and data parsing modules in standby or dormant states, reserving a resource warm-up time window to eliminate the impact of cold start delays on business continuity.

[0087] Step 506, Task scheduling and communication optimization; When system load increases, the main module allocates tasks to different modules based on current resource availability. Simultaneously, during data transmission between modules, only changed data is synchronized, reducing communication overhead. For example, when air conditioner status changes infrequently, only changed device data is uploaded, rather than all data, improving overall system efficiency.

[0088] As can be seen from steps 501 to 506 above, in this embodiment, during the module election process, not only is the voting mechanism based on the traditional Raft algorithm used, but the real-time resource status of the module is also introduced as a dynamic weight, including indicators such as CPU utilization, memory usage, and task queue length, to comprehensively score candidate modules. During the voting phase, the module with the better score is prioritized as the master module. When the system detects a sustained high load on the master module's resources during operation, a re-election or master-slave switch can be triggered to ensure that the scheduling node is always in a better resource state. For example, when a computing module experiences a sustained increase in CPU usage due to processing a large amount of IoT device data, the system automatically switches the master module role to a standby node with a lower load to maintain scheduling efficiency. Furthermore, a hierarchical state management mechanism (running, standby, and dormant) is constructed for the module's operating state. Combined with historical request data and time characteristics, the system load change trend is analyzed. When an impending load increase is detected, modules in standby or dormant states are gradually woken up and their processing capacity is restored in batches according to priority to avoid concentrated startup overhead and response delays under sudden loads. For example, in the IoT scenario of commercial air conditioning, the system determines that the frequency of device reporting will increase before the start of the workday based on historical data, and restores some dormant computing modules to standby or running status in advance, so as to ensure that data processing will not be delayed or lost when devices are brought online in a concentrated manner.

[0089] Corresponding to the above Figure 1 This application also provides a control device for modules in a cloud platform, such as... Figure 7 As shown, the device includes: The first processing module 702 is used to determine whether a candidate module is the main module based on a composite decision-making method after a candidate module in the cloud platform sends an election request to other modules. The candidate module is any module among multiple modules in the cloud platform. The composite decision-making method means that the log integrity and term number of the candidate module are first verified, and the candidate module with the highest resource surplus is selected as the main module after the verification is passed. The second processing module 704 is used to obtain the first load status of other slave modules in the cloud platform and the second load status of the overall internal load of the cloud platform through the main module after the main module is selected. The control module 706 is used to adjust the operating status of the slave modules in real time and to schedule resources among the slave modules by combining the first load status and the second load status.

[0090] In an optional embodiment of this application, the first processing module in this application includes: The verification unit is used to verify the log integrity and term number of the candidate module; where the term number indicates the election round of the main module. The acquisition unit is used to acquire the resource redundancy of the verified candidate module when the log term number of the candidate module is greater than the log term number of other modules, or the log term number is equal to the log term number of other modules and the log sequence number of the candidate module is greater than or equal to the log sequence number of other modules. The first processing unit is used to select the candidate module with the highest resource surplus from the verified candidate modules as the main module.

[0091] In an optional embodiment of this application, the second processing module includes: The second processing unit is used to downgrade the running state of the slave module when the comprehensive load index of the first load state is less than the first preset threshold and the average CPU utilization rate in the second load state is lower than the second preset threshold within N consecutive cycles; wherein, the comprehensive load index is the weighted sum of CPU utilization rate, memory utilization rate and task queue length after normalization; N is a positive integer. The third processing unit is used to continue to downgrade the running state of the slave module after the running state of the slave module has been downgraded. If the time for maintaining the current state exceeds the first preset duration, and the average CPU utilization rate in the second load state is lower than the third preset threshold and the total task queue backlog length in the second load state is lower than the fourth preset threshold, the third preset threshold is less than the second preset threshold.

[0092] In an optional embodiment of this application, downgrading the running state of a slave module means downgrading the running state of the slave module from running state to standby state, or from standby state to hibernation state.

[0093] In an optional embodiment of this application, the control module includes: The fourth processing unit is used to predict the next peak operating time window of the cloud platform's load based on the second load status obtained periodically in history after the operating status of the slave module is downgraded. The fifth processing unit is used to send a wake-up command to the slave module in hibernation or standby mode at a preset time point before the peak time window. The wake-up command is used to upgrade the running status of the slave module.

[0094] In an optional embodiment of this application, the fifth processing unit performs the following steps: The preset time point is determined based on the historical measured time and preset redundancy time of upgrading the module from the current state to the next state. Wake-up commands are sent to slave modules in sleep or standby states based on the historical measured duration sorted from longest to shortest.

[0095] In an optional embodiment of this application, the control module includes: The sixth processing unit is used to perform resource balancing scheduling based on the first load state of each slave module of the same type when the external request arrival rate per unit time in the second load state is greater than the fifth preset threshold, so that the difference between the first load states of slave modules of the same type is less than the sixth preset threshold.

[0096] like Figure 8 As shown in the figure, this application provides an electronic device, including a processor 811, a communication interface 812, a memory 813, and a communication bus 814, wherein the processor 811, the communication interface 812, and the memory 813 communicate with each other through the communication bus 814. Memory 813 is used to store computer programs; In one embodiment of this application, when the processor 811 executes the program stored in the memory 813, it implements the control method of the module in the cloud platform provided in any of the aforementioned method embodiments, and its function is similar, so it will not be described again here.

[0097] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the control method for modules in a cloud platform as provided in any of the foregoing method embodiments.

[0098] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0099] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0100] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0101] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for controlling modules in a cloud platform, characterized in that, include: After a candidate module in the cloud platform sends an election request to other modules, a composite decision-making method is used to determine whether the candidate module is the main module. The candidate module is any one of multiple modules in the cloud platform. The composite decision-making method means that the log integrity and term number of the candidate module are first verified, and the candidate module with the highest resource surplus is selected as the main module after the verification is passed. After selecting the main module, the first load status of other slave modules in the cloud platform and the second load status of the overall internal load of the cloud platform are obtained through the main module. By combining the first load state and the second load state, the operating status of the slave modules is adjusted in real time, and resources among the slave modules are scheduled.

2. The method according to claim 1, characterized in that, After a candidate module in the cloud platform sends an election request to other modules, determining whether the candidate module is the main module based on a composite decision-making method includes: Verify the log integrity and term number of the candidate module; wherein, the term number represents the election round of the main module; If the log term number of the candidate module is greater than the log term number of other modules, or if the log term number is equal to the log term number of other modules and the log sequence number of the candidate module is greater than or equal to the log sequence number of other modules, the resource redundancy of the candidate module that has passed the verification is obtained. The candidate module with the highest resource surplus is selected from the verified candidate modules as the main module.

3. The method according to claim 1, characterized in that, Real-time adjustment of the operating status of the slave module based on the first load status and the second load status includes: If the overall load index of the first load state is less than a first preset threshold and the average CPU utilization rate in the second load state is lower than a second preset threshold for N consecutive cycles, the operating state of the slave module is downgraded; wherein, the overall load index is the weighted sum of CPU utilization rate, memory utilization rate and task queue length after normalization; N is a positive integer; After the running state of the slave module is downgraded, if the time for maintaining the current state exceeds the first preset duration, and the average CPU utilization rate in the second load state is lower than the third preset threshold and the total task queue backlog length in the second load state is lower than the fourth preset threshold, the running state of the slave module will continue to be downgraded, wherein the third preset threshold is less than the second preset threshold.

4. The method according to claim 3, characterized in that, Degrading the operating state of the slave module includes: The running state of the module is downgraded from running state to standby state, or from standby state to hibernation state.

5. The method according to claim 3, characterized in that, The operating status of the slave module is adjusted in real time based on the first load status and the second load status, including: After downgrading the operating status of the module, the next peak operating time window of the cloud platform's load is predicted based on the second load status obtained from historical periodic data. A wake-up command is sent to the slave module in hibernation or standby mode at a preset time point before the peak time window. The wake-up command is used to upgrade the operating status of the slave module.

6. The method according to claim 5, characterized in that, Send a wake-up command to the slave module in sleep or standby mode at a preset time point before the peak time window, including: The preset time point is determined based on the historical measured time and preset redundancy time of the module upgrading from the current state to the next state; The wake-up command is sent to the slave modules that are in sleep or standby mode, based on the historical measured duration sorted from largest to smallest.

7. The method according to claim 1, characterized in that, Scheduling resources among the slave modules based on the first load state and the second load state includes: If the external request arrival rate per unit time in the second load state is greater than the fifth preset threshold, for slave modules of the same type, resource balancing scheduling is performed based on their respective first load states so that the difference between the first load states of slave modules of the same type is less than the sixth preset threshold.

8. A control device for a module in a cloud platform, characterized in that, include: The first processing module is used to determine whether a candidate module is the main module based on a composite decision-making method after a candidate module in the cloud platform sends an election request to other modules. The candidate module is any one of multiple modules in the cloud platform. The composite decision-making method means that the log integrity and term number of the candidate module are first verified, and the candidate module with the highest resource surplus is selected as the main module after the verification is passed. The second processing module is used to obtain the first load status of other slave modules in the cloud platform and the second load status of the overall internal load of the cloud platform through the main module after the main module is selected. The control module is used to adjust the operating status of the slave modules in real time by combining the first load status and the second load status, and to schedule resources among the slave modules.

9. An electronic device, characterized in that, include: The system includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus; the memory is used to store computer programs; and the processor is used to execute the computer programs to implement the control method of the modules in the cloud platform according to any one of claims 1-7.

10. A storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the control method for the modules in the cloud platform according to any one of claims 1-7.

Images