Service switching method, electronic device, storage medium, and program product

Abstract

Embodiments of the present application provide a service switching method, an electronic device, a storage medium and a program product. The method comprises: marking a first logical service as an exit state, and intercepting a new task request; initializing a second logical service; performing type division processing on resources corresponding to the first logical service through the second logical service to obtain no-overwrite resources and overwrite resources; and performing differentiated resource consistency processing on the no-overwrite resources and the overwrite resources through the second logical service, and receiving the new task request, which can shorten the logical service instance switching waiting time, reduce the resource occupation of the old node in the exit phase, improve the overall resource utilization of the system, and maintain resource state consistency and business continuity in the high-concurrency write, complex metadata adjustment and shared resource concurrent access scenarios.

Description

Technical Field

[0001] This application relates to the field of distributed storage and fault recovery technology, and in particular to a service switching method, electronic device, storage medium and program product. Background Technology

[0002] In distributed storage systems, logical service instances can typically be implemented through fault migration and service switchback mechanisms after node recovery.

[0003] However, the relevant switchback schemes usually require the node currently carrying the service to wait for all modification tasks to be completed before the recovery node can take over the service again, resulting in a long switchback waiting time. In high-concurrency or large-scale data scenarios, this waiting time is further amplified, and the concurrent processing of shared resources by new and old nodes can increase the difficulty of consistency control.

[0004] Therefore, how to shorten service waiting time and ensure data consistency during the logical service instance switchback process has become an urgent technical problem to be solved. Summary of the Invention

[0005] This application provides a service switching method, electronic device, storage medium, and program product to solve the technical problem of how to shorten service waiting time and ensure data consistency during the logical service instance switchback process.

[0006] Firstly, this application provides a service switching method, the method comprising:

[0007] Mark the first logical service as exited and intercept new task requests;

[0008] Initialize the second logical service;

[0009] The second logical service performs type classification processing on the resources corresponding to the first logical service to obtain non-overwrite resources and overwrite resources.

[0010] The second logical service performs differentiated resource consistency processing on non-overwrite resources and overwrite resources respectively, and receives new task requests.

[0011] This can shorten the wait time for logical service instances to switch back, reduce the resource consumption of old nodes during the exit phase, improve the overall resource utilization of the system, and maintain resource state consistency and business continuity in scenarios with high-concurrency writes, complex metadata adjustments, and concurrent access to shared resources.

[0012] Optionally, the method described above performs differentiated resource consistency processing on non-overwrite resources and overwrite resources respectively through the second logical service, including:

[0013] The second logical service performs block partitioning and data migration processing on non-rewriteable resources to achieve resource consistency processing.

[0014] The second logical service performs version verification and access control on resources with duplicate types to achieve resource consistency.

[0015] In this way, differentiated synchronization can be implemented for the two types of resources. For non-rewriteable resources, the smooth takeover of incomplete writes can be achieved through block division and data migration. For rewriteable resources, the consistency of modifications can be maintained through version verification and access control. The two work together to enable the second logical service to maintain the continuity of resource status while taking over new task requests and reduce the switchback waiting time.

[0016] Optionally, the above method performs block partitioning and data migration processing on non-overwrite resources through a second logical service, including:

[0017] The second logical service divides the non-rewriteable resources into multiple logical blocks according to a preset size.

[0018] Perform append write operations on multiple logical blocks, and distinguish at least one first logical block and at least one second logical block, where the first logical block is the logical block that has been written and the second logical block is the logical block that has not been written.

[0019] For any given second logical block, read the data within the second logical block and write it to the new logical block;

[0020] The operation corresponding to the new task request is executed through at least one first logic block and at least one new logic block.

[0021] In this way, the migration of non-rewriteable resources no longer relies on unified takeover after the entire process is completed. Instead, it can be segmented at the logical block level, reducing the wait time for switchbacks and minimizing the blocking impact of incomplete writes on subsequent services. Since the first logical block and the new logical block correspond to stable data and migrated data, respectively, the continuity of resource access is enhanced, and the data processing process is easier to control, thereby improving the efficiency and consistency guarantee of logical service switchbacks in distributed storage scenarios.

[0022] Optionally, as described above, the second logical service performs version verification and access control on resources with overridden classes, including:

[0023] Receive resource requests through the second logical service;

[0024] Determine whether the resource request is a read request or a write request.

[0025] If the resource request type is a read request type, add a range read lock to the resource range corresponding to the resource request, and perform version verification and access control processing.

[0026] If the resource request is a write request, add a range write lock to the resource range corresponding to the resource request, increment the write count for the corresponding version, and perform version verification and access control processing.

[0027] In this way, the second logical service can apply differentiated interval lock control to read and write requests respectively, and complete access interception and request scheduling by combining version number comparison and write count status, thereby reducing conflicts between different version requests, avoiding state disorder of rewrite-type resources during switchback and concurrent access, and thus improving resource modification consistency and service continuity.

[0028] Optionally, the above method performs version verification and access control processing, including:

[0029] Get the local version number;

[0030] Determine the request version number corresponding to the resource request;

[0031] Compare the requested version number with the local version number to obtain the version number comparison result;

[0032] Based on the version number comparison results, perform access interception and request scheduling operations.

[0033] This reduces errors caused by version conflicts in logical service instance switching and concurrent access scenarios, prevents old version requests from overwriting new version data, and also reduces the consumption of system resources by invalid requests. It ensures that resource requests are executed in an orderly manner within clear version boundaries, thereby improving the accuracy of access control and the consistency of resource synchronization.

[0034] Optionally, the above method, based on the version number comparison result, performs access interception and request scheduling operations, including:

[0035] If the requested version number is higher than the local version number, wait for any unfinished local requests to complete, update the local version number, and then execute the resource request.

[0036] If the requested version number is lower than the local version number, the resource request will be rejected.

[0037] If the requested version number matches the local version number, execute the resource request.

[0038] This reduces errors caused by version conflicts in logical service instance switching and concurrent access scenarios, prevents old version requests from overwriting new version data, and also reduces the consumption of system resources by invalid requests. It ensures that resource requests are executed in an orderly manner within clear version boundaries, thereby improving the accuracy of access control and the consistency of resource synchronization.

[0039] Optionally, after performing access interception and request scheduling operations, the method described above further includes:

[0040] If the resource request type is a read request type, release the range read lock;

[0041] If the resource request is a write request, release the range write lock and clear the write count.

[0042] In this way, completed read requests will not continue to hold the interval read lock, and completed write requests will not block subsequent access due to unreleased write locks and write counters. This reduces lock holding time, reduces concurrent waiting on resource intervals, improves request processing efficiency during switchbacks, and helps maintain consistency in version verification, access control, and resource status.

[0043] Alternatively, the method described above may further include:

[0044] After the first logical service completes the modification operation, check whether the first logical service is marked as exited and obtain the query result;

[0045] If the query result indicates that the operation has been marked as exited, the operation will fail.

[0046] If the query result shows that the exit status is not marked, the operation is returned as successful.

[0047] This makes the response behavior of the first logical service at the exit boundary clearer, provides consistent result feedback to the upper-layer scheduling module, and reduces the risk of business ambiguity and resource inconsistency caused by state switching.

[0048] Secondly, this application provides a service switching apparatus, the apparatus comprising:

[0049] The interception module is used to mark the first logical service as exited and to intercept new task requests;

[0050] The initialization module is used to initialize the second logical service;

[0051] The classification module is used to classify the resources corresponding to the first logical service through the second logical service to obtain non-override resources and override resources.

[0052] The switching module is used to perform differentiated resource consistency processing on non-overwrite resources and overwrite resources respectively through the second logical service, and to receive new task requests.

[0053] Optionally, in the above-described device, the switching module is specifically used for:

[0054] The second logical service performs block partitioning and data migration processing on non-rewriteable resources to achieve resource consistency processing.

[0055] The second logical service performs version verification and access control on resources with duplicate types to achieve resource consistency.

[0056] Optionally, in the above-described device, the switching module is specifically used for:

[0057] The second logical service divides the non-rewriteable resources into multiple logical blocks according to a preset size.

[0058] Perform append write operations on multiple logical blocks, and distinguish at least one first logical block and at least one second logical block, where the first logical block is the logical block that has been written and the second logical block is the logical block that has not been written.

[0059] For any given second logical block, read the data within the second logical block and write it to the new logical block;

[0060] The operation corresponding to the new task request is executed through at least one first logic block and at least one new logic block.

[0061] Optionally, in the above-described device, the switching module is specifically used for:

[0062] Receive resource requests through the second logical service;

[0063] Determine whether the resource request is a read request or a write request.

[0064] If the resource request type is a read request type, add a range read lock to the resource range corresponding to the resource request, and perform version verification and access control processing.

[0065] If the resource request is a write request, add a range write lock to the resource range corresponding to the resource request, increment the write count for the corresponding version, and perform version verification and access control processing.

[0066] Optionally, in the above-described device, the switching module is specifically used for:

[0067] Get the local version number;

[0068] Determine the request version number corresponding to the resource request;

[0069] Compare the requested version number with the local version number to obtain the version number comparison result;

[0070] Based on the version number comparison results, perform access interception and request scheduling operations.

[0071] Optionally, in the above-described device, the switching module is specifically used for:

[0072] If the requested version number is higher than the local version number, wait for any unfinished local requests to complete, update the local version number, and then execute the resource request.

[0073] If the requested version number is lower than the local version number, the resource request will be rejected.

[0074] If the requested version number matches the local version number, execute the resource request.

[0075] Optionally, in the above-described device, the switching module is also used for:

[0076] If the resource request type is a read request type, release the range read lock;

[0077] If the resource request is a write request, release the range write lock and clear the write count.

[0078] Optionally, the apparatus as described above further includes a confirmation module, which is used for:

[0079] After the first logical service completes the modification operation, check whether the first logical service is marked as exited and obtain the query result;

[0080] If the query result indicates that the operation has been marked as exited, the operation will fail.

[0081] If the query result shows that the exit status is not marked, the operation is returned as successful.

[0082] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0083] The memory stores the instructions that the computer executes;

[0084] The processor executes computer-executable instructions stored in memory to implement any of the methods of the first aspect.

[0085] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any of the first aspects.

[0086] Fifthly, this application provides a computer program product, including a computer program that, when executed by a computer, implements the method as described in any of the first aspects.

[0087] The service switching method, electronic device, storage medium, and program product provided in this application mark a first logical service as exiting and intercept new task requests; initialize a second logical service; classify the resources corresponding to the first logical service into non-overwrite resources and overwrite resources through the second logical service; perform differentiated resource consistency processing on the non-overwrite resources and overwrite resources respectively through the second logical service, and receive new task requests. This shortens the logical service instance switchback waiting time, reduces resource consumption of old nodes during the exit phase, improves the overall system resource utilization, and maintains resource state consistency and business continuity in scenarios with high-concurrency writes, complex metadata adjustments, and concurrent access to shared resources. Attached Figure Description

[0088] 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.

[0089] Figure 1 This application provides a schematic diagram of an application scenario structure for a related technology.

[0090] Figure 2 A flowchart illustrating a service switching method provided in this application embodiment. Figure 1 ;

[0091] Figure 3 This is a schematic diagram illustrating an application scenario structure of this application, provided as an embodiment of the present application.

[0092] Figure 4 A flowchart illustrating a service switching method provided in this application embodiment. Figure 2 ;

[0093] Figure 5 This application provides a schematic diagram of a non-overwrite resource partitioning and data migration process.

[0094] Figure 6 A flowchart illustrating a service switching method provided in this application embodiment. Figure 3 ;

[0095] Figure 7 A schematic diagram of the structure of a service switching device provided in an embodiment of this application;

[0096] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0097] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0098] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0099] It should be noted that although the terms "first," "second," etc., are used to describe various types of information in the embodiments of this application, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. Optionally, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information.

[0100] It should be understood that the terms "comprising" or "including" indicate the presence of the previously mentioned features, steps, or operations, but do not preclude the presence, occurrence, or addition of one or more other features, steps, or operations. The terms "and / or," etc., used in this application can be interpreted as inclusive, or mean any one or any combination thereof. Optionally, "A and / or B" means "any one of the following: A; B; A and B." Additionally, the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0101] High availability management of logical service instances in distributed storage systems is typically applied in scenarios such as cloud storage platforms, distributed file systems, object storage clusters, and hyperconverged infrastructure.

[0102] In such systems, storage controllers, metadata managers, directory service instances, or volume management service instances are typically deployed logically across multiple physical nodes, and business continuity is ensured through primary / standby migration, failover, and recovery switchover.

[0103] In a typical architecture, multiple server nodes are interconnected through a storage network and a management network to jointly access underlying shared storage resources or a distributed resource pool.

[0104] Each physical node can host one or more logical service instances. When a node fails, the corresponding logical service instance will migrate to another healthy node to continue providing services. After the failed node recovers, the logical service instance needs to be switched back to the recovered node to restore the original deployment relationship, load balancing status, and resource usage plan.

[0105] During this process, logical service instances not only need to handle a large number of new requests from front-end businesses, but also need to maintain the continuous accessibility and state consistency of the resources they manage. Especially in environments with large storage resources, high access concurrency, and complex request types, the coordination problem of access to the same batch of resources between old and new nodes during the switchback will be more prominent. Therefore, this scenario places high demands on switchback latency, business continuity, and resource consistency.

[0106] In related technologies, the handover process of logical service instances after the recovery of a faulty node typically adopts a relatively conservative serial takeover mechanism.

[0107] When the faulty node recovers, the node currently hosting the logical service instance will first enter the exit process and mark the corresponding service on itself as no longer accepting new business. Then, it will wait for all the write, delete, update and other modification tasks that it had received before the exit to be completed. Only after these legacy tasks are completely finished can the corresponding service instance on the recovered node be restarted and start receiving new task requests.

[0108] Below, in conjunction with Figure 1 Examples of the above application scenarios will be provided.

[0109] Figure 1 This is a schematic diagram illustrating an application scenario structure of a related technology provided in an embodiment of this application. Please refer to... Figure 1 , Figure 1 It can include faulty nodes and recovery nodes.

[0110] Once the failed node recovers, it first enters an exit process: marking its logical services as exited and refusing to accept new business tasks to prevent new requests from continuing to be processed on the old master node. At this point, the recovered node has not yet started providing services to the outside world.

[0111] Subsequently, the failed node continues processing the write, delete, and update tasks it had received before exiting, and waits for all these ongoing tasks to complete. During this period, the new master node remains in a waiting state and does not accept any business requests.

[0112] Once all legacy modification tasks on the faulty node have been completed and the logical service exit process is finished, the logical service instance on the recovery node will be started and begin providing services to the outside world, receiving and processing new business requests.

[0113] In this approach, the exit process of the faulty node and the startup process of the recovery node are strictly sequential; the recovery node can only take over the service after the faulty node has completely exited.

[0114] The working principle of this type of solution is to extend the exit phase of the failed node, thereby avoiding the modification of the same resource by the old and new nodes at the same time, thus reducing the risk of data overwriting, state disorder and metadata inconsistency caused by concurrent writes.

[0115] However, this approach has significant drawbacks. First, the old node needs to wait for all modification tasks to complete, meaning the recovery node cannot take over the service promptly. The switchback waiting time is directly affected by the number of legacy tasks, task execution time, and the efficiency of underlying resource access. In high-concurrency writes or large-scale metadata adjustments, the waiting time may increase significantly, leading to prolonged blocking of front-end services. Second, although the old node has entered the exit process, it still needs to continuously occupy processors, memory, cache, and network bandwidth to complete the remaining tasks. These resources cannot be used for other services during this period, resulting in a decrease in overall system resource utilization. Third, given the complex access characteristics of shared resources, related solutions often lack finer-grained classification and processing mechanisms, tending to treat resources of different natures with the same waiting method. This processing logic cannot adapt to situations where resource modification behaviors vary significantly in actual storage systems, amplifying both the waiting cost and the management complexity during the switchback window. Especially when the old node is still processing some resources and the recovery node urgently needs to restore service capabilities, relying solely on the overall waiting solution makes it difficult to strike a balance between shortening the switchback time and maintaining data consistency. Therefore, it is difficult to meet the dual requirements of modern distributed storage systems for rapid recovery and stable service.

[0116] To address the aforementioned issues, this application proposes a service switching method. By marking a first logical service as exited and intercepting new task requests, the first logical service ceases to handle new business loads. Subsequently, a second logical service is initialized, which classifies the resources corresponding to the first logical service into non-overwrite and overwrite-enabled resources. The second logical service then performs differentiated resource consistency processing on the non-overwrite and overwrite-enabled resources respectively, and receives new task requests. By introducing resource type classification and differentiated synchronization processing mechanisms within the same switchback process, the recovery node no longer needs to rely on the old node to complete all modification tasks before taking over. Instead, it can accept new tasks after initialization and resource classification, thereby shortening the switchback waiting time, improving service continuity, and enhancing service reliability.

[0117] This method is applicable to distributed storage architectures where logical service instances are jointly hosted by multiple physical nodes. The nodes may include server nodes, storage control nodes, or metadata management nodes. Logical service instances can be migrated between nodes and switched back after recovery.

[0118] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0119] Figure 2 A flowchart illustrating a service switching method provided in this application embodiment. Figure 1 Please see. Figure 2 The above method can be deployed in scenarios where control services, metadata services, directory services, or volume management services instances in cloud storage platforms, distributed file systems, object storage clusters, and hyperconverged infrastructures are switched back to their original locations. The method includes:

[0120] S201. Mark the first logical service as exited and intercept new task requests.

[0121] The first logical service can refer to the currently active logical service instance that actually carries the target business before the faulty node is restored.

[0122] The exit status can be used to indicate that the first logical service has entered the exit process. This status can be recorded in the service registry, node local status file, cluster consistency database, or distributed coordination component, so that other modules in the system can recognize that the logical service no longer undertakes the responsibility of new business access.

[0123] New task requests can refer to new read / write, metadata update, deletion, migration control, attribute modification, etc. requests initiated by the client, upper-layer business modules, management plane, or other internal services during window switching, including at least modification requests that change the state of resources.

[0124] After detecting that the original faulty node has returned to normal, its heartbeat is stable, and the switchback conditions are met, an exit command can be sent to the first logical service currently carrying the business. Upon receiving the exit command, the first logical service first updates its service status from running to exited, and synchronizes this status to the service discovery module, request routing module, and task scheduling module, so that subsequent newly arriving tasks will no longer be distributed to the first logical service. The request entry layer can intercept new task requests based on this exit status. Interception can manifest as directly rejecting access, returning redirection information, forwarding to the access queue of the second logical service that is yet to be initialized, or temporarily storing it in a buffer until the second logical service has the ability to receive before delivery.

[0125] In one possible implementation, the exit status can be implemented using a Boolean flag, an enumerated status code, or a timestamped lifecycle status record.

[0126] The implementation with timestamps makes it easier for other nodes to determine the freshness of the exit status and avoids the overwriting of old statuses caused by network jitter.

[0127] For existing tasks that have been received by the first logical service but have not yet been completed, the system does not require that all tasks in this step be completed before proceeding to the next step. Instead, it allows them to continue in the existing context, thereby avoiding the long-term blocking caused by waiting for all legacy tasks to finish in traditional solutions.

[0128] In one possible embodiment, after marking the exit status, the first logical service can also adjust the access control of its internal execution threads, uniformly refusing to create new write transactions, delete transactions, and metadata update transactions, and only retaining tasks that have entered the execution phase to continue to complete the necessary disk write, log commit, or rollback operations, so as to ensure that the exit process is controllable.

[0129] The interception point for new task requests can be set at the load balancer, gateway proxy, service port monitoring layer, remote procedure call (RPC) framework interceptor, or internal scheduler of logical service.

[0130] When the interception point is located at the service entry layer, the traffic can be routed before the request arrives, reducing the resource consumption of the first logical service.

[0131] When the interception point is located within the service scheduler, it is easier to determine the rejection, caching, or forwarding strategy based on the specific task type.

[0132] Based on the above analysis, by marking the first logical service as exited and intercepting new task requests, it is possible to quickly block the flow of new business into the old node without requiring the old service to immediately clear all historical tasks. This prevents the business load of the old node from further increasing during the switchback, creates stable boundary conditions for the second logical service to take over on the recovery node, and reduces the probability of continuous concurrent modification of the same resource by the new and old nodes, thereby shortening the preparation time for the switchback and reducing the ineffective occupation of system resources.

[0133] S202. Initialize the second logical service.

[0134] The second logical service can refer to a logical service instance used to resume the target business after the faulty node is restored.

[0135] This instance is typically deployed on the original node after recovery, or it can be deployed on a specified node that meets the rollback policy, as long as the control relationship with the resources corresponding to the first logical service can be re-established and subsequent tasks can continue to be processed.

[0136] The purpose of initializing the second logical service is to enable it to receive new task requests, identify and manage the resources corresponding to the first logical service, and perform subsequent resource classification and synchronization processing.

[0137] After the first logical service enters the exit state, the cluster orchestration module or high availability control module starts the second logical service process on the recovery node, allocates processor time slice, memory space, network port, thread pool, cache area and necessary persistent log directory for it, and loads the configuration file, resource index information, protocol stack, authentication information and metadata access permissions corresponding to the target logical service.

[0138] In one possible embodiment, the initialization process includes injecting the service identifier, tenant identifier, volume identifier, directory tree index, object space range, or metadata sharding mapping information corresponding to the first logical service into the second logical service, so that the second logical service can accurately locate the resource range that it needs to take over after startup.

[0139] In another possible embodiment, the initialization process further includes establishing a communication channel between the second logical service and the distributed lock service, the version management module, the log replication module, and the routing management module, so that the second logical service can subsequently verify the resource status and participate in consistency control.

[0140] To ensure continuity during the switchback process, the second logical service does not wait for all historical modification tasks on the first logical service to be completely completed during initialization, but instead establishes basic service capabilities as quickly as possible in a runnable state.

[0141] The second logical service can first complete the loading of the service framework, resource directory, and access credentials, and then enter the resource scanning and type classification stage.

[0142] If the system uses a shared storage architecture, it can mount the shared storage volume, open the corresponding metadata namespace, and restore the checkpoint during initialization.

[0143] If the system adopts a distributed resource pool architecture, it can pull the resource mapping table, the index of incomplete transactions, and the latest commit version number from the metadata service or consistent storage during initialization.

[0144] To prevent the second logical service from being incorrectly assigned requests before it has completed the necessary preparations, the system can maintain a preparation state during the initialization process. This state can include multiple sub-states such as initialization, configuration loaded, resource association established, and request reception ready. The routing layer can then control whether to increase the throughput of new task requests based on these sub-states.

[0145] In one possible embodiment, the conditions for determining the completion of the second logical service initialization include at least the following: the service process is alive, the connection with the underlying resources is successful, the resource identifier is loaded, the state synchronization channel is successfully established, and the classification processing module is executable.

[0146] For scenarios requiring strong consistency, the operation log position or snapshot position of the most recent commit of the first logical service can be read during the initialization phase so that subsequent synchronization processing can start from a specific position.

[0147] Based on the above analysis, by immediately initializing the second logical service after the first logical service exits, and by establishing the operating environment, resource associations, and access control capabilities in advance, the recovery node can enter the takeover preparation phase as soon as possible without waiting for all legacy modifications of the old node to be completed before starting the service. This forms the basis for parallel processing in the switchback process, thereby reducing service interruption time and creating execution conditions for subsequent differentiated synchronization based on resource type.

[0148] S203. The resources corresponding to the first logical service are classified by type through the second logical service to obtain non-overwrite resources and overwrite resources.

[0149] The resources corresponding to the first logical service can refer to the set of target resources that are managed, scheduled, or provided with access interfaces by the logical service.

[0150] The resources corresponding to the first logical service may include data blocks, object fragments, file segments, log segments, metadata items, directory items, index pages, mapping table items, and may also include status records and control information associated with these data.

[0151] Non-overwrite resources are a type of resource that only allows append writing and is written only once. Once a certain write segment of this type of resource is committed, it is usually not overwritten or modified again in the same location. Therefore, its synchronization processing focuses on identifying the incomplete write portion and migrating the processing context.

[0152] Rewrite-type resources are a category of resources that are allowed to be modified repeatedly, such as directory entry attributes, object metadata, block mapping relationships, reference counts, quota status, and transaction status tables. These resources may be updated multiple times during a switchback, thus requiring stricter version verification and access control.

[0153] After initialization, the second logical service can obtain a complete list of resources corresponding to the first logical service from the resource directory, metadata index, transaction log, resource type definition table or business model configuration, and classify the resources according to their modification characteristics.

[0154] For resources such as sequential log writing that only appends and does not overwrite, object segmented upload fragments, write-once archive blocks, and append-only change records, the second logic service categorizes them into the non-overwrite resource set; for resources that allow modification, deletion, renaming, overwriting updates, status write-back, or repeated attribute adjustments, they are categorized into the overwrite resource set.

[0155] In one possible embodiment, the second logical service may also dynamically classify resources based on their current usage status. For example, some resources may be treated as non-overwrite resources when they are in a sealed, read-only, or committed state, while they may be treated as overwrite resources when they are in an edited, merged, or transaction-unclosed state. This classification method can adapt to the processing differences caused by changes in the lifecycle of resources in the storage system.

[0156] The second logical service can establish a classification record for each resource. The record should include at least the resource identifier, resource type, most recent write mode, whether overwriting is allowed, current transaction status, version number, and classification result. Classification can begin with a coarse classification based on the resource model, followed by further subdivision based on runtime status.

[0157] For example, data log segments are non-rewriteable resources by default, but if an index backfill operation is detected for the log segment, it can be temporarily transferred to the rewriteable resource set; some metadata pages are rewriteable resources by default, but if the metadata page has been frozen and is only used for subsequent read-only access, it can be managed as a non-rewriteable resource.

[0158] The system can also adjust the classification range based on system load and the urgency of the switchback.

[0159] For example, in high-concurrency scenarios, resources with low modification risk and easy migration should be prioritized and classified as non-rewriteable resources in advance to accelerate the second logic service to quickly take over most business paths.

[0160] Based on the above analysis, it can be seen that by classifying the resources corresponding to the first logical service into non-overwrite resources and overwrite resources, the existing technology of uniformly waiting for and taking over all resources is no longer adopted. Instead, traffic management is implemented based on the modification behavior of the resources themselves and the concurrency risks, so that subsequent synchronization processing can select different consistency control methods for different resource characteristics.

[0161] This reduces unnecessary overall waiting time and provides a clear boundary for the second logical service to continue processing resources in an orderly manner after receiving new task requests, thereby establishing a balance between shortening the switchback time and maintaining resource consistency.

[0162] S204. Perform differentiated resource consistency processing on non-overwrite resources and overwrite resources respectively through the second logical service, and receive new task requests.

[0163] Differentiated resource consistency processing can refer to the second logical service adopting different consistency strategies for non-rewriteable resources and rewriteable resources, in order to adapt to the differences between the two types of resources in terms of coverage risk, state evolution mode and concurrent modification characteristics.

[0164] For non-rewriteable resources, since such resources typically only undergo one valid write and are expanded in an append-only manner, the synchronization focus of the second logical service is not on repeatedly resolving version conflicts, but on identifying the processing units that the first logical service has not yet completed, migrating the context of these processing units, and continuing subsequent writes at the target location.

[0165] For resources that can be overwritten, since there may still be received but not completed modification operations during the exit of the first logical service, the second logical service needs to rely on version comparison, commit order control, access locks or conflict detection mechanisms to prevent the old and new processing results from overwriting each other.

[0166] The second logical service can scan for processing interruptions left by the first logical service for non-write-reproducible resources, such as incomplete data blocks, unsealed log segments, partially written object fragments, or sequential write cache entries that have not yet been written to disk. The scan results can be obtained by reading the write positions persisted by the first logical service, checkpoint files, task queue snapshots, transaction log tail pointers, or temporary markers in shared storage. Subsequently, the second logical service migrates these incomplete processing units to its own controllable execution context and continues writing or completes sealing operations based on the recorded offset, length, checksum, and target position.

[0167] Since non-overwrite resources do not involve repeated overwrites to the same location, having the second logical service continue processing them after migration can significantly reduce the probability of concurrent write conflicts, while also reducing the need to wait for the first logical service to finish processing.

[0168] For resources with rewrite capabilities, before receiving any related processing requests, the second logical service first reads the current committed version number, last modified timestamp, transaction sequence number, or log position of the resource, and compares it with the version information corresponding to the legacy tasks of the first logical service. If the comparison confirms that a legacy modification has not yet been committed or is an older version, the second logical service can place the request in a waiting queue, perform conflict replay, initiate a retry, or directly reject it; if the comparison confirms that the second logical service has a newer version, it will continue to process new requests based on the current version of the second logical service.

[0169] In one possible embodiment, the second logical service sets fine-grained access control for rewrite-type resources, such as adding read-write locks to directory entries, object metadata, quota records, and mapping table entries, so that new requests can only be executed when the version is consistent or the lock state allows, in order to prevent updates from different sources from overwriting each other.

[0170] In another possible embodiment, the second logical service can also merge the rewrite-type resource modification records left by the first logical service according to the resource identifier, and replay them item by item according to the transaction commit order, thereby restoring a unique and consistent final state.

[0171] Once non-repeatable and repeatable resources have entered their respective synchronization processes, the second logical service can begin receiving new task requests. This receiving action does not require all resources to complete final synchronization; instead, it implements controlled access based on the resource classification results and the current synchronization progress.

[0172] For non-rewriteable resources that have been migrated or can be safely processed, new task requests can be directly handled by the second logic service; for rewriteable resources that have passed version verification and established access control, new task requests can also be executed by the second logic service after the version constraints are met; for a small number of resources that still have conflict risks, the second logic service will return a retry instruction, queue them, or temporarily limit the flow.

[0173] In this way, the second logical service can restore its service capabilities during the switchback period, without having to wait for the old node to finish processing all the modification tasks before taking over in a unified manner, as is the case with traditional solutions.

[0174] Optionally, differentiated resource consistency processing can be performed on non-overwrite resources and overwrite resources respectively through the second logical service in the following ways: the second logical service performs block partitioning and data migration processing on non-overwrite resources to achieve resource consistency processing; the second logical service performs version verification and access control processing on overwrite resources to achieve resource consistency processing.

[0175] Among them, non-rewriteable resources can be maintained as continuous data using append-only writing. After taking over, the second logical service can divide this type of resource into multiple logical blocks according to the preset size. The preset size can be set to a fixed size based on the resource capacity, single block access overhead and cache hit characteristics, which is convenient for subsequent synchronization and migration management.

[0176] When performing append writes on multiple logical blocks, the second logical service can distinguish between the first logical block that has been written and the second logical block that has not been written, based on the write completion flag. For any second logical block, the second logical service reads the data that has not yet been completed and writes the read data into a new logical block. The new logical block can be newly created or pre-allocated by the second logical service. The second logical service continues to accept subsequent requests based on at least one first logical block and at least one new logical block, so that the content that was originally in an incomplete state continues in the new logical block, thereby maintaining the write continuity and data integrity of non-overwrite resources.

[0177] Rewrite-type resources refer to resource types that allow repeated modification, updating, or overwriting of the same resource. When synchronizing such resources, the second logical service first performs version verification. Version verification includes comparing the version number carried in the request, the locally maintained version number, and the currently effective version of the resource to confirm whether the request corresponds to the latest state.

[0178] If the requested version is the same as the current version, the second logic service allows the corresponding modification operation to continue; if the versions are inconsistent, the request will be intercepted, redirected, or suspended according to the access control rules to avoid the old version data from overwriting the new version data.

[0179] Access control rules can be determined by combining resource lock status, read / write permissions, and migration status, and allow access after verification, so that rewrite-type resources maintain consistent modification order and controllable status during the switchback.

[0180] This processing method allows for differentiated synchronization of two types of resources after the second logical service completes initialization. For non-rewriteable resources, incomplete writes can be smoothly taken over through block partitioning and data migration. For rewriteable resources, version verification and access control can maintain modification consistency. The two work together to enable the second logical service to maintain the continuity of resource status while taking over new task requests and reduce the switchback waiting time.

[0181] This improves business continuity after fault recovery and reduces resource consumption and synchronization delays caused by waiting for unified updates, without relying on old service instances to complete all legacy modification tasks.

[0182] Below, in conjunction with Figure 3 Examples of the above application scenarios will be provided.

[0183] Figure 3 This is a schematic diagram illustrating an application scenario structure of this application, provided as an embodiment of the present application. Please refer to... Figure 3 , Figure 3 It can include faulty nodes and recovery nodes.

[0184] The faulty node first enters the exit process, marking its logical services as exited and refusing new business tasks from entering; at the same time, the logical services on the recovered node begin to provide services to the outside world, processing all new business requests and avoiding business interruption.

[0185] While rejecting new tasks, the logical services on the faulty node continue to execute the write, delete, update, and other modification tasks that were received before exiting, and wait for all these ongoing tasks to be completed, ensuring that all unfinished business operations on the old node are closed.

[0186] Once all legacy modification tasks on the faulty node have been processed, the exit process of the logical service is completed, and the service switching process ends.

[0187] Based on the above analysis, it can be seen that by performing differentiated resource consistency processing on non-overwrite resources and overwrite resources respectively through the second logical service, and receiving new task requests during the consistency process, the consistency control in the switchback phase of this application embodiment changes from overall serial waiting to parallel coordination based on resource attributes.

[0188] For non-rewriteable resources, leveraging their append-only and write-only characteristics, takeover conditions are quickly released through incomplete processing unit migration and continuation writing. For rewriteable resources, version verification and access control are used to suppress concurrent modification conflicts, thereby enabling recovery nodes to restore business carrying capacity earlier while ensuring that data status is determinable, traceable, and recoverable.

[0189] This implementation principle directly addresses the issue in related technologies where the switchback waiting time is significantly affected by the number and execution duration of legacy tasks. By decomposing waiting costs through resource classification and synchronization mechanisms, it reduces front-end business blocking time, improves the utilization efficiency of system resources such as processors, memory, and network bandwidth, and reduces the risk of state disorder and metadata inconsistency between new and old nodes around the same batch of resources.

[0190] In one possible implementation, the method further includes: after the first logical service completes the modification operation, querying whether the first logical service is marked as exiting, and obtaining the query result; if the query result indicates that the first logical service is marked as exiting, then returning an operation failure; if the query result indicates that the first logical service is not marked as exiting, then returning an operation success.

[0191] Modification operations can refer to operation requests that change the state of resources, including writing, deleting, updating, or other requests that will cause changes to the content of resources.

[0192] The query results can be used to indicate whether the first logical service has been marked as exited after the modification operation is completed.

[0193] In practical implementation, after processing a modification operation, the first logical service can access its corresponding status record. This status record can be stored in local memory, a shared configuration center, or a distributed consistent storage. Based on this record, it determines whether the current instance has been set to an exit state by external control logic. If the exit status flag is true, it means that although the modification operation has been completed, the service instance is in the exit or rollback finalization stage. In this case, the system returns a failure for the operation to prevent the business side from mistakenly believing that subsequent dependency operations can be submitted on the current instance. If the exit status flag is false, it means that the service instance is still providing services normally. In this case, the system returns a success for the operation, allowing the business side to continue subsequent resource processing based on this result.

[0194] By performing an exit status review after a modification operation is completed, the system can provide a clear result for completed operations that are still in the exit window during service rollback, fault takeover, or instance shutdown, thereby avoiding incorrect confirmations for new services on old instances.

[0195] This approach makes the response behavior of the first logical service at the exit boundary clearer, provides consistent result feedback to the upper-layer scheduling module, and reduces the risk of business ambiguity and resource inconsistency caused by state switching.

[0196] This embodiment provides a service switching method that involves marking a first logical service as exiting and intercepting new task requests; initializing a second logical service; classifying the resources corresponding to the first logical service into non-overwrite and overwrite-enabled resources using the second logical service; performing differentiated resource consistency processing on the non-overwrite and overwrite-enabled resources respectively using the second logical service, and receiving new task requests. This shortens the logical service instance switchback waiting time, reduces resource consumption by old nodes during the exit phase, improves overall system resource utilization, and maintains resource state consistency and business continuity in scenarios involving high-concurrency writes, complex metadata adjustments, and concurrent access to shared resources.

[0197] Below, in conjunction with Figure 4 The process of segmenting and migrating non-rewriteable resources through the second logical service is explained.

[0198] Figure 4 A flowchart illustrating a service switching method provided in this application embodiment. Figure 2 Based on the above embodiments, see also Figure 4 The method includes:

[0199] S401. The non-rewriteable resource is divided into multiple logical blocks according to a preset size through the second logical service.

[0200] A logical block can be a resource logical unit that is divided into a preset size by a second logical service for non-rewrite-type resources, and it serves as the smallest processing object for appending and migrating.

[0201] The preset size can be set according to the capacity of the resource object, the access frequency, and the characteristics of the storage medium, so as to achieve a balance between write granularity and migration overhead.

[0202] After receiving the non-overwrite class resource to be processed, the second logic service can generate multiple consecutive logic blocks according to a preset size and establish corresponding metadata records for each logic block.

[0203] S402, Perform an append write operation on multiple logical blocks, and distinguish between at least one first logical block and at least one second logical block.

[0204] The first logical block is the logical block that has been written, and the second logical block is the logical block that has not been written.

[0205] The first logical block can be used to identify the parts that have been written, and the second logical block can be used to identify the parts that have not yet been written.

[0206] Append write control is performed on multiple logical blocks. When the written content in a logical block reaches a predetermined complete state, it is marked as the first logical block; when a logical block still has unclosed written content, it is marked as the second logical block.

[0207] S403. For any second logic block, read the data in the second logic block and write it to the new logic block.

[0208] The new logical block is used to take over the data migrated from the second logical block and continue writing in the new location.

[0209] After the data in the second logical block is read, it can be rewritten into the newly generated logical block, thereby migrating and taking over the original incomplete writing content.

[0210] S404. Execute the operation corresponding to the new task request through at least one first logic block and at least one new logic block.

[0211] After this process, the logic blocks that have been completed in the old position remain stable, while the logic blocks in the new position continue to accept new content, ensuring the continuity of writing.

[0212] Below, in conjunction with Figure 5 The process of segmenting and migrating non-rewriteable resources through the second logical service is illustrated with an example.

[0213] Figure 5 A schematic diagram illustrating a non-overwrite resource partitioning and data migration process provided in this application embodiment can be found here. Figure 5 , Figure 5 Numbered 1, 2, 3, and 4 are multiple logic blocks obtained after being divided by a preset size, and number 5 is a new logic block generated by migration.

[0214] In this embodiment, the non-rewriteable resource is divided into logical block 1, logical block 2, logical block 3, and logical block 4 by the second logical service according to a preset size. The second logical service then performs append write operations on each logical block in sequence. Once all write tasks for logical blocks 1, 2, and 3 are completed, they are classified as the first logical block. Logical block 4, with only a portion of its write operations completed and the remaining area blank, is classified as the second logical block.

[0215] For logic block 4, which is the second logic block, the second logic service reads the valid data already written inside logic block 4 and writes the read data into a brand new logic block 5, thus completing the data migration of the logic block that has not been written.

[0216] When the second logical service accepts a new task request, it directly reuses all the first logical blocks 1, 2, and 3 that have been written, and at the same time, it relies on the new logical block 5 generated by the migration to accept the subsequent new write operations.

[0217] After adopting this processing method, the first logical service can continue to perform legacy write operations on the original logical block 4, but the write changes made by the old master to the original logical block 4 will not affect the new logical block 5, and thus will not interfere with the resource access and data writing of the second logical service; while the first logical blocks 1, 2 and 3 have been fully written in the old master and there is no overwrite behavior, the second logical service will not have data conflicts when directly calling the data of the first logical block, thus achieving access consistency after switching over non-overwrite type resources.

[0218] This mechanism, during operation, first divides the data into blocks and then identifies completed and incomplete write blocks to achieve fine-grained management of non-overwrite resources. For logical blocks that have not yet been written, the system does not wait for them to finish naturally in their original location. Instead, it migrates the data within them to a new logical block for continued processing, thus avoiding the impact of residual writes in the old location on subsequent access during the switchover. By coordinating the write operations of the first and new logical blocks, the availability of completed content is maintained, and the seamless continuation of migrated content is ensured.

[0219] The implementation details of each step in this application embodiment can be found in the description of the corresponding steps or operations in the above method embodiments; repeated content will not be repeated.

[0220] This embodiment provides a service switching method that divides non-write-resistant resources into multiple logical blocks of a preset size using a second logical service. Append-write operations are performed on these multiple logical blocks, distinguishing between at least one first logical block and at least one second logical block. The first logical block represents the block that has completed writing, while the second logical block represents the block that has not. For any second logical block, data is read from the second logical block and written to a new logical block. Operations corresponding to new task requests are then executed through at least one first logical block and at least one new logical block. In this way, the migration of non-write-resistant resources no longer relies on a unified takeover after the entire process is completed; instead, segmented processing can be performed at the logical block level, reducing switchback waiting time and minimizing the blocking impact of incomplete writes on subsequent services. Since the first logical block and the new logical block correspond to stable data and migrated data, respectively, resource access continuity is enhanced, and the data processing process is easier to control, thereby improving the efficiency and consistency guarantee capability of logical service switchback in distributed storage scenarios.

[0221] Below, in conjunction with Figure 6 The process of performing version verification and access control on rewrite-type resources through the second logical service is explained.

[0222] Figure 6 A flowchart illustrating a service switching method provided in this application embodiment. Figure 3 Based on the above embodiments, see also Figure 6 The method includes:

[0223] S601, Receive resource requests through the second logical service.

[0224] Resource requests can be request objects received and processed by the second logical service.

[0225] Resource requests can be used to carry access intent, resource identifier, and version information, and serve as input for subsequent read / write differentiation, lock control, and version verification.

[0226] After receiving a resource request, the second logic service can parse and process the resource request.

[0227] S602. Determine whether the resource request type is a read request type or a write request type.

[0228] The request type can be parsed from the request message, request header, or request body, and matched with the preset read request type and write request type.

[0229] If the resource request type is a read request type, execute S603;

[0230] If the resource request type is a write request type, execute S604.

[0231] S603. Add a range read lock to the resource range corresponding to the resource request.

[0232] After S603, execute S605.

[0233] Resource ranges can be used to characterize the local area affected by a request in a rewrite-type resource. They can correspond to contiguous address ranges, logical blocks, record segments, or metadata ranges.

[0234] Range read locks can be used to limit concurrent read and modify conflicts on the same resource range.

[0235] For resource requests of the read request type, the second logic service can establish a range read lock on the resource range corresponding to the request, so that access within the same range remains under control during version verification.

[0236] S604. Add a range write lock to the resource range corresponding to the resource request and increase the write count of the corresponding version.

[0237] After S604, execute S605.

[0238] Range write locks can be used to limit concurrent write conflicts on the same resource range.

[0239] Write counters can be used to record the number of write operations that have not yet been completed under a given version, in order to support version consistency checks.

[0240] For write request types, the second logic service can establish a range write lock on the corresponding resource range, and then increment the write count of the version corresponding to the write request to indicate that there are incomplete write operations in that version.

[0241] This approach enables write requests to be included in version status management as soon as they enter the modification process, thereby avoiding data overwriting caused by overlapping requests for different versions within the same timeframe.

[0242] S605, Get the local version number.

[0243] The local version number can be used to represent the current version baseline maintained on the resource side. It serves as a reference for comparing the request version number and is used to determine whether the resource request is executed, waited for, or rejected.

[0244] During the process of obtaining the local version number, the second logical service can read the current version identifier from the locally maintained version status table, version cache area, or metadata record of the corresponding resource, and use it as the base value for resource access control.

[0245] S606. Determine the request version number corresponding to the resource request.

[0246] The request version number can be used to identify the version identifier carried in the resource request, which corresponds to the order of modification when the request enters the resource processing stage.

[0247] When a resource request is generated, it can carry a version identifier corresponding to its write time, commit batch, or commit round. The system can parse the request into a version number to be verified after receiving the request.

[0248] S607. Compare the requested version number with the local version number to obtain the version number comparison result.

[0249] The version number comparison result can be the output obtained by comparing the request version number with the local version number. It serves as the basis for access interception and request scheduling, and is used to determine the subsequent processing path.

[0250] When comparing the request version number with the local version number, a size relationship judgment method can be used to form the version number comparison result, and the current request can be used to determine whether it is allowed to be executed immediately.

[0251] S608. Based on the version number comparison result, perform access interception and request scheduling operations.

[0252] In this embodiment, the execution logic of version verification and access control can be implemented by software modules, hardware logic, or a combination of both. The specific form of the lock table structure, version table structure, and counting structure adopted can be configured according to the system architecture. In practical applications, other models or other equivalent implementations can also be selected. This embodiment does not limit this.

[0253] Access interception and request scheduling operations can uniformly identify resource requests using version numbers, enabling the second logical service to accurately distinguish between new and old request sources during the switchback process and subsequent operation. When the version is upgraded, local legacy requests will be converged first, expired access will be blocked when the version is downgraded, and normal processing will be performed when the versions are the same, thereby ensuring the consistency of access order and status within the same resource range.

[0254] This reduces errors caused by version conflicts in logical service instance switching and concurrent access scenarios, prevents old version requests from overwriting new version data, and also reduces the consumption of system resources by invalid requests. It ensures that resource requests are executed in an orderly manner within clear version boundaries, thereby improving the accuracy of access control and the consistency of resource synchronization.

[0255] Optionally, access interception and request scheduling operations can be performed based on the version number comparison results as follows: if the request version number is higher than the local version number, wait for the unfinished local requests to be completed, update the local version number, and then execute the resource request; if the request version number is lower than the local version number, reject the resource request; if the request version number is the same as the local version number, execute the resource request.

[0256] When the request version number is higher than the local version number, it means that the version sequence corresponding to the current request has advanced the state of the local completed processing. The second logic service can wait for the local unfinished requests to be completed, and then update the local version number and execute the resource request after the write count under the corresponding version is zero or the queue of unfinished requests is empty.

[0257] This approach prevents requests for older versions from entering the execution channel prematurely, thus maintaining the execution continuity of rewrite-type resources during version switching.

[0258] When the requested version number is lower than the local version number, the system can directly reject the resource request and return a version mismatch message to avoid the lower version request overwriting the updated state.

[0259] When the requested version number matches the local version number, the system can directly execute the resource request, allowing read and write processing to continue along the current version baseline.

[0260] After performing access interception and request scheduling operations, the method further includes: if the resource request type is a read request type, releasing the range read lock; if the resource request type is a write request type, releasing the range write lock and clearing the write count.

[0261] Among them, after completing access interception and request scheduling, the second logic service will enter the lock release process according to the request type of the resource request.

[0262] For read request types, after the second logic service confirms that the read operation corresponding to the request has been completed, the relevant cached data has been committed, or the read result has been returned, the lock management unit can release the range read lock previously added to the target resource range, so that the resource range can be allowed to enter again for subsequent read requests, and avoid unnecessary blocking caused by long-term occupation of read locks.

[0263] For write request types, after confirming that the written data has been written to disk, the version information has been updated, or the write request has been rejected and completed, the second logic service can first release the range write lock on the corresponding resource range, and then clear the write count associated with the resource range or the corresponding version to indicate that there are no longer any incomplete write activities that need to be kept write protected, so that subsequent resource requests can re-compare versions and control access based on the latest status.

[0264] During operation, the release of a range lock is usually handled by the lock management module based on the resource identifier, the start and end positions of the range, and the request context. The lock management module can maintain lock table entries, reference counts, or lock holder information to ensure that the release action only applies to the lock instance held by the current request.

[0265] Write count clearing can be performed synchronously after a write request is confirmed, or it can be done when a transaction is committed, rolled back, or the request fails and returns, to ensure that the write count is always consistent with the actual write status of the resource range.

[0266] Through the above processing, the second logical service can promptly reclaim the read-write lock resources after the request scheduling ends and synchronously reset the write status flag.

[0267] With this approach, completed read requests will not continue to hold the interval read lock, and completed write requests will not block subsequent access due to unreleased write locks and write counts. This reduces lock holding time, decreases concurrent waiting on resource intervals, improves request processing efficiency during switchbacks, and helps maintain consistency in version verification, access control, and resource status.

[0268] The implementation details of each step in this application embodiment can be found in the description of the corresponding steps or operations in the above method embodiments; repeated content will not be repeated.

[0269] This embodiment provides a service switching method that receives resource requests through a second logical service; determines whether the resource request type is a read request or a write request; if the resource request type is a read request, adds a range read lock to the resource range corresponding to the resource request and performs version verification and access control processing; if the resource request type is a write request, adds a range write lock to the resource range corresponding to the resource request, increments the write count of the corresponding version, and performs version verification and access control processing. The version verification and access control processing includes: obtaining the local version number; determining the request version number corresponding to the resource request; comparing the request version number with the local version number to obtain the version number comparison result; and performing access interception and request scheduling operations based on the version number comparison result. In this way, the second logical service can apply differentiated range lock control to read and write requests respectively, and combine version number comparison and write count status to complete access interception and request scheduling, thereby reducing conflicts between different version requests, avoiding state disorder of rewrite-type resources during switchback and concurrent access, and thus improving resource modification consistency and service continuity.

[0270] Figure 7 This is a schematic diagram of a service switching device provided in an embodiment of this application. Please refer to... Figure 7 The service switching device 700 includes an interception module 701, an initialization module 702, a classification module 703, and a switching module 704.

[0271] The interception module 701 is used to mark the first logical service as exited and to intercept new task requests;

[0272] Initialization module 702 is used to initialize the second logical service;

[0273] The classification module 703 is used to perform type classification processing on the resources corresponding to the first logical service through the second logical service to obtain non-overwrite resources and overwrite resources.

[0274] The switching module 704 is used to perform differentiated resource consistency processing on non-overwrite resources and overwrite resources respectively through the second logical service, and to receive new task requests.

[0275] Optionally, in the above-described device, the switching module 704 is specifically used for:

[0276] The second logical service performs block partitioning and data migration processing on non-rewriteable resources to achieve resource consistency processing.

[0277] The second logical service performs version verification and access control on resources with duplicate types to achieve resource consistency.

[0278] Optionally, in the above-described device, the switching module 704 is specifically used for:

[0279] The second logical service divides the non-rewriteable resources into multiple logical blocks according to a preset size.

[0280] Perform append write operations on multiple logical blocks, and distinguish at least one first logical block and at least one second logical block, where the first logical block is the logical block that has been written and the second logical block is the logical block that has not been written.

[0281] For any given second logical block, read the data within the second logical block and write it to the new logical block;

[0282] The operation corresponding to the new task request is executed through at least one first logic block and at least one new logic block.

[0283] Optionally, in the above-described device, the switching module 704 is specifically used for:

[0284] Receive resource requests through the second logical service;

[0285] Determine whether the resource request is a read request or a write request.

[0286] If the resource request type is a read request type, add a range read lock to the resource range corresponding to the resource request, and perform version verification and access control processing.

[0287] If the resource request is a write request, add a range write lock to the resource range corresponding to the resource request, increment the write count for the corresponding version, and perform version verification and access control processing.

[0288] Optionally, in the above-described device, the switching module 704 is specifically used for:

[0289] Get the local version number;

[0290] Determine the request version number corresponding to the resource request;

[0291] Compare the requested version number with the local version number to obtain the version number comparison result;

[0292] Based on the version number comparison results, perform access interception and request scheduling operations.

[0293] Optionally, in the above-described device, the switching module 704 is specifically used for:

[0294] If the requested version number is higher than the local version number, wait for any unfinished local requests to complete, update the local version number, and then execute the resource request.

[0295] If the requested version number is lower than the local version number, the resource request will be rejected.

[0296] If the requested version number matches the local version number, execute the resource request.

[0297] Optionally, in the above-described device, the switching module 704 is also used for:

[0298] If the resource request type is a read request type, release the range read lock;

[0299] If the resource request is a write request, release the range write lock and clear the write count.

[0300] Optionally, the apparatus as described above further includes a confirmation module 705, which is used for:

[0301] After the first logical service completes the modification operation, check whether the first logical service is marked as exited and obtain the query result;

[0302] If the query result indicates that the operation has been marked as exited, the operation will fail.

[0303] If the query result shows that the exit status is not marked, the operation is returned as successful.

[0304] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Please refer to... Figure 8 The electronic device 800 may include: a memory 801, a processor 802, and a transceiver 803.

[0305] Memory 801 is used to store program instructions;

[0306] The processor 802 is used to execute the program instructions stored in the memory so that the electronic device 800 performs the above-described method.

[0307] Transceiver 803 may include a transmitter and / or a receiver. The transmitter may also be referred to as a transmitter, transmitter port, or transmitter interface, and the receiver may also be referred to as a receiver port, receiver interface, or similar descriptions. Exemplarily, memory 801, processor 802, and transceiver 803 are interconnected via bus 804.

[0308] This application also provides a computer program product that can be executed by a processor, and when the computer program product is executed, the above-described method can be implemented.

[0309] The service switching apparatus, electronic device, computer-readable storage medium, and computer program product of this application embodiment can execute the technical solutions shown in the above service switching method embodiments. Their implementation principles and beneficial effects are similar and will not be repeated here.

[0310] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0311] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0312] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0313] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0314] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0315] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0316] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0317] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0318] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A service switching method, characterized in that, The method includes: Mark the first logical service as exited and intercept new task requests; Initialize the second logical service; The second logical service performs type classification processing on the resources corresponding to the first logical service to obtain non-overwrite resources and overwrite resources. The second logical service performs differentiated resource consistency processing on the non-overwrite resources and the overwrite resources respectively, and receives the new task request.

2. The method according to claim 1, characterized in that, The second logical service performs differentiated resource consistency processing on the non-overwrite resources and the overwrite resources respectively, including: The second logical service performs block partitioning and data migration processing on the non-overwrite type resources to achieve resource consistency processing. The second logical service performs version verification and access control on the rewrite-type resources to achieve resource consistency.

3. The method according to claim 2, characterized in that, The second logical service performs block partitioning and data migration processing on the non-overwrite-type resources, including: The second logical service divides the non-rewriteable resources into multiple logical blocks according to a preset size. An append write operation is performed on the plurality of logical blocks, and at least one first logical block and at least one second logical block are distinguished, wherein the first logical block is a logical block that has been written and the second logical block is a logical block that has not been written. For any given second logical block, read the data within the second logical block and write it to the new logical block; The operation corresponding to the new task request is executed through at least one first logic block and at least one new logic block.

4. The method according to claim 2, characterized in that, The second logical service performs version verification and access control on the rewrite-type resources, including: Receive resource requests through the second logical service; Determine whether the resource request is a read request or a write request. If the resource request is a read request, add a range read lock to the resource range corresponding to the resource request, and perform version verification and access control processing. If the resource request is a write request, add a range write lock to the resource range corresponding to the resource request, increase the write count of the corresponding version, and perform version verification and access control processing.

5. The method according to claim 4, characterized in that, Perform version verification and access control processing, including: Get the local version number; Determine the request version number corresponding to the resource request; Compare the requested version number with the local version number to obtain the version number comparison result; Based on the version number comparison result, perform access interception and request scheduling operations.

6. The method according to claim 5, characterized in that, Based on the version number comparison result, perform access interception and request scheduling operations, including: If the request version number is higher than the local version number, wait for any unfinished local requests to be completed, update the local version number, and then execute the resource request. If the requested version number is lower than the local version number, the resource request is rejected. If the requested version number matches the local version number, execute the resource request.

7. The method according to claim 6, characterized in that, After performing access interception and request scheduling operations, the method further includes: If the resource request type is a read request type, release the range read lock; If the resource request is a write request, release the range write lock and clear the write count.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: After the first logical service completes the modification operation, query whether the first logical service is marked as exited and obtain the query result. If the query result indicates that the operation has been marked as exited, then the operation will fail. If the query result indicates that the exit status is not marked, the operation is returned as successful.

9. A service switching device, characterized in that, The device includes: The interception module is used to mark the first logical service as exited and to intercept new task requests; The initialization module is used to initialize the second logical service; The classification module is used to perform type classification processing on the resources corresponding to the first logical service through the second logical service to obtain non-overwrite resources and overwrite resources; The switching module is used to perform differentiated resource consistency processing on the non-overwrite class resources and the overwrite class resources respectively through the second logic service, and to receive the new task request.

10. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-8.

12. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.

Images