SpringBoot配置双数据库源

最近遇到一个需要在项目中配置双数据源的需求,虽然在同一个项目中使用两个独立的数据库,听起来有点扯,但是本着试一试的想法,尝试着在项目中进行了双数据源的配置。成功配置,但是遇到了比较多的坑,感觉还挺有意思的。后面成功配置好了之后,经过商讨,在此项目中配置双数据源并不合适,于是直接revert掉了。大致

最近遇到一个需要在项目中配置双数据源的需求,虽然在同一个项目中使用两个独立的数据库,听起来有点扯,但是本着试一试的想法,尝试着在项目中进行了双数据源的配置。成功配置,但是遇到了比较多的坑,感觉还挺有意思的。后面成功配置好了之后,经过商讨,在此项目中配置双数据源并不合适,于是直接revert掉了。

大致流程

如果是只有一个数据源,我们在需要使用数据库的时候,只需要调用Mapper相关方法即可。这里使用的ORM框架是MyBatis。也就是说框架自动会给我们配置好MyBatis相关的参数,让我们可以直接使用。直接使用MyBatis进行数据库操作的的流程,可以参看其官网的教程

目前在yaml中的配置如下:

单数据源配置

所以肯定会有一个解析spring.datasource、并将其配置成连接数据库所需信息的地方。因此我们也需要将第二个数据库信息配置到yaml文件中。如下:

第二数据源

然后让Spring为我们生成一个数据库源信息相关的bean。再为不同的数据源设置不同的MyBatis配置。

成功实现版本

主数据源的配置信息如下代码所示。此处为了更清晰的描述,特意为bean加上了相应的名字。

@Configuration
@MapperScan(basePackages = {"相应包名"}, sqlSessionTemplateRef = "sqlSessionTemplate")
public class MainDataSourceConfig {
    // 未指明bean的名称时,优先使用该bean
    @Primary
    @Bean(name = "dataSource")
    // 设置数据库属性来源
    @ConfigurationProperties(prefix = "spring.datasource")
    public DataSource dataSource(){
        // 默认是Hikari
        return DataSourceBuilder.create().type(DruidDataSource.class).build();
    }

    @Primary
    @Bean(name = "sqlSessionFactory")
    public SqlSessionFactory sqlSessionFactory(@Qualifier("dataSource")DataSource dataSource) throws Exception {
        SqlSessionFactoryBean bean = new SqlSessionFactoryBean();
        // 设置Mapper.xml文件的扫描处
        bean.setMapperLocations(new PathMatchingResourcePatternResolver().getResources("classpath:mappers/*.xml"));
        // mybatis相关设置
        bean.setConfigLocation(new ClassPathResource("mybatis-config.xml"));
        bean.setDataSource(dataSource);
        return bean.getObject();
    }

    @Primary
    @Bean
    public DataSourceTransactionManager transactionManager(@Qualifier("dataSource") DataSource dataSource) {
        return new DataSourceTransactionManager(dataSource);
    }

    @Primary
    @Bean
    public SqlSessionTemplate sqlSessionTemplate(@Qualifier("sqlSessionFactory") SqlSessionFactory sqlSessionFactory) {
        return new SqlSessionTemplate(sqlSessionFactory);
    }
}

第二数据库配置信息,基本与上面类似,如下:

@Configuration
@MapperScan(basePackages = "相应包名", sqlSessionTemplateRef = "secondSqlSessionTemplate")
public class CustomDataSourceConfig {

    @Bean(name = "secondDataSource")
    @ConfigurationProperties(prefix = "spring.second-db")
    public DataSource secondDataSource() {
        return DataSourceBuilder.create().type(DruidDataSource.class).build();
    }

    @Bean(name = "secondSqlSessionFactory")
    public SqlSessionFactory firstSqlSessionFactory(@Qualifier("secondDataSource") DataSource dataSource) throws Exception{
        SqlSessionFactoryBean bean=new SqlSessionFactoryBean();
        bean.setMapperLocations(new PathMatchingResourcePatternResolver().getResources("classpath:phdsun-mappers/*.xml"));
        bean.setConfigLocation(new ClassPathResource("mybatis-config.xml"));
        bean.setDataSource(dataSource);
        return bean.getObject();
    }

    @Bean(name = "secondSqlSessionTemplate")
    public SqlSessionTemplate secondSqlSessionTemplate(@Qualifier("secondSqlSessionFactory") SqlSessionFactory sqlSessionFactory) throws  Exception{
        return new SqlSessionTemplate(sqlSessionFactory);
    }
}

使用

直接调用相关的mapper

Read more

Volcano 与 Kubernetes GPU 调度学习笔记

本笔记系统整理 Volcano 调度器、Kubernetes 调度框架、GPU Device Plugin、HAMi 等云原生 AI 调度领域的核心知识,适合用于学习、复习和工程实践参考。 目录 * 第一部分:Volcano 入门 * 1. Volcano 是什么 * 2. 安装与快速使用 * 3. 核心特性一览 * 第二部分:Volcano 整体架构 * 4. Volcano 解决的核心问题 * 5. 整体架构与数据流 * 6. 三层抽象模型 * 第三部分:Volcano 核心实现原理 * 7. Session 机制 * 8. Gang Scheduling 实现 * 9. Queue 与 DRF 公平调度

容器镜像(4):镜像的常用工具箱

容器镜像(4):镜像的常用工具箱

前几篇在讲多架构镜像时已经用过 skopeo 和 crane 做镜像复制,这篇系统整理这两个工具的完整能力,同时介绍几个日常操作镜像时同样好用的工具。 一、skopeo:不依赖 Daemon 的镜像瑞士军刀 skopeo 的核心价值是绕过 Docker daemon,直接与 Registry API 交互。上一篇用它做镜像复制和离线传输,但它的能力远不止于此。 1.1 安装 # Ubuntu / Debian sudo apt install -y skopeo skopeo --version # skopeo version 1.15.1 1.2 inspect:免拉取检查镜像元数据 docker inspect 需要先把镜像拉到本地,skopeo inspect 直接向 Registry

容器镜像(3):多架构镜像构建

容器镜像(3):多架构镜像构建

一、什么是多架构镜像 1.1 OCI Image Index 上一篇介绍了单平台镜像的结构:一个 Manifest 指向 Config 和若干 Layer blob。多架构镜像在此之上多了一层——OCI Image Index(也叫 Manifest List),是一个轻量的索引文件,把多个单平台 Manifest 组织在一起: $ docker manifest inspect golang:1.22-alpine { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.index.v1+json", "manifests&

容器镜像(2):containerd 视角下的镜像

容器镜像(2):containerd 视角下的镜像

一、为什么需要了解 containerd 如果你只用 docker run 跑容器,从来不关心底层,那可以不了解 containerd。但如果你在用 Kubernetes,或者想真正理解"容器运行时"是什么,containerd 是绕不开的。 事实上,当你执行 docker run 的时候,containerd 早就在后台悄悄工作了——Docker 从 1.11 版本开始,就把核心运行时剥离出来交给 containerd 负责。 1.1 Docker 的架构演变 早期的 Docker(1.10 及之前)是一个"大一统"的单体程序:一个 dockerd