多租户微服务下租户独立数据库场景的连接池高性能架构咨询

1. 租户级动态连接池路由方案 #

• 核心思路：不预创建所有租户的连接池，采用懒加载+闲置销毁机制，仅为当前活跃的租户初始化连接池，连接池的生命周期和租户活跃状态绑定
• 实现要点：
  • 用HikariCP作为底层连接池实现（本身性能远高于Druid、DBCP2，支持毫秒级连接回收），给每个租户维护单独的HikariCP实例，每个实例的最小连接数设为1，最大连接数根据租户的实际QPS动态调整，普通租户最大连接数设为5~10即可
  • 接入层做租户标识解析，请求进来后先拿tenant_id去本地连接池缓存查有没有对应的池实例，没有的话才动态初始化，超过30分钟没有请求的租户连接池自动销毁释放资源
  • 按照你的规模计算：如果同时活跃的租户占比20%，也就是80个租户，每个微服务每个租户的连接池平均持有3个连接，单微服务总连接数才240，完全在数据库的连接承载阈值内

2. 数据库代理层统一连接池方案 #

• 核心思路：把所有微服务的数据库连接管理下沉到独立的代理层，微服务本身不再维护连接池，所有数据库请求都通过代理层转发，由代理层统一维护所有租户的连接池
• 实现要点：
  • 代理层部署为无状态集群，可水平扩容，支持读写分离、SQL审计等额外能力
  • 代理层按照租户+微服务维度做连接池隔离，避免某一个微服务的异常流量打满某个租户的数据库连接，影响其他业务
  • 这种方案下微服务和数据库之间不用维护长连接，大幅降低微服务侧的资源消耗，400个租户的连接池全部由代理层统一调度，连接复用率可以提升60%以上

3. 租户分组分片管理方案 #

• 核心思路：不要完全按照租户1:1分配独立数据库，把租户按照规模、业务域、活跃度分成不同的分组，中小租户共享同组内的逻辑库，仅在逻辑库层面做租户隔离，大租户单独分配独立物理库
• 实现要点：
  • 分组后的逻辑库依然用tenant_id做数据隔离，同时支持随时把高价值租户从共享组迁移到独立物理库，业务层不用修改代码
  • 分组后需要维护的连接池数量直接下降一个量级，比如把380个中小租户分成20个组，总共只需要维护20+20=40个连接池（20个大租户+20个共享组），连接资源消耗大幅降低

额外优化点 #

• 避免在微服务层面做跨租户的事务查询，所有跨租户的统计需求都下沉到数仓处理，减少跨租户连接的频繁创建销毁
• 连接池配置开启leakDetectionThreshold参数，设置为2000ms，自动回收泄露的连接，避免无效连接占用资源
• 对不涉及写操作的查询请求，优先走租户专属的只读实例，分摊主库的连接压力

内容的提问来源于stack exchange，提问作者Ivan