Mutual exclusion verification method and system for multi-user operation of database and related equipment

Abstract

The invention relates to a mutual exclusion verification method and system for database multi-user operation and related equipment. The method comprises the steps of obtaining a distributed lock state in response to user operation; in response to the condition that the distributed lock state is a locked state, intercepting the user operation by using the section component; or, responding to the condition that the distributed lock state is the release state, modifying the distributed lock state into the locking state, and verifying the user operation; in response to verification that the user operation and the target user operation are not mutually exclusive, allowing the user operation; or, in response to verification mutual exclusion between the user operation and the target user operation, intercepting the user operation by using the section component. According to the method provided by the embodiment of the invention, through the distributed lock and the mutual exclusion verification component, the consistency and integrity of the database cluster under multi-user operation and maintenance operations and different operation and maintenance operations of the same user can be ensured, and effective management and control of the operation and maintenance operations are realized.

Description

Technical Field

[0001] The present disclosure relates to the technical field of computer systems, and particularly to a method, a system and related devices for mutual exclusion verification of multi-user operations on a database. Background Art

[0002] With the rapid development of information technology, many enterprises and organizations use database clusters for data storage and management. At the same time, visualization operation and maintenance systems are widely used in cluster management and operation and maintenance operations. However, when performing operation and maintenance operations on a database cluster, such as expansion, contraction, upgrade, etc., it may involve the situation where multiple users perform operation and maintenance operations on the same cluster at the same time, or the same user performs different operation types at the same time. These concurrent operations may cause data inconsistency problems, especially in the case of no effective concurrent control mechanism, affecting the use of the operation and maintenance system and even seriously affecting the availability and data accuracy of the database cluster. Summary of the Invention

[0003] To solve the above technical problems, the present disclosure provides a method, a system and related devices for mutual exclusion verification of multi-user operations on a database.

[0004] The present disclosure provides a method for mutual exclusion verification of multi-user operations on a database, including: in response to a user operation, obtaining the distributed lock status; in response to the distributed lock status being in a locked state, intercepting the user operation by using an aspect component; or, in response to the distributed lock status being in a released state, modifying the distributed lock status to a locked state and verifying the user operation; in response to the user operation being verified as non-mutually exclusive with the target user operation, allowing the user operation and modifying the distributed lock status to a released state; or, in response to the user operation being verified as mutually exclusive with the target user operation, intercepting the user operation by using an aspect component and modifying the distributed lock status to a released state.

[0005] Optionally, verifying the user operation includes: verifying the user name and operation type of the user operation; in response to the user operation being verified as non-mutually exclusive with the target user operation, including: in response to the user name of the user operation being the same as the target user name and the operation type of the user operation being the same as the target operation type, determining that the user operation is verified as non-mutually exclusive with the target user operation; or, in response to the non-existence of the target user operation, determining that the user operation is verified as non-mutually exclusive with the target user operation; in response to the user operation being verified as mutually exclusive with the target user operation, including: in response to the user name of the user operation being different from the target user name, and / or the operation type of the user operation being different from the target operation type, determining that the user operation is verified as mutually exclusive with the target user operation.

[0006] Optionally, the above method further includes: using a database persistence component to save the distributed lock status and the user operation.

[0007] Optionally, before verifying the operation type of the user operation, it further includes: encapsulating multiple different operation types through enumeration, and defining multiple different policy interfaces, where different policy interfaces correspond to different verification logics; managing the policy interfaces through a container, and storing the correspondence between the enumeration of the operation type and the verification logic in the container; creating a context object of the policy interface; verifying the operation type of the user operation, including: according to the operation type of the user operation, calling the target verification logic in the container through the context object, and using the target verification logic to verify the operation type of the user operation.

[0008] Optionally, before obtaining the distributed lock status in response to the user operation, it further includes: creating a custom annotation for the target operation object and the user operation; creating an around advice, where the aspect component executes the around advice in response to the custom annotation.

[0009] Optionally, the around advice includes pre-call processing and post-call processing, where: the pre-call processing is used to modify the distributed lock status to the locked state and verify the user operation, and the post-call processing is used to modify the distributed lock status to the released state.

[0010] Optionally, after intercepting the user operation by using the aspect component, it further includes: presenting the interception information to the user.

[0011] Based on the same inventive concept, the present disclosure also provides a mutual exclusion verification system for multi-user operations of a database, including: a distributed lock component; an aspect component, configured to obtain the distributed lock status in response to the user operation; intercept the user operation in response to the distributed lock status being the locked state; or, in response to the distributed lock status being the released state, modify the distributed lock status to the locked state; in response to the user operation and the target user operation being verified as non-mutually exclusive, allow the user operation and modify the distributed lock status to the released state; or, in response to the user operation and the target user operation being verified as mutually exclusive, intercept the user operation and modify the distributed lock status to the released state; a mutual exclusion verification component, configured to verify the user operation in response to the distributed lock status being the released state.

[0012] Based on the same inventive concept, the present disclosure also provides an electronic device, including: a processor; a memory for storing executable instructions; wherein, the processor is configured to read the executable instructions from the memory and execute the executable instructions to implement the method of any one of the above.

[0013] Based on the same inventive concept, the present disclosure also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the processor implements the method of any one of the above.

[0014] The technical solution provided by the present disclosure has the following advantages compared with the prior art: The method provided by the embodiments of the present disclosure can ensure the consistency and integrity of the database cluster under multi-user operation and maintenance operations and different operation and maintenance operations of the same user through a distributed lock and a mutual exclusion verification component, and realizes the effective management and control of operation and maintenance operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The accompanying drawings herein are incorporated into and constitute a part of this specification, showing embodiments consistent with the present disclosure, and are used together with the specification to explain the principles of the present disclosure.

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, the following will briefly introduce the accompanying drawings required for description in the embodiments or the prior art. Obviously, for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0017] Figure 1 It is a schematic flowchart of a mutual exclusion verification method for multi-user operations of a database provided by an embodiment of the present disclosure; Figure 2 It is a schematic architecture diagram of a mutual exclusion verification system for multi-user operations of a database provided by an embodiment of the present disclosure; Figure 3 It is a schematic flowchart of another mutual exclusion verification method for multi-user operations of a database provided by an embodiment of the present disclosure; Figure 4 It is a schematic flowchart of another mutual exclusion verification method for multi-user operations of a database provided by an embodiment of the present disclosure; Figure 5 It is a schematic architecture diagram of another mutual exclusion verification system for multi-user operations of a database provided by an embodiment of the present disclosure; Figure 6 It is a schematic hardware structure diagram of an electronic device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0018] In order to more clearly understand the above objects, features, and advantages of the embodiments of the present disclosure, the following will further describe the solutions of the embodiments of the present disclosure. It should be noted that, without conflict, the embodiments of the present disclosure and the features in the embodiments can be combined with each other.

[0019] In the following description, many specific details are set forth to fully understand the embodiments of the present disclosure, but the embodiments of the present disclosure can also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only a part of the embodiments of the present disclosure, rather than all the embodiments.

[0020] In the related art, for multi-user concurrent operation and maintenance operations, mutual exclusion is achieved by locking (such as synchronized) at the method level. This approach has some drawbacks, such as high performance overhead, limited scalability, and insufficient flexibility. The related art lacks an effective mutual exclusion mechanism, resulting in conflicts and resource waste among operation and maintenance operations.

[0021] In view of this, an embodiment of the present disclosure provides a mutual exclusion verification method for multi-user operations of a database, as Figure 1 shown, including: S1. In response to a user operation, obtain the distributed lock status. The user operation here can be an operation and maintenance operation performed by the user on the database cluster.

[0022] In response to the distributed lock status being the locked state, execute S2. Intercept the user operation using the aspect component; or, in response to the distributed lock status being the released state, execute S3. Modify the distributed lock status to the locked state and verify the user operation.

[0023] In response to the user operation and the target user operation verification not being mutually exclusive, execute S4. Allow the user operation and modify the distributed lock status to the released state; or, in response to the user operation and the target user operation verification being mutually exclusive, execute S5. Intercept the user operation using the aspect component and modify the distributed lock status to the released state.

[0024] The method provided by the embodiment of the present disclosure can ensure the consistency and integrity of the database cluster under multi-user operation and maintenance operations and different operation and maintenance operations of the same user through the distributed lock and the mutual exclusion verification component, and realizes the effective management and control of the operation and maintenance operations.

[0025] Specifically, the above work of verifying the user operation is executed by the mutual exclusion verification component, and the mutual exclusion verification component can provide flexible business expansion functions in the entire system. The mutual exclusion verification component implements the mutual exclusion verification function using the strategy pattern. The strategy pattern is a behavioral design pattern that defines a series of algorithms (strategies), encapsulates each algorithm, and enables the algorithms to be interchangeably used. The strategy pattern makes the change of the algorithm independent of the client using the algorithm. This way makes the expansion of the verification logic very flexible. When a new mutual exclusion verification rule needs to be added, only a new strategy class needs to be added without modifying the existing verification code, which conforms to the open-closed principle and improves the scalability and maintainability of the code.

[0026] Moreover, the method provided by the embodiments of the present disclosure is non-invasive by horizontally intercepting user operations through the aspect component, without the need to modify the original business logic code, reducing the coupling degree of the system. The aspect component (AOP) is non-invasive mainly because it can dynamically insert additional functions (i.e., the above-mentioned mutual exclusion verification function) into the business logic without modifying the original business logic code. First, the aspect component separates concerns, separating the additional functions from the core business logic. In an embodiment provided by the present disclosure, the above-mentioned mutual exclusion verification function is defined as an independent aspect, and the main business logic code does not need to care about the existence of the mutual exclusion verification function, thus maintaining the clarity and maintainability of the code. Secondly, the aspect component inserts the aspect logic into the specified join point automatically at runtime through the way of dynamic weaving, and the main business logic code does not need to explicitly call these functions, further reducing code coupling. Finally, the non-invasiveness of the aspect component is also reflected in its flexible scalability. When new functions need to be added, only new aspects need to be defined without modifying the main business logic code.

[0027] Specifically, the distributed lock component is a technology used to control access to shared resources in a distributed system, ensuring that only one client can access a specific resource or execute a specific code block at any given moment. The method provided by the embodiments of the present disclosure uses the distributed lock component for preliminary verification, first ensuring the mutual exclusion of operations of different users and avoiding data inconsistency problems caused by simultaneous operations of multiple users. In specific implementation, the distributed lock component is implemented using Redis, leveraging its atomic operation characteristics to ensure the effectiveness of the distributed lock. In specific implementation, a unique identifier can be generated by combining the mutual exclusion prefix "MUTEX" and the cluster ID, and the Lua script is used to execute the SETNX and EXPIRE commands to achieve the locking and release of the lock. In a specific embodiment, when the distributed lock is in the locked state and no user operation is received, the distributed lock becomes the released state after a preset time, and the released state can be one hour.

[0028] Although the above-mentioned distributed lock component and the mutual exclusion verification component are similar in some functions. For example, the aspect component intercepts user operations based on the feedback of these two components, but the distributed lock component and the mutual exclusion verification component are used to perform different functions in the embodiments of the present disclosure. Specifically, the distributed lock component is used for preliminary verification to ensure that only one user is operating on the database cluster at this time, avoiding data inconsistency caused by another user's simultaneous operation when performing mutual exclusion verification on a certain user operation. The mutual exclusion verification component is used for further verification to avoid data loss caused by the same user performing other operations on the database cluster before a certain operation is completed.

[0029] In some embodiments, the verification of the user operation in S3 above includes: Verify the user name and operation type of the user operation.

[0030] In the above method, in response to the user operation and the target user operation verification not being mutually exclusive, it includes: In response to the user name of the user operation being the same as the target user name, and the operation type of the user operation being the same as the target operation type, it is determined that the user operation and the target user operation verification are not mutually exclusive; or, in response to the non-existence of the target user operation, it is determined that the user operation and the target user operation verification are not mutually exclusive.

[0031] In the above method, in response to the user operation and the target user operation verification being mutually exclusive, it includes: In response to the user name of the user operation being different from the target user name, and / or the operation type of the user operation being different from the target operation type, it is determined that the user operation and the target user operation verification are mutually exclusive.

[0032] In a specific embodiment (hereinafter referred to as Embodiment 1), User A and User B simultaneously (User B is 100 milliseconds later) perform user configuration operations for cluster expansion on cluster 1 in the cluster list of the operation and maintenance platform. For User A, when starting the operation, the distributed lock status is in the released state, so it proceeds to the next step of verifying the user operation and changes the distributed lock status to the locked state; for User B, when starting the operation, the distributed lock status has become the locked state due to the operation of User A, and at this time, User B's operation will be intercepted.

[0033] Returning to User A, if all previous configuration operations on cluster 1 have been completed when User A starts the configuration operation and there are no other users currently performing configuration operations on cluster 1, it belongs to the above situation of non-existence of the target user operation. The user operation of User A and the target user operation verification are not mutually exclusive, and User A can start the configuration operation on cluster 1. At this time, the work of the distributed lock has also been completed, and the distributed lock status is changed to the released state.

[0034] After that, when User A is performing a configuration operation on cluster 1, User C also wants to perform a configuration operation on cluster 1. At this time, since the distributed lock status is in the released state, User C passes the preliminary verification of the distributed lock component and enters the mutual exclusion verification. At this time, the user name and operation type of the target user operation are User A and cluster expansion. Since the user name of User C is mutually exclusive with that of User A, User C fails to pass the mutual exclusion verification, and User C's operation is intercepted.

[0035] During the process of expanding the configuration of Cluster 1 by User A, a part of the configuration was saved. After exiting and then performing a cluster upgrade configuration on Cluster 1 again from the cluster list, since the operation type of User A at this time was mutually exclusive with the cluster expansion operation of the target user, User A could not pass the mutual exclusion verification, and the operation of User A was intercepted. After User A was intercepted, the cluster expansion configuration of Cluster 1 was performed again from the cluster list. At this time, the user name of User A was the same as the target user name, and the operation type of User A was the same as the target operation type. User A passed the mutual exclusion verification and could continue the unfinished expansion configuration operation.

[0036] In some embodiments, the above method further includes: Using a database persistence component to save the distributed lock status and user operations.

[0037] Specifically, the database persistence component adopts the persistence framework of Mybatis, and stores key information such as the user name and operation type of cluster operations through a reasonable database table structure design. The mutual exclusion verification logic component needs to rely on this component to query the distributed lock status and target user operations. When the mutual exclusion verification of the user's operation on the cluster passes and starts, the operation and maintenance system will modify this record, write the user name and operation type of the current user operation as the user name and operation type of the target user operation. When the operation and maintenance operation is completed, the relevant information of the target user operation will be cleared.

[0038] In some embodiments, before verifying the operation type of the user operation in the above S3, it further includes: Encapsulating multiple different operation types through enumeration, and defining multiple different policy interfaces, where different policy interfaces correspond to different verification logics. Manage the policy interfaces through a container, and store the corresponding relationship between the enumeration of operation types and the verification logics through the container. Create a context object for the policy interface.

[0039] In some embodiments, verifying the operation type of the user operation in the above S3 includes: According to the operation type of the user operation, call the target verification logic in the container through the context object, and use the target verification logic to verify the operation type of the user operation.

[0040] Encapsulating the operation types through enumeration can clearly define the scope and meaning of each operation. At the same time, defining independent policy interfaces for each operation type makes each verification logic have clear responsibilities. This responsibility division makes the code more modular, and each module only focuses on its specific logic, thus improving the readability and maintainability of the code. When new operation types or verification logics need to be added, only new enumeration values and corresponding policy interface implementation classes need to be added, without modifying the existing code, thus achieving flexible expansion.

[0041] At the same time, this design decouples the operation type from the verification logic, enabling the two to change independently. At runtime, the corresponding verification logic can be dynamically selected according to the enumerated value, further enhancing the flexibility of the system. In addition, the independently encapsulated verification logic is convenient for unit testing and helps improve the overall quality of the system. Therefore, this design method can effectively cope with requirement changes, enhance the maintainability and testability of the code, and has remarkable flexibility and scalability.

[0042] Through the container management strategy interface and by dynamically invoking the target verification logic using the context object, this technology has high flexibility and scalability. The centralized management of the container makes the registration and lookup of strategies more efficient. The mediating role of the context object further decouples the client code from the strategy implementation, enabling the system to dynamically adapt to different operation types. This design conforms to the open-closed principle, is convenient for extension and maintenance, and also supports independent unit testing, effectively improving the overall quality and adaptability of the system.

[0043] In specific implementation, the above method can be executed in the following manner: classify the operation types of operation and maintenance, and encapsulate them using the enumeration Operate Type Enum; define the policy interface Operation Check Strategy, and each verification logic implements this interface and is managed by the IOC container; bind and store the corresponding relationship between the policy implementation classes in the IOC container and the enumeration of operation types. For example, inject the policy class through the Spring framework and store the policy implementation class in the Map container, with the Map key being the operation type enumeration Operate Type Enum; create a context object for the policy, and provide an external access method getStrategy(Operation Type operation Type). This method can extract the corresponding policy implementation class from the binding relationship according to the operation type, and then call the corresponding verification method.

[0044] In some embodiments, before the above S1, the method provided by the embodiments of the present disclosure further includes: Create a custom annotation for the target operation object and the user operation; create a around advice, where the aspect component executes the around advice in response to the custom annotation.

[0045] In specific implementation, not all operations on the database cluster need to be verified and intercepted using the method provided by the embodiments of the present disclosure, nor do all clusters need verification and interception. Therefore, the method provided by the above embodiments creates a custom annotation for the user operations and clusters that need to be verified and intercepted (i.e., the above target operation objects), and creates an around advice before and after the user operation. Then, the aspect component calls the distributed lock and mutual exclusion verification component based on the custom annotation to verify and intercept the specified user operation.

[0046] Specifically, the above database persistence component is also used to store the above custom annotations.

[0047] In some embodiments, the above-mentioned surround notification includes pre-call processing and post-call processing, wherein: the pre-call processing is used to modify the distributed lock state to a locked state and verify user operations, and the post-call processing is used to modify the distributed lock state to a released state.

[0048] In specific implementation, the above method can be executed in the following way: create a custom annotation @Mutex, internally declare the parameters to take over the operation object (cluster ID) and operation type in the request, and the custom annotation is used to mark the method that needs mutual exclusion verification in the control layer; create a section, first define the section, then declare the entry point in the section, and use the custom annotation as the entry point expression; finally, declare the surround notification, which consists of three parts: pre-call processing, target user operation, and post-call processing. Among them, the pre-call processing is responsible for scheduling the distributed lock component, mutual exclusion verification component and database persistence component, and the post-call processing is used to perform the finishing work after the request, such as changing the distributed lock state to the released state.

[0049] In actual application of the above method, when user A sends an HTTP request through the browser, the server receives and processes the request, and the backend framework forwards the request to the corresponding method in the control layer. If the method is marked with a custom annotation, the surround notification in the aspect component will be executed.

[0050] The process in the surround notification is as follows: get the operation object (cluster ID) from the custom annotation, splice the prefix "MUTEX:", and try to change the distributed lock state to the locked state; if the cluster lock already exists in the cache of the database persistence component (the distributed lock state is locked), the lock fails, the user prompt information processing component is called, and the corresponding lock failure prompt information is returned to the front end, and the process ends; if the cluster lock does not exist in the cache of the database persistence component (the distributed lock state is released), the lock is successful, and the mutual exclusion verification component is called for mutual exclusion verification; after the verification passes, the operation and maintenance operations in the control layer are executed, and the database persistence component is called to update the cluster occupancy status. If the verification fails, the user prompt information processing component is called and the current operation occupancy status of the front-end cluster is returned; finally, the distributed lock state is changed to the released state.

[0051] In some embodiments, after intercepting the user operation using the aspect component, it also includes: displaying the interception information to the user.

[0052] Specifically, the method for presenting interception information to the user is executed by the user prompt information processing component, which is responsible for generating prompt information for presentation to the user. When the user mutex verification fails, the user can see the Toast information of the ongoing operation and maintenance operations of the cluster, thereby accurately prompting the user of the operation and maintenance status of the cluster through the interface, improving the user experience, and further reducing the occurrence of operation conflicts and errors.

[0053] During specific implementation, the above method can be implemented by enumerating the operation types configured in the control layer, obtaining the description information of the operation type that occupies the operation object therefrom, and assembling a text template to generate prompt information.

[0054] During specific implementation, for the first embodiment above, user A and user B perform user configuration operations for cluster expansion on the cluster list of the operation and maintenance platform at the same time (user B is slightly 100 milliseconds later). For user A, when starting the operation, the distributed lock status is in the released state, so it enters the next step to verify the user operation and changes the distributed lock status to the locked state; for user B, when starting the operation, the distributed lock status has become the locked state due to the operation of user A. At this time, the operation of user B will be intercepted, and user B will receive a prompt message: "This cluster is already occupied. Please try again later."

[0055] Returning to user A, if all previous configuration operations on cluster 1 have been completed when user A starts the configuration operation and there are no other users performing configuration operations on cluster 1 currently, it belongs to the above situation where there is no target user operation. The user operation of user A and the target user operation verification are not mutually exclusive, and user A can start the configuration operation on cluster 1. At this time, the work of the distributed lock has also been completed, and the distributed lock status is changed to the released state.

[0056] After that, when user A is performing a configuration operation on cluster 1, user C also wants to perform a configuration operation on cluster 1. At this time, since the distributed lock status is in the released state, user C passes the preliminary verification of the distributed lock component and enters the mutex verification. At this time, the user name and operation type of the target user operation are user A and cluster expansion. Since the user name of user C is mutually exclusive with that of user A, user C fails to pass the mutex verification, and the operation of user C is intercepted. User C receives a prompt message: "There is an unfinished cluster expansion configuration on this cluster. Please wait for it to complete before trying again."

[0057] While configuring cluster 1, user A saved a portion of the configuration and then exited. After retrying the cluster upgrade, user A attempted to upgrade cluster 1 again from the cluster list. However, because the type of operation performed by user A at this time was mutually exclusive with the target user's cluster expansion, user A failed the mutual exclusion check and was blocked. User A received the message, "An incomplete cluster expansion has been configured for this cluster. Please wait until it completes before attempting again." After being blocked, user A attempted to expand cluster 1 again from the cluster list. This time, user A's user name matched the target user name, and their operation type matched the target operation type. User A passed the mutual exclusion check and was allowed to continue the unfinished expansion. At this point, user D entered the mutual exclusion check and received the message, "An incomplete cluster expansion has been configured for this cluster. The current operation cannot be performed. Please visit the Task Management Center for details."

[0058] Figure 2 The dependency relationship among the above-mentioned distributed lock component 10, database persistence component 40, mutual exclusion verification component 30, user prompt information processing component 50 and aspect component 20 is shown, wherein the aspect component 20 depends on the other four components and implements the mutual exclusion verification function of operation and maintenance operations by calling the interfaces or methods provided by the other four components; the mutual exclusion verification component 30 depends on the database persistence component 40 to obtain data support; the user prompt information processing component 50 generates corresponding prompt information based on the results of the mutual exclusion verification component 30 and displays it to the user.

[0059] In a specific embodiment, Figure 3 As shown in the figure, after a user initiates an operation and maintenance request, the user first enters the surrounding notification process of the aspect component. In the surrounding notification, an attempt is made to obtain the distributed lock status. If the lock acquisition fails (the distributed lock status is locked), a prompt message is directly returned to the user. If the lock acquisition succeeds (the distributed lock status is released), the mutual exclusion verification component is called for verification. The mutual exclusion verification component selects the appropriate verification strategy from the policy library of the policy mode based on the different operation types. If the verification fails, the user prompt information processing component is called to display the current cluster occupancy status to the user. If the verification passes and the current database cluster is not occupied or the operation is allowed to continue, the user operation is executed, the cluster occupancy status in the database is updated, and the distributed lock is finally released.

[0060] This disclosure also provides another specific embodiment, Figure 4The present embodiment illustrates the process for initiating a cluster management task (e.g., cluster upgrade configuration) for a cluster in the cluster list. First, if the cluster has not been locked by the user through the distributed lock component, a preliminary verification passes. If the cluster has been locked by the user through the distributed lock component, the mutual exclusion verification component determines whether the locked operation type is "data redistribution." If the locked operation type is "data redistribution," the database persistence component checks whether the data redistribution task has been completed. If not, the mutual exclusion verification fails. If completed, the database persistence component unlocks the cluster, and the mutual exclusion verification passes. If the locked operation type is not "data redistribution," the current operating user is compared with the target user of the locking operation to see if they are consistent. If not, the mutual exclusion verification fails. If they are consistent, the current operation type is determined to be consistent with the target locked operation type. If not, the mutual exclusion verification fails. If they are consistent, the mutual exclusion verification passes, and the user can continue to upgrade the cluster.

[0061] The present disclosure also provides another specific embodiment. The main process includes: defining an enumeration of operation types, Operate Type Enum, including an enumeration code and description information; defining an annotation @Mutex, which contains the operation type, operation object, and the configuration ID of the cluster, and is used to mark the operation and maintenance operation methods that require mutex verification in the control layer. For example: @interface Mutex { String clusterId(); Operate Type Enum type(); String configId();}; adding an annotation to the interface method in the control layer and configuring the operation object and the current operation type. For example: @Mutex(type = Operate Type Enum.CONFIG_EXPAND, configId = "configId") public void enterCheck(String clusterId, String configId); defining an aspect, Mutex Aspect, to intercept the methods in the control layer with the custom annotation, using the around advice method; in the around advice of the aspect, first attempt to lock the distributed lock. If the lock acquisition fails, return a user prompt message (call the generateUserTip method). If the lock acquisition is successful, perform subsequent processing; obtain the current operation type from the operation enumeration type configured in the control layer, and execute the corresponding mutex verification policy class, Operation Check Strategy, according to the operation type, and call the verification method checking(String clusterId, String operateCode); if the mutex verification fails, accurately display the occupancy situation of the current cluster to the user through the interface (call the generateUserTip method); if the mutex verification passes, prompt the user whether to continue based on this operation (implemented through interface interaction) according to the occupancy type of the current database cluster, or start executing the operation and maintenance configuration (call the target method). At the same time, update the cluster occupancy status in the database (call the updateClusterOccupiedStatus method) and release the distributed lock (call the unlock method) after the operation and maintenance operation is completed.

[0062] It should be noted that the method of the embodiment of the present application can be executed by a single device, such as a computer or a server. The method of this embodiment can also be applied to a distributed scenario and completed by multiple devices cooperating with each other. In this case of a distributed scenario, one of the multiple devices can only execute one or more steps of the method of the embodiment of the present application, and these multiple devices will interact with each other to complete the above method.

[0063] It should be noted that some embodiments of the present application have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the above embodiments and still achieve the desired results. Additionally, the processes depicted in the figures do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0064] Based on the same inventive concept, corresponding to the method of any of the above embodiments, the present application further provides a mutual exclusion verification system for multi-user operations of a database, as Figure 5 shown, including: A distributed lock component 10.

[0065] A cut-off surface component 20, configured to obtain the distributed lock state in response to a user operation; intercept the user operation in response to the distributed lock state being a locked state; or, in response to the distributed lock state being a released state, modify the distributed lock state to a locked state; in response to the user operation and the target user operation being verified as non-mutually exclusive, allow the user operation and modify the distributed lock state to a released state; or, in response to the user operation and the target user operation being verified as mutually exclusive, intercept the user operation and modify the distributed lock state to a released state.

[0066] A mutual exclusion verification component 30, configured to verify the user operation in response to the distributed lock state being a released state.

[0067] The system provided by the embodiments of the present disclosure can ensure the consistency and integrity of the database cluster under multi-user operation and maintenance operations and different operation and maintenance operations of the same user through the distributed lock and the mutual exclusion verification component, and realizes the effective management and control of the operation and maintenance operations.

[0068] In some embodiments, the mutual exclusion verification component 30 is specifically configured to: Verify the user name and operation type of the user operation; in response to the user name of the user operation being the same as the target user name and the operation type of the user operation being the same as the target operation type, determine that the user operation and the target user operation are verified as non-mutually exclusive; or, in response to the non-existence of the target user operation, determine that the user operation and the target user operation are verified as non-mutually exclusive; in response to the user name of the user operation being different from the target user name, and / or the operation type of the user operation being different from the target operation type, determine that the user operation and the target user operation are verified as mutually exclusive.

[0069] In some embodiments, the mutual exclusion verification system for multi-user operations of the database further includes: A database persistence component 40, configured to save the distributed lock state and the user operation.

[0070] In some embodiments, the mutual exclusion verification component 30 is specifically configured to: Encapsulate multiple different operation types through enumeration, and define multiple different policy interfaces, where different policy interfaces correspond to different verification logics; manage the policy interfaces through a container, and store the corresponding relationship between the enumeration of operation types and the verification logics in the container; create a context object for the policy interface; verify the operation type of the user operation, including: according to the operation type of the user operation, call the target verification logic in the container through the context object, and use the target verification logic to verify the operation type of the user operation.

[0071] In some embodiments, the above-mentioned aspect component 20 is further configured to: Create a custom annotation for the target operation object and the user operation; create a around advice, where the aspect component executes the around advice in response to the custom annotation.

[0072] In some embodiments, the above-mentioned around advice includes pre-invocation processing and post-invocation processing, where: the pre-invocation processing is used to modify the distributed lock state to the locked state and verify the user operation, and the post-invocation processing is used to modify the distributed lock state to the released state.

[0073] In some embodiments, the mutual exclusion verification system for multi-user operations of the database further includes: A user prompt information processing component 50, which is used to display an interception message to the user.

[0074] Figure 2 Shows the dependency relationships among the above-mentioned distributed lock component 10, database persistence component 40, mutual exclusion verification component 30, user prompt information processing component 50, and aspect component 20. Among them, the aspect component 20 depends on the other four components, and realizes the mutual exclusion verification function of the operation and maintenance operations by calling the interfaces or methods provided by the other four components; the mutual exclusion verification component 30 depends on the database persistence component 40 to obtain data support; the user prompt information processing component 50 generates corresponding prompt information according to the result of the mutual exclusion verification component 30 and displays it to the user.

[0075] For the convenience of description, when describing the above system, it is divided into various modules according to functions and described separately. Of course, when implementing the present application, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0076] The system of the above embodiment is used to implement the mutual exclusion verification method for multi-user operations of the database in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be elaborated here.

[0077] Figure 6 Shows a schematic structural diagram of an electronic device provided by an embodiment of the present disclosure.

[0078] As Figure 6 shown, the electronic device may include a processor 1101 and a memory 1102 storing computer program instructions.

[0079] Specifically, the above-mentioned processor 1101 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0080] The memory 1102 may include a mass storage for information or instructions. By way of example and not limitation, the memory 1102 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disc, a magneto-optical disc, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. In a suitable case, the memory 1102 may include removable or non-removable (or fixed) media. In a suitable case, the memory 1102 may be internal or external to the integrated gateway device. In a specific embodiment, the memory 1102 is a non-volatile solid-state memory. In a specific embodiment, the memory 1102 includes a read-only memory (ROM). In a suitable case, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically alterable ROM (EAROM), or a flash memory, or a combination of two or more of these.

[0081] The processor 1101 reads and executes the computer program instructions stored in the memory 1102 to perform the steps of the method for mutual exclusion verification of database multi-user operations provided by the embodiments of the present disclosure.

[0082] In one example, the electronic device may further include a transceiver 1103 and a bus 1104. Among them, as Figure 6 shown, the processor 1101, the memory 1102, and the transceiver 1103 are connected through the bus 1104 and complete communication with each other.

[0083] The bus 1104 includes hardware, software, or both. By way of example and not limitation, the bus can include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side BUS (FSB), a Hyper Transport (HT) interconnect, an Industrial Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a MicroChannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses or a combination of two or more of these. Where appropriate, the bus 1104 can include one or more buses. Although the embodiments of the present application describe and illustrate specific buses, the present application contemplates any suitable bus or interconnect.

[0084] The following are embodiments of a computer-readable storage medium provided by the embodiments of the present disclosure. The computer-readable storage medium and the mutual exclusion verification method for multi-user operation of the database in the above embodiments belong to the same inventive concept. Details not described in detail in the embodiments of the computer-readable storage medium can refer to the embodiments of the mutual exclusion verification method for multi-user operation of the database.

[0085] This embodiment provides a storage medium containing computer-executable instructions. The computer-executable instructions are used to execute a mutual exclusion verification method for multi-user operation of a database when executed by a computer processor.

[0086] Of course, for a storage medium containing computer-executable instructions provided by the embodiments of the present disclosure, the computer-executable instructions are not limited to the above method operations, and can also execute related operations in the mutual exclusion verification method for multi-user operation of the database provided by any embodiment of the present disclosure.

[0087] From the above description of the embodiments, those skilled in the art can clearly understand that the present disclosure can be implemented by means of software and necessary general hardware. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation method. Based on such an understanding, the technical solution of the present disclosure, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as a floppy disk, read-only memory (ROM), random access memory (RAM), flash memory (FLASH), hard disk, or optical disc of a computer, etc., including several instructions to enable a computer cloud platform (which can be a personal computer, server, or network cloud platform, etc.) to execute the mutual exclusion verification method for database multi-user operations provided by each embodiment of the present disclosure.

[0088] It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variation thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising one..." does not exclude the existence of another identical element in the process, method, article or device comprising the above element.

[0089] The above are only specific embodiments of the present disclosure, enabling those skilled in the art to understand or implement the present disclosure. Various modifications to these embodiments will be obvious to those skilled in the art. The general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure will not be limited to these embodiments described above, but will conform to the broadest scope consistent with the principles and novel features disclosed herein.

Claims

1. A mutual exclusion verification method for multi-user operations of a database, characterized in that, including: Upon receiving a user operation, obtain the status of the distributed lock; Upon the distributed lock status being the locked state, intercept the user operation using an aspect component; Alternatively, upon the distributed lock status being the released state, modify the distributed lock status to the locked state and verify the user operation; Upon the user operation and the target user operation being verified as non - mutually exclusive, allow the user operation and modify the distributed lock status to the released state; Alternatively, upon the user operation and the target user operation being verified as mutually exclusive, intercept the user operation using the aspect component and modify the distributed lock status to the released state.

2. The method according to claim 1, wherein The verifying of the user operation includes: Verify the user name and operation type of the user operation; The situation where the user operation and the target user operation are verified as non - mutually exclusive includes: Upon the user name of the user operation being the same as the target user name and the operation type of the user operation being the same as the target operation type, determine that the user operation and the target user operation are verified as non - mutually exclusive; or, upon the non - existence of the target user operation, determine that the user operation and the target user operation are verified as non - mutually exclusive; The situation where the user operation and the target user operation are verified as mutually exclusive includes: Upon the user name of the user operation being different from the target user name, and / or the operation type of the user operation being different from the target operation type, determine that the user operation and the target user operation are verified as mutually exclusive.

3. The method according to claim 1, wherein It also includes: Use a database persistence component to save the distributed lock status and the user operation.

4. The method according to claim 2, wherein Before verifying the operation type of the user operation, it also includes: Encapsulate multiple different operation types through enumeration and define multiple different policy interfaces, where different policy interfaces correspond to different verification logics; Manage the policy interfaces through a container and store the correspondence between the enumeration of the operation type and the verification logic in the container; Create a context object for the policy interface; Verifying the operation type of the user operation includes: According to the operation type of the user operation, call the target verification logic in the container through the context object and use the target verification logic to verify the operation type of the user operation.

5. The method according to claim 1, characterized in that, Before obtaining the distributed lock status upon receiving a user operation, it also includes: Create a custom annotation for the target operation object and the user operation; Create a around advice, where the aspect component executes the around advice in response to the custom annotation.

6. The method according to claim 5, characterized in that, The around advice includes pre - call processing and post - call processing, where: The pre - call processing is used to modify the distributed lock status to the locked state and verify the user operation, and the post - call processing is used to modify the distributed lock status to the released state.

7. The method according to claim 1, characterized in that, After intercepting the user operation using the aspect component, it also includes: Display the interception information to the user.

8. A mutual exclusion verification system for multi-user operations of a database, characterized in that, including: A distributed lock component; An aspect component for obtaining the distributed lock status in response to a user operation; Intercept the user operation in response to the distributed lock state being the locked state; or, in response to the distributed lock state being the released state, modify the distributed lock state to the locked state; In response to the user operation not being mutually exclusive with the target user operation verification, allow the user operation and modify the distributed lock state to the released state; Alternatively, in response to the user operation being mutually exclusive with the target user operation verification, intercept the user operation and modify the distributed lock state to the released state; A mutual exclusion verification component for verifying the user operation in response to the distributed lock state being the released state.

9. An electronic device, characterized in that, Comprising: A processor; A memory for storing executable instructions; wherein the processor is configured to read the executable instructions from the memory and execute the executable instructions to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The storage medium stores a computer program, which when executed by a processor causes the processor to implement the method according to any one of claims 1 to 7.

Images