Cloud data processing method and device based on multiple fault domains, equipment and medium

Abstract

The invention provides a cloud data processing method and device based on multiple fault domains, electronic equipment and a storage medium, and the method comprises the steps: distributing an access request in multiple independent data centers or network regions where target data is located, determining a target fault domain based on a current state, and returning an access result through employing the target data and a redundant copy. According to the invention, the reliability and fault tolerance of data access can be improved.

Description

Technical Field

[0001] The present application relates to the field of cloud storage technology, and in particular to a cloud data processing method, device, equipment and medium based on multiple fault domains. Background Art

[0002] With the rapid development of the Internet, Internet of Things, social media, artificial intelligence and big data technology, the amount of global data has increased dramatically, and traditional local storage methods can no longer meet data storage needs. Cloud storage has become an important choice for data storage in various industries due to its flexibility and scalability.

[0003] However, traditional cloud storage services have many defects, such as single point failure risk, geographical location restrictions, scalability bottlenecks, data security issues, slow recovery time, inflexible cost structure, and limited support for multi-cloud strategies, which restrict the widespread application and in-depth development of cloud storage services. Therefore, it is particularly important to explore more efficient, secure, and reliable cloud storage solutions. Summary of the invention

[0004] In view of this, the embodiments of the present application provide a cloud data processing method, device, electronic device and storage medium based on multiple fault domains, which can improve the reliability and fault tolerance of data access.

[0005] The technical solution of the embodiment of the present application is implemented as follows:

[0006] In a first aspect, an embodiment of the present application provides a cloud data processing method based on multiple fault domains, the method comprising:

[0007] In response to an access request for target data, distribute the access request among multiple fault domains where the target data is located; wherein each of the multiple fault domains represents an independent data center or network area, and each of the fault domains includes a redundant copy of the target data;

[0008] A target fault domain is determined based on current states of the multiple fault domains, and an access result is returned based on the target data and the redundant copy of the target data in the target fault domain.

[0009] In a second aspect, an embodiment of the present application further provides a cloud data processing device based on multiple fault domains, the device comprising:

[0010] an allocation module, configured to allocate, in response to an access request for target data, the access request among a plurality of fault domains where the target data is located; wherein each of the plurality of fault domains represents an independent data center or network area, and each of the fault domains includes a redundant copy of the target data;

[0011] A determination module is used to determine a target fault domain based on current states of the multiple fault domains, and return an access result based on the target data and the redundant copy of the target data in the target fault domain.

[0012] In a third aspect, an embodiment of the present application further provides an electronic device, comprising: a processor, a storage medium and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium through the bus, and the processor executes the machine-readable instructions to execute the cloud data processing method based on multiple fault domains as described in any one of the first aspects.

[0013] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the cloud data processing method based on multiple fault domains as described in any one of the first aspects is executed.

[0014] The embodiments of the present application have the following beneficial effects:

[0015] (1) Enhanced system stability and reliability: Through multi-fault domain deployment, the system can effectively isolate faults within a single fault domain and automatically switch traffic and load to the healthy domain when a fault occurs, significantly improving system stability and reliability and reducing downtime. Cross-region data replication and synchronization enable the system to quickly recover from disasters, reduce data loss, and ensure service continuity.

[0016] (2) Optimizing service availability and user experience: Multi-fault domain deployment enables data and applications to be closer to users, reducing access latency and improving user experience. Intelligently routing user requests to the optimal region improves application response speed and reliability to meet the needs of global users.

[0017] (3) Ensure data consistency and redundancy: Maintain multiple copies of data in multiple fault domains to ensure data persistence and reliability, and provide data services even when a copy fails. Ensure that the data accessed by users in different locations is up-to-date and consistent, meet business needs, and improve data credibility.

[0018] (4) Improve resource utilization efficiency and flexibility: Dynamically adjust resource allocation according to real-time load conditions, optimize resource utilization, and avoid resource waste and overload. Dynamically expand storage and computing resources in different regions or availability zones to meet the growth of business needs while maintaining high system availability.

[0019] (5) Meet compliance and data sovereignty requirements: Store data in a specific region according to regulatory requirements to ensure data compliance and meet data sovereignty requirements. Perform data and access control in multiple fault domains to reduce compliance risks and improve data privacy and security.

[0020] (6) Reduce overall risk and ensure business continuity: Disperse system operation risks to multiple locations to reduce the impact of single point failures on the overall business. The multi-fault domain architecture can cope with various risks and ensure that the business can still run stably under extreme circumstances. Allow system upgrades and maintenance without interrupting services, achieving continuous operation with zero downtime.

[0021] In summary, multi-fault domain deployment has shown significant beneficial effects in enhancing system stability, optimizing service availability, ensuring data consistency, improving resource utilization efficiency, meeting compliance requirements, and reducing overall risks, providing a solid guarantee for the company's continuous business operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0023] Figure 1 It is a flowchart of steps S101-S102 provided in an embodiment of the present application;

[0024] Figure 2 This is a multi-fault domain cloud deployment architecture diagram provided by an embodiment of the present application;

[0025] Figure 3 This is a diagram of a multi-fault domain high-availability cloud storage deployment architecture provided by an embodiment of the present application;

[0026] Figure 4 It is a flowchart of steps S401-S402 provided in an embodiment of the present application;

[0027] Figure 5 It is a flowchart of steps S501-S503 provided in an embodiment of the present application;

[0028] Figure 6 It is a flowchart of steps S601-S602 provided in an embodiment of the present application;

[0029] Figure 7 It is a structural diagram of a cloud data processing device based on multiple fault domains provided in an embodiment of the present application;

[0030] Figure 8 It is a schematic diagram of the composition structure of the electronic device provided in the embodiment of the present application. DETAILED DESCRIPTION

[0031] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the drawings in the present application only serve the purpose of explanation and description and are not used to limit the scope of protection of the present application. In addition, it should be understood that the schematic drawings are not drawn in real proportion. The flowchart used in this application shows the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flowchart can be implemented out of sequence, and the steps without logical context can be reversed in order or implemented simultaneously. In addition, those skilled in the art can add one or more other operations to the flowchart under the guidance of the content of the present application, or remove one or more operations from the flowchart.

[0032] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0033] In addition, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present application.

[0034] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0035] It should be noted that the term "comprising" will be used in the embodiments of the present application to indicate the existence of the features declared thereafter, but does not exclude the addition of other features.

[0036] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0037] See also Figure 1 , Figure 1 is a flowchart of steps S101-S102 of a cloud data processing method based on multiple fault domains provided in an embodiment of the present application, which will be combined with Figure 1 Steps S101-S102 are shown for explanation.

[0038] In step S101, in response to an access request for target data, the access request is distributed among multiple fault domains where the target data is located; wherein each of the multiple fault domains represents an independent data center or network area, and each fault domain includes a redundant copy of the target data.

[0039] Here, when there is an access request for the target data, this method will distribute the request to multiple fault domains where the target data is located. The "fault domain" here refers to an independent data center or network area, and each fault domain stores a redundant copy of the target data. This distribution method is intended to improve data availability and fault tolerance.

[0040] In step S102, a target fault domain is determined based on the current states of the multiple fault domains, and an access result is returned based on the target data and the redundant copy of the target data in the target fault domain.

[0041] Here, the embodiment of the present application will determine an optimal or available target fault domain based on the current status of multiple fault domains. The "current status" here includes information on the operating status of the fault domain, network latency, data integrity, and other aspects. Once the target fault domain is determined, data will be read from the target data in this fault domain and its redundant copy, and returned to the requester as an access result. This method ensures that even if problems occur in some fault domains, data can be obtained from other normal fault domains.

[0042] As an example, see Figure 2 and Figure 3 , Figure 2 is a multi-fault domain cloud deployment architecture diagram provided in an embodiment of the present application, Figure 3 : is a diagram of a multi-fault domain high-availability cloud storage deployment architecture provided by an embodiment of the present application. Figure 2 As shown, the embodiment of the present application provides two modes: one cloud with multiple regions and multi-cloud deployment. In one cloud with multiple regions, cloud management corresponds to multiple regions, each region corresponds to at least one availability zone (AZ), and one AZ corresponds to a micro data center (miniDC). Multi-cloud deployment includes multiple cloud managements, each of which corresponds to a region, an AZ, and a miniDC.

[0043] like Figure 3 As shown,

[0044] User request interface (UI) is an access interface provided to users, such as web applications, mobile applications or API interfaces. The global load balancer distributes user requests among multiple fault domains to ensure efficient distribution of traffic and isolation of fault domains. It is usually deployed at the edge layer of cloud providers. Fault domain (A, B, C): Each fault domain represents an independent data center or network area, with independent network, power and cooling systems to tolerate failures in a single fault domain. The application server processes storage requests and application logic to ensure high availability of the application. There are usually multiple application servers in each fault domain. The storage system provides data storage services, including block storage, file storage and object storage, and each fault domain has an independent storage system. Ensure that data has redundant copies and backups in each fault domain to reduce the risk of single point failure. Synchronize data between multiple fault domains to ensure data consistency and persistence. Provide a data recovery mechanism across fault domains to ensure rapid recovery when a fault domain fails.

[0045] The above approach improves the reliability and fault tolerance of cloud data processing by storing redundant copies of data in multiple independent fault domains and selecting the optimal access path based on the current state of the fault domain when accessing. This approach is particularly suitable for cloud data processing scenarios that require high availability and data consistency.

[0046] In some embodiments, determining the target fault domain based on the current states of the multiple fault domains includes:

[0047] Determine the nearest fault domain that is closest to the access request sending side, and detect and process the current state of the nearest fault domain. If the nearest fault domain meets the health condition, determine the nearest fault domain as the target fault domain;

[0048] If the nearest fault domain does not meet the health condition, the nearest second nearest fault domain except the nearest fault domain is updated to be the nearest fault domain;

[0049] Alternatively, determining at least one candidate fault domain satisfying the health condition from the multiple fault domains;

[0050] For the at least one candidate fault domain, determine the fault domain closest to the sending side among the at least one candidate fault domain as the target fault domain;

[0051] The health condition is determined based on load information and fault information.

[0052] Here, first, the system will determine the nearest fault domain based on the side sending the access request (which may be the location of the user or application), and this fault domain is called the "nearest fault domain". Next, the system will detect and process the current state of this nearest fault domain. This detection process may include checking the load of the fault domain, whether there are any faults or maintenance activities occurring, etc. Determine whether the nearest fault domain meets the health condition: The health condition is determined based on the load information and fault information. If the load of the nearest fault domain is moderate and no serious faults or maintenance activities have occurred, it is considered to meet the health condition. If the nearest fault domain meets the health condition, it is determined as the target fault domain for processing the access request. If the nearest fault domain does not meet the health condition (for example, the load is too high or it is experiencing a serious fault), the system will update the nearest second-closest fault domain other than the nearest fault domain to the new "nearest fault domain" and repeat the above detection and health condition judgment process.

[0053] Another method is that the system can directly filter out candidate fault domains that meet the health conditions from multiple fault domains. This screening process can be based on multiple factors such as the real-time load of the fault domain, historical fault records, maintenance plans, etc. After determining at least one candidate fault domain, the system will select the candidate fault domain closest to the access request sender as the target fault domain. This is done to ensure that the access request can be processed with the lowest possible latency.

[0054] The above approach ensures that the system can intelligently select the optimal fault domain to process access requests, thereby improving data availability and service reliability. By considering multiple factors such as the current state of the fault domain, load conditions, fault information, etc., the system can make more reasonable decisions and avoid sending access requests to fault domains that may have problems or poor performance.

[0055] In some embodiments, see Figure 4 , Figure 4 It is a flowchart diagram of steps S401-S402 provided in an embodiment of the present application. The method also includes steps S401-S402, which will be described in combination with each step.

[0056] In step S401, when a fault occurs in any fault domain among the multiple fault domains, the fault domain where the fault occurs is isolated.

[0057] In step S402, when data loss occurs to the target data in any fault domain among the multiple fault domains, the target data is recovered based on the redundant copy; wherein the recovery process is manual recovery or automatic recovery, and the automatic recovery is based on a preset inspection frequency and / or fixed time.

[0058] Here, when any of the multiple fault domains fails, the system will immediately isolate the fault domain. This isolation is to prevent the fault from spreading to other normal fault domains, thereby ensuring the stability and reliability of the entire system. Isolation may include cutting off the network connection between the fault domain and other fault domains, stopping services or applications in the fault domain, and other measures.

[0059] In multiple fault domains, if the target data in any fault domain is lost, the system will recover the target data based on the redundant copy. This redundant copy is designed to improve data reliability and fault tolerance. Even if the data in a fault domain is lost, it can be recovered from the redundant copies in other fault domains. For manual recovery, administrators or operation and maintenance personnel need to intervene manually to recover the lost data according to specific recovery steps and tools. This method is usually used to handle complex faults or scenarios that require special processing. For automatic recovery, the system will automatically recover according to the preset inspection frequency and / or fixed time. For example, the system can regularly scan the redundant copies in all fault domains. If it is found that the target data in a fault domain is lost, it will be immediately recovered from the redundant copies in other fault domains. This method can greatly shorten the time for data recovery and improve the availability and reliability of the system.

[0060] The above-mentioned approach, by introducing fault isolation processing and data recovery processing mechanisms, can further improve the stability and reliability of the system based on the multi-fault domain cloud data processing method. Even if a fault domain fails or data is lost, the system can respond quickly to ensure data integrity and service continuity. This design is particularly important for cloud data processing scenarios that require high availability and data consistency.

[0061] In some embodiments, see Figure 5 , Figure 5 It is a flow chart of steps S501-S503 provided in an embodiment of the present application, wherein the multiple fault domains are distributed in different geographical areas, and the first data storage specification of each geographical area is different; the method also includes steps S501-S503, which will be explained in combination with each step.

[0062] In step S501, the data storage specification of each geographical area is determined.

[0063] In step S502, in response to a storage request for the target data, a second data storage specification of the target data is determined, and a geographical area in which the first data storage specification matches the second data storage specification is determined.

[0064] In step S503, the target data is stored in the fault domain of the matching geographical area.

[0065] Here, the system first needs to determine the data storage specifications for each geographic region. These specifications include data storage format, encryption method, backup strategy, access rights, etc. Since different geographic regions may have different laws, regulations, industry standards or business needs, the data storage specifications will also vary accordingly.

[0066] When the system receives a storage request for target data, it first determines the second data storage specification for the target data. This is usually determined based on the requester's requirements, business logic, or system policy. Next, the system compares the second data storage specification with the first data storage specification of each geographic region to find a matching geographic region. This matching process involves comparisons in multiple dimensions, including data encryption methods, storage formats, backup strategies, etc.

[0067] Once a matching geographic region is found, the system will store the target data in the fault domain of the matching geographic region. This storage strategy is designed to ensure that data can be stored and managed in a manner that complies with local laws and regulations, industry standards, or business requirements.

[0068] In practical applications, this data storage strategy needs to consider multiple factors. For example, data transmission delays and bandwidth limitations between different geographical regions may affect the real-time and availability of data. In addition, data storage across geographical regions may also involve issues such as data sovereignty and privacy protection. Therefore, when implementing this data storage strategy, the system needs to adopt a series of technical and management measures to ensure the security, reliability and compliance of data. For example, encryption technology can be used to protect the confidentiality of data; data backup and recovery strategies can be used to ensure the availability of data; and strict data access control and audit mechanisms can be established to ensure data compliance.

[0069] The above approach, by introducing geographic data storage specifications and matching mechanisms, allows the multi-fault domain-based cloud data processing method to more flexibly adapt to the data storage needs of different geographic regions. This design not only improves the availability and reliability of data, but also ensures that data can be stored and managed in a manner that complies with local laws and regulations, industry standards, or business needs. This is particularly important for enterprises and institutions that need to deploy and manage data globally.

[0070] In some embodiments, the method further comprises:

[0071] In response to a data synchronization request, the target data is synchronized in the multiple fault domains; wherein the data synchronization request is automatically synchronized or manually synchronized based on a preset time.

[0072] Here, the system is able to respond to data synchronization requests and synchronize target data in multiple fault domains. This synchronization request can be automatically synchronized based on a preset time, or it can be manually triggered by an administrator or user for manual synchronization. For automatic synchronization, the system automatically performs data synchronization tasks based on a preset schedule or trigger conditions. This usually involves regularly copying data from one fault domain to other fault domains to ensure the real-time and consistency of data. Automatic synchronization helps reduce human errors and improves the efficiency of data synchronization. For manual synchronization, administrators or users can manually trigger data synchronization tasks as needed. Data synchronization can be achieved through a variety of technologies, including but not limited to:

[0073] Storage system synchronization: Use the synchronization function provided by the storage system, such as MySQL master-slave data synchronization, master-master data synchronization, etc. This method is simple and easy to use, but it may not be possible to customize the control based on the characteristics of business data.

[0074] Message queue synchronization: Use independent message queues for data synchronization, such as Kafka, ActiveMQ, etc. This method is suitable for data synchronization without transactional or time-series requirements.

[0075] Server synchronization mirroring: Automatic data synchronization between multiple servers to ensure consistency of content on each server. Server synchronization mirroring technology can achieve real-time or near real-time data replication and provide functions such as failover, load balancing and bandwidth optimization.

[0076] In the above-mentioned way, the data synchronization processing strategy in the cloud data processing method based on multiple fault domains is an important link. Through reasonable synchronization strategy, technical implementation and consideration of precautions, it can ensure that the target data maintains consistency and availability among multiple fault domains, thereby improving the stability and reliability of the entire system.

[0077] In some embodiments, each of the multiple fault domains includes an independent storage system, which is used to store the target data; the storage method of the independent storage system includes block storage, file storage and object storage; the storage method of the target data is determined based on the data characteristics and / or business requirements of the target data.

[0078] Here, independent storage systems in each fault domain are key components to ensure high data availability and fault tolerance. These systems are not only responsible for data storage, but also participate in data synchronization, backup, and recovery processes. Independent storage systems distributed in different fault domains can achieve geographical distribution and redundant storage of data, thereby improving data reliability and security.

[0079] The storage methods include the following:

[0080] Block storage: Block storage stores data in blocks, each of which is a fixed-size data unit. Block storage is often used in application scenarios that require high performance and low latency, such as databases and virtual machine disks. It allows direct access and modification of storage blocks, providing high I / O performance and flexibility.

[0081] File storage: File storage organizes data in the form of files, each of which contains metadata and data content. File storage is often used in application scenarios that require sharing and collaboration, such as file servers and shared storage. It provides an easy-to-understand and easy-to-use file structure, as well as file access control and permission management.

[0082] Object storage: Object storage stores data in the form of objects, each of which contains data, metadata, and a unique identifier. Object storage is often used to process large amounts of unstructured data, such as pictures, videos, and backup files. It provides scalability, high availability, and cost-effectiveness, and is suitable for large-scale data storage and distribution.

[0083] The storage method of the target data should be determined according to its data characteristics and business needs. For example, for database applications that require high performance and low latency, block storage can be selected; for file servers that require sharing and collaboration, file storage can be selected; for storage needs that process large amounts of unstructured data, object storage can be selected. When choosing a storage method, other factors need to be considered, such as storage cost, scalability, data consistency, fault recovery capability, and security. By comprehensively considering these factors, you can choose the storage method that best suits the target data characteristics and business needs, thereby optimizing the performance, reliability, and cost of data storage.

[0084] The above-mentioned cloud data processing method based on multiple fault domains equips each fault domain with an independent storage system and provides multiple storage methods to adapt to different data characteristics and business needs. This design not only improves the reliability and security of data, but also provides flexibility and scalability to meet changing business needs.

[0085] In some embodiments, see Figure 6 , Figure 6 It is a flowchart of steps S601-S602 provided in an embodiment of the present application. The method also includes steps S601-S602, which will be described in combination with each step.

[0086] In step S601, resource usage information of each fault domain is determined.

[0087] In step S602, when the resource usage information meets the expansion condition, in response to the expansion request for the fault domain, new resources are added to the fault domain.

[0088] Here, first of all, the system needs to be able to collect and determine the resource usage information of each fault domain. This information includes key performance indicators such as CPU usage, memory usage, disk space, and network bandwidth. By continuously monitoring these indicators, the system can understand the resource status of each fault domain in real time and provide a basis for subsequent decision-making. After determining the resource usage information, the system needs to set a series of expansion conditions to determine when the fault domain needs to be expanded. These conditions are based on a variety of factors such as resource usage thresholds, load change trends, and changes in business needs. For example, when the CPU usage of a fault domain is continuously higher than a set threshold, or when the disk space is about to run out, the system may trigger an expansion condition. Once the expansion condition is met, the system needs to be able to respond to expansion requests for the fault domain. This usually involves adding new computing resources (such as virtual machines, containers, etc.), storage resources (such as disk arrays, cloud storage, etc.), or network resources (such as bandwidth upgrades, network devices, etc.). The expansion request can be triggered automatically by the system or manually initiated by the administrator. After responding to the expansion request, the system needs to add the newly added resources to the corresponding fault domain. This may require a series of complex operations such as resource allocation, configuration adjustment, data migration, etc.

[0089] The above approach ensures that the cloud data processing architecture based on multiple fault domains can efficiently cope with changing business needs and load pressures by monitoring the resource usage information of each fault domain in real time and dynamically adding new resources according to expansion conditions. This dynamic expansion mechanism not only improves the performance and reliability of the system, but also reduces operation and maintenance costs and management complexity.

[0090] In summary, the embodiments of the present application have the following beneficial effects:

[0091] (1) Enhanced system stability and reliability: Through multi-fault domain deployment, the system can effectively isolate faults within a single fault domain and automatically switch traffic and load to the healthy domain when a fault occurs, significantly improving system stability and reliability and reducing downtime. Cross-region data replication and synchronization enable the system to quickly recover from disasters, reduce data loss, and ensure service continuity.

[0092] (2) Optimizing service availability and user experience: Multi-fault domain deployment enables data and applications to be closer to users, reducing access latency and improving user experience. Intelligently routing user requests to the optimal region improves application response speed and reliability to meet the needs of global users.

[0093] (3) Ensure data consistency and redundancy: Maintain multiple copies of data in multiple fault domains to ensure data persistence and reliability, and provide data services even when a copy fails. Ensure that the data accessed by users in different locations is up-to-date and consistent, meet business needs, and improve data credibility.

[0094] (4) Improve resource utilization efficiency and flexibility: Dynamically adjust resource allocation according to real-time load conditions, optimize resource utilization, and avoid resource waste and overload. Dynamically expand storage and computing resources in different regions or availability zones to meet the growth of business needs while maintaining high system availability.

[0095] (5) Meet compliance and data sovereignty requirements: Store data in a specific region according to regulatory requirements to ensure data compliance and meet data sovereignty requirements. Perform data and access control in multiple fault domains to reduce compliance risks and improve data privacy and security.

[0096] (6) Reduce overall risk and ensure business continuity: Disperse system operation risks to multiple locations to reduce the impact of single point failures on the overall business. The multi-fault domain architecture can cope with various risks and ensure that the business can still run stably under extreme circumstances. Allow system upgrades and maintenance without interrupting services, achieving continuous operation with zero downtime.

[0097] In summary, multi-fault domain deployment has shown significant beneficial effects in enhancing system stability, optimizing service availability, ensuring data consistency, improving resource utilization efficiency, meeting compliance requirements, and reducing overall risks, providing a solid guarantee for the company's continuous business operations.

[0098] Based on the same inventive concept, the embodiment of the present application also provides a cloud data processing device based on multiple fault domains corresponding to the cloud data processing method based on multiple fault domains in the first embodiment. Since the principle of solving the problem by the device in the embodiment of the present application is similar to the above-mentioned cloud data processing method based on multiple fault domains, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be repeated.

[0099] like Figure 7 As shown, Figure 7 : is a schematic diagram of the structure of a cloud data processing device 700 based on multiple fault domains provided in an embodiment of the present application. The cloud data processing device 700 based on multiple fault domains includes:

[0100] An allocation module 701 is used to allocate, in response to an access request for target data, the access request among multiple fault domains where the target data is located; wherein each of the multiple fault domains represents an independent data center or network area, and each of the fault domains includes a redundant copy of the target data;

[0101] The determination module 702 is configured to determine a target fault domain based on the current states of the multiple fault domains, and return an access result based on the target data and the redundant copy of the target data in the target fault domain.

[0102] Those skilled in the art should understand that Figure 7 The implementation functions of each unit in the cloud data processing device 700 based on multiple fault domains can be understood by referring to the relevant description of the aforementioned cloud data processing method based on multiple fault domains. Figure 7 The functions of each unit in the cloud data processing device 700 based on multiple fault domains shown can be implemented by a program running on a processor, or can be implemented by a specific logic circuit.

[0103] In a possible implementation manner, the determination module 702 determines the target fault domain based on the current states of the multiple fault domains, including:

[0104] Determine the nearest fault domain that is closest to the access request sending side, and detect and process the current state of the nearest fault domain. If the nearest fault domain meets the health condition, determine the nearest fault domain as the target fault domain;

[0105] If the nearest fault domain does not meet the health condition, the nearest second nearest fault domain except the nearest fault domain is updated to be the nearest fault domain;

[0106] Alternatively, determining at least one candidate fault domain satisfying the health condition from the multiple fault domains;

[0107] For the at least one candidate fault domain, determine the fault domain closest to the sending side among the at least one candidate fault domain as the target fault domain;

[0108] The health condition is determined based on load information and fault information.

[0109] In a possible implementation, the determining module 702 further includes:

[0110] When any fault domain among the multiple fault domains fails, the fault domain where the fault occurs is isolated;

[0111] When data loss occurs to the target data in any fault domain among the multiple fault domains, the target data is recovered based on the redundant copy; wherein the recovery process is manual recovery or automatic recovery, and the automatic recovery is based on a preset inspection frequency and / or fixed time.

[0112] In a possible implementation manner, the multiple fault domains are distributed in different geographical areas, and the first data storage specification of each geographical area is different; the determination module 702 further includes:

[0113] determining data storage specifications for each of the geographic regions;

[0114] In response to a storage request for the target data, determining a second data storage specification for the target data, and determining a geographical area in which the first data storage specification matches the second data storage specification;

[0115] The target data is stored in the failure domain of the matching geographic area.

[0116] In a possible implementation, the determining module 702 further includes:

[0117] In response to a data synchronization request, the target data is synchronized in the multiple fault domains; wherein the data synchronization request is automatically synchronized or manually synchronized based on a preset time.

[0118] In a possible implementation, each of the multiple fault domains includes an independent storage system, which is used to store the target data; the storage method of the independent storage system includes block storage, file storage, and object storage; the storage method of the target data is determined based on the data characteristics and / or business requirements of the target data.

[0119] In a possible implementation, the determining module 702 further includes:

[0120] Determining resource usage information of each fault domain;

[0121] When the resource usage information meets the expansion condition, in response to the expansion request for the fault domain, new resources are added to the fault domain.

[0122] The above-mentioned cloud data processing device based on multiple fault domains has the following beneficial effects:

[0123] (1) Enhanced system stability and reliability: Through multi-fault domain deployment, the system can effectively isolate faults within a single fault domain and automatically switch traffic and load to the healthy domain when a fault occurs, significantly improving system stability and reliability and reducing downtime. Cross-region data replication and synchronization enable the system to quickly recover from disasters, reduce data loss, and ensure service continuity.

[0124] (2) Optimizing service availability and user experience: Multi-fault domain deployment enables data and applications to be closer to users, reducing access latency and improving user experience. Intelligently routing user requests to the optimal region improves application response speed and reliability to meet the needs of global users.

[0125] (3) Ensure data consistency and redundancy: Maintain multiple copies of data in multiple fault domains to ensure data persistence and reliability, and provide data services even when a copy fails. Ensure that the data accessed by users in different locations is up-to-date and consistent, meet business needs, and improve data credibility.

[0126] (4) Improve resource utilization efficiency and flexibility: Dynamically adjust resource allocation according to real-time load conditions, optimize resource utilization, and avoid resource waste and overload. Dynamically expand storage and computing resources in different regions or availability zones to meet the growth of business needs while maintaining high system availability.

[0127] (5) Meet compliance and data sovereignty requirements: Store data in a specific region according to regulatory requirements to ensure data compliance and meet data sovereignty requirements. Perform data and access control in multiple fault domains to reduce compliance risks and improve data privacy and security.

[0128] (6) Reduce overall risk and ensure business continuity: Disperse system operation risks to multiple locations to reduce the impact of single point failures on the overall business. The multi-fault domain architecture can cope with various risks and ensure that the business can still run stably under extreme circumstances. Allow system upgrades and maintenance without interrupting services, achieving continuous operation with zero downtime.

[0129] In summary, multi-fault domain deployment has shown significant beneficial effects in enhancing system stability, optimizing service availability, ensuring data consistency, improving resource utilization efficiency, meeting compliance requirements, and reducing overall risks, providing a solid guarantee for the company's continuous business operations.

[0130] like Figure 8 As shown, Figure 8 The present invention provides a schematic diagram of the structure of an electronic device 800 according to an embodiment of the present invention. The electronic device 800 includes:

[0131] A processor 801, a storage medium 802 and a bus 803, wherein the storage medium 802 stores machine-readable instructions executable by the processor 801. When the electronic device 800 is running, the processor 801 communicates with the storage medium 802 via the bus 803, and the processor 801 executes the machine-readable instructions to perform the steps of the cloud data processing method based on multiple fault domains described in the embodiment of the present application.

[0132] In actual application, the components in the electronic device 800 are coupled together via bus 803. It is understood that bus 803 is used to realize the connection and communication between these components. Bus 803 includes not only a data bus, but also a power bus, a control bus and a status signal bus. However, for the sake of clarity, Figure 8 Various buses are labeled as bus 803.

[0133] The electronic device has the following beneficial effects:

[0134] (1) Enhanced system stability and reliability: Through multi-fault domain deployment, the system can effectively isolate faults within a single fault domain and automatically switch traffic and load to the healthy domain when a fault occurs, significantly improving system stability and reliability and reducing downtime. Cross-region data replication and synchronization enable the system to quickly recover from disasters, reduce data loss, and ensure service continuity.

[0135] (2) Optimizing service availability and user experience: Multi-fault domain deployment enables data and applications to be closer to users, reducing access latency and improving user experience. Intelligently routing user requests to the optimal region improves application response speed and reliability to meet the needs of global users.

[0136] (3) Ensure data consistency and redundancy: Maintain multiple copies of data in multiple fault domains to ensure data persistence and reliability, and provide data services even when a copy fails. Ensure that the data accessed by users in different locations is up-to-date and consistent, meet business needs, and improve data credibility.

[0137] (4) Improve resource utilization efficiency and flexibility: Dynamically adjust resource allocation according to real-time load conditions, optimize resource utilization, and avoid resource waste and overload. Dynamically expand storage and computing resources in different regions or availability zones to meet the growth of business needs while maintaining high system availability.

[0138] (5) Meet compliance and data sovereignty requirements: Store data in a specific region according to regulatory requirements to ensure data compliance and meet data sovereignty requirements. Perform data and access control in multiple fault domains to reduce compliance risks and improve data privacy and security.

[0139] (6) Reduce overall risk and ensure business continuity: Disperse system operation risks to multiple locations to reduce the impact of single point failures on the overall business. The multi-fault domain architecture can cope with various risks and ensure that the business can still run stably under extreme circumstances. Allow system upgrades and maintenance without interrupting services, achieving continuous operation with zero downtime.

[0140] In summary, multi-fault domain deployment has shown significant beneficial effects in enhancing system stability, optimizing service availability, ensuring data consistency, improving resource utilization efficiency, meeting compliance requirements, and reducing overall risks, providing a solid guarantee for the company's continuous business operations.

[0141] The embodiment of the present application further provides a computer-readable storage medium, which stores executable instructions. When the executable instructions are executed by at least one processor 801, the cloud data processing method based on multiple fault domains described in the embodiment of the present application is implemented.

[0142] In some embodiments, the storage medium can be a magnetic random access memory (FRAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a magnetic surface storage, an optical disk, or a compact disc read-only memory (CDROM); it can also be various devices including one or any combination of the above memories.

[0143] In some embodiments, executable instructions may be in the form of a program, software, software module, script or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine or other unit suitable for use in a computing environment.

[0144] As an example, executable instructions may, but do not necessarily, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (for example, files storing one or more modules, subroutines, or code portions).

[0145] By way of example, executable instructions may be deployed to be executed on one computing device, or on multiple computing devices located at one site, or on multiple computing devices distributed across multiple sites and interconnected by a communication network.

[0146] The computer-readable storage medium has the following advantages:

[0147] (1) Enhanced system stability and reliability: Through multi-fault domain deployment, the system can effectively isolate faults within a single fault domain and automatically switch traffic and load to the healthy domain when a fault occurs, significantly improving system stability and reliability and reducing downtime. Cross-region data replication and synchronization enable the system to quickly recover from disasters, reduce data loss, and ensure service continuity.

[0148] (2) Optimizing service availability and user experience: Multi-fault domain deployment enables data and applications to be closer to users, reducing access latency and improving user experience. Intelligently routing user requests to the optimal region improves application response speed and reliability to meet the needs of global users.

[0149] (3) Ensure data consistency and redundancy: Maintain multiple copies of data in multiple fault domains to ensure data persistence and reliability, and provide data services even when a copy fails. Ensure that the data accessed by users in different locations is up-to-date and consistent, meet business needs, and improve data credibility.

[0150] (4) Improve resource utilization efficiency and flexibility: Dynamically adjust resource allocation according to real-time load conditions, optimize resource utilization, and avoid resource waste and overload. Dynamically expand storage and computing resources in different regions or availability zones to meet the growth of business needs while maintaining high system availability.

[0151] (5) Meet compliance and data sovereignty requirements: Store data in a specific region according to regulatory requirements to ensure data compliance and meet data sovereignty requirements. Perform data and access control in multiple fault domains to reduce compliance risks and improve data privacy and security.

[0152] (6) Reduce overall risk and ensure business continuity: Disperse system operation risks to multiple locations to reduce the impact of single point failures on the overall business. The multi-fault domain architecture can cope with various risks and ensure that the business can still run stably under extreme circumstances. Allow system upgrades and maintenance without interrupting services, achieving continuous operation with zero downtime.

[0153] In summary, multi-fault domain deployment has shown significant beneficial effects in enhancing system stability, optimizing service availability, ensuring data consistency, improving resource utilization efficiency, meeting compliance requirements, and reducing overall risks, providing a solid guarantee for the company's continuous business operations.

[0154] In the several embodiments provided in the present application, it should be understood that the disclosed methods and electronic devices can be implemented in other ways. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0155] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0156] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0157] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium that is executable by a processor. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a platform server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard drives, ROM, RAM, magnetic disks, or optical disks.

[0158] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A cloud data processing method based on multiple fault domains, characterized in that: The following steps are involved: In response to an access request for target data, distribute the access request among multiple fault domains where the target data is located; wherein each of the multiple fault domains represents an independent data center or network area, and each of the fault domains includes a redundant copy of the target data; A target fault domain is determined based on current states of the multiple fault domains, and an access result is returned based on the target data and the redundant copy of the target data in the target fault domain.

2. The method according to claim 1, characterized in that The determining a target fault domain based on current states of the multiple fault domains includes: Determine the nearest fault domain that is closest to the access request sending side, and detect and process the current state of the nearest fault domain. If the nearest fault domain meets the health condition, determine the nearest fault domain as the target fault domain; If the nearest fault domain does not meet the health condition, the nearest second nearest fault domain except the nearest fault domain is updated to be the nearest fault domain; Alternatively, determining at least one candidate fault domain satisfying the health condition from the multiple fault domains; For the at least one candidate fault domain, determine the fault domain closest to the sending side among the at least one candidate fault domain as the target fault domain; The health condition is determined based on load information and fault information.

3. The method according to claim 1, characterized in that The method further comprises: When any fault domain among the multiple fault domains fails, the fault domain where the fault occurs is isolated; When data loss occurs to the target data in any fault domain among the multiple fault domains, the target data is recovered based on the redundant copy; wherein the recovery process is manual recovery or automatic recovery, and the automatic recovery is based on a preset inspection frequency and / or fixed time.

4. The method according to claim 1, characterized in that: The multiple fault domains are distributed in different geographical areas, and the first data storage specification of each geographical area is different; the method further includes: determining data storage specifications for each of the geographic regions; In response to a storage request for the target data, determining a second data storage specification for the target data, and determining a geographical area in which the first data storage specification matches the second data storage specification; The target data is stored in the failure domain of the matching geographic area.

5. The method according to claim 1, characterized in that The method further comprises: In response to a data synchronization request, the target data is synchronized in the multiple fault domains; wherein the data synchronization request is automatically synchronized or manually synchronized based on a preset time.

6. The method according to claim 1, characterized in that Each of the multiple fault domains includes an independent storage system, which is used to store the target data; the storage method of the independent storage system includes block storage, file storage and object storage; the storage method of the target data is determined based on the data characteristics and / or business requirements of the target data.

7. The method according to claim 1, characterized in that The method further comprises: Determining resource usage information of each fault domain; When the resource usage information meets the expansion condition, in response to the expansion request for the fault domain, new resources are added to the fault domain.

8. A cloud data processing device based on multiple fault domains, characterized in that: The device comprises: an allocation module, configured to allocate, in response to an access request for target data, the access request among a plurality of fault domains where the target data is located; wherein each of the plurality of fault domains represents an independent data center or network area, and each of the fault domains includes a redundant copy of the target data; A determination module is used to determine a target fault domain based on current states of the multiple fault domains, and return an access result based on the target data and the redundant copy of the target data in the target fault domain.

9. An electronic device, characterized in that: include: A processor, a storage medium and a bus, wherein the storage medium stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the cloud data processing method based on multiple fault domains as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the cloud data processing method based on multiple fault domains according to any one of claims 1 to 7 is executed.

Images