Service configuration scheduling method, electronic device, and storage medium

Abstract

The application provides a service configuration scheduling method, an electronic device and a storage medium. The method comprises the following steps: receiving a data operation request; obtaining a service configuration at the head of a service configuration list as a target service configuration; calling a client corresponding to the target service configuration to execute the data operation request; if the execution result meets a preset completion condition and the target service configuration is not at the head of the list, adjusting the target service configuration to the head of the list; if the execution result does not meet the preset completion condition, switching to the next service configuration to re-execute until the condition is met or all service configurations fail. The application dynamically adjusts the arrangement order of the service configuration list according to the execution result of the current data operation request, solves the problem that the scheduling decision lags behind the real-time state change of the service, and is difficult to respond to the sudden performance decline or service unavailability of the service in a timely manner, and improves the scheduling efficiency and system availability in the multi-cloud storage scene.

Description

Technical Field

[0001] This application relates to the field of object storage technology, and in particular to a service configuration scheduling method. Background Technology

[0002] With the rapid development of cloud computing technology, object storage services have become an important choice for enterprises and institutions to store unstructured data. To reduce vendor lock-in risk and improve data reliability, multi-cloud deployment strategies are widely adopted, which involve simultaneously connecting to multiple object storage services for data storage.

[0003] In multi-cloud storage scenarios, when a business system needs to perform data write or read operations, it typically needs to select a target service from multiple object storage services. In existing technologies, service selection strategies usually rely on an independent scheduling center or monitoring component to periodically collect load information, response time, and other metrics from each object storage service, calculate, and issue scheduling decisions. In this type of solution, because load information collection is performed periodically, there is a time window between data collection, reporting, processing, and the final issuance of the scheduling decision. If a service experiences a sudden performance degradation or becomes unavailable within this time window, the collected data has not yet been updated. The scheduling center may still send requests to the degraded or unavailable service based on outdated data, failing to detect this change before the next collection cycle. This results in multiple requests within this time window facing the risk of delayed response or even execution failure, potentially leading to business interruption, impacting system continuity and user experience.

[0004] Therefore, traditional solutions suffer from scheduling decisions lagging behind real-time changes in service status, making it difficult to respond promptly to sudden performance degradation or service unavailability. Summary of the Invention

[0005] The main purpose of this application is to provide a service configuration scheduling method that aims to solve the technical problem that scheduling decisions lag behind real-time changes in service status, making it difficult to respond in a timely manner to sudden service performance degradation or service unavailability.

[0006] To achieve the above objectives, a service configuration scheduling method is provided, characterized in that the service configuration scheduling includes: Receive data operation requests; Retrieve the service configuration that is first and last in the preset service configuration list, and use it as the target service configuration; The first target client corresponding to the target service configuration is invoked to execute the data operation request; If the execution result of the data operation request meets the preset completion conditions and the target service configuration is not at the top of the service configuration list, then the target service configuration will be moved to the top of the service configuration list. If the execution result of the data operation request does not meet the preset completion conditions, then switch to the next service configuration according to the order of the service configuration list to obtain a new target service configuration; Based on the new target service configuration, return to the first target client corresponding to the target service configuration to execute the data operation request until the preset completion condition is met or all service configurations fail to execute.

[0007] In one embodiment, before the step of invoking the first target client corresponding to the target service configuration to execute the data operation request, the method further includes: Determine whether there exists a cached first historical client that matches the target service configuration; If the first historical client exists, then the first historical client is reused as the first target client; If the first historical client does not exist, a new client is created according to the target service configuration and used as the first target client.

[0008] In one embodiment, after the step of invoking the first target client corresponding to the target service configuration to execute the data operation request, the method further includes: If the execution result of the data operation request meets the preset completion condition, and the response time of the first client corresponding to the target service configuration in executing the data operation request exceeds the preset threshold, and the target service configuration is not the last item in the service configuration list, then the target service configuration is swapped with the next target service configuration in the service configuration list.

[0009] In one embodiment, after the step of invoking the first target client corresponding to the target service configuration to execute the data operation request, the method further includes: If the execution result of the data operation request does not meet the preset completion conditions, the client connection in the first target client used to execute the data operation request is destroyed, wherein the client connection is the connection between the first target client and the object storage service corresponding to the target service configuration; Determine whether the target service configuration is the last item in the service configuration list; If the target service configuration is not the last item in the service configuration list, then the order of the target service configuration in the service configuration list is adjusted to the end of the service configuration list.

[0010] In one embodiment, after the step of invoking the first target client corresponding to the target service configuration to execute the data operation request, the method further includes: If the execution result of the data operation request meets the preset completion conditions, then the service name of the target service configuration, the operation type of the data operation request, and the file identifier of the target file of the data operation request are obtained through the asynchronous synchronous message corresponding to the data operation request. Based on the service name, obtain the second target client; Based on the operation type and the file identifier of the target file, the second client is invoked to retrieve the data corresponding to the file identifier of the target file from the object storage service corresponding to the service name; Based on the service name, obtain the second client corresponding to the other service configurations in the service configuration list besides the service name; Based on the service name, the operation type, and the file identifier of the target file, the second client corresponding to the other service configuration is invoked to synchronize the data corresponding to the file identifier of the target file to the object storage service corresponding to the other service configuration.

[0011] In one embodiment, the method further includes: According to a preset time period, obtain a preset list of file path prefixes, and traverse each file path prefix in the list of file path prefixes; Based on the currently traversed file path prefix, traverse the object storage service corresponding to each service configuration in the service configuration list, and obtain the metadata information of the target object in each object storage service that matches the file path prefix; Based on the metadata information, determine the write status of the target object in each object storage service in the service configuration list; If the target object fails to be written in some object storage services, then select one of the object storage services that successfully wrote the target object as the source service; Generate an asynchronous synchronization message corresponding to the target object to synchronize the target object from the source service to the object storage service where the write failed.

[0012] In one embodiment, applied to an object storage system, the method further includes: Load service configuration from external configuration files, parse the service configuration list, and obtain the service configuration list. If an update to the external configuration file is detected, the external configuration file is reloaded and the service configuration list is updated.

[0013] In one embodiment, the method further includes: When the service configuration list is idle, verify the availability of each object storage service in the service configuration list and obtain the verification result; Based on the verification results, the order of the service configuration list is rearranged.

[0014] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the service configuration scheduling method as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the service configuration scheduling method described above.

[0016] This application first receives a data operation request, obtains the first service configuration in a preset service configuration list as the target service configuration, and calls the first target client corresponding to the target service configuration to execute the data operation request. This determines the object storage service to be used first based on the order of service configurations in the service configuration list, thereby achieving unified management and orderly invocation of multiple object storage services. After the client executes the data operation request, this application determines whether the data operation request meets preset completion conditions to determine whether the current target service has successfully completed the data operation request. If the preset completion conditions are met, it indicates that the current target service can normally complete the data operation request, and the target service configuration is then moved to the first position in the service configuration list. Since the target service is verified to be available in the current operation, prioritizing it ensures that subsequent data operation requests use this service first, thereby shortening the service selection time for subsequent operations and improving the execution efficiency of data operations in multi-cloud storage scenarios. If the preset completion condition is not met, it means that the current target service cannot complete the data operation request normally. In this case, the system switches to the next service configuration according to the order of the service configuration list, obtains a new target service configuration, and returns to the step of calling the first target client to execute the data operation request based on the new target service configuration, until the preset completion condition is met or all service configurations fail. Since the switching is based on the execution result of the current request, when the service status is abnormal, the system switches immediately after a single request failure, avoiding continuous requests to the same unavailable service, thereby improving the success rate of data operations and the availability of the system in multi-cloud storage scenarios.

[0017] In summary, this application achieves automatic scheduling and failover between multiple object storage services by dynamically adjusting the order of service configurations in the service configuration list based on the execution result of the current data operation request—moving the successful one to the first position for priority use later, and automatically switching to the next service configuration to retry if it fails. This solves the problem that scheduling decisions lag behind real-time changes in service status and make it difficult to respond promptly to sudden performance degradation or service unavailability. Attached Figure Description

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

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

[0020] Figure 1 A flowchart illustrating the service configuration scheduling method of this application, provided in Embodiment 1; Figure 2 A flowchart illustrating the asynchronous and synchronous message process provided in Embodiment 1 of the service configuration scheduling method for this application; Figure 3 A flowchart illustrating the write request provided in Embodiment 1 of the service configuration scheduling method for this application; Figure 4 A flowchart illustrating the repair task provided in Embodiment 1 of the service configuration scheduling method for this application; Figure 5 A schematic diagram of the device structure of the hardware operating environment involved in Embodiment 2 of the service configuration scheduling method of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] Currently, service selection strategies typically rely on independent scheduling centers or monitoring components to periodically collect load information, response time, and other metrics from various object storage services, calculate, and issue scheduling decisions. In this approach, because load information collection is performed periodically, there is a time window between data collection, reporting, processing, and the final scheduling decision. If a service experiences a sudden performance degradation within this window, the collected data may not have been updated, and the scheduling center might still send requests to the degraded service based on outdated data. Therefore, traditional solutions suffer from scheduling decisions lagging behind real-time service status changes, making it difficult to respond promptly to sudden performance degradation or service unavailability.

[0025] The main solution of this application embodiment is as follows: receiving a data operation request; obtaining the first object storage service in the preset service configuration list as the target service; calling the client corresponding to the target service to execute the data operation request; if the preset completion condition corresponding to the data operation request is met, adjusting the order of the target service in the service configuration list to the first position in the service configuration list; if the preset completion condition corresponding to the data operation request is not met, switching to the next object storage service according to the order of the service configuration list to obtain a new target service, and based on the new target service, returning to the client corresponding to the target service to execute the data operation request, until the preset completion condition is met or all object storage services fail to execute.

[0026] This application achieves automatic scheduling and failover between multiple object storage services by dynamically adjusting the order of service configurations in the service configuration list based on the execution result of the current data operation request—moving the successful one to the first position for priority use later, and automatically switching to the next service configuration to retry if it fails. This solves the problem that scheduling decisions lag behind real-time changes in service status and make it difficult to respond in a timely manner to sudden performance degradation or service unavailability.

[0027] The service configuration scheduling method provided in this application can be applied to multi-cloud storage scenarios, where business systems need to distribute data operation requests to target services in multiple object storage services for processing. In this scenario, the application server, as the executor of scheduling decisions, manages the scheduling among multiple object storage services through the service configuration scheduling method of this application.

[0028] It should be noted that the execution entity in this embodiment can be a business server, application server, cloud server, or container instance, or other computing device with data processing, network communication, and program execution functions. This embodiment does not specifically limit this. The following description uses an application server as an example. Furthermore, this invention is not only applicable to object storage services but can also be extended to distributed storage service scenarios such as distributed database multi-replica synchronization, multi-cloud storage data backup, cross-regional data replication, and file system multi-node synchronization. Those skilled in the art can apply this invention to the aforementioned other distributed storage service scenarios.

[0029] Example 1 Based on this, embodiments of this application provide a service configuration scheduling method, referring to... Figure 1 , Figure 1 A flowchart illustrating the first embodiment of the service configuration scheduling method for this application.

[0030] In this embodiment, the service configuration scheduling method includes steps S10 to S60: Step S10: Receive a data operation request; It should be noted that "receiving" refers to the action of the execution entity (such as the application server) of the service configuration scheduling method obtaining a data operation request through a pre-defined communication interface. Data operation requests are triggered by the business system or internal system tasks and sent to the execution entity via application programming interfaces (APIs) or message queues. A data operation request is an instruction to perform data processing operations on a target file, originating from either a business system call or an internal system task. A data operation request must at least include the operation type, file identifier, and service name. The operation type includes add, read, update, or delete operations. The file identifier uniquely identifies the target file to be operated on, and the service name specifies the target object storage service to be operated on.

[0031] Step S20: Obtain the service configuration at the top of the preset service configuration list as the target service configuration; It's important to note that "retrieve" refers to the action of retrieving the first service configuration from the service configuration list. The default service configuration list is a pre-configured, ordered list of multiple service configurations stored in memory. A service configuration is a set of parameters used to describe and connect to the object storage service, including the service name, access key, secret key, access endpoint, bucket name, zone identifier, and gateway configuration. "First" refers to the position listed first in the service configuration list, indicating the highest scheduling priority. The target service configuration is the service configuration retrieved from the service configuration list that serves as the target of the current operation.

[0032] For example, if the service configuration list is arranged in the order of [service configuration A, service configuration B, service configuration C], then the first one is the service configuration corresponding to service configuration A, which is used as the target service configuration.

[0033] In one feasible implementation, step S20 may include steps S201 to S203: Step S201: Determine whether there exists a cached first historical client that matches the target service configuration; It should be noted that the judgment refers to the process by which the executing entity checks the cache area in memory to see if a client instance matching the target service configuration exists. Specifically, the executing entity obtains the service name and connection parameters from the target service configuration, uses the service name as the query key, and searches the cache area for a corresponding client instance. If it exists and the client instance is in an available state (i.e., not closed or destroyed), then it is determined that a first historical client matching the target service configuration exists; if it does not exist or the client instance is no longer available, then it is determined that no client exists. The first historical client refers to a client instance that has been previously created and cached in memory, and it is associated with the object storage service corresponding to the target service configuration. Caching means temporarily storing the created client instance in memory for reuse in subsequent operations, thereby avoiding the system overhead caused by repeatedly creating client instances. Matching means that the service configuration corresponding to the first historical client is consistent with the service name and connection parameters of the target service configuration, that is, the first historical client can be used to connect to the object storage service specified by the target service configuration.

[0034] Step S202: If the first historical client exists, then reuse the first historical client as the first target client; Reuse refers to directly using the first historical client instance as the target client for the current operation, without creating a new client instance. By reusing cached clients, the steps of authentication and connection establishment can be repeatedly executed, saving system resources. A client is the communication connection object between the application server and the object storage service, containing connection credentials and network connection information from the target service configuration, used to establish a communication link with the corresponding object storage service. The first target client refers to the client instance used for the current data operation request, used to communicate with the object storage service corresponding to the target service configuration and execute the data operation request. If a first historical client exists, it will be used as the first target client.

[0035] In step S203, if the first historical client does not exist, a new client is created according to the target service configuration and used as the first target client.

[0036] It should be noted that "creation" refers to creating a new client instance based on connection parameters such as service name, access credentials, access endpoint, bucket name, region identifier, and gateway configuration in the target service configuration. The new client refers to this newly created client instance. During creation, the system establishes a communication link with the object storage service corresponding to the target service configuration, completing authentication and connection establishment. After creation, the new client is used as the primary target client for executing the current data operation request. For example, the newly created client instance can be cached after creation for reuse in subsequent operation requests with the same service configuration.

[0037] For example, when a user uploads a file to service configuration A through the business system, step S20 obtains the service configuration corresponding to service configuration A as the target service configuration. Step S201 first checks whether there is a historical client in the cache that matches the service configuration. If it exists (i.e., a file has been uploaded to service configuration A before), then step S202 directly reuses that client as the first target client without re-authentication and connection; if it does not exist (i.e., the file is uploaded to service configuration A for the first time), then step S203 creates a new client instance based on the access credentials, access endpoint, and other information in the target service configuration, and uses it as the first target client.

[0038] In this implementation, by determining whether a historical client instance matches the target service configuration, and selecting to reuse an existing client or create a new client based on the determination result, on-demand acquisition and reuse of client instances are achieved. Since the creation of a client instance involves authentication and connection establishment with the object storage service, reusing an existing client can effectively reduce the system overhead caused by repeated creation, shorten the execution time of data operation requests, and thus improve the execution efficiency of data operations in multi-cloud storage scenarios.

[0039] Step S30: Invoke the first target client corresponding to the target service configuration to execute the data operation request; It should be noted that the client is the communication connection object between the application server and the object storage service. It contains the connection credentials and network connection information in the target service configuration and is used to establish a communication link with the corresponding object storage service. The first target client refers to the client instance corresponding to the target service configuration. Invocation refers to the process by which the executing entity, through the first target client, initiates an operation command to the object storage service corresponding to the target service configuration. Specifically, this includes: the executing entity calling the interface method in the first target client corresponding to the operation type (e.g., upload interface, download interface, delete interface, etc.), encapsulating the file identifier of the target file and operation parameters into a request, and sending it to the object storage service. Execution refers to the object storage service receiving the request, performing the corresponding data processing operation on the target file according to the operation type (e.g., storing data, reading data, updating data, or deleting data), and returning the operation result to the executing entity. The operation result includes status information indicating successful or failed execution.

[0040] For example, if the target service configuration is the configuration corresponding to service configuration A, then the first target client is a client instance between the application server and service configuration A. Calling this client will initiate a file upload request to service configuration A.

[0041] In one feasible implementation, step S30 may include steps S301 to S302: Step S301: If the execution result of the data operation request meets the preset completion condition, and the response time of the first client corresponding to the target service configuration to execute the data operation request exceeds the preset threshold, and the target service configuration is not the last item in the service configuration list, then the target service configuration and the next target service configuration in the service configuration list will be swapped. It should be noted that the preset completion condition refers to the state in which a data operation request has been successfully executed. For example, when the operation type is an add, read, update, or delete operation, if any object storage service is successfully executed, the preset completion condition is deemed met. It should be understood that the above determination method is only one possible approach. The specific determination method for the preset completion condition can be set according to actual business needs. For example, it could also be determined that the preset completion condition is met when a specified number or type of object storage service is successfully executed. This application does not specifically limit this.

[0042] Additionally, it should be noted that response time refers to the time elapsed between the first client initiating a data operation request to the object storage service corresponding to the target service configuration and receiving the operation result returned by the object storage service. The preset threshold is a pre-defined upper limit for response time, used to determine whether the object storage service corresponding to the target service configuration has experienced performance degradation. For example, the preset threshold can be a preset multiple of the average response time, such as 1.5 times, with no specific limitation. Performance degradation refers to a situation where the object storage service, even when capable of successfully completing the request, experiences a response time exceeding the preset threshold, resulting in a significant performance decrease. Performance degradation differs from operation failure—operation failure refers to a request returning an error or connection timeout, requiring switching to the next service for re-execution; while performance degradation occurs when a request has been successfully completed but the response is slow, and the current request does not need to be re-executed; only the scheduling priority of the service configuration needs to be adjusted.

[0043] Additionally, it's important to note that the last item in the service configuration list refers to the service configuration that appears last in the list. Swapping positions means exchanging the current target service configuration with the next service configuration in the service configuration list. In this step, when the object storage service corresponding to the target service configuration becomes degraded, and this service configuration is not the last item in the list, swapping its position with the next service configuration lowers the scheduling priority of the degraded service configuration by one position, while simultaneously raising the priority of the service configuration that originally followed it by one position. This allows subsequent requests to try the faster-responding service first.

[0044] For example, the current order of the service configuration list is [Service Configuration A, Service Configuration B, Service Configuration C], and the target service configuration is Service Configuration A. A user uploads a file to Service Configuration A through the business system. The upload succeeds, but the response time exceeds a preset threshold (e.g., 1.5 times the average response time), indicating that Service Configuration A has become inefficient. Since Service Configuration A is not the last item in the list, the system swaps its positions with Service Configuration B, resulting in a new service configuration list [Service Configuration B, Service Configuration A, Service Configuration C]. After the swap, the request has been successfully completed and does not need to be re-executed; the process ends. Subsequent requests will prioritize Service Configuration B, thus gradually filtering slow services to the back end of the list.

[0045] In this implementation, by detecting whether the response time of the object storage service corresponding to the target service configuration exceeds a preset threshold, when service deterioration occurs, its position is swapped with the next service configuration, achieving immediate response and automatic adjustment to slowed service response. Since the current request for the deteriorated service has already been successfully completed, it does not need to be re-executed; only its scheduling priority needs to be adjusted by swapping positions. Compared to existing technologies that rely on periodic collection mechanisms, this solution can detect slowed service response in the current request, without waiting for the next collection cycle, resulting in faster response speeds. It effectively avoids the problem of subsequent requests continuously being sent to the deteriorated service, improving the efficiency of data operations and the system's adaptability in multi-cloud storage scenarios.

[0046] In one feasible implementation, step S30 may include steps S303 to S307: Step S303: If the execution result of the data operation request meets the preset completion conditions, then obtain the service name of the target service configuration, the operation type of the data operation request, and the file identifier of the target file of the data operation request through the asynchronous synchronous message corresponding to the data operation request. It should be noted that if the execution result of the data operation request meets the preset completion conditions, this is a prerequisite for triggering the asynchronous synchronization process; that is, this step is only executed after the main process has been successfully completed. "Passing" refers to extracting the required information from the asynchronous synchronization message, which serves as the information carrier and acquisition method. The asynchronous synchronization message is generated after the data operation request is successfully executed and is used to trigger the cross-service data synchronization process. "Acquiring" refers to the process of parsing and extracting the service name of the target service configuration, the operation type of the data operation request, and the file identifier of the target file from the asynchronous synchronization message. The service name is a cloud service identifier field included in the target service configuration, used to identify the object storage service corresponding to this synchronization operation (i.e., the object storage service successfully executed in the main process). The operation type is used to determine the execution logic of the synchronization branch, including adding, updating, or deleting. The file identifier is used to uniquely identify the target file to be synchronized. Through this step, the asynchronous synchronization process can obtain the source service information, operation type, and target file information required for synchronization, providing a basis for subsequent data synchronization operations.

[0047] Step S304: Obtain the second target client based on the service name; It should be noted that the second target client is a client instance used for the synchronization process. It and the first target client in step S30 are independently created client instances, isolated from each other: the first target client is used for data operation execution in the main process, while the second target client is used for data acquisition and transmission in the synchronization process. This isolation design avoids resource contention and performance impact on the main process from the synchronization process. Acquisition refers to obtaining the corresponding client instance based on the service name. If a historical client instance matching the service name already exists in the cache, it is directly reused; otherwise, a new client instance is created based on the service configuration corresponding to the service name. The second target client establishes a communication connection with the object storage service corresponding to the service name.

[0048] Step S305: Based on the operation type and the file identifier of the target file, call the second client to obtain the data corresponding to the file identifier of the target file from the object storage service corresponding to the service name; It should be noted that the second client refers to the client instance obtained in step S304 used for the synchronization process. A call refers to the action of the executing entity initiating an operation instruction to the object storage service corresponding to the service name through the second client. When the operation type is an add or update operation, the call specifically involves: calling the method in the second client used to check if a file exists to check if the target file exists in the object storage service corresponding to the service name; if it does not exist, it means the file was deleted before synchronization was triggered, no synchronization is needed, and the current process ends; if it exists, the method in the second client used to download the file is called to download the complete file content of the target file from the object storage service corresponding to the service name to a temporary directory. When the operation type is a delete operation, the call refers to calling the method in the second client used to obtain file metadata to obtain the file identifier of the target file, indicating that the file should be deleted in another service, without needing to download the file content. Obtaining data refers to the process of obtaining the required data from the object storage service according to the operation type, including obtaining file content or obtaining file identifiers.

[0049] Step S306: Based on the service name, obtain the second client corresponding to the other service configurations in the service configuration list besides the service name; It should be noted that "other service configurations" refers to all service configurations in the service configuration list except for those corresponding to the service name, i.e., the set of target service configurations for this synchronization operation. "Acquisition" refers to the process of obtaining the corresponding second client instance based on the information of each target service configuration. Specifically, for each service configuration in the other service configurations, the executing entity first checks if a historical client instance matching that service configuration exists in the cache; if it exists, the historical client is reused as the second client corresponding to that service configuration; if it does not exist, a new client instance is created based on the connection parameters (including access key, secret key, access endpoint, etc.) in that service configuration, serving as the second client corresponding to that service configuration. The second client is a client instance corresponding to each target service configuration, used to synchronize data to the object storage service corresponding to each target service configuration. For add and update operations, this step is only executed after step S305 confirms the existence of the source file.

[0050] Step S307: Based on the service name, operation type, and file identifier of the target file, call the second client corresponding to the other service configuration to synchronize the data corresponding to the file identifier of the target file to the object storage service corresponding to the other service configuration.

[0051] It should be noted that a call refers to the action of the executing entity initiating an operation command to the object storage service corresponding to the other service configuration through the second client corresponding to the other service configuration. The specific execution logic of synchronization varies depending on the operation type: When the operation type is an add operation, synchronization refers to uploading the complete file content of the target file to the object storage service corresponding to the other service configuration. Uploading refers to the process of transferring data from the local temporary directory and writing it to the target object storage service. If the file already exists in the target service, it will be directly overwritten; if the upload fails, retry is supported. When the operation type is an update operation, synchronization refers to first calling the method in the second client used to check if the file exists, checking if the target file exists in the object storage service corresponding to the other service configuration, and then verifying it. If it exists and its modification time is earlier than the source file, the method in the second client used to upload the file is called to upload and overwrite it. If it exists and its modification time is not earlier than the source file, it is skipped; if it does not exist, it is skipped. When the operation type is a delete operation, synchronization refers to calling the method in the second client used to check if the file exists, checking if the file corresponding to the file identifier exists in the object storage service corresponding to the other service configuration. If it exists, the method in the second client used to delete the file is called to delete the file. For add and update operations, after synchronization is complete, the method for deleting temporary files in the second client needs to be called to delete the temporary files in the temporary directory.

[0052] For example, refer to Figure 2 , Figure 2 This is a flowchart for asynchronous / synchronous messages. It involves receiving asynchronous / synchronous messages, parsing the message content, and determining the operation type. If it's an add operation, retrieve the second client corresponding to the service name and check if the file exists. If it doesn't exist, it means it has been deleted, no need to add it, and the process ends; if it exists, call the second client to download the target file to the temporary directory, retrieve the second client corresponding to other service names, call the second client corresponding to those other service names to upload the target file to the corresponding other service, delete the temporary file, and the operation is successful.

[0053] If it's a deletion operation, obtain a second client with a different service name and check if the target file exists. If it doesn't exist, skip this step; if it exists, delete the target file corresponding to the other service name, and the operation succeeds.

[0054] If it's an update operation, retrieve the second client corresponding to the service name and check if the source file exists. If it doesn't exist, it means it has been deleted, no update is needed, and the process ends. If it exists, call the second client to download the target file to a temporary directory, retrieve the second client corresponding to other service names, and then call the second client corresponding to those other service names to upload the target file to the corresponding other service, ending the process.

[0055] In this implementation, by triggering asynchronous synchronization messages after the main process executes successfully and executing differentiated synchronization logic based on the operation type, data consistency is guaranteed among multiple object storage services. Add operations download files from the source service and upload them to all other services, supporting overwrite and retries to ensure newly written data is completely synchronized to all services. Update operations decide whether to overwrite after comparing modification times, avoiding incorrectly overwriting new version data with old version data. Deletion operations delete the corresponding file in other services, ensuring that deleted files do not remain in other services. Simultaneously, both add and update operations check the existence of the source file before execution; if the source file has been deleted, synchronization ends to prevent accidental data recovery due to synchronizing deleted files. Temporary files are automatically cleaned up after synchronization, releasing temporary storage resources. Throughout this process, the synchronization process is executed independently via asynchronous messages, decoupled from the main process, and does not affect the main process's response time. The second target client is isolated from the first target client, avoiding resource contention and performance impact on the main process from the synchronization process, thus improving the stability and data consistency of data operations in multi-cloud storage scenarios.

[0056] Step S40: If the execution result of the data operation request meets the preset completion conditions and the target service configuration is not at the top of the service configuration list, then the target service configuration is adjusted to the top of the service configuration list. It should be noted that the preset completion condition refers to the state in which a data operation request has been successfully executed. For example, when the operation type is an add, read, update, or delete operation, if any object storage service is successfully executed, the preset completion condition is deemed met. It should be understood that the above determination method is only one possible approach. The specific determination method for the preset completion condition can be set according to actual business needs. For example, it could also be determined that the preset completion condition is met when a specified number or type of object storage service is successfully executed. This application does not specifically limit this.

[0057] Additionally, it should be noted that "first place" refers to the position at the top of the service configuration list. Adjustment means moving the target service configuration to the top of the list while maintaining the relative order of other service configurations. If the target service configuration is already at the top, no adjustment is needed.

[0058] Additionally, it should be noted that this step and the processing logic for the degraded performance in step S301 have a sequential judgment relationship: when the execution result of the data operation request meets the preset completion conditions, it is further determined whether the response time of the first client corresponding to the target service configuration executing the data operation request exceeds a preset threshold; if it does not exceed the threshold, this step (adjusting the target service configuration to the first position) is executed; if it exceeds the threshold, step S301 is executed (swapping the positions of the target service configuration and the next service configuration). This step is for the case where the service response is normal, while step S301 is for the case where the service response is slow but the process can still be completed successfully, resulting in a degraded performance.

[0059] For example, a user uploads a file to service configuration A through the business system. After the upload is completed, a success response is returned, satisfying the preset completion conditions. If the service configuration corresponding to service configuration A is not currently at the top of the list, the system will automatically move it to the top.

[0060] Step S50: If the execution result of the data operation request does not meet the preset completion conditions, then switch to the next service configuration according to the order of the service configuration list to obtain a new target service configuration. It should be noted that failure to meet the preset completion conditions means that the object storage service corresponding to the target service configuration failed to successfully execute the data operation request. Switching refers to moving from the current target service configuration to the next service configuration in the service configuration list, based on the current order of the service configurations. The next service configuration is the service configuration that is closest in order to the current target service configuration in the service configuration list. The new target service configuration is the service configuration obtained after the switch, used to continue executing the data operation request.

[0061] For example, the service configuration list is arranged in the order of [service configuration A, service configuration B, service configuration C]. The current target service configuration is service configuration A. After the upload fails, the system switches to the service configuration corresponding to service configuration B in the list order as the new target service configuration.

[0062] Step S60: Based on the new target service configuration, return to the first target client corresponding to the target service configuration to execute the data operation request until the preset completion condition is met or all service configurations fail to execute.

[0063] It should be noted that "return execution" refers to re-executing the operation of calling the client to execute the data operation request in step S30 based on the new target service configuration, and re-performing the condition checks in steps S40 and S50 after the operation is completed. "All service configurations failed to execute" means that all service configurations in the service configuration list have been attempted to execute data operation requests and all have failed. The above switching and return execution process continues until either of the following conditions is met: 1) The object storage service corresponding to any service configuration successfully executes the data operation request, satisfying the preset completion condition; 2) All service configurations in the service configuration list have been attempted and all have failed. When all service configurations fail to execute, the process ends, and an alarm message can be issued to notify operations personnel that all available services are unavailable.

[0064] For example, if the current target service configuration fails to execute, it is moved to the end of the service configuration list, and the process switches to the next service configuration for re-execution. For instance, in one application scenario, the service configuration list is arranged in the order of [Service Configuration A, Service Configuration B, Service Configuration C]. If Service Configuration A fails to upload, it is moved to the end of the list, making the list [Service Configuration B, Service Configuration C, Service Configuration A], and the process switches to Service Configuration B for re-execution. If Service Configuration B uploads successfully, the process ends. If Service Configuration B also fails to upload, it is moved to the end of the list, making the list [Service Configuration C, Service Configuration A, Service Configuration B], and the process switches to Service Configuration C for re-execution. If Service Configuration C also fails to upload, all service configurations fail to execute, the process ends, and an alarm message can be issued to notify operations personnel that all services are unavailable.

[0065] For example, refer to Figure 3 , Figure 3 This is a flowchart of a write request. Upon receiving a write request, the system iterates through the service configuration list, checking if a cached client exists. If a cached client exists, it reuses that client; otherwise, a new client is created. The system calls the new client to upload a file and checks if the upload was successful. If the upload is successful, the system caches the service configuration and client, updates the service configuration list, generates synchronous and asynchronous messages, and returns a success message. If the upload fails, the system destroys the client connection, checks if a service configuration is available, and if so, continues iterating through the service configuration list to retry; otherwise, it returns a failure message.

[0066] This application's embodiment dynamically adjusts the order of object storage services in the service configuration list based on the execution result of the current data operation request—moving it to the first position for priority use after success, and automatically switching to the next service to retry if it fails—achieving automatic scheduling and failover between multiple object storage services. This solution addresses the time window problem caused by the timed data collection mechanism in existing technologies: existing technologies rely on historical statistical data collected periodically as the basis for scheduling decisions. There is a time window between data collection, reporting, processing, and decision issuance. When service performance suddenly declines, the collected data has not yet been updated, and the scheduling decision lags behind the actual service status. This application's embodiment uses the real-time execution result of the current request as the scheduling basis. When service performance suddenly declines, the service selection strategy can be adjusted immediately without waiting for the next collection cycle, thereby improving the success rate of data operations and the system's automated scheduling capabilities in multi-cloud storage scenarios.

[0067] In one feasible implementation, the service configuration scheduling method further includes: Step A10: According to the preset time period, obtain the preset file path prefix list, and traverse each file path prefix in the file path prefix list; It's important to note that the preset time period refers to a pre-defined interval for triggering repair tasks, used to periodically initiate the data repair process. By using a preset time period instead of real-time triggering, eventual data consistency can be ensured while avoiding the impact of frequent repair operations on system performance. "Acquisition" refers to reading the file path prefix list from the system configuration. The file path prefix list is a pre-defined set of file path prefixes to be repaired, used to limit the scope of the repair task and avoid the system overhead of fully traversing all objects. "Traversal" refers to sequentially reading each file path prefix in the file path prefix list as the object for subsequent processing steps.

[0068] Step A20: Based on the currently traversed file path prefix, traverse the object storage service corresponding to each service configuration in the service configuration list, and obtain the metadata information of the target object in each object storage service that matches the file path prefix; It should be noted that traversal refers to accessing each element in the collection sequentially according to a certain order. The service configuration list contains multiple service configurations, each corresponding to an object storage service. The target object refers to the file object that matches the current file path prefix. Metadata information refers to the attribute information about the target object stored in each object storage service, including at least whether the target object exists (i.e., whether the target object's metadata exists in the service, used to determine whether the service stores the object) and the corresponding write status flag, used to determine whether the data in each service is consistent. Retrieval refers to initiating a metadata query request to each object storage service and receiving the returned query results.

[0069] The execution process of this step is as follows: Under the currently traversed file path prefix, traverse each service configuration in the service configuration list; for the currently traversed service configuration, obtain a list of all target objects in its corresponding object storage service that match the current file path prefix; then traverse each target object in the target object list, and for the currently traversed target object, obtain its metadata information from the object storage service; repeat the above process until the metadata information of all target objects corresponding to the current service configuration has been obtained; continue to traverse the next service configuration, repeat the above process, until the metadata information of all target objects corresponding to all service configurations has been obtained.

[0070] Step A30: Determine the write status of the target object in each object storage service in the service configuration list based on the metadata information; It should be noted that "write status" refers to whether the target object has been successfully written to each object storage service. "Determine" refers to judging the write result of the target object in each object storage service based on the metadata information obtained in step A20.

[0071] For example, based on the metadata information returned by each object storage service, if a service has a metadata record of the target object and the record status is successful, then the service is determined to have written successfully; if the corresponding record does not exist or the record status is failed, then the service is determined to have written successfully.

[0072] Step A40: If the target object fails to be written in some object storage services, select one of the object storage services that successfully wrote the target object as the source service. It's important to note that "selection" refers to specifying a successfully written object storage service as the data source when a write failure occurs. The source service is the object storage service used to provide the data to be repaired. By selecting a successfully written service as the source service, the accuracy of the data upon which the repair is based is ensured.

[0073] For example, when the write status of the target object in three object storage services is two successes and one failure, one of the two successful write services is selected as the source service to provide data to the service that failed to write.

[0074] Step A50: Generate an asynchronous synchronization message corresponding to the target object to synchronize the target object from the source service to the object storage service where the write failed.

[0075] It should be noted that generation refers to the process by which the application server's main thread (i.e., the thread executing the repair task) constructs an asynchronous synchronous message. This main thread obtains information such as the target object's service name and file identifier from the source service selected in step A40, constructs an asynchronous synchronous message according to a preset message format, and sends the asynchronous synchronous message to the message queue. The asynchronous synchronous message contains the source service's service name, operation type (add operation), and the target object's file identifier, used to trigger the data synchronization process. The message queue is an intermediary component for asynchronous communication, used to temporarily store pending synchronization tasks, decoupling message generation from consumption. After the asynchronous synchronous message is sent to the message queue, the application server's synchronization thread retrieves and consumes the message from the message queue, performing the synchronization operation. Synchronization refers to the process of completely copying the target object from the source service to the object storage service where the write failed. By reusing the asynchronous synchronous message mechanism for repair tasks, there is no need to develop a separate data copying channel for repair tasks, reducing the complexity of system implementation. Furthermore, the repair task is decoupled from the main process, preventing the blocking of normal data operation requests.

[0076] For example, refer to Figure 4 , Figure 4 This is a flowchart of the repair task. The repair task is triggered by iterating through path prefixes, then iterating through all services based on the current path prefix, and querying the object list. The objects are then iterated through to obtain the target object and its metadata. If the target object's metadata shows a write failure, the service whose metadata was successfully written is selected as the source service, and an asynchronous / synchronous message is generated. The process continues: checking if there are still objects; if so, iterating through objects continues. It also checks if there are still services; if so, iterating through services continues. Finally, it checks if there are still prefixes; if so, iterating through path prefixes continues. After all iterations are complete, the repair task is finished.

[0077] In this implementation, by automatically triggering repair tasks according to a preset time period, the metadata information of each object storage service is traversed to identify objects with inconsistent write states. The source service is selected from the services with successful writes and asynchronous synchronization is triggered, thus achieving automatic discovery and repair of data inconsistency issues between multiple object storage services. Since the repair task is triggered only during the preset time period, the continuous consumption of system performance by real-time full scanning is avoided. Limiting the scan scope through a file path prefix list further reduces the overhead of the repair task. Reusing the asynchronous synchronization message mechanism for repair eliminates the need to develop a separate data replication channel for the repair task, reducing the complexity of system implementation. The repair task is decoupled through asynchronous messages, preventing the blocking of normal data operation requests and ensuring the response efficiency of the main process. Compared to manual intervention repair methods, this solution can periodically ensure eventual data consistency between services without manual intervention, reducing operation and maintenance costs and improving the reliability of data storage in multi-cloud storage scenarios.

[0078] In one feasible implementation, the service configuration scheduling method further includes: Step B10: Load and parse the service configuration from the external configuration file to obtain the service configuration list; It's important to note that loading refers to reading all service configuration information from an external configuration file into system memory. An external configuration file is a structured file, independent of the program code, used to store service configuration information, typically in YAML (YAML Ain't Markup Language) or JSON (JavaScript Object Notation) format. Parsing involves converting the read configuration information into system-recognizable service configuration objects according to a predefined data structure. The service configuration list is an ordered collection containing multiple service configurations, with the order determining their scheduling priority. Loading and parsing are usually performed at system startup, but can also be re-executed after a configuration file update is detected. This step, by storing service configurations in an external configuration file, decouples service configurations from program code, eliminating the need to recompile or repackage the program when configurations are modified.

[0079] Step B20: If an update to the external configuration file is detected, reload the external configuration file and update the service configuration list.

[0080] It's important to note that detecting updates to external configuration files refers to the system using a listening mechanism or periodic polling to detect whether the external configuration files have changed. Updating the service configuration list means replacing the service configuration list in memory with the new configuration content after reloading, making the new configuration effective. Updates include the following scenarios: when a new service configuration is added to the external configuration file, the new service configuration is added to the service configuration list; when a service configuration is removed from the external configuration file, the corresponding service configuration is deleted from the service configuration list; when service parameters in the external configuration file change, the corresponding service configuration is updated to the new parameters in the service configuration list. Configuration changes only affect the arrangement of the service configuration list in memory and do not interrupt ongoing operations; cached clients will update according to the updated service configuration on the next operation. When a new service configuration is added, a periodically triggered data synchronization mechanism synchronizes existing data to the object storage service corresponding to the new service to ensure data consistency between the old and new services. Through the above mechanisms, the system achieves hot-swapping of services, allowing configuration changes to take effect without restarting the system.

[0081] For example, suppose the system's current service configuration list contains two service configurations: Service Configuration A and Service Configuration B. If an operations and maintenance (O&M) personnel need to add Service Configuration C to the system, they add the corresponding service configuration item for Service Configuration C to the external configuration file. After the system detects the configuration file update and reloads, Service Configuration C is automatically added to the service configuration list, and subsequent data operation requests can automatically use Service Configuration C. If the O&M personnel need to remove Service Configuration B, they delete the corresponding configuration item for Service Configuration B from the external configuration file. After the system reloads, Service Configuration B is removed from the list, but currently executing operations are unaffected, and subsequent operations will no longer use Service Configuration B. If the O&M personnel need to change the access key for Service Configuration A, they modify the key parameter corresponding to Service Configuration A in the external configuration file. After the system reloads, the next time the client corresponding to Service Configuration A is called, the new key is used to create a connection.

[0082] In this implementation, by storing service configurations in an external configuration file and loading them at system startup and reloading them upon detecting updates, service configurations and program code are decoupled, and services are hot-swappable. Configuration changes take effect without a system restart; newly added services are automatically added to the scheduling list; removing services does not affect ongoing operations; and clients update according to the new configuration after service parameters are modified. When a new service is added, a periodically triggered data synchronization mechanism synchronizes existing data to the new service, ensuring data consistency between the old and new services. This mechanism allows operations personnel to dynamically adjust object storage services without interrupting business operations, reducing system maintenance complexity and downtime risks, and improving the flexibility and smoothness of service configuration changes in multi-cloud storage scenarios.

[0083] In one possible implementation, the method further includes updating the service configuration list during idle periods: Step C10: When the service configuration list is idle, verify the availability of each object storage service in the service configuration list and obtain the verification results; It's important to note that "idle" refers to a period of time when there are no ongoing data operation requests in the service configuration list, used to avoid interfering with normal business operations during the verification process. Verification involves obtaining real-time operational status information for each object storage service through a pre-defined health check mechanism. Availability is a comprehensive evaluation metric of whether the object storage service can currently handle data operation requests normally, typically based on a combination of parameters such as CPU utilization, memory utilization, network latency, and request response time. Verification results refer to the score or rating obtained after quantitatively assessing the availability of each object storage service, used to guide subsequent service configuration list reordering.

[0084] Step C20: Based on the verification results, rearrange the order of the service configuration list.

[0085] It should be noted that rearranging refers to adjusting the order of service configurations in the service configuration list based on the verification results. The adjustment method is as follows: the service configurations corresponding to object storage services with higher availability in the verification results are placed at the front of the service configuration list, while the service configurations corresponding to object storage services with lower availability or that are unavailable are placed at the back.

[0086] For example, suppose the current order of the service configuration list is [Service Configuration A, Service Configuration B, Service Configuration C]. When the system is idle, a verification is triggered to obtain parameters such as CPU utilization, memory utilization, and network latency for each service and perform a comprehensive evaluation. The verification results are: Service Configuration A scores 85 points, Service Configuration B scores 92 points, and Service Configuration C scores 78 points. After rearranging based on the verification results, the service configuration list is updated to [Service Configuration B, Service Configuration A, Service Configuration C], ensuring that the service with the highest current availability is prioritized in subsequent data operation requests.

[0087] In this embodiment, the availability of each object storage service is actively verified when the service configuration list is idle, and the order of the service configuration list is rearranged according to the verification results, so that services with higher availability are given higher scheduling priority, thereby adjusting the best service to the front of the list before the peak business period.

[0088] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the service configuration scheduling method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0089] Example 2 This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the service configuration scheduling method in Embodiment 1 above.

[0090] The following is for reference. Figure 5The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0091] like Figure 5 As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. While electronic devices with various systems are shown in the figures, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0092] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0093] The electronic device provided in this application, employing the service configuration scheduling method described in the above embodiments, can solve the technical problem that scheduling decisions lag behind real-time changes in service status, making it difficult to respond promptly to sudden service performance degradation or service unavailability. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the terminal unlocking method provided in the above embodiments, and other technical features of this electronic device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0094] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0095] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0096] Example 3 This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the service configuration scheduling method in the above embodiments.

[0097] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0098] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0099] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by an electronic device, the electronic device causes the electronic device to: receive touch operations collected by a preset sensing area in the terminal screen; acquire touch parameters of the touch operations; determine whether the touch operations are preset valid swipe operations based on the touch parameters; and unlock the terminal screen if the touch operations are valid swipe operations.

[0100] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0101] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0102] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0103] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described service configuration scheduling method. This solves the technical problem that scheduling decisions lag behind real-time service status changes, making it difficult to respond promptly to sudden service performance degradation or service unavailability. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the service configuration scheduling method provided in the above embodiments, and will not be repeated here.

[0104] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A service configuration scheduling method, characterized in that, The service configuration scheduling includes: Receive data operation requests; Retrieve the service configuration that is first and last in the preset service configuration list, and use it as the target service configuration; The first target client corresponding to the target service configuration is invoked to execute the data operation request; If the execution result of the data operation request meets the preset completion conditions and the target service configuration is not at the top of the service configuration list, then the target service configuration will be moved to the top of the service configuration list. If the execution result of the data operation request does not meet the preset completion conditions, then switch to the next service configuration according to the order of the service configuration list to obtain a new target service configuration; Based on the new target service configuration, return to the first target client corresponding to the target service configuration to execute the data operation request until the preset completion condition is met or all service configurations fail to execute.

2. The method as described in claim 1, characterized in that, Before the step of invoking the first target client corresponding to the target service configuration to execute the data operation request, the method further includes: Determine whether there exists a cached first historical client that matches the target service configuration; If the first historical client exists, then the first historical client is reused as the first target client; If the first historical client does not exist, a new client is created according to the target service configuration and used as the first target client.

3. The method as described in claim 1, characterized in that, After the step of invoking the first target client corresponding to the target service configuration to execute the data operation request, the method further includes: If the execution result of the data operation request meets the preset completion condition, and the response time of the first client corresponding to the target service configuration in executing the data operation request exceeds the preset threshold, and the target service configuration is not the last item in the service configuration list, then the target service configuration is swapped with the next target service configuration in the service configuration list.

4. The method according to claim 1, characterized in that, After the step of invoking the first target client corresponding to the target service configuration to execute the data operation request, the method further includes: If the execution result of the data operation request does not meet the preset completion conditions, the client connection in the first target client used to execute the data operation request is destroyed, wherein the client connection is the connection between the first target client and the object storage service corresponding to the target service configuration; Determine whether the target service configuration is the last item in the service configuration list; If the target service configuration is not the last item in the service configuration list, then the order of the target service configuration in the service configuration list is adjusted to the end of the service configuration list.

5. The method according to claim 1, characterized in that, After the step of invoking the first target client corresponding to the target service configuration to execute the data operation request, the method further includes: If the execution result of the data operation request meets the preset completion conditions, then the service name of the target service configuration, the operation type of the data operation request, and the file identifier of the target file of the data operation request are obtained through the asynchronous synchronous message corresponding to the data operation request. Based on the service name, obtain the second target client; Based on the operation type and the file identifier of the target file, the second client is invoked to retrieve the data corresponding to the file identifier of the target file from the object storage service corresponding to the service name; Based on the service name, obtain the second client corresponding to the other service configurations in the service configuration list besides the service name; Based on the service name, the operation type, and the file identifier of the target file, the second client corresponding to the other service configuration is invoked to synchronize the data corresponding to the file identifier of the target file to the object storage service corresponding to the other service configuration.

6. The method according to claim 1, characterized in that, The method further includes: According to a preset time period, obtain a preset list of file path prefixes, and traverse each file path prefix in the list of file path prefixes; Based on the currently traversed file path prefix, traverse the object storage service corresponding to each service configuration in the service configuration list, and obtain the metadata information of the target object in each object storage service that matches the file path prefix; Based on the metadata information, determine the write status of the target object in each object storage service in the service configuration list; If the target object fails to be written in some object storage services, then select one of the object storage services that successfully wrote the target object as the source service; Generate an asynchronous synchronization message corresponding to the target object to synchronize the target object from the source service to the object storage service where the write failed.

7. The method according to claim 1, characterized in that, Applied to object storage systems, the method further includes: Load service configuration from external configuration files, parse the service configuration list, and obtain the service configuration list. If an update to the external configuration file is detected, the external configuration file is reloaded and the service configuration list is updated.

8. The method according to claim 1, characterized in that, The method further includes: When the service configuration list is idle, verify the availability of each object storage service in the service configuration list and obtain the verification result; Based on the verification results, the order of the service configuration list is rearranged.

9. An electronic device, characterized in that, The electronic device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the service configuration scheduling method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the service configuration scheduling method as described in any one of claims 1 to 8.

Images