Spring Boot多数据源分库分表实战指南

在Spring Boot中配置多数据源和分库分表，核心是通过定义多个DataSource bean实现多数据源连接与动态切换，并根据分片键将数据分散到不同数据库或表中以提升系统扩展性。1. 多数据源配置需在application.yml中定义多个数据源信息，并通过@Bean创建多个DataSource实例；2. 使用AbstractRoutingDataSource实现动态数据源切换，结合ThreadLocal和AOP实现运行时上下文识别；3. 分库分表策略包括范围分片、哈希分片、时间分片和业务分片，选择合适的分片键至关重要；4. 可借助ShardingSphere等中间件简化实现，也可自定义规则在DAO层或AOP中处理路由；5. 事务管理复杂，优先避免跨库操作，必要时采用分布式事务方案如TCC或SAGA；6. 需综合考虑数据分布均匀性、扩容迁移可行性及查询复杂度，提前规划并逐步迭代以平衡扩展性与维护成本。

在Spring Boot应用里搞多数据源和分库分表，说白了，就是为了解决数据库单点瓶颈和数据量爆炸的问题。我们不再把所有鸡蛋放一个篮子里，而是把数据分散到多个数据库甚至多台服务器上，让系统能扛住更大的并发和数据增长。这玩意儿，搞好了能让你的应用像打了鸡血一样跑得飞快，但搞不好，那真是给自己挖坑。

搞定多数据源和分库分表，核心思路就是两步：第一，让你的Spring Boot应用能同时连接和管理多个数据库连接；第二，当有数据操作请求过来时，能根据一定的规则（比如用户ID）判断这个数据应该去哪个数据库、哪个表。

具体到Spring Boot，多数据源的配置相对直接，就是定义多个DataSource bean，然后通过一个动态数据源切换机制（比如继承AbstractRoutingDataSource）来根据上下文选择使用哪个数据源。分库分表这块就更复杂了，你需要一套规则来决定数据走向，这套规则可以是自己写代码实现，也可以借助像ShardingSphere这样的中间件。自己写代码，通常是在DAO层或Service层前面加一层拦截，或者干脆用AOP，根据业务ID来计算出目标库和表名，然后动态修改SQL或者切换数据源。这个过程中，事务管理是个大挑战，跨库事务通常很麻烦，能避免就避免，实在不行，就得考虑分布式事务方案了，比如XA，但那玩意儿性能损耗大，或者TCC、SAGA这种柔性事务。说实话，我个人倾向于尽量在业务层面规避分布式事务，或者通过最终一致性来解决。

为什么我们需要在Spring Boot中考虑多数据源和分库分表？

其实，这事儿挺无奈的，但又不得不做。当你的用户量和数据量达到一定规模，单台数据库服务器，即便你硬件堆到极致，也总会有扛不住的一天。读写瓶颈、存储容量限制，这些都是明摆着的问题。Spring Boot本身虽然简化了应用开发，但它不负责帮你扩展数据库。所以，一旦你的业务开始高速增长，数据库的横向扩展就成了绕不过去的坎。

考虑多数据源和分库分表，本质上就是为了实现数据库的水平扩展。把一个巨大的数据库拆分成多个小的、易于管理的数据库实例，每个实例只承载一部分数据或请求。这样一来，读写压力分散了，存储空间也扩展了。这就像把一个大水池的水，分流到好几个小水池里，每个小水池的压力都小了，而且可以根据需要增加更多的小水池。当然，这也会带来额外的复杂性，比如数据查询可能需要跨多个库表，数据一致性问题，还有运维的挑战，但这些都是为了高可用和高性能必须付出的代价。我见过太多项目，早期跑得欢，后期因为没提前规划好数据库扩展，导致整个系统性能直线下降，甚至重构。

如何在Spring Boot项目中配置和管理多数据源？

在Spring Boot里配置多个数据源，这算是分库分表的第一步，也是相对直接的一步。你需要在application.yml或application.properties里定义好多个数据源的连接信息，比如datasource.db1.url、datasource.db2.url等等。

然后，在你的配置类里，为每个数据源定义一个@Bean。通常会用@ConfigurationProperties来绑定配置信息，这样能让代码更清晰。例如：

@Configuration
public class DataSourceConfig {

    @Bean(name = "db1DataSource")
    @ConfigurationProperties(prefix = "spring.datasource.db1")
    public DataSource db1DataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean(name = "db2DataSource")
    @ConfigurationProperties(prefix = "spring.datasource.db2")
    public DataSource db2DataSource() {
        return DataSourceBuilder.create().build();
    }

    // 关键：动态数据源
    @Bean(name = "dynamicDataSource")
    @Primary // 标记为主数据源，Spring会默认注入它
    public DataSource dynamicDataSource(@Qualifier("db1DataSource") DataSource db1,
                                        @Qualifier("db2DataSource") DataSource db2) {
        DynamicDataSource dynamicDataSource = new DynamicDataSource();
        Map targetDataSources = new HashMap<>();
        targetDataSources.put("db1", db1);
        targetDataSources.put("db2", db2);
        dynamicDataSource.setTargetDataSources(targetDataSources);
        dynamicDataSource.setDefaultTargetDataSource(db1); // 默认使用db1

        return dynamicDataSource;
    }

    // 事务管理器也需要指向动态数据源
    @Bean
    public PlatformTransactionManager transactionManager(@Qualifier("dynamicDataSource") DataSource dynamicDataSource) {
        return new DataSourceTransactionManager(dynamicDataSource);
    }
}

这里的DynamicDataSource就是我们自定义的，它继承自AbstractRoutingDataSource。你需要重写determineCurrentLookupKey()方法，这个方法会返回当前请求应该使用哪个数据源的键（比如"db1"或"db2"）。这个键通常通过ThreadLocal来传递，比如你在某个Service方法执行前设置好，执行完再清除。

public class DynamicDataSource extends AbstractRoutingDataSource {

    @Override
    protected Object determineCurrentLookupKey() {
        // 从ThreadLocal获取当前数据源的key
        return DynamicDataSourceContextHolder.getDataSourceKey();
    }
}

public class DynamicDataSourceContextHolder {
    private static final ThreadLocal CONTEXT_HOLDER = new ThreadLocal<>();

    public static void setDataSourceKey(String key) {
        CONTEXT_HOLDER.set(key);
    }

    public static String getDataSourceKey() {
        return CONTEXT_HOLDER.get();
    }

    public static void clearDataSourceKey() {
        CONTEXT_HOLDER.remove();
    }
}

然后，你可以通过AOP或者自定义注解来在方法执行前后切换数据源。比如定义一个@TargetDataSource注解，然后用AOP拦截这个注解，在方法执行前设置数据源，方法执行后清除。这样，你的业务代码就不用关心数据源切换的细节了。

分库分表的策略选择与实现考量

分库分表的策略选择，这才是真正的难点和艺术。没有银弹，只有最适合你业务的方案。核心是选择一个合适的“分片键”（Sharding Key），这个键决定了数据最终会落在哪个库、哪个表。

常见的策略有：

1. 范围分片（Range Sharding）：比如用户ID 1-100000放一个库，100001-200000放另一个库。优点是简单直观，扩容方便。缺点是数据分布可能不均匀，某些范围的数据量大，导致热点问题。
2. 哈希分片（Hash Sharding）/取模分片（Modulus Sharding）：比如根据用户ID对N取模，结果为0的放库0，为1的放库1。优点是数据分布相对均匀。缺点是扩容时麻烦，可能需要大量数据迁移。
3. 时间分片（Time Sharding）：按时间维度分表，比如每月一张表。适用于日志、订单等时效性强的数据。优点是查询特定时间范围的数据很快。缺点是跨时间范围查询复杂，历史数据归档麻烦。
4. 业务分片（Business Sharding）：根据业务属性直接划分，比如电商系统把商品数据放一个库，用户数据放一个库。这种其实更像是垂直拆分，而不是严格意义上的分库分表。

在实现上，我个人倾向于先评估是否真的需要自己手写分片逻辑。如果业务复杂，或者未来扩展性要求高，直接上像ShardingSphere这样的分布式数据库中间件会省心很多。它能帮你处理数据路由、读写分离、分布式事务等一系列问题，你只需要配置好规则，SQL语句基本不用改。当然，引入中间件也会增加系统的复杂度，多了一层维护成本。

如果业务相对简单，数据量没那么恐怖，或者你对性能有极致要求，可以考虑自己实现。这通常意味着你需要一个解析SQL的层，或者在ORM框架（比如MyBatis）的拦截器里做手脚，根据分片键动态生成表名和路由到对应的数据源。

无论哪种方式，都要考虑以下几点：

• 分片键的选择：这是重中之重。理想的分片键应该能均匀分布数据，并且大部分查询都能通过分片键来路由，避免全表扫描或跨库查询。比如用户ID通常是个好选择。
• 数据迁移和扩容：当数据量继续增长，或者某个分片变成热点时，如何平滑地进行数据迁移和扩容，是个大挑战。
• 分布式事务：前面提过，尽量避免。如果实在避免不了，需要深入研究XA、TCC或SAGA这些方案，并评估其对性能的影响。
• 查询复杂性：分库分表后，原本简单的JOIN查询可能变得非常复杂，甚至无法实现。聚合查询也可能需要在应用层进行二次聚合。这会倒逼你重新思考数据模型和业务查询模式。

总之，分库分表是个系统性工程，需要从业务、技术、运维多个角度去权衡。提前规划，小步快跑，逐步迭代，比一开始就追求完美要靠谱得多。