摘要信创数据库迁到 K8s 后90% 的团队都会遇到连接类问题Pod 重启后批量断连报错、高峰期连接耗尽获取超时、空闲一段时间后首次请求必失败、随机出现 Broken pipe。很多人归罪于「数据库不稳定」「容器网络差」实则是连接池还在用物理机的老配置完全没适配容器化场景。本文基于政务、金融生产项目落地经验拆解容器化三大特有连接坑从应用层连接池、数据库端参数、K8s 网络层三层深度优化覆盖 HikariCP/Druid 双连接池、人大金仓 V9 / 达梦 DM9 双库专属配置、K8s Service 网络适配全套方案。所有配置均可直接复制照着做能彻底解决断连、超时、连接耗尽三大顽疾。政务选金仓金融选达梦MySQL 迁移选金仓Oracle 迁移选达梦。全文无空泛理论所有参数均经过生产压测验证。一、痛点直击容器化后为什么连接问题突然变多 核心结论物理机上跑的好好的连接池配置搬到 K8s 里必然出问题因为容器环境有三个物理机不存在的特有坑。1.1 容器化三大特有连接坑Pod 生命周期短漂移重建是常态物理机数据库几月不重启连接池长连接可以一直用K8s 里数据库 Pod 重建、漂移、升级是常规操作重建后连接池里的旧连接全部变成死连接业务拿到就报错。网络链路长空闲连接悄悄断开物理机应用直连数据库中间只有交换机K8s 里链路是应用 Pod → Service → iptables/ipvs → 数据库 Pod中间还有内核 conntrack、网络策略、节点防火墙。空闲连接超过阈值会被中间设备悄悄断开应用层完全感知不到下次用的时候直接报错。资源边界硬连接数失控容易雪崩物理机资源充足连接池配大一点也没事容器有 CPU、内存硬限制连接数过大容易触发数据库 OOM、连接数打满进而引发连接池排队、业务雪崩。1.2 最常见的故障表现数据库 Pod 重启后应用报大量Broken pipe、连接已关闭重启应用才恢复低峰期过后第一次请求必超时第二次就正常高峰期报获取连接超时数据库端看连接数直接打满随机出现请求超时数据库里看 SQL 本身执行很快二、先定位三类连接故障的典型特征与根因遇到连接问题先别瞎调参数1 分钟判断类型精准解决。故障类型典型现象核心根因优先级频繁断连空闲后首次请求失败、Pod 重启后批量报错、Broken pipe死连接未及时回收中间设备断开空闲连接⭐⭐⭐⭐⭐连接耗尽高峰期获取连接超时、连接池全满、数据库连接数打满连接数配置不合理、连接泄露、长事务占连接⭐⭐⭐⭐⭐随机超时偶发请求超时、SQL 执行很快但整体耗时高网络转发损耗、连接池排队、DNS 解析延迟⭐⭐⭐ 快速判断技巧重启应用后问题消失过一段时间又出现 → 基本是死连接问题只有高峰期出现 → 基本是连接数不够或泄露。三、第一层应用层连接池核心优化HikariCP/Druid 双模板连接池优化的核心原则连接数不是越大越好够用就行死连接要主动回收不要等网络断开。3.1 先搞懂连接数到底配多大合适很多人一上来就配最大连接数 200这是典型的物理机思维误区。数据库最佳连接数公式核心数 * 2 有效磁盘数普通 SSD 磁盘8 核数据库最佳活跃连接数也就 16-20 个。连接数过多只会增加上下文切换、锁冲突性能反而下降。✅ 生产推荐配置单应用实例最大连接数 10~20足够支撑上千 QPS 的 OLTP 业务多实例部署按实例数叠加总连接数不超过数据库最大连接数的 70%核心原则小连接池 排队等待胜过大连接池 上下文切换3.2 HikariCP 容器化最优配置SpringBoot 默认HikariCP 性能最高重点优化连接生命周期、空闲检测、超时控制三个点。人大金仓 V9 配置模板spring: datasource: driver-class-name: com.kingbase8.Driver url: jdbc:kingbase8://kingbase-svc.kingbase:54321/your_db?currentSchemapublic username: your_user password: your_password hikari: # 核心连接数配置 maximum-pool-size: 15 # 最大连接数按业务压测调整 minimum-idle: 5 # 最小空闲连接 # 生死周期配置容器化核心 max-lifetime: 1800000 # 连接最大生命周期30分钟主动回收死连接 idle-timeout: 60000 # 空闲连接超时60秒回收 connection-timeout: 3000 # 获取连接超时3秒快速失败避免雪崩 # 存活检测配置 connection-test-query: SELECT 1 test-while-idle: true validation-timeout: 1000 # 兜底控制 leak-detection-threshold: 60000 # 连接泄露检测60秒未归还告警达梦 DM9 配置模板spring: datasource: driver-class-name: dm.jdbc.driver.DmDriver url: jdbc:dm://dmdb-svc.dmdb:5236/your_db username: your_user password: your_password hikari: maximum-pool-size: 15 minimum-idle: 5 max-lifetime: 1800000 # 30分钟主动回收适配达梦空闲超时 idle-timeout: 60000 connection-timeout: 3000 connection-test-query: SELECT 1 leak-detection-threshold: 600003.3 Druid 容器化最优配置国内项目常用 Druid重点优化保活机制、检测频率、回收逻辑。spring: datasource: type: com.alibaba.druid.pool.DruidDataSource # 基础连接配置 initial-size: 3 max-active: 15 min-idle: 3 max-wait: 3000 # 核心保活与检测容器化必开 test-while-idle: true test-on-borrow: false test-on-return: false validation-query: SELECT 1 time-between-eviction-runs-millis: 30000 # 每30秒检测一次空闲连接 min-evictable-idle-time-millis: 60000 # 空闲60秒可回收 max-evictable-idle-time-millis: 1800000 # 最长30分钟强制回收 keep-alive: true # 开启保活维持最小空闲连接 # 泄露检测 remove-abandoned: true remove-abandoned-timeout: 60 log-abandoned: true3.4 容器化必加的两个配置max-lifetime 30 分钟必须比数据库空闲超时、网络设备超时都短主动淘汰连接永远不拿到死连接。leak-detection自动检测连接泄露长事务占着连接不释放会打日志告警是排查连接耗尽的神器。四、第二层数据库端连接参数适配金仓 / 达梦双库只调应用层不够数据库端也要配合两端参数对齐才能效果最大化。4.1 人大金仓 V9 连接参数优化写入kingbase.conf# 连接数控制 max_connections 500 # 总最大连接数按业务规模设置 superuser_reserved_connections 3 # 预留管理员连接防止全满登不进去 # 空闲连接回收 idle_in_transaction_session_timeout 30min # 空闲事务超时自动回滚释放连接 idle_session_timeout 60min # 空闲会话超时自动断开 statement_timeout 30min # 语句执行超时防止长SQL占连接 # TCP保活检测 tcp_keepalives_idle 300 # 空闲300秒开始发保活包 tcp_keepalives_interval 10 # 每10秒发一次 tcp_keepalives_count 6 # 失败6次判定断开主动回收连接 关键数据库端的空闲超时要大于应用连接池的 max-lifetime保证应用先主动回收不要等数据库断开。4.2 达梦 DM9 连接参数优化写入dm.ini# 连接数控制 MAX_CONNECTIONS 500 # 最大连接数 MAX_SESSIONS 1000 # 最大会话数 # 空闲与超时 IDLE_TIME 60 # 空闲会话超时单位分钟 CONNECT_TIMEOUT 10 # 连接建立超时单位秒 LOGIN_TIMEOUT 10 # 登录超时 # TCP保活 TCP_KEEP_ALIVE 1 # 开启TCP保活 TCP_KEEP_IDLE 300 # 空闲300秒开始探测 TCP_KEEP_INTERVAL 10 # 探测间隔10秒 TCP_KEEP_COUNT 6 # 探测失败次数 # 资源限制 MAX_STATEMENT_TIME 1800 # 语句最大执行时间单位秒4.2 连接数对齐原则所有应用连接池最大连接数总和 ≤ 数据库 max_connections × 70%预留 30% 给运维工具、监控、备份、主备同步使用绝对不能所有应用都往满了配高峰期直接打满数据库连接五、第三层K8s 网络层适配从根源减少断连容器化连接问题一半以上出在网络层这是物理机没有的额外环节。5.1 优先用 Headless Service 直连少走一层转发普通 ClusterIP Service 有一层 kube-proxy 转发长连接场景下容易出现超时、断连。数据库这种长连接场景优先用 Headless Service 直连 Pod IP优点少一层转发延迟更低断连概率大幅降低注意配合 DNS 缓存避免频繁解析# 应用连接串直接用Headless域名 url: jdbc:kingbase8://kingbase-headless.kingbase:54321/your_db5.2 节点内核参数调优解决空闲断连K8s 节点默认 TCP 保活时间是 7200 秒2 小时空闲连接早就被中间设备断开了。统一调整节点内核参数# 调整TCP保活5分钟开始探测快速发现死连接 net.ipv4.tcp_keepalive_time 300 net.ipv4.tcp_keepalive_intvl 10 net.ipv4.tcp_keepalive_probes 6 # 连接优化 net.ipv4.tcp_tw_reuse 1 # 复用TIME_WAIT连接 net.core.somaxconn 1024 # 加大连接队列深度应对突发连接通过 DaemonSet 批量给所有数据库节点配置一劳永逸。5.3 网络模式选型优先选Calico BGP 模式无隧道封装三层直连长连接最稳定避免 Flannel VXLAN 模式隧道封装增加开销长连接偶发断连kube-proxy 模式优先 ipvs 模式长连接性能和稳定性优于 iptables5.4 探针独立不要占用业务连接池很多图省事把数据库检测写进存活探针用业务连接池的连接结果探针频繁执行占用连接不说还可能打满连接。 ✅ 正确做法探针用独立的客户端命令比如livenessProbe: exec: command: [kb_isready, -U, monitor, -p, 54321] initialDelaySeconds: 90 periodSeconds: 15完全不占用业务连接池也不会因为探针导致连接数异常。六、分场景根治断连 / 耗尽 / 超时对应解决方案6.1 场景一频繁断连、空闲后首次请求失败根治方案三板斧应用连接池设置max-lifetime30分钟主动淘汰旧连接数据库开启 TCP 保活设置合理的空闲超时K8s 节点调整 TCP keepalive 参数缩短检测周期 ✅ 效果95% 以上的断连问题可以彻底解决不会再出现空闲后首次请求失败。6.2 场景二高峰期连接耗尽、获取超时排查与根治先查泄露开启连接泄露检测看是不是有长事务、未关闭的连接占着不放再看大小确认连接数配置是否合理不是太小就是太大快速失败连接超时设 3 秒不要无限等避免请求堆积雪崩扩容兜底确实不够的话优先加应用实例分散连接不要单实例猛加连接数6.3 场景三随机超时、SQL 执行快但整体慢排查方向检查是不是拿到了死连接第一次用的时候才发现断开超时重连检查 Service 转发延迟换成 Headless 直连检查 DNS 解析延迟应用开启 DNS 缓存检查节点网络是否有丢包、重传七、生产避坑10 个连接池最容易踩的致命错误⚠️坑 1连接数越大越好配 200 个才安心后果上下文切换剧增锁冲突加剧数据库性能反而下降还容易 OOM正解OLTP 场景单实例 10-20 个足够压测验证后再调整⚠️坑 2连接永久持有不设生命周期后果网络断开后全是死连接业务拿到就报错重启应用才好正解max-lifetime 必设30 分钟主动回收永远比网络超时短⚠️坑 3test-on-borrowtrue每次获取连接都检测后果每次借连接都执行一次查询性能下降明显正解test-while-idle 周期检测性能和可靠性平衡最好⚠️坑 4探针复用业务连接池后果探针频繁占用连接极端情况把连接池占满业务没连接用正解探针用独立命令行工具完全不碰业务连接池⚠️坑 5应用超时比数据库超时还长后果数据库都断开了应用还以为连接是好的拿到手就报错正解应用层超时 连接池生命周期 数据库空闲超时⚠️坑 6不开启连接泄露检测后果连接泄露了不知道慢慢打满连接池最后全超时正解开启泄露检测超时未归还自动打日志告警⚠️坑 7多个应用共享一套连接池配置后果低并发的应用连接池浪费高并发的应用不够用正解按业务量级分别配置核心系统单独调优⚠️坑 8容器资源不足连接池硬撑后果容器 CPU 打满连接处理不过来全排队超时正解先保证数据库容器资源充足再谈连接池优化⚠️坑 9只调应用层不管数据库端后果数据库端早就把连接断开了应用还在当有效连接用正解两端参数对齐协同优化⚠️坑 10出问题就加大连接数后果掩盖了连接泄露、长事务的根因越调问题越大正解先找根因泄露就治泄露不够再扩容八、监控告警连接池核心指标与告警规则连接池有没有问题不能等业务报错才知道监控必须跟上。8.1 核心监控指标指标说明正常范围活跃连接数正在使用的连接数≤ 最大连接数的 70%空闲连接数空闲可用的连接数≥ 最小空闲数等待线程数排队等连接的请求数 0获取连接平均耗时拿到连接的平均时间 10ms连接创建速率每秒新建连接数低且稳定突增 断连泄露连接数超时未归还的连接数 08.2 分级告警规则告警项触发条件级别连接等待告警等待线程数 0 持续 1 分钟严重连接使用率过高活跃连接占比 80% 持续 5 分钟一般获取连接耗时高平均获取耗时 100ms一般连接创建突增连接创建速率环比增长 100%严重大概率批量断连连接泄露告警泄露连接数 0严重总结容器化数据库连接问题从来不是单一原因导致的而是应用配置、数据库参数、K8s 网络三层共同作用的结果。只调某一层永远治标不治本三层协同优化才能彻底解决断连、超时、连接耗尽三大顽疾。连接池优化的本质从来不是堆连接数而是用最少的连接支撑最高的并发同时保证稳定性。把生命周期、检测机制、超时控制、网络适配这几件事做对容器化的连接体验完全可以追上物理机。政务选金仓金融选达梦MySQL 迁移选金仓Oracle 迁移选达梦。专栏推荐专注 SpringBoot3 人大金仓 达梦信创实战持续输出生产级部署、性能调优、运维监控、避坑指南干货关注不迷路。觉得文章有用的话欢迎点赞、收藏、关注三连后续更新更多信创数据库云原生落地的硬核内容。
摘要信创数据库迁到 K8s 后90% 的团队都会遇到连接类问题Pod 重启后批量断连报错、高峰期连接耗尽获取超时、空闲一段时间后首次请求必失败、随机出现 Broken pipe。很多人归罪于「数据库不稳定」「容器网络差」实则是连接池还在用物理机的老配置完全没适配容器化场景。本文基于政务、金融生产项目落地经验拆解容器化三大特有连接坑从应用层连接池、数据库端参数、K8s 网络层三层深度优化覆盖 HikariCP/Druid 双连接池、人大金仓 V9 / 达梦 DM9 双库专属配置、K8s Service 网络适配全套方案。所有配置均可直接复制照着做能彻底解决断连、超时、连接耗尽三大顽疾。政务选金仓金融选达梦MySQL 迁移选金仓Oracle 迁移选达梦。全文无空泛理论所有参数均经过生产压测验证。一、痛点直击容器化后为什么连接问题突然变多 核心结论物理机上跑的好好的连接池配置搬到 K8s 里必然出问题因为容器环境有三个物理机不存在的特有坑。1.1 容器化三大特有连接坑Pod 生命周期短漂移重建是常态物理机数据库几月不重启连接池长连接可以一直用K8s 里数据库 Pod 重建、漂移、升级是常规操作重建后连接池里的旧连接全部变成死连接业务拿到就报错。网络链路长空闲连接悄悄断开物理机应用直连数据库中间只有交换机K8s 里链路是应用 Pod → Service → iptables/ipvs → 数据库 Pod中间还有内核 conntrack、网络策略、节点防火墙。空闲连接超过阈值会被中间设备悄悄断开应用层完全感知不到下次用的时候直接报错。资源边界硬连接数失控容易雪崩物理机资源充足连接池配大一点也没事容器有 CPU、内存硬限制连接数过大容易触发数据库 OOM、连接数打满进而引发连接池排队、业务雪崩。1.2 最常见的故障表现数据库 Pod 重启后应用报大量Broken pipe、连接已关闭重启应用才恢复低峰期过后第一次请求必超时第二次就正常高峰期报获取连接超时数据库端看连接数直接打满随机出现请求超时数据库里看 SQL 本身执行很快二、先定位三类连接故障的典型特征与根因遇到连接问题先别瞎调参数1 分钟判断类型精准解决。故障类型典型现象核心根因优先级频繁断连空闲后首次请求失败、Pod 重启后批量报错、Broken pipe死连接未及时回收中间设备断开空闲连接⭐⭐⭐⭐⭐连接耗尽高峰期获取连接超时、连接池全满、数据库连接数打满连接数配置不合理、连接泄露、长事务占连接⭐⭐⭐⭐⭐随机超时偶发请求超时、SQL 执行很快但整体耗时高网络转发损耗、连接池排队、DNS 解析延迟⭐⭐⭐ 快速判断技巧重启应用后问题消失过一段时间又出现 → 基本是死连接问题只有高峰期出现 → 基本是连接数不够或泄露。三、第一层应用层连接池核心优化HikariCP/Druid 双模板连接池优化的核心原则连接数不是越大越好够用就行死连接要主动回收不要等网络断开。3.1 先搞懂连接数到底配多大合适很多人一上来就配最大连接数 200这是典型的物理机思维误区。数据库最佳连接数公式核心数 * 2 有效磁盘数普通 SSD 磁盘8 核数据库最佳活跃连接数也就 16-20 个。连接数过多只会增加上下文切换、锁冲突性能反而下降。✅ 生产推荐配置单应用实例最大连接数 10~20足够支撑上千 QPS 的 OLTP 业务多实例部署按实例数叠加总连接数不超过数据库最大连接数的 70%核心原则小连接池 排队等待胜过大连接池 上下文切换3.2 HikariCP 容器化最优配置SpringBoot 默认HikariCP 性能最高重点优化连接生命周期、空闲检测、超时控制三个点。人大金仓 V9 配置模板spring: datasource: driver-class-name: com.kingbase8.Driver url: jdbc:kingbase8://kingbase-svc.kingbase:54321/your_db?currentSchemapublic username: your_user password: your_password hikari: # 核心连接数配置 maximum-pool-size: 15 # 最大连接数按业务压测调整 minimum-idle: 5 # 最小空闲连接 # 生死周期配置容器化核心 max-lifetime: 1800000 # 连接最大生命周期30分钟主动回收死连接 idle-timeout: 60000 # 空闲连接超时60秒回收 connection-timeout: 3000 # 获取连接超时3秒快速失败避免雪崩 # 存活检测配置 connection-test-query: SELECT 1 test-while-idle: true validation-timeout: 1000 # 兜底控制 leak-detection-threshold: 60000 # 连接泄露检测60秒未归还告警达梦 DM9 配置模板spring: datasource: driver-class-name: dm.jdbc.driver.DmDriver url: jdbc:dm://dmdb-svc.dmdb:5236/your_db username: your_user password: your_password hikari: maximum-pool-size: 15 minimum-idle: 5 max-lifetime: 1800000 # 30分钟主动回收适配达梦空闲超时 idle-timeout: 60000 connection-timeout: 3000 connection-test-query: SELECT 1 leak-detection-threshold: 600003.3 Druid 容器化最优配置国内项目常用 Druid重点优化保活机制、检测频率、回收逻辑。spring: datasource: type: com.alibaba.druid.pool.DruidDataSource # 基础连接配置 initial-size: 3 max-active: 15 min-idle: 3 max-wait: 3000 # 核心保活与检测容器化必开 test-while-idle: true test-on-borrow: false test-on-return: false validation-query: SELECT 1 time-between-eviction-runs-millis: 30000 # 每30秒检测一次空闲连接 min-evictable-idle-time-millis: 60000 # 空闲60秒可回收 max-evictable-idle-time-millis: 1800000 # 最长30分钟强制回收 keep-alive: true # 开启保活维持最小空闲连接 # 泄露检测 remove-abandoned: true remove-abandoned-timeout: 60 log-abandoned: true3.4 容器化必加的两个配置max-lifetime 30 分钟必须比数据库空闲超时、网络设备超时都短主动淘汰连接永远不拿到死连接。leak-detection自动检测连接泄露长事务占着连接不释放会打日志告警是排查连接耗尽的神器。四、第二层数据库端连接参数适配金仓 / 达梦双库只调应用层不够数据库端也要配合两端参数对齐才能效果最大化。4.1 人大金仓 V9 连接参数优化写入kingbase.conf# 连接数控制 max_connections 500 # 总最大连接数按业务规模设置 superuser_reserved_connections 3 # 预留管理员连接防止全满登不进去 # 空闲连接回收 idle_in_transaction_session_timeout 30min # 空闲事务超时自动回滚释放连接 idle_session_timeout 60min # 空闲会话超时自动断开 statement_timeout 30min # 语句执行超时防止长SQL占连接 # TCP保活检测 tcp_keepalives_idle 300 # 空闲300秒开始发保活包 tcp_keepalives_interval 10 # 每10秒发一次 tcp_keepalives_count 6 # 失败6次判定断开主动回收连接 关键数据库端的空闲超时要大于应用连接池的 max-lifetime保证应用先主动回收不要等数据库断开。4.2 达梦 DM9 连接参数优化写入dm.ini# 连接数控制 MAX_CONNECTIONS 500 # 最大连接数 MAX_SESSIONS 1000 # 最大会话数 # 空闲与超时 IDLE_TIME 60 # 空闲会话超时单位分钟 CONNECT_TIMEOUT 10 # 连接建立超时单位秒 LOGIN_TIMEOUT 10 # 登录超时 # TCP保活 TCP_KEEP_ALIVE 1 # 开启TCP保活 TCP_KEEP_IDLE 300 # 空闲300秒开始探测 TCP_KEEP_INTERVAL 10 # 探测间隔10秒 TCP_KEEP_COUNT 6 # 探测失败次数 # 资源限制 MAX_STATEMENT_TIME 1800 # 语句最大执行时间单位秒4.2 连接数对齐原则所有应用连接池最大连接数总和 ≤ 数据库 max_connections × 70%预留 30% 给运维工具、监控、备份、主备同步使用绝对不能所有应用都往满了配高峰期直接打满数据库连接五、第三层K8s 网络层适配从根源减少断连容器化连接问题一半以上出在网络层这是物理机没有的额外环节。5.1 优先用 Headless Service 直连少走一层转发普通 ClusterIP Service 有一层 kube-proxy 转发长连接场景下容易出现超时、断连。数据库这种长连接场景优先用 Headless Service 直连 Pod IP优点少一层转发延迟更低断连概率大幅降低注意配合 DNS 缓存避免频繁解析# 应用连接串直接用Headless域名 url: jdbc:kingbase8://kingbase-headless.kingbase:54321/your_db5.2 节点内核参数调优解决空闲断连K8s 节点默认 TCP 保活时间是 7200 秒2 小时空闲连接早就被中间设备断开了。统一调整节点内核参数# 调整TCP保活5分钟开始探测快速发现死连接 net.ipv4.tcp_keepalive_time 300 net.ipv4.tcp_keepalive_intvl 10 net.ipv4.tcp_keepalive_probes 6 # 连接优化 net.ipv4.tcp_tw_reuse 1 # 复用TIME_WAIT连接 net.core.somaxconn 1024 # 加大连接队列深度应对突发连接通过 DaemonSet 批量给所有数据库节点配置一劳永逸。5.3 网络模式选型优先选Calico BGP 模式无隧道封装三层直连长连接最稳定避免 Flannel VXLAN 模式隧道封装增加开销长连接偶发断连kube-proxy 模式优先 ipvs 模式长连接性能和稳定性优于 iptables5.4 探针独立不要占用业务连接池很多图省事把数据库检测写进存活探针用业务连接池的连接结果探针频繁执行占用连接不说还可能打满连接。 ✅ 正确做法探针用独立的客户端命令比如livenessProbe: exec: command: [kb_isready, -U, monitor, -p, 54321] initialDelaySeconds: 90 periodSeconds: 15完全不占用业务连接池也不会因为探针导致连接数异常。六、分场景根治断连 / 耗尽 / 超时对应解决方案6.1 场景一频繁断连、空闲后首次请求失败根治方案三板斧应用连接池设置max-lifetime30分钟主动淘汰旧连接数据库开启 TCP 保活设置合理的空闲超时K8s 节点调整 TCP keepalive 参数缩短检测周期 ✅ 效果95% 以上的断连问题可以彻底解决不会再出现空闲后首次请求失败。6.2 场景二高峰期连接耗尽、获取超时排查与根治先查泄露开启连接泄露检测看是不是有长事务、未关闭的连接占着不放再看大小确认连接数配置是否合理不是太小就是太大快速失败连接超时设 3 秒不要无限等避免请求堆积雪崩扩容兜底确实不够的话优先加应用实例分散连接不要单实例猛加连接数6.3 场景三随机超时、SQL 执行快但整体慢排查方向检查是不是拿到了死连接第一次用的时候才发现断开超时重连检查 Service 转发延迟换成 Headless 直连检查 DNS 解析延迟应用开启 DNS 缓存检查节点网络是否有丢包、重传七、生产避坑10 个连接池最容易踩的致命错误⚠️坑 1连接数越大越好配 200 个才安心后果上下文切换剧增锁冲突加剧数据库性能反而下降还容易 OOM正解OLTP 场景单实例 10-20 个足够压测验证后再调整⚠️坑 2连接永久持有不设生命周期后果网络断开后全是死连接业务拿到就报错重启应用才好正解max-lifetime 必设30 分钟主动回收永远比网络超时短⚠️坑 3test-on-borrowtrue每次获取连接都检测后果每次借连接都执行一次查询性能下降明显正解test-while-idle 周期检测性能和可靠性平衡最好⚠️坑 4探针复用业务连接池后果探针频繁占用连接极端情况把连接池占满业务没连接用正解探针用独立命令行工具完全不碰业务连接池⚠️坑 5应用超时比数据库超时还长后果数据库都断开了应用还以为连接是好的拿到手就报错正解应用层超时 连接池生命周期 数据库空闲超时⚠️坑 6不开启连接泄露检测后果连接泄露了不知道慢慢打满连接池最后全超时正解开启泄露检测超时未归还自动打日志告警⚠️坑 7多个应用共享一套连接池配置后果低并发的应用连接池浪费高并发的应用不够用正解按业务量级分别配置核心系统单独调优⚠️坑 8容器资源不足连接池硬撑后果容器 CPU 打满连接处理不过来全排队超时正解先保证数据库容器资源充足再谈连接池优化⚠️坑 9只调应用层不管数据库端后果数据库端早就把连接断开了应用还在当有效连接用正解两端参数对齐协同优化⚠️坑 10出问题就加大连接数后果掩盖了连接泄露、长事务的根因越调问题越大正解先找根因泄露就治泄露不够再扩容八、监控告警连接池核心指标与告警规则连接池有没有问题不能等业务报错才知道监控必须跟上。8.1 核心监控指标指标说明正常范围活跃连接数正在使用的连接数≤ 最大连接数的 70%空闲连接数空闲可用的连接数≥ 最小空闲数等待线程数排队等连接的请求数 0获取连接平均耗时拿到连接的平均时间 10ms连接创建速率每秒新建连接数低且稳定突增 断连泄露连接数超时未归还的连接数 08.2 分级告警规则告警项触发条件级别连接等待告警等待线程数 0 持续 1 分钟严重连接使用率过高活跃连接占比 80% 持续 5 分钟一般获取连接耗时高平均获取耗时 100ms一般连接创建突增连接创建速率环比增长 100%严重大概率批量断连连接泄露告警泄露连接数 0严重总结容器化数据库连接问题从来不是单一原因导致的而是应用配置、数据库参数、K8s 网络三层共同作用的结果。只调某一层永远治标不治本三层协同优化才能彻底解决断连、超时、连接耗尽三大顽疾。连接池优化的本质从来不是堆连接数而是用最少的连接支撑最高的并发同时保证稳定性。把生命周期、检测机制、超时控制、网络适配这几件事做对容器化的连接体验完全可以追上物理机。政务选金仓金融选达梦MySQL 迁移选金仓Oracle 迁移选达梦。专栏推荐专注 SpringBoot3 人大金仓 达梦信创实战持续输出生产级部署、性能调优、运维监控、避坑指南干货关注不迷路。觉得文章有用的话欢迎点赞、收藏、关注三连后续更新更多信创数据库云原生落地的硬核内容。
)
