Method and device for processing running data, computer device and storage medium

Abstract

The application discloses a processing method and device of operation data, computer equipment and a storage medium, and belongs to the technical field of computers. According to the application, after operation data is acquired, a target device that meets target conditions in terms of load conditions is selected from candidate devices supporting the running environment of the operation data, a platform for providing cloud function service is built, and the target device is provided as a computing resource to execute the operation data, so that conflicts caused by unsuitable running environments are avoided, and the target device that tends to be more balanced in terms of load conditions can be reasonably allocated according to the load conditions, so that the target device can execute the operation data at a target time, and the resource utilization rate can be greatly improved because the target device that tends to be more balanced in terms of load conditions can be selected for each operation data.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer equipment, and storage medium for processing running data. Background Technology

[0002] With the development of computer technology, scheduled tasks have become an indispensable part of application development. A scheduled task refers to a piece of running data that is expected to be executed at a delayed time in the future. The running data is usually implemented in the form of script code, program code, or other code data.

[0003] Currently, when processing runtime data, the crontab component that comes with the Linux system is usually used. The crontab component can execute runtime data on a local single machine. However, when application development involves the collaboration of multiple hosts, the runtime data on different hosts are independent of each other, which often leads to situations where some hosts are very busy and others are relatively idle, that is, low resource utilization. Therefore, there is an urgent need for a method to process runtime data that can improve resource utilization. Summary of the Invention

[0004] This application provides a method, apparatus, computer device, and storage medium for processing runtime data, which can improve resource utilization during the processing of runtime data. The technical solution is as follows:

[0005] On the one hand, a method for processing runtime data is provided, the method including:

[0006] Obtain the runtime data to be processed, wherein the runtime data is the code data running at the target time;

[0007] In response to the arrival of the target time, based on the operating environment of the operating data, multiple candidate devices supporting the operating environment are determined;

[0008] Based on the load conditions of the multiple candidate devices, a target device is determined from the multiple candidate devices, and the load conditions of the target device meet the target conditions;

[0009] The operation data is executed through the target device.

[0010] In one possible implementation, determining the target device from the plurality of candidate devices based on their load conditions includes:

[0011] Based on the geographic location associated with the operational data, at least one first device is determined from the plurality of candidate devices, the first device supporting the provision of services to terminals within the geographic location;

[0012] From the at least one first device, determine the target device whose load condition meets the target condition.

[0013] On the one hand, a data processing apparatus is provided, the apparatus comprising:

[0014] The acquisition module is used to acquire the running data to be processed, wherein the running data is the code data running at the target time;

[0015] The first determining module is used to determine, in response to the arrival of the target time, multiple candidate devices that support the operating environment based on the operating environment of the operating data;

[0016] The second determining module is used to determine a target device from the multiple candidate devices based on the load conditions of the multiple candidate devices, wherein the load conditions of the target device meet the target conditions;

[0017] An execution module is used to execute the running data through the target device.

[0018] In one possible implementation, the execution module is used to:

[0019] In response to reaching the target time, the identification information of multiple data items that are periodically executed at the target time is added to the message queue, and the multiple data items include the running data;

[0020] For the running data in the message queue, the identification information of the running data is sent to the target device, and the target device loads and executes the running data based on the identification information.

[0021] In one possible implementation, the device further includes:

[0022] The first setting module is used to set the status information of the running data to a pending execution state in response to the addition of the identification information of the running data to the message queue. The pending execution state is used to indicate that the target time has been reached but the running data has not yet been sent to the corresponding target device.

[0023] In one possible implementation, the device further includes:

[0024] The second setting module is used to set the status information of the running data to an "execution in progress" state in response to the identification information of the running data being sent to the target device. The "execution in progress" state is used to indicate that the running data is being loaded and executed by the corresponding target device.

[0025] In one possible implementation, the device further includes:

[0026] An add module is used to add the identification information of the running data to the tail of the message queue in response to the running data being code data that is executed in a loop.

[0027] In one possible implementation, the load condition includes at least one of central processing unit (CPU) utilization, disk input / output (I / O) utilization, or memory occupancy, and the second determining module is used to:

[0028] From the plurality of candidate devices, the candidate device with the lowest CPU utilization is determined as the target device; or,

[0029] From the plurality of candidate devices, the candidate device with the lowest disk I / O utilization is determined as the target device; or,

[0030] From the multiple candidate devices, the candidate device with the lowest memory usage rate is determined as the target device.

[0031] In one possible implementation, the second determining module is used to:

[0032] Based on the geographic location associated with the operational data, at least one first device is determined from the plurality of candidate devices, the first device supporting the provision of services to terminals within the geographic location;

[0033] From the at least one first device, determine the target device whose load condition meets the target condition.

[0034] In one possible implementation, the device further includes:

[0035] The association module is used to associate the running data with the timer corresponding to the time granularity of the target time, and the timer is used to determine whether the target time has been reached.

[0036] In one possible implementation, the time granularity includes at least one of seconds, minutes, or hours, and the association module is used for:

[0037] In response to the target time having a time granularity of seconds, the running data is associated with a seconds timer, the minimum timing unit of which is 1 second; or,

[0038] In response to the target time having a time granularity of minutes, the running data is associated with a minute timer, the minute timer having a minimum timing unit of 1 minute; or,

[0039] In response to the target time having a time granularity of hours, the running data is associated with an hour timer, the minimum timing unit of which is 1 hour.

[0040] In one possible implementation, the association module is used for:

[0041] Assign identification information to the running data, and bind the identification information to the timer corresponding to the time granularity.

[0042] In one possible implementation, the device further includes:

[0043] The third setting module is used to set the status information of the running data to a pending state in response to the running data being associated with the timer. The pending state indicates that the running data has been bound to the corresponding timer but has not yet reached the target time.

[0044] In one possible implementation, the device further includes:

[0045] The fourth setting module is used to set the status information of the running data to a pending release state in response to the acquisition of the running data. The pending release state is used to indicate that the running data has been acquired but has not been bound to the corresponding timer.

[0046] In one possible implementation, the acquisition module is further configured to acquire the operation results and operation logs of the operation data from the target device;

[0047] The device further includes a sending module, configured to send an alarm message to a terminal associated with the running data in response to the running result being a running failure, the alarm message carrying the running result and the running log.

[0048] On one hand, a computer device is provided, the computer device including one or more processors and one or more memories, the one or more memories storing at least one computer program, the at least one computer program being loaded and executed by the one or more processors to implement a method for processing runtime data as described in any of the possible implementations above.

[0049] On the one hand, a storage medium is provided that stores at least one computer program, which is loaded and executed by a processor to implement a method for processing runtime data as described in any of the possible implementations above.

[0050] On one hand, a computer program product or computer program is provided, the computer program product or computer program comprising one or more lines of program code stored in a computer-readable storage medium. One or more processors of a computer device are capable of reading the one or more lines of program code from the computer-readable storage medium, and the one or more processors execute the one or more lines of program code, enabling the computer device to perform the data processing method of any of the above possible embodiments.

[0051] The beneficial effects of the technical solutions provided in this application include at least the following:

[0052] After obtaining the running data, the system selects the target device whose load condition meets the target conditions from the candidate devices of the running environment that support the running data. This avoids conflicts that may be caused by incompatible running environments. Furthermore, the system can reasonably allocate the target device to a more load-balanced target device based on the load condition, so that the running data can be executed by the target device at the target time. Since a more load-balanced target device can be selected for each running data, the resource utilization rate can be greatly improved. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0054] Figure 1 This is a schematic diagram of the implementation environment of a method for processing runtime data provided in an embodiment of this application;

[0055] Figure 2 This is a flowchart of a method for processing runtime data provided in an embodiment of this application;

[0056] Figure 3 This is an interactive flowchart of a method for processing runtime data provided in an embodiment of this application;

[0057] Figure 4 This is a schematic diagram illustrating the principle of a time wheel timer provided in an embodiment of this application;

[0058] Figure 5 This is a schematic diagram illustrating the principle of a second timer provided in an embodiment of this application;

[0059] Figure 6 This is a schematic diagram of a minute timer provided in an embodiment of this application;

[0060] Figure 7 This is a schematic diagram illustrating the principle of an hour timer provided in an embodiment of this application;

[0061] Figure 8 This is a schematic diagram illustrating the principle of adding identification information to a message queue, as provided in an embodiment of this application.

[0062] Figure 9 This is a dynamic change graph of the CPU utilization rate of the two candidate devices provided in the embodiments of this application;

[0063] Figure 10 This is a schematic diagram illustrating the principle of loading and running data on a target device, as provided in an embodiment of this application.

[0064] Figure 11 This is a schematic diagram illustrating the principle of a method for processing runtime data provided in an embodiment of this application;

[0065] Figure 12 This is a schematic diagram of a management statistics interface provided in an embodiment of this application;

[0066] Figure 13 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0067] Figure 14 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application;

[0068] Figure 15 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0069] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0070] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor are there any restrictions on quantity or execution order.

[0071] In this application, the term "at least one" means one or more, and "multiple" means two or more, for example, multiple first positions means two or more first positions.

[0072] Before introducing the embodiments of this application, some basic concepts in the field of cloud technology will be introduced first, which will be described below.

[0073] Cloud technology refers to a hosting technology that unifies hardware, software, and network resources within a wide area network (WAN) or local area network (LAN) to achieve data computation, storage, processing, and sharing. It encompasses network technologies, information technologies, integration technologies, management platform technologies, and application technologies based on cloud computing business models. These technologies can form resource pools, allowing for on-demand, flexible, and convenient use. Cloud computing technology will become a crucial support in the cloud technology field. Backend services of technical network systems require substantial computing and storage resources, such as those for video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring data to be transmitted to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will require robust system support, all of which can be achieved through cloud computing.

[0074] Cloud computing refers to the delivery and usage model of IT (Internet Technology) infrastructure, specifically obtaining necessary resources through a network in an on-demand and easily scalable manner. In a broader sense, cloud computing also refers to the delivery and usage model of services, meaning obtaining necessary services through a network in an on-demand and easily scalable manner. These services can be IT and software-related, internet-related, or other services. Cloud computing is a product of the development and integration of traditional computer and network technologies such as grid computing, distributed computing, parallel computing, utility computing, network storage technologies, virtualization, and load balancing.

[0075] In cloud computing, computing tasks are distributed across a resource pool comprised of numerous computers, enabling various application systems to access computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." From the user's perspective, the resources in the "cloud" are infinitely scalable, readily available, on-demand, expandable, and pay-as-you-go.

[0076] As a provider of fundamental cloud computing capabilities, we establish a cloud resource pool (referred to as a cloud platform, generally called IaaS, or Infrastructure as a Service) platform. Within this resource pool, we deploy various types of virtual resources for external customers to choose from. The cloud resource pool primarily includes: computing devices (virtualized machines containing operating systems), storage devices, and network devices.

[0077] Based on logical function, a PaaS (Platform as a Service) layer can be deployed on top of the IaaS layer, and a SaaS (Software as a Service) layer can be deployed on top of the PaaS layer. Alternatively, SaaS can be deployed directly on top of IaaS. PaaS is a platform for running software, such as databases and web (web page) containers. SaaS refers to various types of business software, such as web portals and bulk SMS senders. Generally speaking, SaaS and PaaS are upper layers compared to IaaS.

[0078] With the development of the internet, real-time data streams, and the diversification of connected devices, as well as the demands for search services, social networks, mobile commerce, and open collaboration, cloud computing has rapidly developed. Unlike previous parallel distributed computing, cloud computing will fundamentally revolutionize the entire internet model and enterprise management model.

[0079] Cloud functions (Function as a Service, FaaS) are a new way of providing computing power, namely functions that run in the cloud (server-side). Physically, a cloud function can consist of multiple files, consuming a certain amount of computing resources such as CPU (Central Processing Unit) and memory; each cloud function is completely independent and can be deployed in different regions. Developers do not need to purchase or build servers; they only need to write function code and deploy it to the cloud to call it on the mini-program side. Cloud functions can also call each other. For developers, using cloud functions only requires writing core code in a platform-supported language and setting the conditions for code execution to run the code elastically and securely on the cloud infrastructure. Cloud functions allow developers to abandon server configuration and management; they only need to write and upload core business code (i.e., running data) to obtain the corresponding data results (i.e., execution results). Using cloud functions eliminates all operational and maintenance tasks for developers, allowing enterprises and developers to focus more on core business development, achieving rapid deployment and iteration, and controlling the pace of business development.

[0080] Microservices: Microservices are a software development technique and a variation of Service-Oriented Architecture (SOA) that constructs an application as a set of loosely coupled services. In a microservice architecture, services are fine-grained, and protocols are lightweight. In other words, microservices are an architecture and organizational method for developing software where applications (i.e., software) consist of small, independent services that can communicate with each other through well-defined APIs (Application Programming Interfaces). Microservice architecture makes applications easier to scale and faster to develop, thereby accelerating innovation and shortening the time to market for new features.

[0081] Time Wheel Timer: The time wheel is a circular queue that stores delayed messages. It is implemented using an array for efficient iteration. Each element in this circular queue corresponds to a list of delayed tasks. This list is a doubly linked circular list, where each item represents a delayed task to be executed. Delayed tasks, also known as scheduled tasks, are runtime data that is scheduled to execute at a future time. This runtime data is typically implemented in the form of script code, program code, or other code data.

[0082] Distributed message queues are fault-tolerant message queues, such as Kafka (a high-throughput distributed publish-subscribe messaging system) and RabbitMQ (Rabbit Message Queue, a message queue developed by RabbitMQ, a method of program-to-program communication).

[0083] POD (PeaPod): A POD is the smallest management element in a Kubernetes (K8s) cluster. That is, the smallest management element in a K8s cluster is not an individual container, but rather a POD, which is the smallest unit used for management, creation, and scheduling. K8s is a server cluster. The runtime data involved in this embodiment can be processed within the K8s cluster. Each script in the K8s cluster is packaged into a Docker image. After the target device pulls the Docker image from the cloud database, it runs the script through the POD. A POD is a logical host in a container environment. A POD may contain one or more closely connected applications, which may reside on the same physical host or virtual machine.

[0084] In application development, scheduled tasks are inevitably used. A scheduled task is a piece of data that is scheduled to execute at a delayed time in the future. This data is usually implemented in the form of script code, program code, or other code. Currently, the mainstream implementation of scheduled tasks is using the crontab component built into the Linux system. While crontab can execute on a local single machine, this results in low availability of the data. Furthermore, when application development involves collaboration across multiple hosts, the scheduled tasks on different hosts are independent, making the data unreusable and lacking scalability. Additionally, in the case of multiple hosts collaborating, different tasks typically consume different computing resources—for example, some tasks are CPU-intensive, while others are memory-intensive—leading to situations where some hosts are very busy while others are relatively idle, resulting in low resource utilization. Moreover, when tasks fail, it is often difficult to pinpoint the problem (bug), complicating the troubleshooting process. If a single machine crashes, the task cannot be executed normally, and developers cannot be alerted in a timely manner.

[0085] In view of this, the embodiments of this application relate to a method for processing runtime data, which can improve the availability and scalability of runtime data, improve the processing performance of runtime data, improve the resource utilization of the entire cloud function cluster, and can synchronize the status information of runtime data to developers in a timely manner. If the runtime data execution fails, it can also promptly alert developers and send runtime results and runtime logs to facilitate developers in accurately locating bugs in runtime data, simplifying the bug location process, reducing the difficulty of bug location, and making the application development process simpler and more transparent.

[0086] In an exemplary scenario, taking script code as the running data as an example, by building a distributed function computing microservice script system, and utilizing the cloud function computing platform and microservices, the reusability and scalability of the script code can be improved, as well as development efficiency. Distributed message queues and multiple execution PODs are used to ensure the high availability of the script code. At the same time, microservice components can promptly alert developers to the execution status of the script code. In addition, by obtaining the load status of each machine (i.e., candidate devices), each machine can preemptively pull the script code to be executed to ensure load balancing among machines as much as possible and make reasonable use of cluster resources. Finally, the execution process is made more transparent by using microservice metrics (a metrics library).

[0087] Figure 1 This is a schematic diagram illustrating the implementation environment of a method for processing runtime data provided in an embodiment of this application. See also... Figure 1The implementation environment includes terminal 110 and server 120, both of which are exemplary embodiments of computer devices.

[0088] Terminal 110 is used to provide running data to be processed. The running data refers to code data that runs at a target time. The target time refers to any time after the current time, that is, the target time is a future time. The code data can be script code written in a scripting language, program code written in a high-level programming language, etc. This application embodiment does not specifically limit it.

[0089] In some embodiments, a user (typically a developer) logs into their cloud platform account on terminal 110, writes runtime data to be processed in an application associated with the cloud platform, and uploads the runtime data to the cloud platform. Upon receiving the runtime data, server 120 periodically triggers the execution of the runtime data on the target device deployed on the cloud platform. For example, the application could be a browser application. After writing runtime data (such as script code snippets) to be executed periodically in the browser application's online IDE (Integrated Development Environment), the developer clicks the publish or upload option in the online IDE, causing the terminal to send the runtime data to server 120. Optionally, besides a browser application, the application could also be other clients that support uploading runtime data, such as applications corresponding to the cloud platform; this embodiment does not specifically limit this.

[0090] Terminal 110 and server 120 can be connected directly or indirectly via wired or wireless communication, and this application does not impose any restrictions on this.

[0091] Server 120 can be used to provide processing services for running data to each terminal 110. That is, after receiving the running data published by each terminal 110, server 120 allocates a target device as the execution host from the server cluster or distributed system for each running data when the target time for executing the running data is reached, and executes the running data on time through the target device.

[0092] Optionally, when allocating target devices, the load of each candidate device in the distributed system can be comprehensively considered, and the candidate device with a relatively light load (i.e. less occupied computing resources) can be selected as the target device to improve the low resource utilization and unbalanced load caused by each terminal 110 executing its own running data locally.

[0093] Optionally, the server 120 can also collect the running results and running logs of each running data through the log platform. For any running data, if the running result of any running data is successful, the server 120 sends a confirmation message to the terminal associated with the running data. The confirmation message is used to indicate that the running data has been completed. If the running result of any running data is a failure, the server 120 sends an alarm message to the terminal associated with the running data. The alarm message is used to indicate that the running data has failed. Optionally, the alarm message can carry the running result and the running log, so that developers can trace back the entire running process of the running data based on the running log and easily locate the bugs that occur in the running data.

[0094] It should be noted that the various operational data to be processed disclosed in this application can be stored on a blockchain. In other words, a cluster of servers or multiple servers in a distributed system used to execute the operational data can form a blockchain, and the servers are nodes on the blockchain.

[0095] Server 120 may include at least one of a single server, multiple servers, a cloud computing platform, or a virtualization center. Optionally, server 120 may undertake the primary computing task, and terminal 110 may undertake the secondary computing task; or, server 120 may undertake the secondary computing task, and terminal 110 may undertake the primary computing task; or, terminal 110 and server 120 may collaborate on computing using a distributed computing architecture.

[0096] Optionally, server 120 may be an independent physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0097] Optionally, terminal 110 may be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, in-vehicle terminal, MP3 (Moving Picture Experts Group Audio Layer III) player, MP4 (Moving Picture Experts Group Audio Layer IV) player, e-book reader, etc., but is not limited to these.

[0098] Those skilled in the art will understand that terminal 110 can refer to one of a plurality of terminals, and the number of such terminals can be more or less. For example, there may be only one terminal, or there may be dozens or hundreds of terminals, or even more. This application does not limit the number of terminals or the type of device.

[0099] Figure 2 This is a flowchart illustrating a method for processing runtime data according to an embodiment of this application. See also... Figure 2 This embodiment is applied to a computer device. The following description uses a computer device as a server as an example. This embodiment includes the following steps:

[0100] 201. The server obtains the runtime data to be processed, which is the code data running at the target time.

[0101] Optionally, the runtime data refers to code data running at a target time, which is any time after the current time, i.e., a future time. Optionally, the code data can be script code written in a scripting language, program code written in a high-level programming language, or code implemented in other forms; this application embodiment does not specifically limit this.

[0102] Optionally, the running data is code data executed once, such as code data executed at 3 PM. Alternatively, the running data is code data executed cyclically, that is, the running data is triggered periodically. For code data executed cyclically, the number of times to execute cyclically or the stop time to execute cyclically can be set so that the code data is no longer executed after the number of times to execute cyclically or after the stop time is reached. For example, code data executed at 3 PM every day will stop after 7 days of cyclic execution. This application embodiment does not specifically limit whether the code data is executed once or periodically.

[0103] In some embodiments, the server receives runtime data uploaded or published by the terminal in the cloud platform. In other words, when the server receives any data transmission message, it parses the header field of the data transmission message. When the data type information carried in the header field indicates that the data transmission message is runtime data, the server determines that the data transmission message is a runtime data transmission message. The server then parses the data field of the data transmission message to obtain the runtime data to be processed. Optionally, the data field carries the terminal identifier or account identifier, the target time, and the runtime data.

[0104] The cloud platform refers to a platform that provides cloud function services. In other words, the server provides computing power, and the terminal only needs to upload or publish the data to be processed to the cloud platform to execute the data in the cloud without consuming local computing resources. For developers, using cloud functions simply requires writing the execution data in a language supported by the cloud platform and setting the execution conditions (i.e., setting the target time) to execute the data elastically and securely on the cloud infrastructure (i.e., the target device).

[0105] Optionally, the data type information can be an identification code, for example, 00 represents running data, 01 represents business data, 10 represents control data, etc. Alternatively, the data type information can also be the target time, that is, the execution condition of the running data is used as its own data type information.

[0106] In an exemplary embodiment, taking the transmission data type information as a target time as an example, when the server receives any data transmission message, it parses the header field of the data transmission message. When the header field carries the target time, it determines that the data transmission message is a transmission message for running data. It then parses the data field of the data transmission message to obtain the running data to be processed. Optionally, the data field carries the terminal identifier or account identifier and the running data.

[0107] In an exemplary scenario, a developer logs into their cloud platform account on a terminal, writes runtime data to be processed in an application associated with the cloud platform, and triggers the publish or upload function option in the application to send the runtime data to be processed to the server, which then receives the data. For example, the application is a software development application that provides an online IDE for writing code. The developer writes the runtime data (such as script code snippets, program code snippets, or function calls) in the online IDE, and then clicks or uses a shortcut key to trigger the publish or upload function option, causing the terminal to send the runtime data to be processed to the server.

[0108] 202. Upon arrival at the target time, the server determines multiple candidate devices that support the operating environment based on the operating environment of the operating data.

[0109] In some embodiments, since the server is used to provide computing power to various terminals through the cloud platform, the server can be a server cluster (or a distributed system or blockchain system) composed of multiple computing devices, which are equivalent to multiple cloud infrastructures of the cloud platform.

[0110] In some embodiments, the server identifies the runtime environment of the runtime data and determines multiple candidate devices that support the runtime environment from multiple computing devices in the server cluster. In one example, the runtime data is JavaScript script code, and the server identifies the runtime environment of the runtime data as a Java environment, and determines multiple computing devices that support the Java environment as the multiple candidate devices from all computing devices in the server cluster.

[0111] In some embodiments, the server can intelligently identify the runtime environment of the runtime data through a machine learning model. For example, the runtime environment can be identified through a classification model. Alternatively, since runtime data in different runtime environments usually have different programming syntaxes, the server can identify the runtime environment of the runtime data through the programming syntax of the runtime data. Or, the runtime environment of the runtime data can also be identified manually. This application embodiment does not specifically limit the method of identifying the runtime environment.

[0112] In some embodiments, when a developer uploads or publishes the runtime data to the server via a terminal, the developer may also carry runtime environment indication information for the runtime data. This runtime environment indication information is used to indicate the runtime environment of the runtime data, so that the server does not need to expend computing power to identify the runtime environment. Instead, the runtime environment indication information sent by the terminal can directly determine multiple candidate devices supporting the runtime environment from multiple computing devices in the server cluster.

[0113] Optionally, the runtime environment indication information may be a runtime environment set by the developer (such as a Java environment) or a programming language used to write the runtime data (such as a JavaScript scripting language). This application embodiment does not specifically limit this.

[0114] In some embodiments, if the runtime environment indication information is the runtime environment itself, the server may pre-store association information between computing devices and runtime environments. This association information is used to record each computing device in the server cluster (or a distributed system or a blockchain system) and the runtime environment it supports. Based on this association information, the server selects each computing device that supports the runtime environment as one of the multiple candidate devices.

[0115] Optionally, the association information can be multiple key-value pairs. Each key-value pair uses an operating environment as the key name and the device identifier of each computing device supporting that operating environment as the key value. The server uses the operating environment as an index to query the index content corresponding to the index, and determines the computing devices corresponding to each device identifier stored in the index content (i.e., the key value) as the multiple candidate devices. Optionally, in addition to key-value pairs, the association information can also be in the form of a list, or it can also be a linked list, array, hash table, bitmap, etc. The embodiments of this application do not specifically limit the storage format of the association information.

[0116] In some embodiments, if the runtime environment indication information is a programming language for writing the runtime data, the server can determine the runtime environment corresponding to the programming language based on the mapping relationship between the programming language and the runtime environment, and select each computing device that supports the runtime environment as the multiple candidate devices based on the association information of computing devices and runtime environments pre-stored on the server. This association information has been introduced above and will not be repeated here.

[0117] 203. Based on the load conditions of the multiple candidate devices, the server determines the target device from the multiple candidate devices, and the load conditions of the target device meet the target conditions.

[0118] The load condition is used to characterize the computing resource usage of the candidate device. Optionally, the load condition includes at least one of the following: CPU utilization, disk input / output (I / O) utilization, or memory occupancy.

[0119] In some embodiments, when the load condition includes CPU utilization, the target condition can be the lowest CPU utilization. That is, the server determines the candidate device with the lowest CPU utilization from among the multiple candidate devices as the target device. Optionally, the server can obtain the CPU utilization of the multiple candidate devices and sort them in ascending order of CPU utilization, determining the candidate device ranked first as the target device.

[0120] In some embodiments, when the load condition includes disk I / O utilization, the target condition can be the lowest disk I / O utilization. That is, the server determines the candidate device with the lowest disk I / O utilization from among the multiple candidate devices as the target device. Optionally, the server can obtain the disk I / O utilization of the multiple candidate devices and sort them in ascending order of disk I / O utilization, determining the candidate device ranked first as the target device.

[0121] In some embodiments, when the load condition includes memory utilization, the target condition can be the lowest memory utilization. That is, the server determines the candidate device with the lowest memory utilization from among the multiple candidate devices as the target device. Optionally, the server can obtain the memory utilization of the multiple candidate devices and sort them in ascending order of memory utilization, determining the candidate device ranked first as the target device.

[0122] In the above process, by selecting the candidate device with a lighter load from among the candidate devices as the target device, it is beneficial to balance the load of each device in the entire server cluster, avoid the phenomenon that some devices in the server cluster are very busy and some devices are very idle, thereby improving the resource utilization of the server cluster.

[0123] In some embodiments, when allocating a target device, in addition to considering load conditions, geographical location may also be considered. Since computing devices in a server cluster (or a distributed system or blockchain system) are typically deployed in different geographical locations, this allows the computing devices to provide computing power to terminals within a nearby geographical area, thereby improving the overall response speed of the server cluster. In this case, the server can determine at least one first device from a plurality of candidate devices based on the geographical location associated with the operational data. This first device supports providing services to terminals within that geographical location. From the at least one first device, the target device whose load conditions meet the target criteria is then determined.

[0124] Optionally, the geographical location can be the location of the terminal that uploaded the running data (usually the terminal corresponding to the developer), or the geographical location can also be the location of the terminal that operated the running data (usually the terminal corresponding to the consumer). This application embodiment does not specifically limit this.

[0125] In an exemplary scenario, assuming the geographical location associated with the running data is City A, the server first determines at least one first device from the multiple candidate devices that supports providing services to terminals within City A. Then, based on the load of the at least one first device, the server determines the target device whose load meets the target condition. Optionally, the first device can be deployed in City A or in a surrounding city of City A, but it is necessary to ensure that the first device supports providing services to terminals within City A. This application embodiment does not specifically limit this.

[0126] In the above process, by considering not only the load but also the geographical location when selecting target devices, the entire server cluster can provide services to the corresponding terminals from the nearest target device. This can improve the response speed of the server cluster under the premise of balanced load, thereby optimizing the cloud platform's performance in processing running data.

[0127] 204. The server executes the running data through the target device.

[0128] In some embodiments, since there may be multiple pieces of data, including the running data, to be executed within the server cluster at a target time, the server can use a message queue to manage the various pieces of data scheduled for execution at the same time. That is, in response to the arrival of the target time, the server adds the identification information of the multiple pieces of data scheduled for execution at the target time, including the running data, to the message queue; the server then sends the identification information of the running data in the message queue to the target device, which loads and executes the running data based on the identification information.

[0129] In an exemplary scenario, the server maintains a message queue for each time period. When the target time is reached, it determines multiple data items that need to be executed periodically at that target time and adds the identification information of these multiple data items to the message queue corresponding to that target time. Then, for the running data corresponding to each identification information in the message queue, it determines candidate devices based on the running environment and allocates target devices based on the load. Next, it sends each identification information to the corresponding target device, and each target device loads and executes its corresponding running data based on the identification information it receives.

[0130] In some embodiments, the target device may employ preemptive loading or distributed loading when loading runtime data. Preemptive loading refers to the target device actively retrieving the runtime data corresponding to the identification information from the server after receiving the identification information, and executing the runtime data after receiving the runtime data returned by the server. Distributed loading refers to the server simultaneously distributing the identification information to the target device and sending the corresponding runtime data to the target device, and the target device executing the runtime data after receiving it. The server may employ synchronous or asynchronous distribution when distributing the identification information and runtime data; this embodiment does not specifically limit this approach.

[0131] In the above process, the server uses a message queue to rationally coordinate multiple data items scheduled for execution at the same time. In a distributed system, this message queue is also called a distributed message queue. When too much data needs to be executed at the same time, the surge in the number of pending data items can cause the thundering herd effect. The thundering herd effect refers to the simultaneous awakening of processes corresponding to multiple data items waiting to be executed at a target time. By using a distributed message queue, the number of data items to be executed at the target time (i.e., the length of the message queue) can be determined in advance before the target time arrives. This allows for advance resource allocation and rational coordination of computing resources, thereby mitigating the thundering herd effect.

[0132] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0133] The method provided in this application, after obtaining the running data, selects a target device whose load condition meets the target conditions from the candidate devices of the running environment that support the running data. This avoids conflicts that may be caused by incompatible running environments. Furthermore, the load condition can be used to reasonably allocate the target device to a more load-balanced target device so that the running data can be executed by the target device at the target time. Since a more load-balanced target device can be selected for each running data, resource utilization can be greatly improved.

[0134] Figure 3 This is an interactive flowchart of a method for processing runtime data provided in an embodiment of this application. See also... Figure 3 This embodiment is applied to a computer device. The following description uses a computer device as a server as an example. This embodiment includes the following steps:

[0135] 301. The server obtains the runtime data to be processed, which is the code data running at the target time.

[0136] Step 301 above is similar to step 201 above, and will not be described in detail here.

[0137] In an exemplary scenario, using the runtime data as script code, an example of runtime data to be processed is shown:

[0138]

[0139]

[0140] 302. Upon receiving the runtime data, the server assigns identification information to the runtime data.

[0141] In some embodiments, since the server is typically a server cluster (or a distributed system or blockchain system) consisting of multiple servers, the device receiving the running data, the device allocating the target device for the running data, and the target device executing the running data are usually not integrated on the same physical machine. That is, they are performed by different physical machines. Therefore, the execution process of the running data involves transmission within the cluster. However, only the target device needs to load and execute the full amount of running data. Therefore, the server can assign a unique identifier to each piece of running data after receiving it. When performing subsequent processes such as allocating the target device and adding message queues, the identifier is used to represent the running data, which can greatly save the communication overhead within the cluster.

[0142] In some embodiments, when allocating identification information, the server can ensure that the identification information increments according to the order in which the running data is received. That is, the server allocates larger identification information to running data received later, thereby facilitating the management of various running data to be processed by the cluster in chronological order. Optionally, the identification information can be an incrementing sequence number, or an incrementing sequence number carrying timestamp information, etc. The embodiments of this application do not specifically limit the composition of the identification information.

[0143] In other embodiments, the server may not assign identification information in an incrementing order based on the received running data. For example, the server may concatenate the terminal identifier with the timestamp of the received running data to form a sequence number, encrypt the sequence number, and use the encrypted information as the unique identifier for the running data, thereby improving the security of the identification information generation process. Optionally, the encryption algorithm for the sequence number can be a hash algorithm, a digest algorithm, etc., and this application embodiment does not impose specific limitations.

[0144] 303. The server sets the status information of the running data to the pending publication status. The pending publication status is used to indicate that the running data has been acquired but has not been bound to the corresponding timer.

[0145] In some embodiments, the server may set a status information for each piece of runtime data uploaded to the cloud platform. This status information is used to obtain the execution status of the runtime data. Optionally, the status information includes the following types:

[0146] a) Pending release status, indicating that the runtime data has been acquired but not yet bound to the corresponding timer;

[0147] b) Pending trigger status, which indicates that the running data has been bound to the corresponding timer but has not yet reached the target time;

[0148] c) Pending execution status, which indicates that the target time has been reached but the running data has not yet been sent to the corresponding target device;

[0149] d) Execution status, which indicates that the running data is being loaded and executed by the corresponding target device.

[0150] In some embodiments, the status information can be a status variable. Within the server cluster, the various devices involved in the running data need to synchronize the status variable. Optionally, when transmitting the identification information of the running data within the server cluster, the status variable of the running data can also be transmitted simultaneously. For example, after the server has allocated the target device to the running data, it needs to send the identification information and status variable of the running data to the target device. After receiving the identification information and status variable, the target device compares the received status variable with the locally stored (synchronized) status variable. If the two are consistent, the verification is successful, and the target device loads and executes the running data. If the two are inconsistent, it indicates that there is a risk of leakage of the running data or that the status variable has not been updated in time. In this case, the verification fails, and the target device can alert the server, so that technicians can investigate the specific problem based on the alert.

[0151] Optionally, since there are four possible states for the above-mentioned status information, the status variable can be set with four possible values. For example, 00 represents the state to be published, 01 represents the state to be triggered, 10 represents the state to be executed, and 11 represents the state in execution. Or, for example, 1 represents the state to be published, 2 represents the state to be triggered, 3 represents the state to be executed, and 4 represents the state in execution. This application embodiment does not specifically limit the way the status variable is set.

[0152] In an exemplary scenario, after receiving the running data, the server assigns identification information to the running data, creates a state variable for the running data, and initializes the state variable to a state to be published (e.g., setting the state variable State = 00). Then, the running data, the identification information, and the state variable are stored in the database in a corresponding manner, for example, using the identification information as the key name and the running data and the state variable as the key values, thereby forming a set of key-value pairs.

[0153] In some embodiments, since the status information can reflect the process in which the runtime data is executed within the cloud platform in real time, the status information can also be fed back by the server to the terminal that uploaded or published the runtime data (usually the developer's terminal), so that the developer can understand the real-time status of the runtime data he / she wrote.

[0154] It should be noted that there is no order of execution between steps 302 and 303. That is, in response to receiving the running data, the server may first allocate the identification information and then modify the status information to the pending release status, or it may first modify the status information to the pending release status and then allocate the identification information, or it may allocate the identification information and modify the status information to the pending release status at the same time. This application embodiment does not specifically limit the execution order between steps 302 and 303.

[0155] 304. Based on the time granularity of the target time, the server binds the identification information to the timer corresponding to the time granularity. The timer is used to determine whether the target time has been reached.

[0156] In some embodiments, the server identifies the time granularity of the target time and binds the identification information to the timer corresponding to the time granularity.

[0157] Optionally, the time granularity includes at least one of seconds, minutes, or hours, and each time granularity can correspond to one or more timers. Assuming each time granularity corresponds to one timer, the timers can be divided into second timers, minute timers, and hour timers, where the minimum timing unit of the second timer is 1 second, the minimum timing unit of the minute timer is 1 minute, and the minimum timing unit of the hour timer is 1 hour. Optionally, each time granularity can also correspond to multiple timers, for example, setting a 1-second timer (minimum timing unit of 1 second), a 2-second timer (minimum timing unit of 2 seconds), a 5-second timer (minimum timing unit of 5 seconds), etc. This application embodiment does not specifically limit this.

[0158] In some embodiments, when the server identifies the time granularity of the target time, it can determine the time granularity of the target time by the time granularity of the smallest time unit. For example, if the target time is 2 PM on May 7th, the time granularity of the smallest time unit is 1 hour; if the target time is 2:10 PM on May 7th, the time granularity of the smallest time unit is 1 minute. This application embodiment does not specifically limit this.

[0159] In steps 302-304 above, the server associates the running data with the timer corresponding to the target time granularity. By binding only the identification information of the running data with the timer of the corresponding time granularity, it avoids binding all the running data with the timer of the corresponding time granularity, thereby saving server computing resources and storage overhead. In some embodiments, all the running data can also be bound with the timer of the corresponding time granularity, which simplifies the process of associating running data with timers.

[0160] In some embodiments, the server, in response to the target time having a time granularity of seconds, associates the running data with a second timer. Optionally, the server binds the identification information of the running data to the second timer, wherein the minimum timing unit of the second timer is 1 second.

[0161] In some embodiments, the server, in response to the target time having a time granularity of minutes, associates the running data with a minute timer. Optionally, the server binds the identification information of the running data to the minute timer, wherein the minimum timing unit of the minute timer is 1 minute.

[0162] In some embodiments, the server associates the running data with an hourly timer in response to the target time having a time granularity of hours. Optionally, the server binds the identification information of the running data to the hourly timer, wherein the minimum timing unit of the hourly timer is 1 hour.

[0163] In the above process, by binding the identification information of the running data with the timer corresponding to its own time granularity, it is possible to support the execution of the corresponding running data at the target time under multiple time granularities. However, the crontab component of the Linux system in related technologies only supports minute timers. In other words, timed tasks (running data) at the second granularity cannot be implemented, and timed tasks at the hour granularity are crowded and redundant. The embodiments of this application can greatly improve the processing efficiency of running data by designing timers with multiple time granularities.

[0164] The principle of the time wheel timer will be explained below. Figure 4 This is a schematic diagram of a time wheel timer provided in this application embodiment, as shown in Figure 400. The smallest timing unit is called a Tick (which can be understood as the smallest time interval represented by one jump of the timer pointer). In a second timer, a Tick refers to 1 second; in a minute timer, a Tick refers to 1 minute; and in an hour timer, a Tick refers to 1 hour. Assuming that one cycle of the timer includes N Tick units, where N is an integer greater than or equal to 1, and each Tick unit of the time wheel timer maintains a message queue, then a total of N message queues need to be maintained. If the current time is after S cycles pointing to element i (referring to the i-th Tick unit), where i is a value greater than or equal to 1 and less than or equal to N, then the current time T... c It can be represented as T c =S*N+i. If at this time a running data with a time interval of Ti between the target time and the current time is bound, then the identification information of this running data will be added to the message queue of element n, then n = (Tc+Ti)mod N = (S*N+i+Ti)mod N = (i+Ti)mod N.

[0165] Figure 5 This is a schematic diagram of the principle of a second timer provided in this application embodiment. As shown in 500, the smallest timing unit in the second timer is 1 second. Therefore, the second timer contains a total of 60 ticks. Assuming that the clock is pointing to the tick=2 mark at the current time, a running data that is delayed for 4 seconds is bound (or associated) and executed. Then the target time is the tick=6 mark. At this time, the identification information of the running data is inserted into the message queue under Tick=6.

[0166] Figure 6 This is a schematic diagram of a minute timer provided in an embodiment of this application. As shown in 600, the smallest timing unit in the minute timer is 1 minute (Tick). Therefore, the minute timer contains 60 ticks. Assuming that the clock is pointing to the tick=1 mark at the current time, a running data that is delayed for 5 minutes is bound (or associated). The target time is the tick=6 mark. At this time, the identification information of the running data is inserted into the message queue under Tick=6.

[0167] Figure 7 This is a schematic diagram of the principle of an hour timer provided in the embodiment of this application. As shown in 700, the smallest timing unit in the hour timer is 1 hour. Therefore, the second timer contains a total of 24 ticks. Assuming that the clock is pointing to the tick=1 mark at the current time, a running data that is delayed for 5 hours is bound (or associated) at this time. Then the target time is the tick=6 mark. At this time, the identification information of the running data is inserted into the message queue under Tick=6.

[0168] 305. In response to the fact that the running data has been associated with the timer, the server sets the status information of the running data to a pending state. The pending state indicates that the running data has been bound to the corresponding timer but has not yet reached the target time.

[0169] Step 305 is similar to step 303 above, and will not be described in detail here.

[0170] Based on the example provided in step 303 above, assuming that the status information is implemented in the form of a status variable, the status variable corresponds to setting 4 possible values, for example, 00 represents the state to be released, 01 represents the state to be triggered, 10 represents the state to be executed, and 11 represents the state in execution.

[0171] The server then responds that the running data has been associated with the timer (i.e., the identification information of the running data has been bound to the timer with the corresponding time granularity). The server uses the identification information as an index in the database to query the index content stored corresponding to the index. The index content includes the running data and the status variable. At this time, the status variable is changed from the original 00 (pending release status) to 01 (pending trigger status), that is, the status variable is assigned the value 01.

[0172] In the above process, since the status information can reflect the process of the running data in the cloud platform in real time, the status information can also be fed back by the server to the terminal that uploaded or published the running data (usually the developer's terminal), so that the developer can understand the real-time status of the running data he wrote.

[0173] 306. Upon reaching the target time, the server adds the identification information of multiple data items scheduled to be executed at that target time to the message queue. These multiple data items include the running data.

[0174] In some embodiments, the server maintains a message queue for each tick unit in the timer. Based on the target time corresponding to the running data, it obtains the time interval between the target time and the current time, and determines the number of tick units corresponding to the time interval in the timer based on the time interval. It adds the tick unit scale pointed to by the current time pointer to the number of tick units to obtain the tick unit scale that the pointer should point to at the target time. Thus, when the pointer points to the tick unit scale corresponding to the target time, it is determined that the target time has been reached. Then, the identification information of multiple data that are timed to be executed at the target time is added to the message queue corresponding to the tick unit. Since the running data is also timed to be executed at the target time, the multiple data includes the running data.

[0175] Optionally, the message queue can be a Kafka message queue, or a RabbitMQ (a high-throughput distributed publish-subscribe messaging system), ActiveMQ (an active message queue), etc. This application embodiment does not specifically limit the type of the message queue.

[0176] In some embodiments, in addition to writing the identification information of each data item into the message queue, parameters such as the last execution time and the estimated execution time of each data item can also be written at the same time, so as to maintain more comprehensive metadata of each data item in the message queue.

[0177] Figure 8This is a schematic diagram illustrating the principle of adding identification information to a message queue, as provided in an embodiment of this application. As shown in 800, assuming that the timer pointer points to Tick=5 at the target time, the identification information of all running data at Tick=5 is triggered to be written to the message queue at Tick=5. This is illustrated by taking the Kafka message queue at Tick=5 as an example.

[0178] 307. In response to the addition of the identification information of the running data to the message queue, the server sets the status information of the running data to the pending execution state. The pending execution state is used to indicate that the target time has been reached but the running data has not yet been sent to the corresponding target device.

[0179] Step 307 is similar to step 303 above, and will not be described in detail here.

[0180] Based on the example provided in step 303 above, assuming that the status information is implemented in the form of a status variable, the status variable corresponds to setting 4 possible values, for example, 00 represents the state to be released, 01 represents the state to be triggered, 10 represents the state to be executed, and 11 represents the state in execution.

[0181] The server then responds that the identification information of the running data has been added to the message queue. The server uses the identification information as an index in the database to query the index content stored corresponding to the index. The index content includes the running data and the status variable. At this time, the status variable is changed from the original 01 (pending trigger status) to 10 (pending execution status), that is, the status variable is assigned the value 10.

[0182] In the above process, since the status information can reflect the process of the running data in the cloud platform in real time, the status information can also be fed back by the server to the terminal that uploaded or published the running data (usually the developer's terminal), so that the developer can understand the real-time status of the running data he wrote.

[0183] 308. Based on the runtime environment of the runtime data in the message queue, the server determines multiple candidate devices that support the runtime environment.

[0184] Step 308 above is similar to step 202 above, and will not be described in detail here.

[0185] It should be noted that the embodiments of this application only take the running data in the message queue as an example to illustrate how to allocate the target device and have the target device execute the running data. However, the running data can be any data in the message queue. That is to say, the server can perform similar operations for each data in the message queue, which will not be elaborated here.

[0186] 309. Based on the load conditions of the multiple candidate devices, the server determines the target device from the multiple candidate devices, and the load conditions of the target device meet the target conditions.

[0187] Step 309 above is similar to step 203 above, and will not be described in detail here.

[0188] Figure 9 This is a dynamic change graph of the CPU utilization of the two candidate devices provided in the embodiments of this application, such as... Figure 9 As shown, taking load conditions including CPU utilization as an example, the upper part 901 shows the CPU utilization of candidate device A. The latest value of candidate device A's CPU utilization is 14, and it reached a peak of 40 at 12:13:14 on [Date]. The lower part 902 shows the CPU utilization of candidate device B. The latest value of candidate device B's CPU utilization is 27, and it reached a peak of 40 at 12:14:14 on [Date]. Between these two candidate devices A and B, the server can choose candidate device A with the smaller latest value of CPU utilization as the target device.

[0189] 310. The server sends the identification information of the running data to the target device.

[0190] Optionally, the server compresses and encrypts the identification information before sending it to the target device to save communication overhead during data transmission. Optionally, the server compresses and encrypts the identification information and the status information together before sending them to the target device to facilitate verification of whether the running data has been leaked or whether the status information has been tampered with. Optionally, the server compresses and encrypts the identification information, the status information, and the running data together before sending them to the target device. In this case, it is equivalent to adopting a distributed loading method for running data, that is, the server actively allocates running data to the target device. This application embodiment does not specifically limit this.

[0191] 311. In response to the identification information of the running data being sent to the target device, the server sets the status information of the running data to an in-process status, which indicates that the running data is being loaded and executed by the corresponding target device.

[0192] Step 311 above is similar to step 303 above, and will not be repeated here.

[0193] Based on the example provided in step 303 above, assuming that the status information is implemented in the form of a status variable, the status variable corresponds to setting 4 possible values, for example, 00 represents the state to be released, 01 represents the state to be triggered, 10 represents the state to be executed, and 11 represents the state in execution.

[0194] The server then responds to the fact that the identification information of the running data has been sent to the target device. The server uses the identification information as an index in the database to query the index content stored corresponding to the index. The index content includes the running data and the status variable. At this time, the status variable is changed from the original 10 (pending execution status) to 11 (execution status), that is, the status variable is assigned the value 11.

[0195] In the above process, since the status information can reflect the process of the running data in the cloud platform in real time, the status information can also be fed back by the server to the terminal that uploaded or published the running data (usually the developer's terminal), so that the developer can understand the real-time status of the running data he wrote.

[0196] 312. Upon receiving the identification information, the target device loads and executes the runtime data based on the identification information.

[0197] In some embodiments, two loading methods for runtime data are provided. One is allocation loading, where the server sends the runtime data along with the identification information in step 310 above. In this case, the target device can directly execute the runtime data. Of course, if the server also sends a status variable, a verification process based on the status variable can be performed. This application embodiment does not specifically limit whether the verification process needs to be performed. The other is preemptive loading, where after receiving the identification information, the target device actively queries the index content stored in the (cloud) database using the identification information as an index. The index content includes at least the runtime data. The target device downloads the runtime data from the database and then executes the runtime data. Optionally, if the index content also includes a status variable, a verification process based on the status variable is also performed. This application embodiment does not specifically limit whether the verification process needs to be performed.

[0198] The following is an illustrative description of a verification process based on state variables: The target device compares the state variable read from the database (or actively sent by the server) with the state variable stored locally. If they match, the verification passes and the running data is executed normally. If they do not match, the verification fails and the abnormal situation is reported to the technical staff.

[0199] In steps 310-312 above, a possible implementation of the server executing the running data through the target device is shown. That is, the identification information of each data that needs to be executed periodically at the target time is stored in the message queue. When the target time is reached, the identification information stored in the message queue is distributed to the respective target devices. Each target device loads and executes its corresponding running data, thereby improving the thundering herd effect caused by suddenly waking up a large number of timed tasks (i.e. executing too much running data) at the target time.

[0200] Figure 10 This is a schematic diagram illustrating the principle of loading runtime data onto a target device, as shown in Figure 1000. Assume that at the target time, N (N≥1) identification information (ID) are recorded in the Kafka message queue. The server determines the load status of each candidate device in real time and pulls the IDs of the runtime data to be executed from the Kafka message queue in real time. Based on the load status of each candidate device, the server assigns the corresponding target device (i.e., execution unit worker) to each runtime data stored in the Kafka message queue. Optionally, in allocation-based loading, the server actively distributes runtime data to the target device; in preemptive loading, the server only distributes the ID of the runtime data to the target device. The target device actively queries the (cloud) database using this ID as an index to retrieve the corresponding index content. This index content includes the runtime data and the state variable. The target device then compares the state variable read from the database with the state variable stored locally. If they match, the verification is successful, and the runtime data is downloaded and executed. If they do not match, the verification fails, and this anomaly is reported to technical personnel. (Illustratively,) Figure 10 This illustrates a preemptive loading method, where each target device retrieves an image task from the cloud database using the received ID, and the cloud database returns the corresponding runtime data (i.e., the runtime data written by the developer in the IDE online platform) to the target device.

[0201] 313. Upon completion of the execution of the running data, the target device sends the execution results and running logs of the running data to the server.

[0202] In some embodiments, during the execution of the running data, a running log is generated simultaneously. This running log records all operations performed during the execution of the running data, and upon completion, an execution result is generated, which may indicate success or failure. The reasons for failure can be varied, such as a bug in the running data's code, a target device crash, or a network failure at the target device at the target time. After the target device completes the execution of the running data, it can compress and encrypt the identification information, running log, and execution result before sending them to the server.

[0203] 314. The server obtains the running results and running logs of the running data from the target device.

[0204] Optionally, the server receives the identification information, running results, and running logs sent by the target device. For running data with a running result of successful running, the server can send confirmation information to the terminal associated with the running data. The confirmation information is used to indicate that the running data has been completed (and no error has been reported). For running data with a running result of failed running, the server can perform the following step 315.

[0205] 315. When the server responds to the result of the operation as a failure, it sends an alarm message to the terminal associated with the operation data. The alarm message carries the operation result and the operation log.

[0206] Optionally, in response to the running data indicating a running failure, the server may send an alarm message to the terminal associated with the running data (which may be the terminal that published the running data or the terminal used for debugging bugs, etc.). The alarm message shall at least carry the running result and the running log. Optionally, the alarm message may also carry the original running data and the identification information of the running data. This application embodiment does not specifically limit this.

[0207] During the above process, the server can promptly obtain the running data of running failures by collecting the running logs and running results in a timely manner, and report them to the terminal so that users can promptly investigate the cause of the failure. This improves the timeliness of troubleshooting and makes it easier for users to quickly locate the cause of the failure based on the running logs.

[0208] In some embodiments, since the running data can be divided into code data that is executed once and code data that is executed periodically (i.e., cyclically), for code data that is executed once, the server can end the process and enter the next Tick unit of the timer. For code data that is executed cyclically, the server can respond to the fact that the running data is code data that is executed cyclically by adding the identification information of the running data to the tail of the message queue and repeat the operation similar to steps 307-315 above, which will not be elaborated here.

[0209] In the above process, by directly adding the identifier information to the current message queue of the code data that is executed in a loop, it is possible to avoid repeatedly calculating the message queue of the Tick unit to which the identifier information should be added, thereby saving server computing resources. In some embodiments, the code data that is executed in a loop can also be split into multiple identical timed tasks (i.e., copy multiple copies of the running data and set the target time in sequence), which can also ensure the smooth execution of periodic timed tasks.

[0210] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0211] The method provided in this application, after obtaining the running data, selects a target device whose load condition meets the target conditions from the candidate devices of the running environment that support the running data. This avoids conflicts that may be caused by incompatible running environments. Furthermore, the load condition can be used to reasonably allocate the target device to a more load-balanced target device so that the running data can be executed by the target device at the target time. Since a more load-balanced target device can be selected for each running data, resource utilization can be greatly improved.

[0212] Figure 11 This is a schematic diagram illustrating the principle of a method for processing runtime data provided in an embodiment of this application, such as... Figure 11 As shown, taking the running data as the script code as an example, the cloud platform 1100 that supports cloud function services includes a script management terminal 1101, a time wheel control module 1102, and a management platform 1103.

[0213] The script management terminal 1101 receives script code uploaded from various terminals, assigns a script ID (Identification) to each script code, and initializes the status information of the script code to a pending publication state. The script management terminal 1101 publishes the script code to be processed to the time wheel control module 1102. Optionally, during publication, the script management terminal 1101 can package each script code into Docker (an open-source application container engine) and deploy it on a microservice platform.

[0214] After receiving the script code from the script management terminal 1101, the time wheel control module 1102 binds the script code's script ID to the timer with the corresponding time granularity and updates the script code's status information to the pending trigger state. When the timer indicates that the target time has arrived, the script code's script ID is written to the message queue corresponding to the target time, and the script code's status information is updated to the pending execution state. After allocating a target device for the script code based on the operating environment and load conditions, the script code's script ID is sent to the target device. The target device then retrieves the complete script code from the database of the script management terminal 1101 based on the script ID, executes the script code, and updates the script code's status information to the executing state. For script code executed only once, the process ends at this point. For script code executed repeatedly, the script ID is added to the tail of the current message queue in the timer.

[0215] The management platform 1103, also known as the log platform, synchronizes the status information of each script code with the script management terminal 1101 and the time wheel control module 1102 in real time. Therefore, the management platform 1103 is used to check and view the status information of each script code. Optionally, it can also check and view the execution time of each script code. Furthermore, after each target device finishes executing each script code, each target device reports the running result of the script code and the log ID of the running log to the management platform 1103. If the running result is successful, the management platform 1103 can ignore the running result or send a confirmation message to the terminal associated with the script code. If the running result is a failure, the management platform can pull the complete running log from the target device according to the log ID, which is convenient for fault location of the script code.

[0216] The following is a schematic code illustrating the operation results and log ID reported by the target device to the management platform 1103. Optionally, the target device also reports the execution time of the script code to the management platform 1103:

[0217]

[0218] Figure 12 This is a schematic diagram of a management and statistics interface provided in an embodiment of this application. As shown in 1200, after the management platform 1103 collects the execution results and log IDs of each script code, it can also count the total number of script codes that failed to run within each time period, facilitating real-time alarms. Through the log ID and execution time, it also facilitates tracing back the script execution process and time consumption, making it easier to locate and troubleshoot faults. Figure 12The lower half of the document also shows that there were 186 scripts that failed to run within the specified time period, and lists the log ID, account ID of the terminal operated by the script, error domain, error code, and log storage location for each script.

[0219] In this embodiment, a cloud platform supporting cloud function services provides an efficient running solution for timed scripts based on the distributed function computation time loop algorithm. Compared with the drawbacks of related technologies, such as inflexible single-machine deployment, complex operating environment dependencies, and inability to balance load, users can quickly develop scripts using the cloud platform. It also supports the reuse of interfaces of other co-built cloud services, ensuring high availability and scalability of script execution, as well as high performance. It can balance cluster load, support multi-granularity timed tasks, and provide a complete understanding of the script execution process.

[0220] Figure 13 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application. Please refer to it. Figure 13 The device includes:

[0221] The acquisition module 1301 is used to acquire the running data to be processed, which is the code data running at the target time.

[0222] The first determining module 1302 is used to determine, in response to the arrival of the target time, multiple candidate devices that support the operating environment based on the operating environment of the operating data;

[0223] The second determining module 1303 is used to determine a target device from the multiple candidate devices based on the load conditions of the multiple candidate devices, wherein the load conditions of the target device meet the target conditions;

[0224] Execution module 1304 is used to execute the running data through the target device.

[0225] The apparatus provided in this application, after acquiring the running data, selects a target device whose load condition meets the target conditions from among the candidate devices of the running environment that support the running data. This avoids conflicts that may be caused by incompatible running environments. Furthermore, the load condition can be used to reasonably allocate the target device to a more load-balanced target device so that the running data can be executed by the target device at the target time. Since a more load-balanced target device can be selected for each running data, resource utilization can be greatly improved.

[0226] In one possible implementation, the execution module 1304 is used to:

[0227] In response to the arrival of the target time, the identification information of multiple data items to be executed at the target time is added to the message queue, including the running data;

[0228] For the running data in the message queue, the identification information of the running data is sent to the target device, and the target device loads and executes the running data based on the identification information.

[0229] In one possible implementation, based on Figure 13 The device comprises:

[0230] The first setting module is used to set the status information of the running data to a pending execution state in response to the addition of the identification information of the running data to the message queue. The pending execution state is used to indicate that the target time has been reached but the running data has not yet been sent to the corresponding target device.

[0231] In one possible implementation, based on Figure 13 The device comprises:

[0232] The second setting module is used to set the status information of the running data to an "in execution" state in response to the identification information of the running data being sent to the target device. The "in execution" state indicates that the running data is being loaded and executed by the corresponding target device.

[0233] In one possible implementation, based on Figure 13 The device comprises:

[0234] Add a module to add the identifier information of the running data to the tail of the message queue in response to the running data being code data that is executed in a loop.

[0235] In one possible implementation, the load condition includes at least one of central processing unit (CPU) utilization, disk input / output (I / O) utilization, or memory occupancy, and the second determining module 1303 is used to:

[0236] From these multiple candidate devices, determine the candidate device with the lowest CPU utilization as the target device; or,

[0237] From these multiple candidate devices, the candidate device with the lowest disk I / O utilization is selected as the target device; or,

[0238] From the multiple candidate devices, the candidate device with the lowest memory usage rate is selected as the target device.

[0239] In one possible implementation, the second determining module 1303 is used to:

[0240] Based on the geographic location associated with the operational data, at least one first device is determined from the plurality of candidate devices, the first device supporting the provision of services to terminals within the geographic location;

[0241] From the at least one first device, determine the target device whose load condition meets the target condition.

[0242] In one possible implementation, based on Figure 13 The device comprises:

[0243] The association module is used to associate the running data with the timer corresponding to the time granularity of the target time, and the timer is used to determine whether the target time has been reached.

[0244] In one possible implementation, the time granularity includes at least one of seconds, minutes, or hours, and the association module is used for:

[0245] In response to the target time being measured in seconds, the running data is associated with a seconds timer whose minimum timing unit is 1 second; or,

[0246] In response to the target time being measured in minutes, the running data is associated with a minute timer whose minimum timing unit is 1 minute; or,

[0247] In response to the target time being granular in hours, the running data is associated with an hour timer whose minimum timing unit is 1 hour.

[0248] In one possible implementation, the association module is used for:

[0249] Assign identification information to the running data and bind the identification information to the timer corresponding to the time granularity.

[0250] In one possible implementation, based on Figure 13 The device comprises:

[0251] The third setting module is used to set the status information of the running data to a pending state in response to the running data being associated with the timer. The pending state indicates that the running data has been bound to the corresponding timer but has not yet reached the target time.

[0252] In one possible implementation, based on Figure 13 The device comprises:

[0253] The fourth setting module is used to set the status information of the running data to a pending release status in response to the acquisition of the running data. The pending release status is used to indicate that the running data has been acquired but has not been bound to the corresponding timer.

[0254] In one possible implementation, the acquisition module 1301 is further configured to acquire the operation results and operation logs of the operation data from the target device;

[0255] based on Figure 13 The device comprises: a sending module, used to send an alarm message to a terminal associated with the running data in response to the running result being a running failure, the alarm message carrying the running result and the running log.

[0256] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0257] It should be noted that the above embodiments of the running data processing device are only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computer device can be divided into different functional modules to complete all or part of the functions described above. In addition, the running data processing device and the running data processing method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the running data processing method embodiments, which will not be repeated here.

[0258] Figure 14 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 14 As shown, the example of terminal 1400 is a computer device. Terminal 1400 can be a script management terminal in a server cluster, that is, a device in a server cluster used to receive running data. It can also be a management platform in a server cluster, that is, a device in a server cluster used to collect the running results and running logs of various running data. It can also be a candidate device or target device in a server cluster used to execute running data. This application embodiment does not specifically limit this.

[0259] Optionally, the device type of the terminal 1400 includes: a smartphone, tablet computer, MP3 player (Moving Picture Experts Group Audio Layer III), MP4 player (Moving Picture Experts Group Audio Layer IV), laptop computer, or desktop computer. The terminal 1400 may also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or other names.

[0260] Typically, terminal 1400 includes a processor 1401 and a memory 1402.

[0261] Optionally, the processor 1401 includes one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Optionally, the processor 1401 is implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). In some embodiments, the processor 1401 includes a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 1401 integrates a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the screen. In some embodiments, the processor 1401 also includes an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0262] In some embodiments, the memory 1402 includes one or more computer-readable storage media, optionally non-transitory. Optionally, the memory 1402 also includes high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1402 is used to store at least one program code, which is executed by the processor 1401 to implement the data processing methods provided in the various embodiments of this application.

[0263] In some embodiments, the terminal 1400 may also optionally include a peripheral device interface 1403 and at least one peripheral device. The processor 1401, memory 1402, and peripheral device interface 1403 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 1403 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: a radio frequency circuit 1404, a display screen 1405, a camera assembly 1406, an audio circuit 1407, and a power supply 1408.

[0264] Peripheral interface 1403 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 1401 and memory 1402. In some embodiments, processor 1401, memory 1402 and peripheral interface 1403 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 1401, memory 1402 and peripheral interface 1403 are implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0265] The radio frequency (RF) circuit 1404 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 1404 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 1404 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 1404 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. Optionally, the RF circuit 1404 communicates with other terminals via at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: metropolitan area networks (MANs), various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks (WLANs), and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 1404 also includes circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0266] Display screen 1405 is used to display a UI (User Interface). Optionally, the UI includes graphics, text, icons, videos, and any combination thereof. When display screen 1405 is a touch display screen, display screen 1405 also has the ability to collect touch signals on or above the surface of display screen 1405. The touch signals can be input to processor 1401 for processing as control signals. Optionally, display screen 1405 is also used to provide virtual buttons and / or virtual keyboards, also known as soft buttons and / or soft keyboards. In some embodiments, there is one display screen 1405, which is set on the front panel of terminal 1400; in other embodiments, there are at least two display screens 1405, which are respectively set on different surfaces of terminal 1400 or have a folded design; in still other embodiments, display screen 1405 is a flexible display screen, which is set on the curved surface or folded surface of terminal 1400. Furthermore, optionally, display screen 1405 is set as a non-rectangular irregular shape, that is, an irregularly shaped screen. Optionally, the display screen 1405 is made of materials such as LCD (Liquid Crystal Display) or OLED (Organic Light-Emitting Diode).

[0267] The camera assembly 1406 is used to acquire images or videos. Optionally, the camera assembly 1406 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the terminal, and the rear-facing camera is located on the back of the terminal. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 1406 also includes a flash. Optionally, the flash is a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm-light flash and a cool-light flash, used for light compensation at different color temperatures.

[0268] In some embodiments, the audio circuit 1407 includes a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, and convert the sound waves into electrical signals that are input to the processor 1401 for processing, or input to the radio frequency circuit 1404 to realize voice communication. For stereo acquisition or noise reduction purposes, multiple microphones are used, each located at a different part of the terminal 1400. Optionally, the microphone is an array microphone or an omnidirectional acquisition microphone. The speaker is used to convert the electrical signals from the processor 1401 or the radio frequency circuit 1404 into sound waves. Optionally, the speaker is a conventional film speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can convert electrical signals not only into sound waves that humans can hear, but also into sound waves that humans cannot hear for purposes such as distance measurement. In some embodiments, the audio circuit 1407 also includes a headphone jack.

[0269] Power supply 1408 is used to power the various components in terminal 1400. Optionally, power supply 1408 is AC power, DC power, a disposable battery, or a rechargeable battery. When power supply 1408 includes a rechargeable battery, the rechargeable battery supports wired or wireless charging. The rechargeable battery also supports fast charging technology.

[0270] In some embodiments, the terminal 1400 further includes one or more sensors 1409. The one or more sensors 1409 include, but are not limited to: an accelerometer 1410, a gyroscope 1411, a pressure sensor 1412, an optical sensor 1413, and a proximity sensor 1414.

[0271] In some embodiments, the accelerometer 1410 detects the magnitude of acceleration along the three coordinate axes of a coordinate system established with the terminal 1400. For example, the accelerometer 1410 is used to detect the components of gravitational acceleration along the three coordinate axes. Optionally, the processor 1401 controls the display screen 1405 to display the user interface in either a landscape or portrait view based on the gravitational acceleration signal acquired by the accelerometer 1410. The accelerometer 1410 is also used for acquiring motion data from games or the user.

[0272] In some embodiments, the gyroscope sensor 1411 detects the orientation and rotation angle of the terminal 1400. The gyroscope sensor 1411 and the accelerometer sensor 1410 work together to acquire the user's 3D movements on the terminal 1400. Based on the data acquired by the gyroscope sensor 1411, the processor 1401 implements the following functions: motion sensing (e.g., changing the UI based on the user's tilt operation), image stabilization during shooting, game control, and inertial navigation.

[0273] Optionally, the pressure sensor 1412 is disposed on the side bezel of the terminal 1400 and / or on the lower layer of the display screen 1405. When the pressure sensor 1412 is disposed on the side bezel of the terminal 1400, it can detect the user's grip signal on the terminal 1400, and the processor 1401 performs left / right hand recognition or quick operation based on the grip signal collected by the pressure sensor 1412. When the pressure sensor 1412 is disposed on the lower layer of the display screen 1405, the processor 1401 controls the operable controls on the UI interface based on the user's pressure operation on the display screen 1405. The operable controls include at least one of button controls, scroll bar controls, icon controls, and menu controls.

[0274] An optical sensor 1413 is used to collect ambient light intensity. In one embodiment, the processor 1401 controls the display brightness of the display screen 1405 based on the ambient light intensity collected by the optical sensor 1413. Specifically, when the ambient light intensity is high, the display brightness of the display screen 1405 is increased; when the ambient light intensity is low, the display brightness of the display screen 1405 is decreased. In another embodiment, the processor 1401 also dynamically adjusts the shooting parameters of the camera assembly 1406 based on the ambient light intensity collected by the optical sensor 1413.

[0275] The proximity sensor 1414, also known as a distance sensor, is typically located on the front panel of the terminal 1400. The proximity sensor 1414 is used to detect the distance between the user and the front of the terminal 1400. In one embodiment, when the proximity sensor 1414 detects that the distance between the user and the front of the terminal 1400 is gradually decreasing, the processor 1401 controls the display screen 1405 to switch from a screen-on state to a screen-off state; when the proximity sensor 1414 detects that the distance between the user and the front of the terminal 1400 is gradually increasing, the processor 1401 controls the display screen 1405 to switch from a screen-off state to a screen-on state.

[0276] Those skilled in the art will understand that Figure 14 The structure shown does not constitute a limitation on terminal 1400, which may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0277] Figure 15This is a schematic diagram of a computer device 1500 provided in an embodiment of this application. The computer device 1500 can vary significantly due to differences in configuration or performance. The computer device 1500 includes one or more Central Processing Units (CPUs) 1501 and one or more memories 1502. The memories 1502 store at least one computer program, which is loaded and executed by the one or more processors 1501 to implement the data processing methods provided in the various embodiments described above. Optionally, the computer device 1500 also includes wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The computer device 1500 also includes other components for implementing device functions, which will not be elaborated here.

[0278] In an exemplary embodiment, a computer-readable storage medium is also provided, such as a memory including at least one computer program, which can be executed by a processor in a terminal to perform the data processing methods in the various embodiments described above. For example, the computer-readable storage medium includes ROM (Read-Only Memory), RAM (Random-Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, and optical data storage devices, etc.

[0279] In an exemplary embodiment, a computer program product or computer program is also provided, including one or more lines of program code stored in a computer-readable storage medium. One or more processors of a computer device are capable of reading the one or more lines of program code from the computer-readable storage medium, and the one or more processors execute the one or more lines of program code, enabling the computer device to perform the data processing method described in the above embodiments.

[0280] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. Optionally, the program is stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0281] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A processing method of operation data, characterized by, The cloud platform comprises a script management end and a time wheel control module, and the cloud platform refers to a platform providing a cloud function service; the method comprises: The script management end receives running data uploaded by each terminal, allocates identification information for each running data, packs the running data into docker, and deploys the running data on a micro-service platform; the script management end publishes the identification information of the running data to the time wheel control module; the running data refers to script code running at a target time; After the time wheel control module receives the identification information of the running data published by the script management end, in response to reaching the target time, the time wheel control module determines a plurality of candidate devices supporting the running environment of the running data based on the running environment of the running data; based on the load conditions of the plurality of candidate devices, the time wheel control module determines a target device from the plurality of candidate devices, and the load condition of the target device meets a target condition; the time wheel control module sends the identification information of the running data to the target device, and the target device pulls a docker image from a database of the script management end based on the identification information, and executes the running data through a POD; The terminal is used to write the running data in a software development application associated with the cloud platform by using a language supported by the cloud platform, and set a running condition of the running data, and the running condition comprises the target time; The cloud platform further comprises a management platform, and after the running data is executed, the method further comprises: the management platform acquires a running result of the running data and a log ID of a running log from the target device; in response to the running result being a running failure, the management platform pulls the running log from the target device according to the log ID, and sends alarm information to a terminal associated with the running data, and the alarm information carries the running result and the running log, and the alarm information is used to locate a fault in the running data; The method further comprises: identifying the running environment of the running data through a machine learning model; or, identifying the running environment of the running data through a programming syntax of the running data; or, manually identifying the running environment of the running data; or, the running data carries running environment indication information, and the running environment of the running data is determined based on the running environment indication information.

2. The method of claim 1, wherein, The method further comprises: In response to reaching the target time, identification information of a plurality of data executed at the target time is added to a message queue, and the plurality of data comprises the running data; For the running data in the message queue, the identification information of the running data is sent to the target device.

3. The method of claim 2, wherein, After the identification information of the plurality of data executed at the target time is added to the message queue, the method further comprises: In response to the identification information of the running data being added to the message queue, state information of the running data is set to a to-be-executed state, and the to-be-executed state is used to represent that the target time has been reached but the running data has not been issued to the corresponding target device.

4. The method of claim 2, wherein, After the identification information of the multiple data executed at the target time is added to the message queue, the method further comprises: In response to the identification information of the running data being sent to the target device, setting state information of the running data as an executing state, the executing state being used to represent that the running data is being loaded and executed by the corresponding target device.

5. The method according to any one of claims 2 to 4, characterized in that, After the running data is executed, the method further comprises: In response to the running data being code data executed in a loop, adding the identification information of the running data to the tail of the message queue.

6. The method of claim 1, wherein, The load condition comprises at least one of a central processing unit (CPU) usage rate, a disk input / output (I / O) utilization rate, or a memory occupancy rate, and determining the target device from the multiple candidate devices based on the load condition of the multiple candidate devices comprises: Determining, from the multiple candidate devices, a candidate device with the lowest CPU usage rate as the target device; or Determining, from the multiple candidate devices, a candidate device with the lowest disk I / O utilization rate as the target device; or Determining, from the multiple candidate devices, a candidate device with the lowest memory occupancy rate as the target device.

7. The method of claim 1, wherein, Determining the target device from the multiple candidate devices based on the load condition of the multiple candidate devices comprises: Determining, from the multiple candidate devices, at least one first device supporting providing services to terminals within a geographic location associated with the running data based on the geographic location; Determining, from the at least one first device, the target device with a load condition meeting the target condition.

8. The method of claim 1, wherein, Before determining, in response to the target time being reached, multiple candidate devices supporting a running environment of the running data based on the running environment, the method further comprises: The time wheel control module associates the running data with a timer corresponding to a time granularity of the target time, the timer being used to determine whether the target time is reached.

9. The method of claim 8, wherein, The time granularity comprises at least one of a second, a minute, or an hour, and binding the identification information of the running data to the timer corresponding to the time granularity of the target time comprises: In response to the time granularity of the target time being a second, binding the identification information of the running data to a second timer, the minimum timing unit of the second timer being 1 second; or In response to the time granularity of the target time being a minute, binding the identification information of the running data to a minute timer, the minimum timing unit of the minute timer being 1 minute; or In response to the time granularity of the target time being an hour, binding the identification information of the running data to an hour timer, the minimum timing unit of the hour timer being 1 hour.

10. The method of claim 8, wherein, After the identification information of the running data is bound to the timer corresponding to the time granularity of the target time, the method further comprises: In response to the identification information of the running data being bound to the timer, set state information of the running data as a to-be-triggered state, the to-be-triggered state being used to represent that the identification information of the running data has been bound to the corresponding timer but has not reached the target moment.

11. The method of claim 1, wherein, The method further comprises: In response to receiving the running data, set state information of the running data as a to-be-published state, the to-be-published state being used to represent that the running data has been acquired but is not bound to the corresponding timer.

12. A processing device of operation data, characterized by, The device is configured on a cloud platform, the cloud platform being a platform providing a cloud function service; the device comprises: An obtaining module is configured to receive running data uploaded by each terminal, allocate identification information to each running data, package the running data into docker, and deploy the running data on a micro-service platform; and publish the identification information of the running data, the running data being script code to be run at a target moment; A first determining module is configured to, in response to reaching the target moment, determine, based on a running environment of the running data, a plurality of candidate devices supporting the running environment; A second determining module is configured to determine, based on load conditions of the plurality of candidate devices, a target device from the plurality of candidate devices, the load condition of the target device meeting a target condition; An executing module is further configured to send the identification information of the running data to the target device, and pull, by the target device, a docker image from a database based on the identification information, and execute the running data through a POD; The terminal is configured to write the running data in a language supported by the cloud platform in a software development application associated with the cloud platform, and set a running condition of the running data, the running condition comprising the target moment; The obtaining module is further configured to obtain, from the target device, a running result of the running data and a log ID of a running log; The device further comprises a sending module configured to, in response to the running result being a running failure, pull the running log from the target device according to the log ID, and send alarm information to a terminal associated with the running data, the alarm information carrying the running result and the running log, the alarm information being used to locate a fault in the running data; The first determining module is further configured to identify the running environment of the running data through a machine learning model, or identify the running environment of the running data through a programming syntax of the running data, or manually identify the running environment of the running data, or the running data carrying running environment indication information, and determine the running environment of the running data based on the running environment indication information.

13. The apparatus of claim 12, wherein, The executing module is configured to: In response to reaching the target moment, add identification information of a plurality of data executed at the target moment to a message queue, the plurality of data comprising the running data; For the running data in the message queue, send the identification information of the running data to the target device.

14. The apparatus of claim 13, wherein, The device further comprises: The first setting module is configured to set state information of the running data as a to-be-executed state in response to the identification information of the running data being added to the message queue, the to-be-executed state being used to represent that the target moment has been reached but the running data has not been issued to the corresponding target device.

15. The apparatus of claim 13, wherein, The apparatus further includes: The second setting module is configured to set the state information of the running data as an executing state in response to the identification information of the running data being sent to the target device, the executing state being used to represent that the running data is being loaded and executed by the corresponding target device.

16. The apparatus of any one of claims 13-15, wherein, The apparatus further includes: The adding module is configured to add the identification information of the running data to the tail of the message queue in response to the running data being code data to be executed in a loop.

17. The apparatus of claim 12, wherein, The load condition includes at least one of a central processing unit (CPU) usage rate, a disk input / output (I / O) utilization rate, or a memory occupancy rate, and the second determining module is configured to: determine, from the plurality of candidate devices, a candidate device with the lowest CPU usage rate as the target device; or determine, from the plurality of candidate devices, a candidate device with the lowest disk I / O utilization rate as the target device; or determine, from the plurality of candidate devices, a candidate device with the lowest memory occupancy rate as the target device.

18. The apparatus of claim 12, wherein, The second determining module is configured to: determine, from the plurality of candidate devices, at least one first device based on a geographic location associated with the running data, the first device supporting providing services to terminals within the geographic location; and determine, from the at least one first device, the target device with a load condition meeting the target condition.

19. The apparatus of claim 12, wherein, The apparatus further includes: The association module is configured to associate the running data with a timer corresponding to a time granularity of the target moment, the timer being used to determine whether the target moment has been reached.

20. The apparatus of claim 19, wherein, The time granularity includes at least one of a second, a minute, or an hour, and the association module is configured to: associate the running data with a second timer in response to the time granularity of the target moment being a second, the second timer having a minimum timing unit of 1 second; or associate the running data with a minute timer in response to the time granularity of the target moment being a minute, the minute timer having a minimum timing unit of 1 minute; or associate the running data with an hour timer in response to the time granularity of the target moment being an hour, the hour timer having a minimum timing unit of 1 hour.

21. The apparatus of claim 19, wherein, The apparatus further includes: The third setting module is configured to set the state information of the running data as a to-be-triggered state in response to the identification information of the running data having been bound to the timer, the to-be-triggered state being used to represent that the running data has been bound to the corresponding timer but the target moment has not been reached.

22. The apparatus of claim 12, wherein, The apparatus further includes: The fourth setting module is configured to set the state information of the running data as a to-be-published state in response to the running data being received, the to-be-published state being used to represent that the running data has been acquired but not bound to the corresponding timer.

23. A computer device, comprising: The computer device comprises one or more processors and one or more memories, and at least one computer program is stored in the one or more memories, and the at least one computer program is loaded and executed by the one or more processors to implement the processing method of the running data according to any one of claims 1 to 11.

24. A computer-readable storage medium, characterized in that, The computer readable storage medium stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the processing method of the running data according to any one of claims 1 to 11.

25. A computer program product, characterised in that, The computer readable storage medium stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the processing method of the running data according to any one of claims 1 to 11.

Images