1. 多租户多数据源到底在解决什么问题第一次接触“多租户多数据源”这个组合词很多人会把它和“分库分表”混为一谈。其实两者解决的是完全不同层面的问题。分库分表关注的是单租户内数据量过大导致的性能瓶颈而多租户多数据源关注的是多个租户之间数据如何隔离。这是SaaS系统架构设计中最核心的决策之一。我做过几个中小型SaaS项目早期为了图快所有租户共用一张表靠tenant_id字段做逻辑隔离。这种方案在租户数量少、数据量小的时候确实省事但一旦遇到客户提出“我们的数据必须独立存储”或者“需要单独备份某个租户的数据”这类需求改造起来就非常痛苦。后来我逐步切换到多数据源方案虽然前期配置麻烦一些但后期的灵活性和安全性提升非常明显。这篇文章适合正在做SaaS系统架构选型的开发者也适合已经用了共享表方案但想迁移到独立数据源的团队。我会从方案选型、核心配置、动态切换、事务处理、常见问题几个维度把踩过的坑和验证过的方案完整分享出来。全文基于SpringBoot生态默认你已经有基本的SpringBoot和MyBatis使用经验。2. 多租户数据隔离方案选型与对比2.1 三种主流隔离方案的核心差异在动手写代码之前必须先想清楚选哪种隔离级别。业界常见的方案有三种独立数据库、共享数据库独立Schema、共享数据库共享表。这三者的隔离程度、成本、复杂度是递增关系。独立数据库方案下每个租户拥有完全独立的数据库实例。隔离级别最高租户数据互不可见备份恢复可以按租户粒度操作。但成本也最高租户数量多了之后数据库连接数、运维复杂度都会急剧上升。适合中大型企业客户尤其是对数据安全有强合规要求的场景。共享数据库独立Schema方案所有租户共用一个数据库实例但每个租户有独立的Schema。隔离级别中等成本适中运维比独立数据库简单。MySQL中Schema和Database概念基本等价所以这种方案在MySQL下和独立数据库差别不大。PostgreSQL的Schema支持更好一个数据库下可以创建多个Schema切换成本低。共享数据库共享表方案所有租户数据存在同一张表里通过tenant_id字段区分。隔离级别最低成本最低但数据安全性和灵活性最差。适合小微租户、对数据隔离没有强要求的场景。对比维度独立数据库独立Schema共享表隔离级别最高中等最低硬件成本高中低运维复杂度高中低租户备份恢复支持支持困难跨租户统计困难较难容易适合租户规模中大型中型小微2.2 为什么我最终选择了动态数据源方案在实际项目中我最终采用的是独立数据库动态数据源切换的组合方案。核心原因是客户群体中有相当比例的企业客户他们在合同里明确要求数据物理隔离。同时租户数量控制在几十到几百这个量级数据库实例数量还可控。动态数据源方案的核心思路是应用启动时加载所有租户的数据源配置运行时根据请求上下文中的租户标识动态切换到对应的数据源。Spring提供了AbstractRoutingDataSource这个抽象类专门用于实现动态数据源路由。它的原理是维护一个目标数据源的Map通过determineCurrentLookupKey()方法返回的key去Map中查找对应的数据源。这个方案的优势在于对业务代码侵入极小Service层不需要关心当前用的是哪个数据源扩展性好新增租户只需要添加配置事务管理可以通过Transactional注解配合自定义的事务管理器实现。缺点是需要自己处理数据源的动态注册和销毁以及事务传播时的数据源一致性问题。注意动态数据源方案下跨租户的统计查询会变得非常麻烦。如果业务中有大量跨租户的聚合分析需求建议在架构设计阶段就考虑引入独立的数据仓库或ETL流程不要在业务库上硬做。3. 动态数据源核心配置与实现细节3.1 数据源配置的存储与加载策略数据源配置存哪里这是第一个要决策的点。常见的有三种配置文件、数据库、配置中心。配置文件方式最简单在application.yml里列出所有租户的数据源信息启动时全部加载。缺点是新增租户需要改配置重启不适合租户频繁变动的场景。数据库方式是把租户数据源信息存在一张管理表里应用启动时从表里读取。新增租户只需要插入一条记录配合定时刷新或手动触发刷新即可生效。这种方式灵活度高我推荐在生产环境使用。配置中心方式适合已经有成熟配置中心基础设施的团队本质和数据库方式类似只是存储介质不同。我采用的是数据库存储启动加载手动刷新的组合。管理表结构大致如下CREATE TABLE tenant_datasource ( id BIGINT PRIMARY KEY AUTO_INCREMENT, tenant_id VARCHAR(64) NOT NULL UNIQUE, driver_class_name VARCHAR(128) NOT NULL, url VARCHAR(512) NOT NULL, username VARCHAR(128) NOT NULL, password VARCHAR(256) NOT NULL, initial_size INT DEFAULT 5, max_active INT DEFAULT 20, status TINYINT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );密码字段在实际项目中必须加密存储我一般用AES对称加密密钥放在环境变量里不硬编码在代码或配置文件中。这一点在安全审计时经常被检查提前做好省事。3.2 动态数据源路由的完整实现核心实现分三步定义数据源上下文持有器、实现路由数据源、注册数据源。先看上下文持有器它负责在当前线程中保存租户标识。这里用ThreadLocal实现注意在请求结束时必须清理否则线程池复用时会串数据。public class TenantContextHolder { private static final ThreadLocalString CONTEXT new ThreadLocal(); public static void setTenantId(String tenantId) { CONTEXT.set(tenantId); } public static String getTenantId() { return CONTEXT.get(); } public static void clear() { CONTEXT.remove(); } }路由数据源的实现继承AbstractRoutingDataSource重写determineCurrentLookupKey()方法public class DynamicDataSource extends AbstractRoutingDataSource { Override protected Object determineCurrentLookupKey() { String tenantId TenantContextHolder.getTenantId(); if (tenantId null) { return default; } return tenantId; } }数据源注册我封装了一个DynamicDataSourceManager负责从数据库读取配置、创建Druid数据源、注册到路由数据源的targetDataSources中。这里有个关键点AbstractRoutingDataSource的targetDataSources是protected的外部无法直接操作。我的做法是继承后暴露一个addDataSource方法或者通过反射操作。更优雅的方式是继承AbstractRoutingDataSource并重写afterPropertiesSet()在初始化时把所有数据源都塞进去。public class DynamicDataSource extends AbstractRoutingDataSource { private final MapObject, Object targetDataSources new ConcurrentHashMap(); public void addDataSource(String tenantId, DataSource dataSource) { targetDataSources.put(tenantId, dataSource); super.setTargetDataSources(targetDataSources); super.afterPropertiesSet(); } Override protected Object determineCurrentLookupKey() { return TenantContextHolder.getTenantId(); } }注意每次调用afterPropertiesSet()都会重建resolvedDataSources租户数量多的时候频繁刷新会有性能损耗。建议在租户配置变更时批量刷新而不是单个添加。3.3 租户标识的传递与拦截器设计租户标识从哪里来常见的有三种请求头、JWT Token、域名。请求头方式最简单前端在每个请求的Header里带上X-Tenant-Id。JWT方式更安全租户信息编码在Token里服务端解析后自动设置。域名方式适合每个租户有独立域名的场景通过域名解析出租户标识。我一般采用JWT请求头兜底的方案。正常请求从JWT中解析租户标识内部服务调用时通过请求头传递。实现一个HandlerInterceptor在preHandle中解析并设置上下文在afterCompletion中清理。public class TenantInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String tenantId request.getHeader(X-Tenant-Id); if (tenantId null) { tenantId parseFromToken(request); } if (tenantId ! null) { TenantContextHolder.setTenantId(tenantId); } return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { TenantContextHolder.clear(); } }这里有个容易忽略的点异步任务和定时任务中无法获取请求上下文。如果业务中有异步处理逻辑需要手动传递租户标识。我的做法是封装一个TenantAwareRunnable在任务提交时捕获当前租户标识执行时重新设置。4. 事务管理与跨租户操作的实战处理4.1 单租户事务的正确配置方式动态数据源下Transactional注解默认使用Spring的事务管理器但如果不指定具体的数据源事务管理器可能无法正确绑定到当前租户的数据源。解决方案是配置一个DataSourceTransactionManager并确保它使用的是动态数据源。Configuration public class TransactionConfig { Bean public PlatformTransactionManager transactionManager( Qualifier(dynamicDataSource) DataSource dataSource) { return new DataSourceTransactionManager(dataSource); } }这样配置后Transactional注解会作用于动态数据源事务开启时会根据当前租户标识获取对应的物理连接。实测下来单租户内的事务操作完全正常回滚也能正确执行。但有一个坑事务开启后再切换租户标识是无效的。因为事务一旦开启连接就已经绑定到具体的数据源了。如果在事务方法内部修改了TenantContextHolder后续的数据库操作仍然走原来的数据源。这个行为在排查问题时经常让人困惑记住“事务绑定的是连接不是租户标识”就能理解。4.2 跨租户操作的三种处理策略跨租户操作是多数据源方案中最棘手的问题。比如管理员需要查询所有租户的汇总数据或者某个业务需要同时操作两个租户的数据。我总结了三套处理策略按推荐程度排序。策略一循环切换逐个查询。适用于跨租户查询场景。先查出所有租户标识然后循环设置上下文、执行查询、收集结果。这种方式实现简单但租户数量多时性能差且无法保证数据一致性。public ListStatResult queryAllTenants() { ListString tenantIds tenantService.getAllTenantIds(); ListStatResult results new ArrayList(); for (String tenantId : tenantIds) { TenantContextHolder.setTenantId(tenantId); results.add(statMapper.queryStat()); } TenantContextHolder.clear(); return results; }策略二独立数据源专用查询。适用于跨租户统计场景。配置一个专门的数据源指向汇总库或数据仓库跨租户查询走这个数据源。这种方式性能好但需要额外的数据同步机制。策略三分布式事务强一致性。适用于跨租户写入场景。引入Seata等分布式事务框架保证多个数据源的操作要么全部成功要么全部回滚。这种方式复杂度最高除非业务强需求否则不建议。提示大部分SaaS系统的跨租户操作都是读多写少优先考虑策略一和策略二。真正需要跨租户写入的场景建议重新审视业务设计看能否拆分成多个单租户操作通过消息队列最终一致。4.3 事务传播行为在动态数据源下的表现Transactional的传播行为在动态数据源下有一些微妙的表现。REQUIRED是默认行为如果当前没有事务就新建一个有就加入。在动态数据源下如果外层事务已经绑定了租户A的数据源内层方法即使设置了租户B的上下文也会加入外层事务仍然使用租户A的连接。REQUIRES_NEW会新建一个事务挂起外层事务。这种情况下内层方法会根据自己的租户上下文获取新的连接。但要注意如果外层事务持有锁内层事务可能会死锁。我遇到过一种情况外层事务更新了租户A的某条记录内层REQUIRES_NEW事务尝试更新同一条记录直接死锁。排查了半天才定位到是传播行为的问题。NESTED使用保存点实现嵌套事务在动态数据源下表现和REQUIRED类似内层不会切换数据源。所以如果确实需要跨租户写入不要指望通过传播行为解决老老实实用分布式事务或者拆分业务。5. 常见问题排查与避坑经验实录5.1 数据源切换失效的排查思路数据源切换失效是最常见的问题表现是明明设置了租户标识但查询的还是默认库的数据。排查思路按以下顺序进行。第一步确认TenantContextHolder中是否有值。可以在determineCurrentLookupKey()方法中打日志看返回的key是什么。如果返回null说明上下文没有正确设置检查拦截器是否生效、请求头是否传递。第二步确认数据源是否已注册。在DynamicDataSource的targetDataSources中查看是否有对应的key。如果没有说明数据源加载失败检查数据库配置、连接是否正常。第三步确认事务是否已开启。如果方法上有Transactional且事务在设置租户标识之前就开启了那么数据源已经绑定后续切换无效。检查事务注解的位置和租户标识设置的时机。第四步确认是否有缓存。MyBatis的二级缓存、Spring的缓存注解都可能导致数据被缓存看起来像是数据源没切换。检查缓存配置必要时在切换租户时清理缓存。问题现象可能原因排查方法始终查默认库上下文未设置检查拦截器、请求头切换后仍查旧库事务已绑定检查事务注解位置部分请求切换失败线程池串数据检查ThreadLocal清理数据源找不到注册失败检查配置加载日志数据不一致缓存未清理检查缓存配置5.2 连接池配置的注意事项每个租户独立数据源意味着独立连接池。租户数量多的时候连接池总数会非常大。假设50个租户每个连接池最大20个连接理论上最多1000个连接。MySQL默认最大连接数是151直接爆掉。我的做法是按租户活跃度分级配置。活跃租户给大连接池不活跃租户给小连接池。同时设置连接池的空闲回收时间不活跃的连接及时释放。Druid的minIdle设置为0或1maxActive根据租户等级设置5到20不等。spring: datasource: druid: initial-size: 2 min-idle: 1 max-active: 10 max-wait: 5000 time-between-eviction-runs-millis: 60000 min-evictable-idle-time-millis: 300000 validation-query: SELECT 1 test-while-idle: true另外maxWait不要设置太大否则连接耗尽时请求会长时间阻塞。我一般设置5000毫秒超时直接抛异常让上层快速失败。5.3 租户数据源动态增删的实操要点新增租户时除了插入配置记录还需要创建租户的数据库和表结构。我封装了一个TenantProvisionService流程是创建数据库、执行建表脚本、插入数据源配置、刷新动态数据源。整个过程要保证幂等避免重复创建。删除租户要谨慎。我的做法是逻辑删除把数据源状态置为不可用而不是物理删除。物理删除数据库的操作单独走审批流程由运维手动执行。这样即使误操作数据还有恢复的可能。刷新数据源时要注意正在处理的请求。如果直接替换数据源正在使用旧数据源的请求可能会出错。我的做法是先把新数据源加入等一段时间后再移除旧数据源给正在处理的请求一个缓冲期。6. 性能优化与扩展性考量6.1 数据源懒加载与预热策略启动时加载所有租户数据源如果租户数量多启动时间会很长。我采用了懒加载预热的策略。启动时只加载活跃租户的数据源不活跃的租户在第一次请求时再加载。同时对于已知会频繁访问的租户在启动后异步预热避免第一次请求时的延迟。懒加载的实现是在determineCurrentLookupKey()返回key后如果targetDataSources中没有对应的数据源触发加载逻辑。这里要注意并发问题多个请求同时触发加载时需要加锁保证只加载一次。public DataSource getDataSource(String tenantId) { Object ds targetDataSources.get(tenantId); if (ds ! null) { return (DataSource) ds; } synchronized (this) { ds targetDataSources.get(tenantId); if (ds null) { ds loadDataSource(tenantId); addDataSource(tenantId, (DataSource) ds); } } return (DataSource) ds; }6.2 监控与告警体系的搭建多数据源环境下监控尤为重要。我一般监控以下几个指标每个数据源的活跃连接数、等待连接数、慢查询数量、错误率。这些指标通过Druid的StatFilter采集推送到监控系统。告警规则设置活跃连接数持续超过最大连接数的80%时告警等待连接数大于0时告警慢查询数量突增时告警。这些告警能帮助提前发现租户数据源配置不合理或存在慢查询的问题。另外建议记录每个租户的请求量和响应时间用于识别高负载租户。对于高负载租户可以考虑单独部署或升级数据源配置。6.3 从共享表迁移到多数据源的平滑方案如果系统已经用了共享表方案想迁移到多数据源直接切换风险很大。我推荐双写灰度切换的方案。第一阶段新代码同时写共享表和新数据源读还是走共享表。第二阶段数据校验一致后读切换到新数据源共享表停止写入。第三阶段观察一段时间无问题后下线共享表相关代码。这个过程中数据同步是关键。我写了一个同步工具按租户维度把共享表中的数据拆分到各个独立库。同步时注意外键依赖和事务一致性建议在业务低峰期执行。注意迁移过程中要保证新旧数据的映射关系可追溯。我在共享表中增加了一个migrated标记字段记录每条数据是否已迁移方便回滚和校验。7. 我个人在实际操作中的几点体会多租户多数据源这个方案技术上的难点其实不在动态切换本身AbstractRoutingDataSource已经帮我们解决了大部分问题。真正的难点在于边界情况的处理异步任务怎么传递租户标识、跨租户查询怎么做、事务传播怎么控制、连接池怎么规划。这些问题在项目初期往往被忽略等到业务复杂了才暴露出来改造成本很高。我的建议是在架构设计阶段就把这些边界情况想清楚哪怕多花几天时间做技术验证也比后期返工强。另外租户数据源的管理一定要有完善的监控和告警否则某个租户的数据源出问题可能影响到整个系统。最后分享一个小技巧在开发环境我一般配置一个“万能租户”它的数据源指向本地库方便调试。在拦截器中如果请求头带了特定的调试标识就强制使用这个万能租户。这样开发时不用频繁切换配置效率高很多。生产环境记得把这个逻辑关掉。 
长河君 · 2026/10/14 9:57:21 · 阅读 1.2k 多租户多数据源架构实战：动态数据源切换与事务管理避坑指南
1. 多租户多数据源到底在解决什么问题第一次接触“多租户多数据源”这个组合词很多人会把它和“分库分表”混为一谈。其实两者解决的是完全不同层面的问题。分库分表关注的是单租户内数据量过大导致的性能瓶颈而多租户多数据源关注的是多个租户之间数据如何隔离。这是SaaS系统架构设计中最核心的决策之一。我做过几个中小型SaaS项目早期为了图快所有租户共用一张表靠tenant_id字段做逻辑隔离。这种方案在租户数量少、数据量小的时候确实省事但一旦遇到客户提出“我们的数据必须独立存储”或者“需要单独备份某个租户的数据”这类需求改造起来就非常痛苦。后来我逐步切换到多数据源方案虽然前期配置麻烦一些但后期的灵活性和安全性提升非常明显。这篇文章适合正在做SaaS系统架构选型的开发者也适合已经用了共享表方案但想迁移到独立数据源的团队。我会从方案选型、核心配置、动态切换、事务处理、常见问题几个维度把踩过的坑和验证过的方案完整分享出来。全文基于SpringBoot生态默认你已经有基本的SpringBoot和MyBatis使用经验。2. 多租户数据隔离方案选型与对比2.1 三种主流隔离方案的核心差异在动手写代码之前必须先想清楚选哪种隔离级别。业界常见的方案有三种独立数据库、共享数据库独立Schema、共享数据库共享表。这三者的隔离程度、成本、复杂度是递增关系。独立数据库方案下每个租户拥有完全独立的数据库实例。隔离级别最高租户数据互不可见备份恢复可以按租户粒度操作。但成本也最高租户数量多了之后数据库连接数、运维复杂度都会急剧上升。适合中大型企业客户尤其是对数据安全有强合规要求的场景。共享数据库独立Schema方案所有租户共用一个数据库实例但每个租户有独立的Schema。隔离级别中等成本适中运维比独立数据库简单。MySQL中Schema和Database概念基本等价所以这种方案在MySQL下和独立数据库差别不大。PostgreSQL的Schema支持更好一个数据库下可以创建多个Schema切换成本低。共享数据库共享表方案所有租户数据存在同一张表里通过tenant_id字段区分。隔离级别最低成本最低但数据安全性和灵活性最差。适合小微租户、对数据隔离没有强要求的场景。对比维度独立数据库独立Schema共享表隔离级别最高中等最低硬件成本高中低运维复杂度高中低租户备份恢复支持支持困难跨租户统计困难较难容易适合租户规模中大型中型小微2.2 为什么我最终选择了动态数据源方案在实际项目中我最终采用的是独立数据库动态数据源切换的组合方案。核心原因是客户群体中有相当比例的企业客户他们在合同里明确要求数据物理隔离。同时租户数量控制在几十到几百这个量级数据库实例数量还可控。动态数据源方案的核心思路是应用启动时加载所有租户的数据源配置运行时根据请求上下文中的租户标识动态切换到对应的数据源。Spring提供了AbstractRoutingDataSource这个抽象类专门用于实现动态数据源路由。它的原理是维护一个目标数据源的Map通过determineCurrentLookupKey()方法返回的key去Map中查找对应的数据源。这个方案的优势在于对业务代码侵入极小Service层不需要关心当前用的是哪个数据源扩展性好新增租户只需要添加配置事务管理可以通过Transactional注解配合自定义的事务管理器实现。缺点是需要自己处理数据源的动态注册和销毁以及事务传播时的数据源一致性问题。注意动态数据源方案下跨租户的统计查询会变得非常麻烦。如果业务中有大量跨租户的聚合分析需求建议在架构设计阶段就考虑引入独立的数据仓库或ETL流程不要在业务库上硬做。3. 动态数据源核心配置与实现细节3.1 数据源配置的存储与加载策略数据源配置存哪里这是第一个要决策的点。常见的有三种配置文件、数据库、配置中心。配置文件方式最简单在application.yml里列出所有租户的数据源信息启动时全部加载。缺点是新增租户需要改配置重启不适合租户频繁变动的场景。数据库方式是把租户数据源信息存在一张管理表里应用启动时从表里读取。新增租户只需要插入一条记录配合定时刷新或手动触发刷新即可生效。这种方式灵活度高我推荐在生产环境使用。配置中心方式适合已经有成熟配置中心基础设施的团队本质和数据库方式类似只是存储介质不同。我采用的是数据库存储启动加载手动刷新的组合。管理表结构大致如下CREATE TABLE tenant_datasource ( id BIGINT PRIMARY KEY AUTO_INCREMENT, tenant_id VARCHAR(64) NOT NULL UNIQUE, driver_class_name VARCHAR(128) NOT NULL, url VARCHAR(512) NOT NULL, username VARCHAR(128) NOT NULL, password VARCHAR(256) NOT NULL, initial_size INT DEFAULT 5, max_active INT DEFAULT 20, status TINYINT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );密码字段在实际项目中必须加密存储我一般用AES对称加密密钥放在环境变量里不硬编码在代码或配置文件中。这一点在安全审计时经常被检查提前做好省事。3.2 动态数据源路由的完整实现核心实现分三步定义数据源上下文持有器、实现路由数据源、注册数据源。先看上下文持有器它负责在当前线程中保存租户标识。这里用ThreadLocal实现注意在请求结束时必须清理否则线程池复用时会串数据。public class TenantContextHolder { private static final ThreadLocalString CONTEXT new ThreadLocal(); public static void setTenantId(String tenantId) { CONTEXT.set(tenantId); } public static String getTenantId() { return CONTEXT.get(); } public static void clear() { CONTEXT.remove(); } }路由数据源的实现继承AbstractRoutingDataSource重写determineCurrentLookupKey()方法public class DynamicDataSource extends AbstractRoutingDataSource { Override protected Object determineCurrentLookupKey() { String tenantId TenantContextHolder.getTenantId(); if (tenantId null) { return default; } return tenantId; } }数据源注册我封装了一个DynamicDataSourceManager负责从数据库读取配置、创建Druid数据源、注册到路由数据源的targetDataSources中。这里有个关键点AbstractRoutingDataSource的targetDataSources是protected的外部无法直接操作。我的做法是继承后暴露一个addDataSource方法或者通过反射操作。更优雅的方式是继承AbstractRoutingDataSource并重写afterPropertiesSet()在初始化时把所有数据源都塞进去。public class DynamicDataSource extends AbstractRoutingDataSource { private final MapObject, Object targetDataSources new ConcurrentHashMap(); public void addDataSource(String tenantId, DataSource dataSource) { targetDataSources.put(tenantId, dataSource); super.setTargetDataSources(targetDataSources); super.afterPropertiesSet(); } Override protected Object determineCurrentLookupKey() { return TenantContextHolder.getTenantId(); } }注意每次调用afterPropertiesSet()都会重建resolvedDataSources租户数量多的时候频繁刷新会有性能损耗。建议在租户配置变更时批量刷新而不是单个添加。3.3 租户标识的传递与拦截器设计租户标识从哪里来常见的有三种请求头、JWT Token、域名。请求头方式最简单前端在每个请求的Header里带上X-Tenant-Id。JWT方式更安全租户信息编码在Token里服务端解析后自动设置。域名方式适合每个租户有独立域名的场景通过域名解析出租户标识。我一般采用JWT请求头兜底的方案。正常请求从JWT中解析租户标识内部服务调用时通过请求头传递。实现一个HandlerInterceptor在preHandle中解析并设置上下文在afterCompletion中清理。public class TenantInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String tenantId request.getHeader(X-Tenant-Id); if (tenantId null) { tenantId parseFromToken(request); } if (tenantId ! null) { TenantContextHolder.setTenantId(tenantId); } return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { TenantContextHolder.clear(); } }这里有个容易忽略的点异步任务和定时任务中无法获取请求上下文。如果业务中有异步处理逻辑需要手动传递租户标识。我的做法是封装一个TenantAwareRunnable在任务提交时捕获当前租户标识执行时重新设置。4. 事务管理与跨租户操作的实战处理4.1 单租户事务的正确配置方式动态数据源下Transactional注解默认使用Spring的事务管理器但如果不指定具体的数据源事务管理器可能无法正确绑定到当前租户的数据源。解决方案是配置一个DataSourceTransactionManager并确保它使用的是动态数据源。Configuration public class TransactionConfig { Bean public PlatformTransactionManager transactionManager( Qualifier(dynamicDataSource) DataSource dataSource) { return new DataSourceTransactionManager(dataSource); } }这样配置后Transactional注解会作用于动态数据源事务开启时会根据当前租户标识获取对应的物理连接。实测下来单租户内的事务操作完全正常回滚也能正确执行。但有一个坑事务开启后再切换租户标识是无效的。因为事务一旦开启连接就已经绑定到具体的数据源了。如果在事务方法内部修改了TenantContextHolder后续的数据库操作仍然走原来的数据源。这个行为在排查问题时经常让人困惑记住“事务绑定的是连接不是租户标识”就能理解。4.2 跨租户操作的三种处理策略跨租户操作是多数据源方案中最棘手的问题。比如管理员需要查询所有租户的汇总数据或者某个业务需要同时操作两个租户的数据。我总结了三套处理策略按推荐程度排序。策略一循环切换逐个查询。适用于跨租户查询场景。先查出所有租户标识然后循环设置上下文、执行查询、收集结果。这种方式实现简单但租户数量多时性能差且无法保证数据一致性。public ListStatResult queryAllTenants() { ListString tenantIds tenantService.getAllTenantIds(); ListStatResult results new ArrayList(); for (String tenantId : tenantIds) { TenantContextHolder.setTenantId(tenantId); results.add(statMapper.queryStat()); } TenantContextHolder.clear(); return results; }策略二独立数据源专用查询。适用于跨租户统计场景。配置一个专门的数据源指向汇总库或数据仓库跨租户查询走这个数据源。这种方式性能好但需要额外的数据同步机制。策略三分布式事务强一致性。适用于跨租户写入场景。引入Seata等分布式事务框架保证多个数据源的操作要么全部成功要么全部回滚。这种方式复杂度最高除非业务强需求否则不建议。提示大部分SaaS系统的跨租户操作都是读多写少优先考虑策略一和策略二。真正需要跨租户写入的场景建议重新审视业务设计看能否拆分成多个单租户操作通过消息队列最终一致。4.3 事务传播行为在动态数据源下的表现Transactional的传播行为在动态数据源下有一些微妙的表现。REQUIRED是默认行为如果当前没有事务就新建一个有就加入。在动态数据源下如果外层事务已经绑定了租户A的数据源内层方法即使设置了租户B的上下文也会加入外层事务仍然使用租户A的连接。REQUIRES_NEW会新建一个事务挂起外层事务。这种情况下内层方法会根据自己的租户上下文获取新的连接。但要注意如果外层事务持有锁内层事务可能会死锁。我遇到过一种情况外层事务更新了租户A的某条记录内层REQUIRES_NEW事务尝试更新同一条记录直接死锁。排查了半天才定位到是传播行为的问题。NESTED使用保存点实现嵌套事务在动态数据源下表现和REQUIRED类似内层不会切换数据源。所以如果确实需要跨租户写入不要指望通过传播行为解决老老实实用分布式事务或者拆分业务。5. 常见问题排查与避坑经验实录5.1 数据源切换失效的排查思路数据源切换失效是最常见的问题表现是明明设置了租户标识但查询的还是默认库的数据。排查思路按以下顺序进行。第一步确认TenantContextHolder中是否有值。可以在determineCurrentLookupKey()方法中打日志看返回的key是什么。如果返回null说明上下文没有正确设置检查拦截器是否生效、请求头是否传递。第二步确认数据源是否已注册。在DynamicDataSource的targetDataSources中查看是否有对应的key。如果没有说明数据源加载失败检查数据库配置、连接是否正常。第三步确认事务是否已开启。如果方法上有Transactional且事务在设置租户标识之前就开启了那么数据源已经绑定后续切换无效。检查事务注解的位置和租户标识设置的时机。第四步确认是否有缓存。MyBatis的二级缓存、Spring的缓存注解都可能导致数据被缓存看起来像是数据源没切换。检查缓存配置必要时在切换租户时清理缓存。问题现象可能原因排查方法始终查默认库上下文未设置检查拦截器、请求头切换后仍查旧库事务已绑定检查事务注解位置部分请求切换失败线程池串数据检查ThreadLocal清理数据源找不到注册失败检查配置加载日志数据不一致缓存未清理检查缓存配置5.2 连接池配置的注意事项每个租户独立数据源意味着独立连接池。租户数量多的时候连接池总数会非常大。假设50个租户每个连接池最大20个连接理论上最多1000个连接。MySQL默认最大连接数是151直接爆掉。我的做法是按租户活跃度分级配置。活跃租户给大连接池不活跃租户给小连接池。同时设置连接池的空闲回收时间不活跃的连接及时释放。Druid的minIdle设置为0或1maxActive根据租户等级设置5到20不等。spring: datasource: druid: initial-size: 2 min-idle: 1 max-active: 10 max-wait: 5000 time-between-eviction-runs-millis: 60000 min-evictable-idle-time-millis: 300000 validation-query: SELECT 1 test-while-idle: true另外maxWait不要设置太大否则连接耗尽时请求会长时间阻塞。我一般设置5000毫秒超时直接抛异常让上层快速失败。5.3 租户数据源动态增删的实操要点新增租户时除了插入配置记录还需要创建租户的数据库和表结构。我封装了一个TenantProvisionService流程是创建数据库、执行建表脚本、插入数据源配置、刷新动态数据源。整个过程要保证幂等避免重复创建。删除租户要谨慎。我的做法是逻辑删除把数据源状态置为不可用而不是物理删除。物理删除数据库的操作单独走审批流程由运维手动执行。这样即使误操作数据还有恢复的可能。刷新数据源时要注意正在处理的请求。如果直接替换数据源正在使用旧数据源的请求可能会出错。我的做法是先把新数据源加入等一段时间后再移除旧数据源给正在处理的请求一个缓冲期。6. 性能优化与扩展性考量6.1 数据源懒加载与预热策略启动时加载所有租户数据源如果租户数量多启动时间会很长。我采用了懒加载预热的策略。启动时只加载活跃租户的数据源不活跃的租户在第一次请求时再加载。同时对于已知会频繁访问的租户在启动后异步预热避免第一次请求时的延迟。懒加载的实现是在determineCurrentLookupKey()返回key后如果targetDataSources中没有对应的数据源触发加载逻辑。这里要注意并发问题多个请求同时触发加载时需要加锁保证只加载一次。public DataSource getDataSource(String tenantId) { Object ds targetDataSources.get(tenantId); if (ds ! null) { return (DataSource) ds; } synchronized (this) { ds targetDataSources.get(tenantId); if (ds null) { ds loadDataSource(tenantId); addDataSource(tenantId, (DataSource) ds); } } return (DataSource) ds; }6.2 监控与告警体系的搭建多数据源环境下监控尤为重要。我一般监控以下几个指标每个数据源的活跃连接数、等待连接数、慢查询数量、错误率。这些指标通过Druid的StatFilter采集推送到监控系统。告警规则设置活跃连接数持续超过最大连接数的80%时告警等待连接数大于0时告警慢查询数量突增时告警。这些告警能帮助提前发现租户数据源配置不合理或存在慢查询的问题。另外建议记录每个租户的请求量和响应时间用于识别高负载租户。对于高负载租户可以考虑单独部署或升级数据源配置。6.3 从共享表迁移到多数据源的平滑方案如果系统已经用了共享表方案想迁移到多数据源直接切换风险很大。我推荐双写灰度切换的方案。第一阶段新代码同时写共享表和新数据源读还是走共享表。第二阶段数据校验一致后读切换到新数据源共享表停止写入。第三阶段观察一段时间无问题后下线共享表相关代码。这个过程中数据同步是关键。我写了一个同步工具按租户维度把共享表中的数据拆分到各个独立库。同步时注意外键依赖和事务一致性建议在业务低峰期执行。注意迁移过程中要保证新旧数据的映射关系可追溯。我在共享表中增加了一个migrated标记字段记录每条数据是否已迁移方便回滚和校验。7. 我个人在实际操作中的几点体会多租户多数据源这个方案技术上的难点其实不在动态切换本身AbstractRoutingDataSource已经帮我们解决了大部分问题。真正的难点在于边界情况的处理异步任务怎么传递租户标识、跨租户查询怎么做、事务传播怎么控制、连接池怎么规划。这些问题在项目初期往往被忽略等到业务复杂了才暴露出来改造成本很高。我的建议是在架构设计阶段就把这些边界情况想清楚哪怕多花几天时间做技术验证也比后期返工强。另外租户数据源的管理一定要有完善的监控和告警否则某个租户的数据源出问题可能影响到整个系统。最后分享一个小技巧在开发环境我一般配置一个“万能租户”它的数据源指向本地库方便调试。在拦截器中如果请求头带了特定的调试标识就强制使用这个万能租户。这样开发时不用频繁切换配置效率高很多。生产环境记得把这个逻辑关掉。