Spring Boot多租户应用连接Azure MSSQL闲置后出现连接重置报错

这种闲置后抛出Connection reset by peer: socket write error的问题，我在Azure环境部署Spring Boot应用时碰过好多次，结合你的多租户（按请求头切换Azure MSSQL数据库）场景，核心原因就是闲置连接被Azure网络层或SQL Server回收，但应用连接池没检测到这些连接已失效。下面给你几个针对性的解决办法：

1. 给连接池加上连接有效性验证 #

Spring Boot默认用HikariCP连接池，必须开启连接有效性检查，确保每次从池里取出的连接都是活的。因为你是多租户架构，每个租户的数据源都要应用这套配置：

HikariCP配置示例（application.yml）： #

spring:
  datasource:
    hikari:
      # 每次获取连接时执行简单验证查询
      connection-test-query: SELECT 1
      # 连接空闲120秒后触发验证（设为Azure负载均衡器超时的一半，避免被提前断开）
      idle-timeout: 120000
      # 连接最大生命周期设为28分钟（必须小于SQL Server默认的30分钟连接超时）
      max-lifetime: 1680000
      # 保留最小空闲连接数，避免池里全是闲置过久的无效连接
      minimum-idle: 2

2. 调整Azure环境的闲置相关设置 #

• App Service应用闲置超时：默认是20分钟，你可以在Azure门户进入你的App Service → 配置 → 常规设置，把闲置超时调长（比如60分钟），但这只是缓解，不能替代连接池的验证机制。
• TCP连接心跳保持：Azure负载均衡器的TCP空闲超时是4分钟（无法修改），可以在Spring Boot里加个定时任务，每隔3分钟对每个租户的数据源执行一次SELECT 1的心跳查询，保持连接活跃。

3. 调整SQL Server的连接超时设置 #

登录Azure SQL Server门户，或者用T-SQL调整数据库的连接超时参数，确保它大于连接池的max-lifetime，避免数据库主动踢掉还在池中的连接：

ALTER DATABASE [你的租户数据库名] SET CONNECT_TIMEOUT = 3600; -- 设置为1小时

4. 多租户架构的额外注意事项 #

• 每个租户的数据源要独立配置连接池参数，不要共用一套配置模板。
• 请求处理结束后要确保正确释放连接，避免连接泄漏导致池里堆积大量无效连接。
• 如果是动态创建租户数据源的模式，定期清理长时间未使用的租户数据源，减少闲置连接的数量。

优先测试连接池的有效性验证配置，这是解决这类问题最直接有效的方案，大部分情况下开启connection-test-query并调整idle-timeout就能解决问题。

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