Dynamic multi-data source switching assembly and implementation method thereof

Abstract

The invention provides a dynamic multi-data source switching component and an implementation method thereof. Belongs to the technical field of data processing. The method comprises the steps of defining information of a plurality of data sources in a configuration file of an application program; the method comprises the following steps: when an application is started, reading data source information in a configuration file, and instantiating a plurality of DataSource objects; the DataSource object is stored in a Map (Map) set, and the DataSource object is stored in the Map set; and defining a Thread Local variable, and storing the name of the data source bound with the current thread through the Thread Local variable. By means of the dynamic multi-data-source switching method, the data sources can be flexibly switched according to service requirements, dynamic updating according to configuration during application running is supported, and the adaptive capacity of a system is enhanced.

Description

Technical Field

[0001] The invention proposes a dynamic multi-data source switching component and an implementation method thereof, belonging to the technical field of data processing. Background Art

[0002] In the existing technology, the configuration and management of multiple data sources usually requires a lot of work, and when adding or modifying data sources, the server often needs to be restarted, which has a certain impact on business continuity. At the same time, the existing multi-data source integration method does not solve the problem of thread isolation during the integration process, resulting in low efficiency in switching multiple data sources and easily causing thread safety issues. Summary of the invention

[0003] The present invention provides a dynamic multi-data source switching component and an implementation method thereof, to solve the problems mentioned in the above background technology: The present invention proposes a method for implementing dynamic multi-data source switching, the method comprising: S1. Define the information of multiple data sources in the configuration file of the application; S2. When the application starts, the data source information in the configuration file is read, and multiple DataSource objects are instantiated; and the DataSource objects are stored in a Map collection; S3. Define a ThreadLocal variable, and store the data source name bound to the current thread through the ThreadLocal variable; S4. In the AOP aspect, intercept the business method that uses the switch data source annotation; switch to the specified data source before the method is executed, and switch back to the default data source after the method is executed; S5. Configure the transaction manager in the Spring framework to ensure the consistency and integrity of transactions during the switching of multiple data sources.

[0004] Furthermore, the S1 includes: S11. Create a dedicated configuration file to centrally manage the configuration of all data sources through the configuration file; in the configuration file, define the independent configuration items of each data source; S12, grouping data sources according to business logic and setting a priority for each data source. If a data source fails, it will automatically switch to an alternative data source; S13. Based on the dynamic loading mechanism of the configuration file, the data source configuration is updated through external commands or APIs without restarting the application.

[0005] Furthermore, the S2 includes: S21. When the application starts, the data source information in the configuration file is read through the @PropertySource or @ConfigurationProperties annotation of the Spring framework; S22. Use Java reflection or Spring's BeanUtils tool class to dynamically create DataSource objects based on configuration information; S23. Create a global Map based on a thread-safe collection<String,DataSource> A collection where the key is the data source name and the value is the corresponding DataSource object; S24. Perform a health check on each instantiated DataSource object, including a connection test, SQL execution, and efficiency test. If the data source check fails, a log is recorded and an attempt is made to use an alternative data source or an alarm is triggered.

[0006] Furthermore, the S3 includes: S31. Define a global ThreadLocal <string>Variables, via ThreadLocal <string>The variable stores the name of the data source bound to the current thread; S32. Set the data source name of the current thread through the static method setCurrentDataSource(Stringname); and obtain the data source name of the current thread through getCurrentDataSource(); S33, and in the business logic involving switching of multiple data sources, the setCurrentDataSource method is called through AOP or manually.

[0007] Furthermore, the S4 includes: S41. Customize the @DataSourceSwitch annotation, type attribute, and a fallback attribute. In the AOP aspect class, parse the @DataSourceSwitch annotation on the method through the reflection mechanism to obtain relevant information. S42. Configure an aspect class through the SpringAOP framework, and intercept all methods annotated with @DataSourceSwitch through interception logic; the interception logic includes pre-notification and post-notification; S43. In the AOP aspect, use the try-catch block to capture all possible exceptions, record detailed error information, and execute the corresponding fallback strategy according to the configuration.

[0008] Furthermore, the pre-notification is implemented by the following method: Check whether the ThreadLocal variable has been bound to the data source name. If it has been bound, record the current data source as the data source before switching; According to the @DataSourceSwitch annotation on the method, obtain the corresponding information, which includes the target data source name, switch type, and fallback data source; Search the target data source in the global DataSourceMap collection. If it does not exist, search for the fallback data source according to the fallback property. If the fallback data source does not exist, record the error log and decide whether to throw an exception or continue execution according to the configuration. Before switching, perform a health check on the target data source. If the check fails, use the fallback data source or record the error log and execute the fallback strategy; If all the above checks pass, the ThreadLocal variable is set to the target data source name.

[0009] Furthermore, the post notification is implemented by the following method: Regardless of whether the method is executed successfully, after the method is executed, the ThreadLocal variable is restored to the data source name before the switch, or set to the default data source; If an exception is thrown during the execution of the method, the exception is captured and logged. At the same time, it is decided whether to roll back the transaction and switch to the fallback data source based on the configuration.

[0010] Furthermore, the S5 includes: S51. In the Spring configuration, define an independent DataSourceTransactionManager for each data source and register it in the Spring transaction manager list; S52. Configure different transaction propagation behaviors and isolation levels for different data sources based on business requirements; S53. In the AOP aspect, the propagation behavior and isolation level of the current transaction are dynamically set according to the method annotation or configuration; S54. For transactions across multiple physical databases, data consistency is guaranteed through a distributed transaction solution; and automatic recovery is performed when a distributed transaction fails through a rollback log record and recovery mechanism.

[0011] Furthermore, the S53 includes: Define the @TransactionalConfig annotation. In the AOP aspect class, parse the @TransactionalConfig annotation on the method through the reflection mechanism to obtain the transaction propagation behavior and isolation level information. In the Spring configuration, define a separate DataSourceTransactionManager for each data source and register them with Spring's transaction manager list; In the AOP aspect, dynamically select the corresponding data source and transaction manager based on the @TransactionalConfig annotation on the method or the global configuration; Extract the transaction propagation behavior and isolation level information from the @TransactionalConfig annotation; apply the level information to the transaction environment of the current thread; control the opening and commit / rollback of transactions through AOP pre-notification and post-notification before and after method execution; When a method is called by another method annotated with @TransactionalConfig, if there is a nested transaction, it has a deep understanding of the transaction propagation behavior and decides whether to create a new transaction, join an existing transaction, or ignore the transaction based on the propagation behavior; Make corresponding logical choices based on the propagation behavior specified in the annotation; Apply the isolation level specified in the annotation to the current transaction; If the method involves transaction operations across multiple physical databases, SpringCloudSleuth combined with Seata is used to identify and handle distributed transactions; In a distributed transaction, if an operation fails, the status and result of each operation is recorded through the rollback log recording mechanism; if the transaction fails, the system status is restored according to the rollback log; When a distributed transaction fails, the failed operation is re-executed or rolled back to a previous consistent state through an automatic recovery mechanism.

[0012] The present invention provides a dynamic multi-data source switching component, on which a computer program is stored. The program is executed by a processor to implement any of the above-mentioned dynamic multi-data source switching implementation methods.

[0013] Beneficial effects of the present invention: The dynamic multi-data source switching method of the present invention can flexibly switch data sources according to business needs, support dynamic updates according to configurations when applications are running, and enhance the adaptability of the system; by configuring the priority and backup mechanism of the data source, the system can automatically switch to the backup data source when the main data source fails, ensuring the high availability and stability of the system; in the process of switching multiple data sources, the transaction manager is used to ensure the consistency and integrity of the transaction. Through the distributed transaction solution, the consistency of operations across multiple physical databases is ensured, and the problem of data inconsistency is avoided; the health check of the data source can timely discover and handle data source failures, record logs and take appropriate rollback measures, and enhance the monitoring and maintenance capabilities of the system; through the execution of the AOP aspect interception method, combined with exception capture and rollback strategies, the system can gracefully recover when an error occurs, ensuring the smooth execution of business logic; through custom annotations and AOP technology, developers can easily implement the switching of data sources in business logic without repeated coding, improving development efficiency; all data source configurations are concentrated in one file, which is easy to manage and maintain, reducing the complexity and error probability caused by scattered configuration; through efficient thread-safe collection storage of data sources, resource competition in a multi-threaded environment is reduced, and system performance and response speed are improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 This is a step diagram of the method described in the present invention. DETAILED DESCRIPTION

[0015] The preferred embodiments of the present invention are described below in conjunction with the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.

[0016] One embodiment of the present invention, as Figure 1 As shown, a method for implementing dynamic multi-data source switching includes: S1. Define the information of multiple data sources in the configuration file of the application; S2. When the application starts, the data source information in the configuration file is read and multiple DataSource objects are instantiated; and the DataSource objects are stored in a Map collection; the key is the name of the data source and the value is the DataSource object; S3. Define a ThreadLocal variable, and store the data source name bound to the current thread through the ThreadLocal variable; S4. In the AOP aspect, intercept the business method that uses the switch data source annotation; switch to the specified data source before the method is executed, and switch back to the default data source after the method is executed; S5. Configure the transaction manager in the Spring framework to ensure the consistency and integrity of transactions during the switching of multiple data sources.

[0017] The working principle of the above technical solution is as follows: in the configuration file of the application (such as application.properties or application.yml), all the data source information to be used is listed in detail, and the data source information includes the name of the data source, the URL of the database connection, the user name and password for authentication. When the application starts, the program reads the data source information in the configuration file. According to the information read, multiple DataSource objects are instantiated, and the objects represent different database connections. The DataSource objects are stored in a Map collection, where the key is the name of the data source and the value is the corresponding DataSource object. In this way, the application can find and use a specific database connection by the data source name. Define a ThreadLocal variable to store the data source name bound to the current thread. The ThreadLocal variable provides an independent storage space for each thread to ensure that the data source switching between threads does not interfere with each other. In the AOP aspect, define the logic for intercepting the business method that uses the switching data source annotation (such as @DataSourceSwitch). When the method is called, the AOP aspect first checks whether there is an annotation for switching the data source on the method, and reads the data source name specified in the annotation. Then, the AOP aspect switches the data source of the current thread to the specified data source through the ThreadLocal variable. After the method is executed, the AOP aspect switches the data source of the current thread back to the default data source to ensure that subsequent operations are not affected. In the Spring framework, an independent transaction manager (DataSourceTransactionManager) is configured for each data source. The transaction manager is responsible for opening, committing, or rolling back transactions during the data source switching process. When the business method is executed, the Spring framework will select the corresponding transaction manager to handle the transaction based on the data source name bound to the current thread. If an exception occurs during the method execution, the transaction manager will roll back the transaction to ensure data consistency.

[0018] The effect of the above technical solution is: by defining the information of multiple data sources in the configuration file, the application can easily add, delete or modify the data source without modifying the code, so that when the application needs to access a new database, it only needs to update the configuration file, which greatly improves flexibility and scalability. The ThreadLocal variable is used to store the data source name bound to the current thread, so that the thread-level isolation of the data source is realized. Each thread can have its own data source context without interfering with each other, thereby avoiding the problem of data source conflict in a multi-threaded environment. Combined with AOP aspect technology, the data source can be dynamically switched before and after the execution of the business method, so that the application can flexibly access different databases according to business needs, such as read-write separation, sub-library and sub-table scenarios. In the Spring framework, an independent transaction manager is configured for each data source to ensure the consistency and integrity of transactions during the switching of multiple data sources. Even when switching between different data sources, the transaction manager can correctly manage the opening, submission and rollback of transactions, thereby ensuring data consistency. Through configuration and AOP aspect technology, the logic of data source switching is separated from the business code, which simplifies the code structure, improves the readability and maintainability of the code, and reduces the risk of problems caused by errors in data source switching logic. Dynamic multi-data source switching technology can select the optimal data source for access according to business needs, such as distributing read operations to multiple slave libraries, thereby improving system performance and throughput. At the same time, by reducing unnecessary database connection and closing operations, it can further reduce database resource consumption and response time.

[0019] In an embodiment of the present invention, storing the data source name of the current thread through ThreadLocal is implemented by the following pseudo code: public class DataSourceContext { / / Create a ThreadLocal variable to store the data source name private static ThreadLocal <string>dataSourceName = newThreadLocal<>(); / / Set the data source name of the current thread public static void setDataSourceName(String name) { dataSourceName.set(name); } / / Get the data source name of the current thread public static String getDataSourceName() { return dataSourceName.get(); } / / Clear the data source name of the current thread public static void clear() { dataSourceName.remove(); } } / / Example usage public class ThreadLocalExample { public static void main(String[] args) { Runnable task = () -> { / / Set the data source name for the current thread String dataSource = Thread.currentThread().getName().equals("Thread-0") ? "DataSource1" : "DataSource2"; DataSourceContext.setDataSourceName(dataSource); / / Get and print the data source name of the current thread System.out.println(Thread.currentThread().getName() + "is using " + DataSourceContext.getDataSourceName()); / / Perform data source related operations here... / / Clean up ThreadLocal variables DataSourceContext.clear(); }; Thread thread1 = new Thread(task); Thread thread2 = new Thread(task); thread1.start(); thread2.start(); } } In one embodiment of the present invention, the S1 includes: S11. Create a dedicated configuration file to centrally manage the configuration of all data sources through the configuration file; in the configuration file, define the independent configuration items of each data source. S12, grouping data sources according to business logic and setting a priority for each data source. If a data source fails, it will automatically switch to an alternative data source; S13. Based on the dynamic loading mechanism of the configuration file, the data source configuration is updated through external commands or APIs without restarting the application.

[0020] The working principle of the above technical solution is as follows: create a dedicated configuration file, such as application-datasources.yml or application-datasources.properties, to centrally manage the configuration of all data sources. In the configuration file, define independent configuration items for each data source, including name, connection URL, database username, password, driver class name, maximum number of connections (max-active), initial number of connections (initial-size), etc. According to the business logic, group the data sources, such as read-write separation group, read-write balancing group, etc. The data sources in each group are configured and allocated according to business needs. Set a priority for each data source. When the main data source fails, it automatically switches to the alternative data source to ensure business continuity and data integrity. The priority setting can be comprehensively considered based on factors such as the performance, stability, and load of the data source. When the application starts, it will load and parse the application-datasources.yml or application-datasources.properties configuration file, instantiate the data source object, and store it in memory. When you need to update the data source configuration, you can send a request to the application through an external command or API to trigger the dynamic loading mechanism of the configuration file. After receiving the request, the application will reload the configuration file, update the data source configuration, and re-instantiate the data source object.

[0021] The effect of the above technical solution is: by creating a dedicated configuration file (such as application-datasources.yml or application-datasources.properties), centralized management of all data source configurations is achieved. The centralized management method simplifies the complexity of configuration, making it easier and more intuitive to maintain and update data source configurations. The data source configuration items in the configuration file can be easily added, deleted or modified without modifying the code, which improves the flexibility and scalability of the system. When a new data source needs to be added, it is only necessary to add the corresponding configuration items in the configuration file without making major modifications to the application. Grouping data sources according to business logic (such as read-write separation groups, read-write balancing groups, etc.) makes the selection of data sources more in line with business needs and improves the efficiency and stability of data access. Setting a priority for each data source and automatically switching to an alternative data source when a data source fails ensures business continuity and data integrity. Based on the dynamic loading mechanism of the configuration file, the data source configuration can be updated through external commands or APIs without restarting the application, reducing the risk of downtime caused by configuration updates and improving the availability and maintainability of the system. Database connection information (such as user names, passwords, etc.) is centrally stored in the configuration file, and sensitive information can be protected by encryption and other methods, thereby improving the security of the system. At the same time, centralized configuration management also facilitates compliance checks and audits to ensure that the system meets relevant security standards and regulatory requirements. Centrally managed configuration files make monitoring and troubleshooting easier. Administrators can quickly understand the system's data source configuration by viewing the configuration files, and quickly locate the problem when a failure occurs. Configuration files can be configured differently for different environments (such as development, testing, production, etc.), allowing the system to easily adapt to different deployment environments. This helps ensure the stability and consistency of the system in different environments.

[0022] In one embodiment of the present invention, the S2 includes: S21. When the application starts, the data source information in the configuration file is read through the @PropertySource or @ConfigurationProperties annotation of the Spring framework; S22. Use Java reflection or Spring's BeanUtils tool class to dynamically create DataSource objects based on configuration information; S23. Create a global Map based on a thread-safe collection<String,DataSource> A collection where the key is the data source name and the value is the corresponding DataSource object; S24. Perform a health check on each instantiated DataSource object, including a connection test, SQL execution, and efficiency test. If the data source check fails, a log is recorded and an attempt is made to use an alternative data source or an alarm is triggered.

[0023] The working principle of the above technical solution is: when the application starts, the Spring framework will automatically scan and load the specified configuration file. Through the @PropertySource or @ConfigurationProperties annotation, Spring can read the data source information defined in the configuration file.

[0024] The @PropertySource annotation is used to load configuration files such as .properties or .yml, and inject configuration values ​​into Spring-managed beans through the @Value annotation.

[0025] The @ConfigurationProperties annotation provides a more structured way to read properties in the configuration file. It can bind the configuration properties to a Java object, making the configuration information clearer and easier to manage.

[0026] After reading the data source information in the configuration file, the application needs to use this information to dynamically create a DataSource object. This is achieved through Java reflection or Spring's BeanUtils tool class. Java reflection allows the program to dynamically obtain class information and create class instances at runtime. Through reflection, DataSource objects can be instantiated based on properties such as the class name and driver class name in the configuration information. Spring's BeanUtils tool class provides a simpler and more convenient way to create and initialize beans. It can automatically create DataSource objects based on configuration information and set their properties. To ensure that the data source can be easily accessed and managed throughout the application, a global Map can be created based on a thread-safe collection (such as ConcurrentHashMap).<String,DataSource> In this collection, the key is the data source name (usually a unique identifier defined in the configuration file), and the value is the corresponding DataSource object. In this way, you can get the corresponding DataSource object by the data source name anywhere in the application to perform database operations. Performing health checks on each instantiated DataSource object is an important step to ensure the stability and reliability of database connections. Health checks include the following aspects: Connection testing: Verify that you can successfully connect to the database. This typically involves attempting to establish a connection to the database and checking whether the connection is successful.

[0027] SQL Execution: Execute a simple SQL query (such as SELECT1) to verify that the database is responsive. This can check whether the database can process SQL statements normally.

[0028] Efficiency testing: Measures the response time of query execution and other performance indicators to evaluate the performance status of the database.

[0029] If the data source check fails, logs are recorded and an attempt is made to use an alternate data source or an alarm is triggered. When the primary data source is unavailable, the application can automatically switch to the alternate data source to ensure business continuity. At the same time, by recording logs and triggering alarms, administrators can understand the status of the data source in a timely manner and take appropriate measures to solve the problem.

[0030] The effect of the above technical solution is: through the @PropertySource or @ConfigurationProperties annotation of the Spring framework, the data source information in the configuration file can be easily read, making the data source configuration more flexible and extensible. When a new data source needs to be added, you only need to add the corresponding configuration items to the configuration file, and you can dynamically load and use the new data source without making major modifications to the application. Using Java reflection or Spring's BeanUtils tool class, you can dynamically create DataSource objects based on the configuration information, avoiding hard-coded data source information and improving the maintainability and readability of the code. By creating a global Map<String,DataSource> The collection realizes unified management and access of data sources, making it more convenient and efficient to switch and select data sources in applications. Performing health checks on each instantiated DataSource object, including connection tests, SQL execution, and efficiency tests, can timely discover and handle data source failures, improving the stability and reliability of the system. If the data source check fails, the log is recorded and an attempt is made to use an alternative data source or trigger an alarm, which helps administrators to understand and solve data source problems in a timely manner, reducing the risk of business interruption caused by data source failures. Using thread-safe collections (such as ConcurrentHashMap) to store data source objects ensures the thread safety of data source access in a high-concurrency environment and avoids problems caused by data competition. Storing data source configuration information in the configuration file realizes the separation of configuration and code, making the configuration information clearer and easier to manage. This also facilitates switching and sharing of configuration information between different environments (such as development, testing, production, etc.), improving development efficiency and deployment flexibility. Through the unified data source management and access interface, advanced functions such as read-write separation and load balancing can be easily implemented, improving the performance and scalability of the system.

[0031] One embodiment of the present invention creates a global Map based on a thread-safe collection<String,DataSource> The collection is implemented by the following pseudo code: import java.util.concurrent.ConcurrentHashMap; import javax.sql.DataSource; public class DataSourceRegistry { / / Create a thread-safe global Map private static final ConcurrentHashMap<String, DataSource> dataSourceMap = new ConcurrentHashMap<>(); / / Add data source public static void registerDataSource(String name, DataSourcedataSource) { dataSourceMap.put(name, dataSource); } / / Get the data source public static DataSource getDataSource(String name) { return dataSourceMap.get(name); } / / Remove the data source public static DataSource removeDataSource(String name) { return dataSourceMap.remove(name); } } In one embodiment of the present invention, S3 includes: S31. Define a global ThreadLocal <string>Variables, via ThreadLocal <string>The variable stores the name of the data source bound to the current thread; S32. Set the data source name of the current thread through the static method setCurrentDataSource(Stringname); and obtain the data source name of the current thread through getCurrentDataSource(); S33, and in the business logic involving switching of multiple data sources, the setCurrentDataSource method is called through AOP or manually.

[0032] The working principle of the above technical solution is: first, define a global ThreadLocal <string>Variable. ThreadLocal is a thread local variable class provided in Java, which can provide an independent copy of the variable for each thread that uses the variable, thereby ensuring that each thread can independently change its own copy without affecting the copies of other threads. In this scenario, ThreadLocal <string>The variable is used to store the data source name bound to the current thread. Due to the isolation of ThreadLocal, each thread can have its own independent data source name without conflicting with other threads. Next, two static methods setCurrentDataSource(Stringname) and getCurrentDataSource() are used to set and get the data source name of the current thread respectively; setCurrentDataSource(Stringname) accepts a string parameter name, which represents the name of the data source. It will set this name to the ThreadLocal of the current thread. <string>The getCurrentDataSource() method does not accept any parameters, it returns the ThreadLocal of the current thread. <string>The data source name stored in the variable. If the current thread does not set the data source name, it may return null or throw an exception (the specific behavior depends on the implementation). In business logic involving multiple data source switching, dynamic switching of data sources can be achieved through AOP (aspect-oriented programming) or manually calling the setCurrentDataSource method. Define an aspect class and write a pointcut and an advice in the class. The pointcut is used to match the method that needs to switch the data source, while the advice is used to switch the data source before and after the method is executed. Specifically, the target data source can be set by the setCurrentDataSource method before the method is executed, and then switch back to the original data source after the method is executed (if necessary). At the code location where the data source needs to be switched, directly call the setCurrentDataSource method to set the target data source. This method requires developers to explicitly switch data sources when writing business logic, so it is relatively cumbersome, but more flexible.

[0033] The effect of the above technical solution is: by using ThreadLocal <string>The variable is used to store the data source name bound to the current thread, ensuring that each thread has its own independent data source context, avoiding data access conflicts in a multi-threaded environment, and improving the thread safety of the system. Static methods setCurrentDataSource(Stringname) and getCurrentDataSource() are provided to set and obtain the data source name of the current thread, making the data source switching operation simple and flexible. Developers can switch data sources at any time as needed in the business logic without having to worry about the underlying data source management details. Encapsulating the logic of data source switching in static methods reduces code duplication and improves the readability and maintainability of the code. At the same time, it is also convenient for unified management and optimization of data source switching logic in subsequent development. Through AOP (aspect-oriented programming) technology, data sources can be automatically switched before and after method execution without explicitly calling the setCurrentDataSource method in the business logic, further simplifying the code and improving the transparency and automation of data source switching. Since each thread is bound to an independent data source name, the connection leakage problem that may occur when sharing database connections between different threads can be avoided, improving the stability and reliability of the system. This technical solution can easily cope with the switching needs of multiple data sources in complex business scenarios. Whether in read-write separation, database and table sharding, or multi-tenancy scenarios, data access isolation and optimization can be achieved through flexible data source switching. It provides a simple and easy-to-use API interface, allowing developers to quickly get started and implement multi-data source switching functions, improve development efficiency, and shorten project delivery cycles.

[0034] In one embodiment of the present invention, the S4 includes: S41. Customize the @DataSourceSwitch annotation, including the data source name (value) as an optional parameter, the type attribute to specify the switching type (such as read-write separation, load balancing, etc.), and a fallback attribute to specify the fallback data source name when the switch fails; in the AOP aspect class, the @DataSourceSwitch annotation on the method is parsed through the reflection mechanism to obtain relevant information; S42. Configure an aspect class through the SpringAOP framework, and intercept all methods annotated with @DataSourceSwitch through interception logic; the interception logic includes pre-notification and post-notification; S43. In the AOP aspect, use the try-catch block to capture all possible exceptions, record detailed error information, and execute the corresponding fallback strategy according to the configuration.

[0035] The working principle of the above technical solution is as follows: First, define a custom annotation named @DataSourceSwitch. The annotation contains three main properties: value: This is an optional parameter that specifies the name of the data source.

[0036] type: used to specify the switching type, such as read-write separation, load balancing, etc. This attribute can help the system select the appropriate data source switching strategy according to different business needs.

[0037] fallback: used to specify the name of the fallback data source when the switch fails. This attribute ensures that when the data source switch fails, the system can automatically fall back to an available data source to avoid business interruption.

[0038] In the AOP aspect class, the @DataSourceSwitch annotation on the method is parsed through the reflection mechanism to obtain the above-mentioned related information, including the data source name, switch type, and fallback data source. Next, configure an aspect class through the SpringAOP framework. This aspect class will intercept all methods annotated with @DataSourceSwitch. The interception logic includes pre-notification and post-notification: Pre-notification: Executed before the method is executed. In this notification, according to the information in the @DataSourceSwitch annotation, switch to the specified data source. If the switch fails, fall back to the backup data source according to the fallback attribute.

[0039] Post-notification: Executed after the method is executed. Regardless of whether the method is executed successfully, the post-notification will be executed. In this notification, some cleanup work can be performed, such as releasing the database connection.

[0040] In the AOP aspect, use try-catch blocks to catch all possible exceptions. These exceptions include data source switching exceptions and database operation exceptions. When an exception is caught, detailed error information is recorded and the corresponding fallback strategy is executed according to the configuration. The fallback strategy may include falling back to an alternative data source, throwing an exception to the upper-level caller, or executing other custom exception handling logic.

[0041] The effect of the above technical solution is: by customizing the @DataSourceSwitch annotation, the logic of data source switching is separated from the business code, making the business code more concise and clear. The use of annotations reduces hard coding, making the code more flexible and easy to maintain. Using the SpringAOP framework, methods with @DataSourceSwitch annotations can be automatically intercepted, and automatically switched to the specified data source according to the information in the annotation, avoiding the tedious process of manually switching the data source in the business code and improving development efficiency. The type attribute in the @DataSourceSwitch annotation supports specifying multiple switching types, such as read-write separation, load balancing, etc., to meet the needs of different business scenarios. The fallback attribute specifies the fallback data source when the switch fails, ensuring the stability and reliability of the system. Use the try-catch block in the AOP aspect to capture all possible exceptions, including data source switching exceptions and database operation exceptions. Recording detailed error information helps to quickly locate and solve problems. Execute the corresponding fallback strategy according to the configuration, such as falling back to the backup data source or throwing an exception to the upper caller, which improves the fault tolerance of the system. The logic of data source switching is separated from the business code through the AOP aspect, reducing the coupling between the business code and the data source management logic. This allows the data source management logic to be modified and optimized more independently without affecting the business code. Thanks to the use of annotations and AOP frameworks, the system can easily add new data source switching types and fallback strategies. This allows the system to respond more flexibly and quickly to new business needs.

[0042] In one embodiment of the present invention, the pre-notification is implemented by the following method: Check whether the ThreadLocal variable has been bound to the data source name. If it has been bound, record the current data source as the data source before switching; According to the @DataSourceSwitch annotation on the method, obtain the corresponding information, which includes the target data source name, switch type, and fallback data source; Search the target data source in the global DataSourceMap collection. If it does not exist, search for the fallback data source according to the fallback property. If the fallback data source does not exist, record the error log and decide whether to throw an exception or continue execution according to the configuration. Before switching, perform a health check on the target data source. If the check fails, use the fallback data source or record the error log and execute the fallback strategy.

[0043] If all the above checks pass, the ThreadLocal variable is set to the target data source name.

[0044] The working principle of the above technical solution is as follows: in the pre-notification, first check whether the ThreadLocal variable has been bound to the data source name. If it has been bound, the current data source is recorded as the data source before the switch, so that it can roll back to the original data source when necessary. The @DataSourceSwitch annotation on the method is parsed through the reflection mechanism to obtain relevant information, including the target data source name, the switch type, and the fallback data source name. The target data source is searched in the global DataSourceMap collection. If the target data source does not exist, the fallback data source is searched according to the fallback attribute. If the fallback data source does not exist either, an error log is recorded, and it is decided whether to throw an exception or continue execution (using the default data source) according to the configuration. Before switching, a health check is performed on the target data source to ensure its availability. The health check includes key indicators such as connection test and response time. If the check fails, the fallback data source is used or the error log is recorded and the fallback strategy is executed. If all the above checks pass, the ThreadLocal variable is set to the target data source name so that the data source can be used in the current thread to perform database operations.

[0045] The effect of the above technical solution is: by checking whether the ThreadLocal variable has been bound to the data source name, it can ensure that before each data source switch, the system knows which data source the current thread is using, avoiding the confusion of data source switching in a concurrent environment, and ensuring the atomicity and consistency of data source switching. According to the @DataSourceSwitch annotation on the method, the target data source name, switch type, and fallback data source are obtained, so that the data source switch can be flexibly configured according to business needs, improving the scalability of the system and making it easier for developers to cope with different business scenarios and data source requirements. Find the target data source in the global DataSourceMap collection, and find the fallback data source according to the fallback attribute, so that the system can automatically fall back to the backup data source when the target data source is unavailable, enhancing the fault tolerance of the system and avoiding business interruptions caused by data source failures. Before switching, a health check is performed on the target data source, including key indicators such as connection test and response time, which can ensure that the target data source is available after switching, improve the stability of the system, and avoid business exceptions caused by unavailable data sources. If an exception occurs during the data source switching process, it is determined whether to throw an exception or continue to execute (using the default data source) according to the configuration, making the exception handling process more concise and clear. This reduces the complexity of exception handling for developers and improves the maintainability of the system. By setting the target data source name as a ThreadLocal variable, it can be ensured that database operations executed in the current thread use the same data source for connection and execution, reducing the number and cost of data source switching and optimizing system performance. By implementing the data source switching logic through custom @DataSourceSwitch annotations and AOP aspect classes, the business code is separated from the data source management logic, which improves the readability and maintainability of the code and allows developers to focus more on the implementation of business logic.

[0046] In one embodiment of the present invention, the post-notification is implemented by the following method: Regardless of whether the method is executed successfully, after the method is executed, the ThreadLocal variable is restored to the data source name before the switch (if it exists), or set to the default data source; If an exception is thrown during the execution of the method, the exception is captured and logged. At the same time, it is decided whether to roll back the transaction and switch to the fallback data source based on the configuration.

[0047] The working principle of the above technical solution is: regardless of whether the business method is executed successfully, the post notification will be executed after the method is executed. In the post notification, first check whether there is a record of the data source name before the switch (that is, whether the ThreadLocal variable has been bound to the data source before the switch). If it exists, the ThreadLocal variable is restored to the data source name before the switch to ensure that the subsequent operations use the correct data source. If there is no data source record before the switch, or the business method is executed on the default data source, the ThreadLocal variable can be set to the default data source. The post notification also contains exception capture logic. If an exception is thrown during the execution of the business method, the post notification will capture the exception and record a detailed error log. This helps developers quickly locate and solve problems. According to the configuration, if the business method fails to execute and the transaction needs to be rolled back, the post notification will trigger the transaction rollback operation. At the same time, according to business needs and configuration, the post notification may switch to the fallback data source to ensure that subsequent operations can be performed on the available data source, enhancing the fault tolerance and stability of the system.

[0048] The effect of the above technical solution is: after the method is executed, whether it is successful or not, the post notification will restore the ThreadLocal variable to the data source name before the switch (if it exists), or set it to the default data source, ensuring the correctness of the data source and avoiding subsequent operation errors caused by the failure to restore the data source. By capturing the exceptions thrown during the method execution and recording the log, the post notification enables the system to detect and handle errors in a timely manner, which helps developers to quickly locate problems and improve the robustness and reliability of the system. Deciding whether to roll back the transaction and switch to the fallback data source based on the configuration enables the system to respond flexibly according to different business needs when handling exceptions, enhancing the flexibility of transaction management and enabling the system to better cope with various abnormal situations. The post notification automatically restores the data source and handles the exception, simplifying the data source management logic. This allows developers to focus more on the implementation of business logic and improves development efficiency. The implementation method of the post notification enables the system to easily add new data source switching logic and exception handling strategies, improves the scalability of the system, and enables the system to evolve continuously with changes in business needs. When the method execution fails and the transaction needs to be rolled back, the post notification can ensure that the transaction is correctly rolled back, thereby ensuring the integrity of the data. By capturing and handling exceptions in a timely manner, post-notification can reduce user waiting time and frustration caused by system errors.

[0049] In one embodiment of the present invention, S5 includes: S51. In the Spring configuration, define a separate DataSourceTransactionManager for each data source and register it in the Spring transaction manager list; S52. Configure different transaction propagation behaviors and isolation levels for different data sources based on business requirements; S53. In the AOP aspect, the propagation behavior and isolation level of the current transaction are dynamically set according to the method annotation or configuration; S54. For transactions across multiple physical databases, data consistency is guaranteed through a distributed transaction solution; and automatic recovery is performed when a distributed transaction fails through a rollback log record and recovery mechanism.

[0050] The working principle of the above technical solution is as follows: In the Spring configuration, define an independent DataSourceTransactionManager instance for each data source. Register these transaction managers in the Spring transaction manager list, and configure different transaction propagation behaviors and isolation levels for different data sources according to business needs. For example, you can configure the PROPAGATION_REQUIRED propagation behavior for some data sources, indicating that the current method must run in a transaction. If there is a transaction, join the transaction; if there is no transaction, create a new transaction. At the same time, you can configure the ISOLATION_READ_COMMITTED isolation level for these data sources, indicating that a transaction can only read committed data to avoid dirty reading. In the AOP aspect, the propagation behavior and isolation level of the current transaction are dynamically set according to the method annotation or configuration. This allows developers to flexibly adjust transaction properties according to specific business scenarios and requirements to adapt to different data operation requirements. For transactions across multiple physical databases, a distributed transaction solution is adopted, such as SpringCloudSleuth combined with Seata, Atomikos, etc. At the same time, through the rollback log record and recovery mechanism, it can automatically recover when a distributed transaction fails, further improving the reliability and stability of the system.

[0051] The effect of the above technical solution is: define an independent DataSourceTransactionManager for each data source and register it in the Spring transaction manager list; configure different transaction propagation behaviors and isolation levels for different data sources according to business needs, such as PROPAGATION_REQUIRED and ISOLATION_READ_COMMITTED, etc., to meet various complex business scenarios and performance requirements, and improve the flexibility and configurability of the system. In the AOP aspect, the propagation behavior and isolation level of the current transaction are dynamically set according to the method annotation or configuration, so that developers can flexibly control the behavior of transactions according to specific business logic and scenarios without hard-coding transaction attributes in the code, which improves the reusability and maintainability of the code. For transactions across multiple physical databases, a distributed transaction solution is adopted, such as SpringCloudSleuth combined with Seata, Atomikos, etc. The solution provides powerful distributed transaction coordination capabilities to ensure that transactions executed between multiple data sources are consistent and atomic. Through the rollback logging and recovery mechanism, distributed transactions can be automatically recovered when they fail, which enhances the fault tolerance and stability of the system and reduces the business risks caused by transaction failures. Transaction management in a multi-data source environment is implemented in a modular and configurable way. The system can easily add or delete data sources without making a lot of modifications to the existing transaction management logic. At the same time, the dynamic setting of transaction attributes is implemented through AOP aspects and annotations, which reduces the coupling between codes and improves the scalability and maintainability of the system. The performance of the system can be optimized by configuring appropriate transaction propagation behaviors and isolation levels for different data sources. For example, for read-only operations, a lower isolation level can be configured to reduce the overhead of locks; for scenarios that require high concurrent access, appropriate transaction propagation behaviors can be configured to avoid unnecessary transaction nesting and lock contention. In addition, the optimization algorithm and caching mechanism in the distributed transaction solution can further improve the performance of the system. Through the distributed transaction solution and rollback logging and recovery mechanism, the consistency and recoverability of transactions executed in a distributed environment are ensured, which enhances the reliability of the system and enables the system to maintain data integrity and consistency in the face of various abnormal situations.

[0052] In one embodiment of the present invention, the S53 includes: Define the @TransactionalConfig annotation. In the AOP aspect class, parse the @TransactionalConfig annotation on the method through the reflection mechanism to obtain the transaction propagation behavior and isolation level information. In the Spring configuration, define a separate DataSourceTransactionManager for each data source and register them with Spring's transaction manager list; In the AOP aspect, dynamically select the corresponding data source and transaction manager based on the @TransactionalConfig annotation on the method or the global configuration; Extract the transaction propagation behavior and isolation level information from the @TransactionalConfig annotation; apply the level information to the transaction environment of the current thread; control the opening and commit / rollback of transactions through AOP pre-notification and post-notification before and after method execution; When a method is called by another method annotated with @TransactionalConfig, if there is a nested transaction, it has a deep understanding of the transaction propagation behavior and decides whether to create a new transaction, join an existing transaction, or ignore the transaction based on the propagation behavior; Make corresponding logical choices based on the propagation behavior specified in the annotation; Apply the isolation level specified in the annotation to the current transaction. If the method involves transaction operations across multiple physical databases, SpringCloudSleuth combined with Seata is used to identify and handle distributed transactions; In a distributed transaction, if an operation fails, the status and result of each operation is recorded through the rollback log recording mechanism; if the transaction fails, the system status is restored according to the rollback log; When a distributed transaction fails, the failed operation is re-executed or rolled back to a previous consistent state through an automatic recovery mechanism.

[0053] The working principle of the above technical solution is: define the @TransactionalConfig annotation, which contains two main attributes: propagation and isolation.

[0054] Propagation is used to specify the propagation behavior of a transaction, such as PROPAGATION_REQUIRED (join if a transaction currently exists, create a new transaction if it does not exist), PROPAGATION_REQUIRES_NEW (create a new transaction regardless of whether a transaction currently exists), etc.

[0055] Isolation is used to specify the isolation level of transactions, such as ISOLATION_READ_COMMITTED (only committed data can be read), ISOLATION_SERIALIZABLE (the highest level of isolation, transaction serialization execution), etc.

[0056] In the AOP aspect class, the @TransactionalConfig annotation on the method is parsed through the reflection mechanism to obtain the propagation behavior and isolation level information of the transaction. In the Spring configuration, a separate DataSourceTransactionManager is defined for each data source and registered in the Spring transaction manager list. In the AOP aspect, the corresponding data source and transaction manager are dynamically selected according to the @TransactionalConfig annotation on the method or the global configuration. The propagation behavior and isolation level information of the transaction are extracted from the @TransactionalConfig annotation and applied to the transaction environment of the current thread. Before and after the method is executed, the opening and commit / rollback of the transaction are controlled by the pre-notification and post-notification of AOP. When a method is called by another method with the @TransactionalConfig annotation, if there is a nested transaction, whether to create a new transaction, join an existing transaction, or ignore the transaction is determined based on the propagation behavior. The isolation level specified in the annotation is applied to the current transaction. The aspect class can contain intelligent logic to dynamically adjust the isolation level according to the current system load and the importance of the transaction. If the method involves transaction operations across multiple physical databases, the distributed transaction situation is identified and processed through SpringCloudSleuth combined with Seata. In a distributed transaction, if an operation fails, the status and results of each operation are recorded through the rollback log recording mechanism. If a transaction fails, the system status is restored according to the rollback log, or the failed operation is re-executed or rolled back to the previous consistent state through the automatic recovery mechanism.

[0057] The effects of the above technical solutions are as follows: through the @TransactionalConfig annotation, developers can easily specify the propagation behavior and isolation level of transactions for each method without hard-coding transaction attributes in the code, which improves the reusability and maintainability of the code. The use of annotations makes transaction configuration more intuitive and easy to understand, reducing the risk of configuration errors. The application of AOP aspects separates transaction management logic from business logic and reduces the coupling of the code. By parsing annotations through the reflection mechanism, the corresponding data source and transaction manager can be dynamically selected according to the @TransactionalConfig annotation on the method or the global configuration, realizing the dynamic management of transaction management. It supports the processing of nested transactions, and decides whether to create a new transaction, join an existing transaction, or ignore a transaction based on the propagation behavior of the transaction, realizing the fine management of transaction control. It provides a variety of propagation behavior options, such as PROPAGATION_REQUIRES_NEW, PROPAGATION_SUPPORTS, etc., to meet the needs of different business scenarios. It allows developers to dynamically adjust the isolation level of transactions according to business needs and system load to balance the relationship between data consistency and system performance. The aspect class can contain intelligent logic to automatically adjust the isolation level according to the current system status, optimizing system performance. By combining SpringCloudSleuth with distributed transaction solutions such as Seata, transaction operations across multiple physical databases are identified and processed to ensure the consistency of distributed transactions. A rollback log recording mechanism and an automatic recovery mechanism are provided to record the status and results of each operation when a distributed transaction fails, and to restore the system status based on the rollback log, thereby improving the reliability and fault tolerance of the system. This technical solution simplifies the development and maintenance of transaction management, allowing developers to focus more on the implementation of business logic without having to pay too much attention to the details of transaction management. Through unified configuration and annotation methods, transaction management is more standardized and standardized, reducing maintenance costs.

[0058] An embodiment of the present invention is a dynamic multi-data source switching component, on which a computer program is stored. The program is executed by a processor to implement any of the dynamic multi-data source switching implementation methods described above.

[0059] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.< / string> < / string> < / string> < / string> < / string> < / string> < / string> < / string> < / string> < / string>

Claims

1. A method for implementing dynamic multi-data source switching, characterized in that: The method comprises: S1. Define the information of multiple data sources in the configuration file of the application; S2. When the application starts, the data source information in the configuration file is read, and multiple DataSource objects are instantiated; and the DataSource objects are stored in a Map collection; S3. Define a ThreadLocal variable, and store the data source name bound to the current thread through the ThreadLocal variable; S4. In the AOP aspect, intercept the business method that uses the switch data source annotation; switch to the specified data source before the method is executed, and switch back to the default data source after the method is executed; S5. Configure the transaction manager in the Spring framework to ensure the consistency and integrity of transactions during the switching of multiple data sources.

2. A method for implementing dynamic multi-data source switching according to claim 1, characterized in that: Said S1 comprises: S11. Create a dedicated configuration file to centrally manage the configuration of all data sources through the configuration file; in the configuration file, define the independent configuration items of each data source; S12, grouping data sources according to business logic and setting a priority for each data source. If a data source fails, it will automatically switch to an alternative data source; S13. Based on the dynamic loading mechanism of the configuration file, the data source configuration is updated through external commands or APIs without restarting the application.

3. A method for implementing dynamic multi-data source switching according to claim 1, characterized in that: The S2 comprises: S21. When the application starts, the data source information in the configuration file is read through the @PropertySource or @ConfigurationProperties annotation of the Spring framework; S22. Use Java reflection or Spring's BeanUtils tool class to dynamically create DataSource objects based on configuration information; S23. Create a global Map based on a thread-safe collection<String,DataSource> A collection where the key is the data source name and the value is the corresponding DataSource object; S24. Perform a health check on each instantiated DataSource object, including a connection test, SQL execution, and efficiency test. If the data source check fails, a log is recorded and an attempt is made to use an alternative data source or an alarm is triggered.

4. A method for implementing dynamic multi-data source switching according to claim 1, characterized in that: The S3 includes: S31. Define a global ThreadLocal <string>Variables, via ThreadLocal <string> The variable stores the name of the data source bound to the current thread;< / string> < / string> S32. Set the data source name of the current thread through the static method setCurrentDataSource(Stringname); and obtain the data source name of the current thread through getCurrentDataSource(); S33, and in the business logic involving switching of multiple data sources, the setCurrentDataSource method is called through AOP or manually.

5. A method for implementing dynamic multi-data source switching according to claim 1, characterized in that: The S4 comprises: S41. Customize the @DataSourceSwitch annotation, type attribute, and a fallback attribute. In the AOP aspect class, parse the @DataSourceSwitch annotation on the method through the reflection mechanism to obtain relevant information. S42. Configure an aspect class through the SpringAOP framework, and intercept all methods annotated with @DataSourceSwitch through interception logic; the interception logic includes pre-notification and post-notification; S43. In the AOP aspect, use the try-catch block to capture all possible exceptions, record detailed error information, and execute the corresponding fallback strategy according to the configuration.

6. A method for implementing dynamic multi-data source switching according to claim 5, characterized in that: The pre-notification is implemented by the following method: Check whether the ThreadLocal variable has been bound to the data source name. If it has been bound, record the current data source as the data source before switching; According to the @DataSourceSwitch annotation on the method, obtain the corresponding information, which includes the target data source name, switch type, and fallback data source; Search the target data source in the global DataSourceMap collection. If it does not exist, search for the fallback data source based on the fallback property. If the fallback data source does not exist, an error log is recorded and the decision on whether to throw an exception or continue execution is made based on the configuration; Before switching, perform a health check on the target data source. If the check fails, use the fallback data source or record the error log and execute the fallback strategy; If all the above checks pass, the ThreadLocal variable is set to the target data source name.

7. A method for implementing dynamic multi-data source switching according to claim 5, characterized in that: The post notification is implemented by the following method: Regardless of whether the method is executed successfully, after the method is executed, the ThreadLocal variable is restored to the data source name before the switch, or set to the default data source; If an exception is thrown during the execution of the method, the exception is captured and logged. At the same time, it is decided whether to roll back the transaction and switch to the fallback data source based on the configuration.

8. A method for implementing dynamic multi-data source switching according to claim 1, characterized in that: The S5 comprises: S51. In the Spring configuration, define an independent DataSourceTransactionManager for each data source and register it in the Spring transaction manager list; S52. Configure different transaction propagation behaviors and isolation levels for different data sources based on business requirements; S53. In the AOP aspect, the propagation behavior and isolation level of the current transaction are dynamically set according to the method annotation or configuration; S54. For transactions across multiple physical databases, data consistency is guaranteed through a distributed transaction solution; and automatic recovery is performed when a distributed transaction fails through a rollback log record and recovery mechanism.

9. A method for implementing dynamic multi-data source switching according to claim 8, characterized in that: The S53 comprises: Define the @TransactionalConfig annotation. In the AOP aspect class, parse the @TransactionalConfig annotation on the method through the reflection mechanism to obtain the transaction propagation behavior and isolation level information. In the Spring configuration, define a separate DataSourceTransactionManager for each data source and register them with Spring's transaction manager list; In the AOP aspect, dynamically select the corresponding data source and transaction manager based on the @TransactionalConfig annotation on the method or the global configuration; Extract the transaction propagation behavior and isolation level information from the @TransactionalConfig annotation; apply the level information to the transaction environment of the current thread; control the opening and commit / rollback of transactions through AOP pre-notification and post-notification before and after method execution; When a method is called by another method annotated with @TransactionalConfig, if there is a nested transaction, it has a deep understanding of the transaction propagation behavior and decides whether to create a new transaction, join an existing transaction, or ignore the transaction based on the propagation behavior; Make corresponding logical choices based on the propagation behavior specified in the annotation; Apply the isolation level specified in the annotation to the current transaction; If the method involves transaction operations across multiple physical databases, SpringCloudSleuth combined with Seata is used to identify and handle distributed transactions; In a distributed transaction, if an operation fails, the status and result of each operation is recorded through the rollback log recording mechanism; if the transaction fails, the system status is restored according to the rollback log; When a distributed transaction fails, the failed operation is re-executed or rolled back to a previous consistent state through an automatic recovery mechanism.

10. A dynamic multi-data source switching component having a computer program stored thereon, characterized in that: The program is executed by a processor to implement the dynamic multi-data source switching implementation method as described in any one of claims 1-9.

Images