Method and device for scheduling cloud computing resources in the field of urban simulation

Abstract

The present invention proposes a scheduling method and device for cloud computing resources in the field of urban simulation, including: S1, initializing a server list; S2, setting a cycle; S3, processing task requests; S4, identifying tasks with high response time requirements; S5, adjusting reserved resources; S6, monitoring reserved resource servers; S7, task allocation; S8, updating server status and adjusting reserved resources. The present invention can monitor task requests and server status in real time, dynamically adjust the scale of reserved resources, ensure that when tasks with high response time requirements appear, it can respond quickly and allocate sufficient resources, and at the same time can more accurately judge the resource requirements in the field of urban simulation to avoid over-allocation or under-allocation of resources.

Description

Technical Field

[0001] The present invention belongs to the field of information technology, and in particular relates to a method and device for scheduling cloud computing resources in the field of urban simulation. Background Art

[0002] Traditional cloud computing resource allocation mainly uses virtualization technology to encapsulate physical resources (such as CPU, memory, and storage) into independent virtual resources to form a resource pool. These resources are statically or dynamically allocated according to user needs to support the operation of applications of different scales. Resource scheduling algorithms such as first come first served (FCFS) and shortest job first (SJF) are used to determine the specific resource allocation strategy.

[0003] The field of urban simulation has put forward unique requirements for cloud computing resource allocation. First, urban simulation involves large-scale data processing and high-precision calculations, requiring cloud computing platforms to provide strong computing power and high scalability. Second, the simulation process requires real-time feedback and rapid iteration to support decision-making and solution optimization.

[0004] Traditional cloud computing resource allocation methods face challenges in the field of urban simulation. First, the demand for resources in urban simulation changes dynamically, and traditional static or simple dynamic allocation methods are difficult to respond in real time. Second, urban simulation requires high concurrent processing and low-latency feedback, while traditional resource allocation algorithms have limitations in optimizing resource utilization and response speed. Therefore, it is necessary to design a more intelligent, flexible and secure cloud computing resource allocation solution based on the characteristics of the urban simulation field. Summary of the invention

[0005] The present invention proposes a scheduling method and device for cloud computing resources in the field of urban simulation, which can make cloud computing resource allocation more efficient and better adapt to the complex and changeable workloads in the field of urban simulation.

[0006] To achieve the above object, the technical solution of the present invention is achieved as follows:

[0007] A method for scheduling cloud computing resources in the field of urban simulation, comprising:

[0008] S1. Initialize the server list:

[0009] The initialization includes the average response time of each server, the maximum request number threshold, and whether it is marked as a reserved resource server; the initialization value of whether it is marked as a reserved resource server is no;

[0010] S2, set cycle:

[0011] Set a fixed period for calculating server weights, updating server lists, and monitoring task requests;

[0012] S3, task request processing:

[0013] receiving a task request sent by a user according to conventional means and assigning it to a server as a conventional task, and monitoring whether the user sends a task request for the second time due to no server response within a predetermined time;

[0014] S4. Identify tasks with high reaction time requirements:

[0015] Identify the second task request issued by the user as a task with high response time requirement;

[0016] S5. Adjust reserved resources:

[0017] When a task with high response time requirement is identified, the server with the least current tasks is found and marked as a reserved resource server. Regular tasks are no longer assigned to the reserved resource server, only the task with high response time requirement is assigned, and the task with high response time requirement is placed before the regular tasks that have not yet been completed.

[0018] S6. Monitor the reserved resource server:

[0019] Monitor the number of unprocessed tasks of the reserved resource server in real time, and if the number of unprocessed tasks exceeds the maximum request number threshold, select other servers with fewer tasks to join, so as to expand the scale of the reserved resource server;

[0020] S7. Task allocation:

[0021] For regular tasks, the basic allocation strategy is used to allocate tasks based on the server weight and the current number of requests. For tasks with high response time requirements, servers are directly allocated from reserved resource servers to handle them.

[0022] The basic allocation strategy includes:

[0023] S701, define server weight; the server weight Wi is defined as the reciprocal of the server average response time Ri, that is, Wi=1 / Ri;

[0024] S702, calculating the allocation probability; the allocation probability is proportional to the server weight, ; Where n is the total number of servers, i and j represent the serial numbers of the servers;

[0025] S703, consider the number of tasks that have been assigned: when assigning tasks, it is necessary to consider the number of tasks Ti that have been assigned by the server but have not yet been executed; if Ti plus the number of newly assigned tasks t exceeds the maximum request number threshold Ci of the server, the server will no longer assign new tasks and set the assignment probability to 0;

[0026] S704, task allocation decision: based on the allocation probability, randomly select a server with different probabilities to allocate the task;

[0027] S705, updating server status: after each task is assigned, updating the task quantity Ti of the selected server;

[0028] S8. Update server status and adjust reserved resources:

[0029] At the end of each cycle, the average reaction time of the servers in the server list is updated. If no high reaction time requirement tasks occur during the entire cycle, whether the server is marked as a reserved resource server is reset to No.

[0030] Furthermore, the initialization of the average reaction time in step S1 includes:

[0031] S101, monitor the actual task request and processing process of the server, set monitoring points and record timestamps;

[0032] S102, collecting task actual response time data, calculating and storing it according to the timestamp of the monitoring point;

[0033] S103 , regularly summarizing the reaction times of all actual tasks in the period, and calculating an average value as an initialization value of the average reaction time.

[0034] Furthermore, the method for initializing the maximum request number threshold in step S1 includes:

[0035] Analyze the number of CPU cores, memory size, and disk I / O capabilities of the server; evaluate the number of concurrent tasks that the server can efficiently handle based on the computing intensity, memory usage, and disk read and write frequency of the tasks; and set an upper limit on the number of requests as the maximum request number threshold.

[0036] Furthermore, the method for setting the cycle in step S2 includes: ：

[0037] According to the task types of urban simulation systems, including computationally intensive, I / O intensive, or mixed tasks, as well as the real-time requirements of the tasks, the utilization rate of system resources is considered, the average arrival rate of tasks is counted, the average time required for tasks to be received and completed is measured, the current load of the system is monitored, and the cycle duration is set to respond to task requests in a timely manner and effectively manage resource allocation; after setting the cycle duration, adjustments and optimizations are made through actual operation and monitoring of system status.

[0038] On the other hand, the present invention also proposes a scheduling device for cloud computing resources in the field of urban simulation, comprising:

[0039] An initialization module, used to initialize the server list: the initialization includes the average response time of each server, the maximum request number threshold, and whether it is marked as a reserved resource server; the initialization value of whether it is marked as a reserved resource server is no;

[0040] The cycle module is used to set the cycle: set a fixed cycle to calculate server weights, update server lists, and monitor task requests;

[0041] Task request processing module: receiving task requests sent by users according to conventional means and assigning them to servers as regular tasks, monitoring whether users send task requests for the second time due to no server response within a predetermined time;

[0042] An identification module, used for identifying tasks requiring high reaction time: identifying the task request sent by the user for the second time as a task requiring high reaction time;

[0043] Adjust the reserved resource module: When a task with high response time requirement is identified, find the server with the least current tasks and mark it as a reserved resource server. No longer assign regular tasks to the reserved resource server, only assign tasks with high response time requirement, and arrange the tasks with high response time requirement before the regular tasks that have not yet been completed.

[0044] A monitoring module is used to monitor the reserved resource server: monitor the number of unprocessed tasks of the reserved resource server in real time, and if the number of unprocessed tasks exceeds the maximum request number threshold, select other servers with fewer tasks to join, so as to expand the scale of the reserved resource server;

[0045] Task allocation module: For conventional tasks, the basic allocation strategy is used to allocate tasks according to the server weight and the current number of requests; for tasks with high response time requirements, servers are directly allocated from the reserved resource servers to handle them; the task allocation module includes a basic allocation strategy submodule, and the basic allocation strategy submodule includes: a server weight definition unit: the server weight Wi is defined as the inverse of the server average response time Ri, that is, Wi=1 / Ri; a calculation allocation probability unit: the allocation probability is proportional to the server weight, ; Where n is the total number of servers, i and j represent the serial numbers of the servers; Consider the number of tasks that have been assigned but not yet executed by the server, Ti; If Ti plus the number of newly assigned tasks t exceeds the maximum request number threshold Ci of the server, the server will no longer assign new tasks and the assignment probability will be set to 0; Task assignment decision unit: Based on the assignment probability, a server is randomly selected with different probabilities to assign tasks; Server status update unit: After each task is assigned, the number of tasks Ti of the selected server is updated;

[0046] Update module: Update server status and reserve resource adjustment:

[0047] At the end of each cycle, the average reaction time of the servers in the server list is updated. If no high reaction time requirement tasks occur during the entire cycle, whether the server is marked as a reserved resource server is reset to No.

[0048] Furthermore, the initialization module includes:

[0049] Monitoring unit: monitors the actual task request and processing process of the server, sets monitoring points and records timestamps;

[0050] Collection unit: collects the actual response time data of the task, calculates and stores it according to the timestamp of the monitoring point;

[0051] Calculation unit: regularly summarizes the reaction time of all actual tasks in the period, calculates the average value, and uses it as the initialization value of the average reaction time.

[0052] Furthermore, the initialization module includes:

[0053] Maximum request number threshold unit: analyzes the number of CPU cores, memory size, and disk I / O capabilities of the server; evaluates the number of concurrent tasks that the server can efficiently handle based on the computing intensity, memory usage, and disk read and write frequency of the tasks; and sets an upper limit on the number of requests as the maximum request number threshold.

[0054] Furthermore, the cycle module includes ：

[0055] Setting unit: According to the task types of the urban simulation system, including computationally intensive, I / O intensive or mixed tasks, and the real-time requirements of the tasks, consider the utilization of system resources, calculate the average arrival rate of tasks, measure the average time required from task reception to completion, monitor the current load of the system, and set the cycle duration that can respond to task requests in a timely manner and effectively manage resource allocation;

[0056] Adjustment unit: After setting the cycle duration, make adjustments and optimizations through actual operation and monitoring of system status.

[0057] Compared with the prior art, the present invention has the following beneficial effects:

[0058] 1. The present invention has high flexibility and dynamic adaptability: The solution of the present invention can monitor task requests and server status in real time, dynamically adjust the size of the reserved resource pool, and ensure that when tasks with high response time requirements appear, they can respond quickly and allocate sufficient resources. This flexibility makes resource allocation more efficient and can better adapt to the complex and changeable workloads in the field of urban simulation.

[0059] 2. The present invention optimizes resource utilization: Through intelligent monitoring and dynamic resource adjustment, the present invention can more accurately determine the resource demand in the urban simulation field and avoid over-allocation or under-allocation of resources. This can not only reduce resource waste, but also ensure that key tasks receive sufficient resource support when needed, thereby improving the performance and stability of the overall system. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Figure 1 It is a schematic diagram of a flow chart of an embodiment of the present invention. DETAILED DESCRIPTION

[0061] It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments may be combined with each other.

[0062] In order to make the purpose and features of the present invention more obvious and understandable, the present invention is further described below in conjunction with the accompanying drawings and specific embodiments.

[0063] In this embodiment, the "system" mentioned below refers to the cloud computing platform system.

[0064] The scheduling method of cloud computing resources in the field of urban simulation, such as Figure 1 As shown, including:

[0065] Step 1: Initialize the server list:

[0066] Including the average response time of each server, the current number of requests, the maximum request number threshold, and whether it is a reserved resource server.

[0067] Here is how to do it:

[0068] Step 1.1: Create a server list.

[0069] Create a list of all available servers on the system.

[0070] Each server is assigned a unique identifier.

[0071] Step 1.2: Record the server properties.

[0072] 1.2.1 Record the average response time of each server, obtained through regular measurement and calculation.

[0073] Step refinement: Record the actual average response time of each server

[0074] 1.2.1.1 Monitor actual task requests:

[0075] Set monitoring points: Set monitoring points at the key processing nodes of each server (such as task reception, task start execution, task completion, etc.).

[0076] Record timestamps: Record detailed timestamp information when tasks enter and leave these monitoring points.

[0077] 1.2.1.2 Collect actual reaction time data:

[0078] Calculate task reaction time: For each actual task, use the timestamp of leaving the task receiving monitoring point minus the timestamp of entering the monitoring point to get the reaction time of the task.

[0079] Store data: Store the reaction time of each task in a database or in-memory data structure so that the average reaction time can be calculated later.

[0080] 1.2.1.3 Calculating the average reaction time

[0081] Periodic summary: Set a fixed time period (such as every hour, every day, etc.) and regularly summarize the response time of all actual tasks within that period.

[0082] Calculate the average: Sum the aggregated reaction time data and divide by the total number of tasks to get the average reaction time for that period.

[0083] 1.2.2 Set and record the maximum number of requests for each server to prevent overload.

[0084] First, analyze the server's hardware performance indicators, such as the number of CPU cores, memory size, and disk I / O capacity. Then, combined with business requirements, such as the computing intensity of the task, memory usage, and disk read and write frequency, evaluate the number of concurrent tasks that the server can efficiently handle. Based on hardware performance and business requirements, set an upper limit on the number of requests that can ensure service quality without overloading through stress testing or empirical estimation. This upper limit should be used as a configuration parameter of the server to facilitate dynamic adjustment to adapt to changing requirements in different scenarios.

[0085] 1.2.3 Mark whether each server is a reserved resource server, initialized to "no".

[0086] Step 1.3: Initialize the server state.

[0087] Set the current number of requests for each server to 0.

[0088] Verify that the Reserved Resource Servers flag is set to No for all servers.

[0089] Step 2: Set the cycle:

[0090] Set a fixed period to calculate server weight, update server status, and monitor task requests.

[0091] Step 2.1: Determine the cycle length.

[0092] Determine a reasonable cycle length based on system requirements and actual task processing conditions.

[0093] Steps to determine cycle length

[0094] Analyze system requirements:

[0095] Task type: Understand the type of tasks processed in the system, including compute-intensive, I / O-intensive, or mixed tasks.

[0096] Real-time requirements: Evaluate the real-time requirements of the task, that is, how long it takes for the task to be responded to or completed.

[0097] Resource utilization: Consider the utilization of system resources, including CPU, memory, and storage.

[0098] Evaluation task processing actual situation:

[0099] Task arrival rate: The average arrival rate of statistical tasks, that is, the number of tasks arriving at the system per unit time.

[0100] Task processing time: Measures the average time it takes for a task to be completed from the time it is received.

[0101] System load: monitor the current load of the system, including CPU usage, memory usage, etc.

[0102] Set cycle duration:

[0103] Comprehensive consideration: Based on system requirements and the actual situation of task processing, select a cycle duration that can both respond to task requests in a timely manner and effectively manage resource allocation.

[0104] Experimentation and adjustment: After initially setting the cycle duration, make necessary adjustments and optimizations through actual operation and monitoring of system performance.

[0105] Example

[0106] Suppose a city simulation cloud computing system needs to process a large amount of real-time traffic data and requires the system to respond quickly to changes in traffic conditions. The system requirements should be analyzed first, and it is found that the tasks are mainly computationally intensive and have high real-time requirements. Then the actual situation of task processing is evaluated, and it is found that the average arrival rate of tasks is high, but the processing time of each task is relatively short.

[0107] Based on this information, a shorter cycle can be initially set, such as calculating the average server response time and updating the server status every 5 minutes. However, in actual operation, it is found that this cycle may be too frequent, resulting in a waste of system resources (such as CPU and memory). Therefore, the cycle length is gradually adjusted to finally determine a reasonable cycle length that can meet real-time requirements and effectively manage resources, such as every 10 minutes or 15 minutes.

[0108] Step 2.2: Set the timer.

[0109] Use the timer function provided by the system or write a scheduled task script to trigger the task at a specified period.

[0110] Step 3: Task request processing:

[0111] The user first sends a task request according to conventional means. If the server fails to respond within a predetermined time, the user sends the task request again.

[0112] The following is the specific implementation process of step 3 task request processing:

[0113] Step 3.1: The user initiates a task request.

[0114] The user terminal initiates a new task request through the system interface or the user terminal interface according to the normal operation. This request contains the relevant information and requirements of the task that the user terminal wants to perform.

[0115] Step 3.2: Wait for the server to respond.

[0116] After the client submits a task request, the system will start processing the request. At this point, the client needs to wait for the server's response.

[0117] Step 3.3: Determine whether the response has timed out.

[0118] The user sets or the system provides a predetermined response time threshold.

[0119] If the client does not receive any response from the server within the preset time, it will be considered that the response has timed out.

[0120] Step 3.4: The user initiates the request again.

[0121] Once the timeout occurs, the user client initiates the request again. The user client can adjust the content of the request or add additional information according to the agreement between the user client and the server, such as increasing the importance or urgency of the request, and then send it within the scheduled time so that the system can monitor and identify it and process it with higher priority.

[0122] Step 4: Identify tasks with high reaction time requirements:

[0123] The server monitors the task request sent for the second time and identifies it as a task with high response time requirement.

[0124] The following is the detailed process flow for step 4 to identify tasks with high response time requirements:

[0125] Step 4.1: Monitor task requests

[0126] The server or system monitoring component continuously monitors all incoming task requests, including initial and subsequent requests.

[0127] Step 4.2: Detect the second request

[0128] When the monitoring component detects that the same task (or a similar task from the same user) is sent for the second time within the scheduled time, the processing flow of step 5 is triggered. (The user side can also adjust the request content or add additional information to identify the request according to the agreement between the user side and the server.

[0129] Step 5: Adjust reserved resources:

[0130] When a task with high response time requirement is identified, the system looks for the server with the least current tasks and marks it as a reserved resource server. The reserved resource server no longer receives regular tasks, but only receives tasks issued for the second time, and puts the second-issued tasks before the regular tasks that have not yet been completed.

[0131] The specific implementation method of step five is:

[0132] Step 5.1: Find the server with the fewest current tasks.

[0133] The system traverses all available servers and checks the current task queue length or the number of tasks being processed by each server.

[0134] Select a server with the least number of tasks as a candidate for reserving resources.

[0135] Step 5.2: Mark the reserved resource server.

[0136] The system marks the selected server as a reserved resource server and updates its status information.

[0137] The marked servers will no longer receive regular task requests (that is, the system will no longer assign regular requests to the marked servers) and will only be used to process tasks with high response time requirements.

[0138] Step 5.3: Adjust the task queue.

[0139] The system inserts the high response time requirement task issued for the second time into the task queue of the reserved resource server.

[0140] If the server already has regular tasks that are being executed or waiting to be executed, the new task will be queued before them to ensure priority execution.

[0141] Step 6: Monitor the reserved resource server:

[0142] The number of unprocessed tasks of the reserved resource server is monitored in real time. If the number of unprocessed tasks exceeds the set threshold, the scale of the reserved resource server is expanded, that is, other servers with fewer tasks are selected to be marked as reserved resource servers and added to the reserved resource pool.

[0143] The following is the specific implementation process of step 6 monitoring the reserved resource server:

[0144] Step 6.1: Monitor the number of unprocessed tasks in real time.

[0145] The system continuously monitors the number of unprocessed tasks of the reserved resource server, that is, the number of tasks in the current task queue.

[0146] Step 6.2: Set the threshold

[0147] The system administrator or automatic configuration mechanism sets a threshold for the number of unprocessed tasks for the reserved resource server.

[0148] This threshold represents the number of unprocessed tasks on the server when capacity expansion measures need to be taken.

[0149] Step 6.3: Determine whether capacity expansion is needed.

[0150] The system periodically or in real time determines whether the number of unprocessed tasks of the reserved resource server exceeds a set threshold.

[0151] If it is exceeded, the expansion mechanism is triggered; if it is not exceeded, monitoring continues.

[0152] Step 6.4: Select another server with fewer tasks.

[0153] When capacity expansion is needed, the system traverses all available non-reserved resource servers and checks their current task queue lengths or the number of tasks being processed.

[0154] One or more servers with fewer tasks are selected as candidates for new reserved resource servers.

[0155] Step 6.5: Add to the reserved resource pool.

[0156] The system marks the selected server as a reserved resource server and updates its status information.

[0157] These newly added servers will no longer receive regular task requests and will only be used to handle tasks with high response time requirements.

[0158] Step 7: Task Assignment:

[0159] For tasks that do not require high response time (i.e., regular tasks), the basic allocation strategy is used to allocate tasks based on the server weight and the current number of requests; for tasks that require high response time, servers are directly allocated from the reserved resource servers to handle them.

[0160] For tasks that do not require high response time (i.e., regular tasks), a distribution strategy based on server weight and task quantity can be used. The specific solution is as follows:

[0161] Define server weights:

[0162] The weight Wi of a server is defined as the inverse of its average response time Ri, that is, Wi = 1 / Ri. In this way, the server with a shorter average response time has a greater weight and a higher probability of being assigned a task.

[0163] Calculate the assignment probability:

[0164] For each server, calculate its allocation probability Pi, which is proportional to the weight of the server, that is, , where n is the total number of servers, .

[0165] Consider the number of assigned tasks:

[0166] When assigning tasks, the number of tasks Ti that the server has assigned but not yet executed needs to be considered. If Ti plus the number of newly assigned tasks t exceeds the total number of tasks Ci of the server, the server should not accept new tasks.

[0167] Task allocation decisions:

[0168] For each new task, follow these steps to assign it:

[0169] Calculate the allocation probability Pi for each server.

[0170] For each server, check whether Ti+t≤Ci holds. If not, set the allocation probability of the server to 0.

[0171] According to the updated allocation probability, a probability-based random allocation is performed with different probabilities to select a server to allocate the task.

[0172] Update server status:

[0173] After each task is assigned, the number of assigned tasks Ti of the selected server is updated.

[0174] The mathematical formula is as follows:

[0175] Server weight: Wi=1 / Ri;

[0176] Assignment probability: (valid when Ti+t≤Ci, otherwise Pi=0);

[0177] Task allocation decision: Randomly select a server k such that k=argmaxi(random()≤Pi), where random() generates a random number between [0, 1].

[0178] In this way, it is ensured that tasks are distributed among servers according to the inverse of their reaction time as a weight, while taking into account the number of assigned tasks of the server to avoid overloading.

[0179] For tasks with high response time requirements, servers are directly allocated from reserved resource servers to handle them. The specific execution method is as follows:

[0180] If there is only one reserved resource server, the task with high response time requirement is directly provided to the reserved resource server; if there are multiple reserved resource servers, the server can be selected in the same way as the task without high response time requirement.

[0181] Step 8: Update server status and adjust reserved resources:

[0182] At the end of each cycle, the server's average response time, current number of requests and other status information are updated. If no high response time requirement tasks occur during the entire cycle, the reserved resource server is reset to a regular server.

[0183] The following is the specific implementation process of step 8 updating server status and adjusting reserved resources:

[0184] Step 8.1: End of cycle trigger.

[0185] When the system-set period ends, the server status update and reserved resource adjustment tasks are triggered.

[0186] Step 8.2: Collect server status information.

[0187] The system traverses all servers and collects their current status information, including average response time, current number of requests, task queue length, etc.

[0188] Step 8.3: Update the server status.

[0189] The collected status information is updated to the server's status record for subsequent analysis and processing.

[0190] Step 8.4: Examine high reaction time demanding tasks.

[0191] The system checks whether any tasks with high reaction time requirements occur during the entire cycle.

[0192] This can be done by examining task request records, monitoring logs, or specific event markers.

[0193] Step 8.5: Adjust reserved resources.

[0194] If no high response time requirement tasks occur during the entire cycle, the system performs the following operations:

[0195] Reset the reserved resource server to a regular server, that is, cancel the mark of its reserved resources.

[0196] Updates the server's status information to reflect its new role and availability.

[0197] Notify the server about its state change so that it can begin accepting and processing regular tasks.

[0198] Step 8.6: Enter the next cycle.

[0199] After completing the server status update and reserved resource adjustment, the system is ready to enter the next cycle and continue to monitor and process task requests.

[0200] Through the solution, this embodiment can monitor task requests and server status in real time, dynamically adjust the size of the reserved resource pool, and ensure that when tasks with high response time requirements occur, they can respond quickly and allocate sufficient resources.

[0201] This embodiment optimizes resource utilization and more accurately determines resource demand in the urban simulation field through intelligent monitoring and dynamic resource adjustment, thereby avoiding over-allocation or under-allocation of resources.

[0202] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for scheduling cloud computing resources in the field of urban simulation, characterized in that: include: S1. Initialize the server list: The initialization includes the average response time of each server, the maximum request number threshold, and whether it is marked as a reserved resource server; The initialization value of whether to mark as a reserved resource server is no; S2, set cycle: Set a fixed period for calculating server weights, updating server lists, and monitoring task requests; S3, task request processing: receiving a task request sent by a user according to conventional means and assigning it to a server as a conventional task, and monitoring whether the user sends a task request for the second time due to no server response within a predetermined time; S4. Identify tasks with high reaction time requirements: Identify the second task request issued by the user as a task with high response time requirement; S5. Adjust reserved resources: When a task with high response time requirement is identified, the server with the least current tasks is found and marked as a reserved resource server. Regular tasks are no longer assigned to the reserved resource server, only the task with high response time requirement is assigned, and the task with high response time requirement is placed before the regular tasks that have not yet been completed. S6. Monitor the reserved resource server: Monitor the number of unprocessed tasks of the reserved resource server in real time, and if the number of unprocessed tasks exceeds the maximum request number threshold, select other servers with fewer tasks to join, so as to expand the scale of the reserved resource server; S7. Task allocation: For common tasks, the basic allocation strategy is used to allocate tasks based on the server weight and the current number of requests. For tasks with high response time requirements, servers are directly allocated from reserved resource servers to handle them; The basic allocation strategy includes: S701, define server weight; the server weight Wi is defined as the reciprocal of the server average response time Ri, that is, Wi=1 / Ri; S702, calculating the allocation probability; the allocation probability is proportional to the server weight, ; Where n is the total number of servers, i and j represent the serial numbers of the servers; S703, consider the number of tasks that have been assigned: when assigning tasks, it is necessary to consider the number of tasks Ti that have been assigned by the server but have not yet been executed; if Ti plus the number of newly assigned tasks t exceeds the maximum request number threshold Ci of the server, the server will no longer assign new tasks and set the assignment probability to 0; S704, task allocation decision: based on the allocation probability, randomly select a server with different allocation probabilities to allocate the task; specifically: randomly select a server k, so that k=argmaxi(random()≤Pi), where random() generates a random number between [0, 1], and Pi is the allocation probability; S705, updating server status: after each task is assigned, updating the task quantity Ti of the selected server; S8. Update server status and adjust reserved resources: At the end of each cycle, the average reaction time of the servers in the server list is updated. If no high reaction time requirement tasks occur during the entire cycle, whether the server is marked as a reserved resource server is reset to No.

2. The method for scheduling cloud computing resources in the field of urban simulation according to claim 1, characterized in that: The initialization of the average reaction time in step S1 includes: S101, monitor the actual task request and processing process of the server, set monitoring points and record timestamps; S102, collecting task actual response time data, calculating and storing it according to the timestamp of the monitoring point; S103 , regularly summarizing the reaction times of all actual tasks in the period, and calculating an average value as an initialization value of the average reaction time.

3. The method for scheduling cloud computing resources in the field of urban simulation according to claim 1, characterized in that: The method for initializing the maximum request number threshold in step S1 includes: Analyze the number of CPU cores, memory size, and disk I / O capabilities of the server; evaluate the number of concurrent tasks that the server can efficiently handle based on the computing intensity, memory usage, and disk read and write frequency of the tasks; and set an upper limit on the number of requests as the maximum request number threshold.

4. The method for scheduling cloud computing resources in the field of urban simulation according to claim 1, characterized in that: The method for setting the cycle in step S2 includes: ： According to the task types of the urban simulation system, including computationally intensive, I / O intensive or mixed tasks, as well as the real-time requirements of the tasks, the utilization rate of system resources is considered, the average arrival rate of tasks is counted, the average time required from task reception to completion is measured, the current load of the system is monitored, and the cycle duration is set to respond to task requests in a timely manner and effectively manage resource allocation; After setting the cycle duration, make adjustments and optimizations through actual operation and monitoring of system status.

5. A scheduling device for cloud computing resources in the field of urban simulation, characterized in that: include: An initialization module, used to initialize the server list: the initialization includes the average response time of each server, the maximum request number threshold, and whether it is marked as a reserved resource server; The initialization value of whether to mark as a reserved resource server is no; The cycle module is used to set the cycle: set a fixed cycle to calculate server weights, update server lists, and monitor task requests; Task request processing module: receiving task requests sent by users according to conventional means and assigning them to servers as regular tasks, monitoring whether users send task requests for the second time due to no server response within a predetermined time; An identification module, used for identifying tasks requiring high reaction time: identifying the task request sent by the user for the second time as a task requiring high reaction time; Adjust the reserved resource module: When a task with high response time requirement is identified, find the server with the least current tasks and mark it as a reserved resource server. No longer assign regular tasks to the reserved resource server, only assign tasks with high response time requirement, and arrange the tasks with high response time requirement before the regular tasks that have not yet been completed. A monitoring module is used to monitor the reserved resource server: monitor the number of unprocessed tasks of the reserved resource server in real time, and if the number of unprocessed tasks exceeds the maximum request number threshold, select other servers with fewer tasks to join, so as to expand the scale of the reserved resource server; Task allocation module: For regular tasks, the basic allocation strategy is used to allocate tasks based on the server weight and the current number of requests; for tasks with high response time requirements, servers are directly allocated from the reserved resource servers to handle them; The task allocation module includes a basic allocation strategy submodule, which includes: a server weight definition unit: the server weight Wi is defined as the inverse of the server average reaction time Ri, that is, Wi=1 / Ri; a distribution probability calculation unit: the distribution probability is proportional to the server weight, ; Where n is the total number of servers, i and j represent the serial numbers of the servers; Consider the number of tasks that have been assigned but not yet executed by the server, Ti; If Ti plus the number of newly assigned tasks t exceeds the maximum request number threshold Ci of the server, the server will no longer assign new tasks and the assignment probability will be set to 0; Task assignment decision unit: Based on the assignment probability, a server is randomly selected with different assignment probabilities to assign tasks; Specifically: randomly select a server k, so that k=argmaxi(random()≤Pi), where random() generates a random number between [0, 1], and Pi is the assignment probability; Update server status unit: After each task is assigned, the number of tasks Ti of the selected server is updated; Update module: Update server status and reserve resource adjustment: At the end of each cycle, the average reaction time of the servers in the server list is updated. If no high reaction time requirement tasks occur during the entire cycle, whether the server is marked as a reserved resource server is reset to No.

6. The scheduling device for cloud computing resources in the field of urban simulation according to claim 5, characterized in that: The initialization module includes: Monitoring unit: monitors the actual task request and processing process of the server, sets monitoring points and records timestamps; Collection unit: collects the actual response time data of the task, calculates and stores it according to the timestamp of the monitoring point; Calculation unit: regularly summarizes the reaction time of all actual tasks in the period, calculates the average value, and uses it as the initialization value of the average reaction time.

7. The scheduling device for cloud computing resources in the field of urban simulation according to claim 5, characterized in that: The initialization module includes: Maximum request number threshold unit: analyzes the number of CPU cores, memory size, and disk I / O capabilities of the server; evaluates the number of concurrent tasks that the server can efficiently handle based on the computing intensity, memory usage, and disk read and write frequency of the tasks; and sets an upper limit on the number of requests as the maximum request number threshold.

8. The scheduling device for cloud computing resources in the field of urban simulation according to claim 5, characterized in that: The cycle module includes ： Setting unit: According to the task types of the urban simulation system, including computationally intensive, I / O intensive or mixed tasks, and the real-time requirements of the tasks, consider the utilization of system resources, calculate the average arrival rate of tasks, measure the average time required from task reception to completion, monitor the current load of the system, and set the cycle duration that can respond to task requests in a timely manner and effectively manage resource allocation; Adjustment unit: After setting the cycle duration, make adjustments and optimizations through actual operation and monitoring of system status.

Images