A multi-database adaptive patrol method and system based on a strategy mode
By adopting a multi-database adaptive inspection method based on strategy patterns, the problems of high coupling and poor reusability in existing technologies are solved. This method achieves decoupling of database types and maximizes the reuse of logic, thereby improving the scalability and adaptability of the system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 广州海量数据库技术有限公司
- Filing Date
- 2026-05-09
- Publication Date
- 2026-07-31
AI Technical Summary
Existing multi-database inspection solutions suffer from high coupling, poor reusability, lack of abstraction, and inefficient adaptation, resulting in difficult system maintenance, limited scalability, and inability to achieve dynamic adaptation and policy switching.
A multi-database adaptive inspection method based on the strategy pattern is adopted. By combining the database type identification mechanism driven by enumeration with the strategy pattern, a database type enumeration system and an abstract hierarchy system of inspection executors are constructed to achieve decoupling between inspection logic and database type. The appropriate inspection strategy executor is dynamically selected through the strategy scheduler.
It achieves complete decoupling between inspection logic and database type, supports adding new databases without modifying existing code, maximizes the reuse of common logic, provides a unified database type identification standard, and improves the system's scalability and adaptation efficiency.
Smart Images
Figure CN122489380A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of database operation and maintenance management technology, specifically to a multi-database adaptive inspection method, system, and electronic equipment based on a strategy pattern. It is applicable to operation and maintenance management platforms that need to perform unified automated inspections of various heterogeneous databases (including but not limited to Vastbase G100, Vastbase V100, VexDB, and other domestic and open-source databases). Background Technology
[0002] With the rapid development of domestic databases, enterprise IT architectures are increasingly characterized by the coexistence of multiple heterogeneous databases. Due to significant differences in system table structure, SQL dialects, configuration parameters, and monitoring metrics among different database products, traditional database inspection solutions face severe challenges. Existing technologies typically employ a customized development model for specific databases, relying heavily on hard-coded conditional branching statements (such as if-else or switch-case) to differentiate between multiple databases. This approach results in extremely high system code coupling, poor scalability, and requires intrusive modifications to core logic when adding new database support, severely violating the "open / closed principle" of software engineering.
[0003] Specifically, existing multi-database inspection solutions have the following technical shortcomings:
[0004] 1. High coupling: The inspection business logic is strongly bound to the specific database type, which makes system maintenance difficult and limits scalability.
[0005] 2. Poor reusability: The inspection logic common to different databases lacks effective abstraction and refinement, resulting in code redundancy.
[0006] 3. Lack of abstraction: There is a lack of a unified process abstraction layer to address the differences in topology and operating mechanism between distributed and centralized databases.
[0007] 4. Inefficient adaptation: The lack of a standardized database type identification system makes it impossible for the inspection executor to achieve dynamic adaptation and strategy switching at runtime. Summary of the Invention
[0008] To overcome the aforementioned shortcomings of existing solutions, this application proposes a novel multi-database adaptive inspection method and system based on the strategy pattern. This invention combines an enumeration-driven database type identification mechanism with the strategy pattern to achieve complete decoupling between inspection logic and database type. It supports automatic selection of the corresponding inspection strategy executor based on the database type at runtime, while maximizing the reuse of common inspection logic through an abstract hierarchical system.
[0009] Specifically, this application provides the following technical solutions:
[0010] The first aspect of this application provides a multi-database adaptive inspection method based on a strategy pattern, such as... Figure 5 As shown, it includes the following steps:
[0011] S1. Construct a database type enumeration system: Define a database type enumeration, assign a unique identifier to each supported database type, and associate it with the driver class name, JDBC connection URL template, and display tag metadata of that database type;
[0012] S2. Construct an abstract hierarchy of inspection executors: Define the inspection runnable interface as the top-level abstraction, and derive the operating system-level abstract executor, the metric abstract executor, and the database-compatible family abstract executor in sequence. Each abstraction layer encapsulates the common inspection logic of all database types at that level.
[0013] S3. Implement specific database strategy executors: For each database type, inherit the corresponding abstract executor in the abstract hierarchy and rewrite the differentiated inspection method to form a strategy executor corresponding to each database type.
[0014] S4. Construct a policy scheduler: Receive an inspection context, which contains database connection information and an inspection task list. Extract database type enumeration values from the inspection context and match and instantiate the corresponding specific database policy executor according to the preset policy mapping relationship.
[0015] S5. Execute inspection tasks: The policy scheduler delegates inspection tasks to specific database policy executors. The specific database policy executors determine the set of inspection methods to be executed through annotation-driven automatic discovery mechanisms, and execute the inspection items one by one through reflection calls, collecting and returning the inspection results.
[0016] Furthermore, in the method of this application, the inspection executor abstract hierarchy in step S2 includes: an operating system-level abstract executor, a metric abstract executor, and a database-compatible family abstract executor; the operating system-level abstract executor encapsulates the common inspection logic at the operating system level, the metric abstract executor encapsulates the common inspection logic at the database running status metric level and inherits from the operating system-level abstract executor, and the database-compatible family abstract executor encapsulates the common inspection logic of the database-compatible family and inherits from the metric abstract executor.
[0017] Furthermore, in the method of this application, the operating system-level abstract executor encapsulates common inspection logic for disk monitoring, memory monitoring, and CPU monitoring; the metric abstract executor encapsulates common inspection logic for database operation information and cache hit rate; and the database compatibility family abstract executor encapsulates common inspection logic for version query, HBA configuration check, and replication status check.
[0018] Furthermore, in the method of this application, the database-compatible family abstract executor includes at least a PostgreSQL-compatible family abstract executor;
[0019] The specific database policy executor includes at least VastbaseG100Extractor and VastbaseIntgExtractor, wherein VastbaseIntgExtractor inherits from VastbaseG100Extractor, and VastbaseG100Extractor inherits from the PostgreSQL-compatible family abstract executor.
[0020] Furthermore, in the method of this application, the policy scheduler in step S4 uses an internal policy selection method and a switch-case structure to implement the mapping and matching between database types and policy executors. When the database type is VASTBASE_G100, VASTBASE_V100, VEXDB_EE, or VEXDB_DE, it returns a VastbaseG100Extractor instance; when the database type is VASTBASE_G100_INTG, it returns a VastbaseIntgExtractor instance.
[0021] Furthermore, in the method of this application, in step S4, when the database type is a distributed database type, the policy scheduler additionally instantiates an independent distributed inspection policy executor, which works in parallel with the centralized inspection policy executor to form a centralized and distributed dual-track inspection architecture.
[0022] Furthermore, in the method of this application, the same policy executor in the database type enumeration system can map to multiple database types. When multiple databases are compatible at the inspection interface level, they share the same policy executor implementation.
[0023] Furthermore, in the method of this application, the database types in the database type enumeration system include, but are not limited to: MySQL, Vastbase G100, Vastbase V100, Vastbase V5, VexDB Development Edition, VexDB Enterprise Edition, and openGauss.
[0024] The second aspect of this application provides a multi-database adaptive inspection system based on a strategy pattern, wherein the system implements the steps of the aforementioned multi-database adaptive inspection method based on a strategy pattern during operation, such as... Figure 6 As shown, it includes:
[0025] The database type enumeration module is used to define the database type enumeration, assign a unique identifier to each supported database type, and associate the driver class name, JDBC connection URL template, and display tag metadata of that database type.
[0026] The abstract executor layer module is used to define the inspection runnable interface as the top-level abstraction, and then derive the operating system-level abstract executor, the metric abstract executor and the database-compatible family abstract executor in sequence. Each abstraction layer encapsulates the common inspection logic of all database types at that level.
[0027] The specific executor module is used to inherit the corresponding abstract executor in the abstract hierarchy for each database type and rewrite the differentiated inspection method to form the strategy executor corresponding to each database type.
[0028] The policy scheduler module is used to receive the inspection context, which contains database connection information and a list of inspection tasks. It extracts the database type enumeration value from the inspection context and matches and instantiates the corresponding specific database policy executor according to the preset policy mapping relationship.
[0029] The inspection execution module is used to execute inspection tasks. The policy scheduler delegates the inspection tasks to specific database policy executors. The specific database policy executors determine the set of inspection methods to be executed through annotation-driven automatic discovery mechanism, and execute the inspection items one by one through reflection calls, collect and return the inspection results.
[0030] A third aspect of this application provides an electronic device, including: a memory and a processor;
[0031] Memory: Used to store computer programs;
[0032] Processor: Used to execute the computer program to implement the steps of the aforementioned policy pattern-based multi-database adaptive inspection method.
[0033] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the steps of the aforementioned policy-pattern-based multi-database adaptive inspection method.
[0034] In summary, compared with the prior art, the solution of the present invention has the following advantages:
[0035] (1) Complete decoupling of inspection logic and database type has been achieved. Adding database support only requires adding a new policy executor class and registering the mapping relationship in the scheduler, without modifying existing code, which conforms to the open / closed principle.
[0036] (2) Maximize the reuse of common logic through a multi-level abstract inheritance system. For example, all PostgreSQL-compatible databases (Vastbase G100, Vastbase V100, etc.) share common inspection methods in AbstractPostgresqlExtractor, only rewriting the differences.
[0037] (3) The database type enumeration system not only serves the inspection module, but can also be reused by other functional modules in the system (such as backup management, performance monitoring, etc.) to achieve global consistency in database type identification.
[0038] Other features and advantages of this application will be set forth in detail in the following description, or will become apparent through the implementation of the relevant technical solutions of this application. The objectives and other advantages of this application can be achieved through the technical features and means explicitly pointed out in the description, claims, and drawings, and will be obtained through the implementation of these technical contents. Attached Figure Description
[0039] To more clearly illustrate the technical solution of this application, the accompanying drawings involved in the description of this invention will be briefly introduced below. It should be noted that the drawings only show some embodiments of the invention. For those skilled in the art, other related drawings can be derived from these drawings without creative effort.
[0040] Figure 1 The flowchart is for the multi-database adaptive inspection method provided in the embodiments of the present invention.
[0041] Figure 2 An abstract hierarchical architecture diagram of the inspection actuator provided in an embodiment of the present invention.
[0042] Figure 3 This is a schematic diagram illustrating the working principle of the policy scheduler provided in an embodiment of the present invention.
[0043] Figure 4 This is a database type enumeration architecture diagram provided for embodiments of the present invention.
[0044] Figure 5 This diagram illustrates the implementation steps of the strategy-based multi-database adaptive inspection method of this application.
[0045] Figure 6 This is a structural diagram of the multi-database adaptive inspection system based on the strategy pattern in this application.
[0046] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0047] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be noted that the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.
[0048] In this document, the term "comprising" and any variations thereof (such as "including," "including," etc.) are open-ended expressions and should be understood as "including but not limited to," meaning that the listed content is not exhaustive and may include other content not explicitly mentioned. The term "based on" should be understood as "at least partially based on," meaning that the basis or condition referred to may not be the only factor and may involve other relevant factors. The term "one embodiment" should be understood as "at least one embodiment," meaning that the described embodiment is not the only possible implementation, and other similar embodiments may exist.
[0049] In this application, the terms "a" and "a plurality of" are used to modify related elements or features, and their expression is illustrative rather than restrictive. Unless otherwise expressly stated in the context, "a" should be understood as "at least one," and "a plurality of" should be understood as "at least two." Those skilled in the art should reasonably interpret these terms based on the semantic and logical relationships of the context to ensure that they cover the possibility of "one or more."
[0050] This invention provides a multi-database adaptive inspection method based on strategy patterns. Figure 1 The flowchart of the multi-database adaptive inspection method provided in this embodiment of the invention includes the following steps:
[0051] Step 1: Construct a database type enumeration system. Define a database type enumeration DbTypeEnum, assign a unique identifier to each supported database type, and associate it with metadata information such as the driver class name, JDBC connection URL template, and display label for that database type.
[0052] Step 2: Design the inspection executor abstract hierarchy. Define the inspection runnable interface InspectionRunnable as the top-level abstraction, and derive the operating system-level abstract executor AbstractOsExtractor, the metric abstract executor AbstractMetricExtractor, and the PostgreSQL-compatible family of abstract executors AbstractPostgresqlExtractor in sequence, forming a multi-level inheritance hierarchy. Each layer encapsulates the common inspection logic for all database types at that layer.
[0053] Step 3: Implement the specific database strategy executor. For each database type, inherit the corresponding abstraction layer and override the differentiated inspection methods. Specifically, VastbaseG100Extractor inherits from AbstractPostgresqlExtractor, and VastbaseIntgExtractor inherits from VastbaseG100Extractor.
[0054] Step 4: Construct the policy scheduler DelegatingRunnable. Receive the InspectionContext (containing database connection information and a list of inspection tasks), extract the database type enumeration value from the context, and use the policy selection method chooseExtractor() to match and instantiate the corresponding policy executor based on the database type enumeration value; for distributed database types, additionally instantiate a distributed inspection policy executor.
[0055] Step 5: Execute the inspection task. The policy scheduler delegates the inspection task to the selected policy executor. The policy executor determines the set of inspection methods to be executed through the annotation-driven automatic discovery mechanism, executes the inspection items one by one through reflection, and collects the inspection results.
[0056] To more clearly illustrate the technical solution of this application, the present invention will be further described in detail below through specific scenario embodiments.
[0057] Example 1: Implementation of a Policy Scheduler
[0058] Figure 3 This is a schematic diagram illustrating the working principle of the policy scheduler provided in an embodiment of the present invention.
[0059] The DelegatingRunnable policy scheduler is the core component for implementing adaptive multi-database inspection. Its constructor takes the InspectionContext as a parameter, retrieves the database type DbTypeEnum of the current inspection target from the context, and returns the corresponding inspection executor instance through the internal policy selection method chooseExtractor().
[0060] Specifically, the chooseExtractor() method uses a switch-case structure to implement strategy mapping: when the database type is VASTBASE_G100, VASTBASE_V100, VEXDB_EE, or VEXDB_DE, it returns a VastbaseG100Extractor instance; when the database type is VASTBASE_G100_INTG, it returns a VastbaseIntgExtractor instance.
[0061] Example 2: Implementation of the Abstract Hierarchy System
[0062] Figure 2 An abstract hierarchical architecture diagram of the inspection actuator provided in an embodiment of the present invention.
[0063] The inspection executor abstraction hierarchy is as follows: InspectionRunnable (top-level abstraction) → AbstractOsExtractor (operating system-level inspection: disk monitoring, memory monitoring, CPU monitoring, etc.) → AbstractMetricExtractor (metric-level inspection: database operation information, cache hit rate, etc., inheriting from AbstractOsExtractor) → AbstractPostgresqlExtractor (PostgreSQL-compatible family inspection: version query, HBA configuration check, replication status check, etc., inheriting from AbstractMetricExtractor).
[0064] Each specific strategy executor, based on the abstraction layer, implements database-specific inspection logic by overriding parent class methods. For example, VastbaseG100Extractor overrides the getVersionSql() method to return "select vb_version()" to obtain Vastbase-specific version information, while the default implementation in AbstractPostgresqlExtractor returns "select version()".
[0065] Example 3: Definition of Database Type Enumeration
[0066] Figure 4 This is a database type enumeration architecture diagram provided for embodiments of the present invention.
[0067] The `DbTypeEnum` enumeration defines all database type identifiers supported by the system. Each enumeration value carries four metadata items: type code, display label, fully qualified JDBC driver class name, and JDBC connection URL template. This enumeration includes, but is not limited to, the following values: `MYSQL` (MySQL database), `VASTBASE_G100` (VASTBASE database G100), `VASTBASE_V100` (VASTBASE database V100), `VASTBASE_V5` (VASTBASE database V5), `VEXDB_DE` (VexDB development version), `VEXDB_EE` (VexDB enterprise version), `OPENGAUSS` (openGauss open-source database), etc.
[0068] This enumeration system provides a unified database type identification standard for the entire operation and maintenance platform, ensuring that all functional modules such as inspection, backup, and monitoring identify the same database type consistently.
[0069] The flowcharts and block diagrams in the accompanying drawings illustrate possible implementations of systems, methods, and computer program products according to various embodiments of this application, including architecture, functionality, and operation. In these figures, each block may represent a module, program segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should be noted that each block in the block diagrams and / or flowcharts, and combinations thereof, can be implemented using either a dedicated hardware-based system or a combination of dedicated hardware and computer instructions to achieve the specified function or operation.
[0070] like Figure 7 As shown, embodiments of this application also disclose an electronic device, including: a processor 310, a communication interface 320, a memory 330 for storing a processor-executable computer program, and a communication bus 340. The processor 310, communication interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 executes the executable computer program to implement the steps of the aforementioned policy-pattern-based multi-database adaptive inspection method.
[0071] It is understood that, in addition to memory and a processor, this electronic device may also include input devices (such as a keyboard), output devices (such as a display), and other communication modules. These input devices, output devices, and other communication modules all communicate with the processor through I / O interfaces (i.e., input / output interfaces).
[0072] The operations described in this application can be implemented by writing computer program code using one or more programming languages or a combination thereof. The programming languages include, but are not limited to, the following types:
[0073] Object-oriented programming languages, such as Java, Smalltalk, C++, etc.
[0074] Conventional procedural programming languages, such as "C" or similar programming languages.
[0075] The execution methods of program code include, but are not limited to:
[0076] It runs entirely on the user's computer;
[0077] Part of it executes on the user's computer, and part of it executes on a remote computer;
[0078] Execute as a standalone software package;
[0079] It is executed entirely on a remote computer or server.
[0080] In scenarios involving remote computers, the remote computer can connect to the user's computer via any type of network, including but not limited to local area networks (LANs) or wide area networks (WANs). Furthermore, the remote computer can also connect to external computers through an internet service provider, for example, by utilizing the internet for connection.
[0081] Furthermore, this application also discloses a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the various steps of the policy pattern-based multi-database adaptive inspection method disclosed in this application.
[0082] In the context of this application, a computer-readable storage medium refers to a tangible medium capable of storing computer program code and related data. Specific examples include, but are not limited to, the following:
[0083] (1) Portable computer disk: such as floppy disks and other removable magnetic storage media.
[0084] (2) Hard disk: including mechanical hard disks and solid-state hard disks and other fixed storage devices.
[0085] (3) Random Access Memory (RAM): A volatile storage medium used for temporary storage of data and program code.
[0086] (4) Read-only memory (ROM): a non-volatile storage medium used to store fixed programs and data.
[0087] (5) Erasable programmable read-only memory (EPROM) or flash memory: non-volatile storage media that supports multiple erasures and reprogrammings.
[0088] (6) Fiber optic storage devices: storage media based on fiber optic technology.
[0089] (7) Portable compact disc read-only memory (CD-ROM): a read-only medium that stores data in the form of an optical disc.
[0090] (8) Optical storage devices: such as DVDs, Blu-ray discs and other storage media based on optical principles.
[0091] (9) Magnetic storage devices: such as magnetic tapes, disks and other storage media based on magnetic principles.
[0092] (10) Any suitable combination of the above: for example, combining multiple storage media to meet different storage needs.
[0093] These computer-readable storage media can be used to store the program code and related data described in this application to support program execution and persistent data storage.
[0094] Specifically, according to embodiments of this application, the processes described in the flowcharts can be implemented as computer software programs. For example, embodiments of this application relate to a computer program product comprising a computer program carried on a non-transitory computer-readable medium. This computer program contains program code for executing the policy pattern-based multi-database adaptive inspection method disclosed in this application. When this computer program is executed by a processing system, it can achieve the functions defined in the embodiments of this application.
[0095] While the foregoing discussion contains several specific implementation details, these details should not be construed as limiting the scope of this application. The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this application is not limited to technical solutions formed by specific combinations of the above-described technical features. Furthermore, this application should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the foregoing disclosed concept.
[0096] Those skilled in the art should also understand that modifications can be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features, without departing from the spirit and scope of the technical solutions of the embodiments of this application. These modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the core spirit and scope of the technical solutions of the embodiments of this application.
Claims
1. A multi-database adaptive inspection method based on strategy patterns, characterized in that, Includes the following steps: S1. Construct a database type enumeration system: Define a database type enumeration, assign a unique identifier to each supported database type, and associate it with the driver class name, JDBC connection URL template, and display tag metadata of that database type; S2. Construct an abstract hierarchy of inspection executors: Define the inspection runnable interface as the top-level abstraction, and derive the operating system-level abstract executor, the metric abstract executor, and the database-compatible family abstract executor in sequence. Each abstraction layer encapsulates the common inspection logic of all database types at that level. S3. Implement specific database strategy executors: For each database type, inherit the corresponding abstract executor in the abstract hierarchy and rewrite the differentiated inspection method to form a strategy executor corresponding to each database type. S4. Construct a policy scheduler: Receive an inspection context, which contains database connection information and an inspection task list. Extract database type enumeration values from the inspection context and match and instantiate the corresponding specific database policy executor according to the preset policy mapping relationship. S5. Execute inspection tasks: The policy scheduler delegates inspection tasks to specific database policy executors. The specific database policy executors determine the set of inspection methods to be executed through annotation-driven automatic discovery mechanisms, and execute the inspection items one by one through reflection calls, collecting and returning the inspection results.
2. The method according to claim 1, characterized in that, The inspection executor abstract hierarchy in step S2 includes: an operating system-level abstract executor, a metric abstract executor, and a database-compatible family abstract executor. The operating system-level abstract executor encapsulates the common inspection logic at the operating system level. The metric abstract executor encapsulates the common inspection logic at the database running status metric level and inherits from the operating system-level abstract executor. The database-compatible family abstract executor encapsulates the common inspection logic of the database-compatible family and inherits from the metric abstract executor.
3. The method according to claim 2, characterized in that, The operating system-level abstract executor encapsulates the common inspection logic for disk monitoring, memory monitoring, and CPU monitoring; The abstract executor of the metric encapsulates the common inspection logic of database operation information and cache hit rate; The database-compatible family abstract executor encapsulates common inspection logic for version query, HBA configuration check, and replication status check.
4. The method according to claim 2, characterized in that, The database-compatible family abstract executor includes at least the PostgreSQL-compatible family abstract executor; The specific database policy executor includes at least VastbaseG100Extractor and VastbaseIntgExtractor, wherein VastbaseIntgExtractor inherits from VastbaseG100Extractor, and VastbaseG100Extractor inherits from the PostgreSQL-compatible family abstract executor.
5. The method according to claim 1, characterized in that, In step S4, the policy scheduler uses an internal policy selection method and a switch-case structure to map and match database types with policy executors. When the database type is VASTBASE_G100, VASTBASE_V100, VEXDB_EE, or VEXDB_DE, it returns a VastbaseG100Extractor instance; when the database type is VASTBASE_G100_INTG, it returns a VastbaseIntgExtractor instance.
6. The method according to claim 1, characterized in that, In step S4, when the database type is a distributed database type, the policy scheduler additionally instantiates an independent distributed inspection policy executor, which works in parallel with the centralized inspection policy executor to form a dual-track inspection architecture of centralized and distributed systems.
7. The method according to claim 1, characterized in that, The same policy executor in the database type enumeration system can map to multiple database types. When multiple databases are compatible at the inspection interface level, they share the same policy executor implementation.
8. The method according to claim 1, characterized in that, The database types in the database type enumeration system include: MySQL, Vastbase G100, Vastbase V100, Vastbase V5, VexDB Developer Edition, VexDB Enterprise Edition, and openGauss.
9. A multi-database adaptive inspection system based on a strategy pattern, characterized in that, The system implements the steps of the method as described in any one of claims 1-8 during runtime, including: The database type enumeration module is used to define the database type enumeration, assign a unique identifier to each supported database type, and associate the driver class name, JDBC connection URL template, and display tag metadata of that database type. The abstract executor layer module is used to define the inspection runnable interface as the top-level abstraction, and then derive the operating system-level abstract executor, the metric abstract executor and the database-compatible family abstract executor in sequence. Each abstraction layer encapsulates the common inspection logic of all database types at that level. The specific executor module is used to inherit the corresponding abstract executor in the abstract hierarchy for each database type and rewrite the differentiated inspection method to form the strategy executor corresponding to each database type. The policy scheduler module is used to receive the inspection context, which contains database connection information and a list of inspection tasks. It extracts the database type enumeration value from the inspection context and matches and instantiates the corresponding specific database policy executor according to the preset policy mapping relationship. The inspection execution module is used to execute inspection tasks. The policy scheduler delegates the inspection tasks to specific database policy executors. The specific database policy executors determine the set of inspection methods to be executed through annotation-driven automatic discovery mechanism, and execute the inspection items one by one through reflection calls, collect and return the inspection results.
10. An electronic device, characterized in that, include: Memory and processor; Memory: Used to store computer programs; Processor: for executing the computer program to implement the steps of the policy pattern-based multi-database adaptive inspection method as described in any one of claims 1-8.