场景描述
当数据库的连接拓扑（网络路由）确立后，应用代码层面的连接池配置与安全防护将直接决定系统的稳定性与数据资产的安全。在日常开发与排障中，团队经常会因“配置不当”而遭遇以下高危场景：
连接数超限风险： 在微服务架构下，若频繁使用短连接，或在多应用实例中将 maxPoolSize 设置过大，系统总并发连接数可能超出数据库的连接上限。这将导致新请求发生排队或超时，影响系统的整体可用性。
读写策略匹配不当： 读写分离配置需与业务场景相匹配。若在核心交易中读取从库，可能因主从同步延迟导致数据读取不一致；而高频的分析与报表查询若未配置读写分离，则会显著增加主库（Primary）的性能负载。
数据安全与合规风险： 在开发或测试过程中，部分业务可能会开启数据库的公网访问，且未配置复杂的鉴权密码。此类缺乏网络边界管控与权限最小化隔离的配置，不仅不符合安全合规要求，还会显著增加数据泄露、恶意篡改及外部勒索攻击的风险。
连接规范总览表
规范编号 | 规范名称 | 核心要求 | 适用范围 | 约束等级 |
规范一 | 正确配置连接串核心参数 | 必须使用高可用连接地址。 必须包含 `authSource=admin`。 副本集必须指定 `replicaSet`。 建议开启 `retryWrites` 和 `retryReads`。 | 副本集 / 分片集群 |  |
规范二 | 建议使用连接池（长连接） | 生产环境不建议使用短连接，建议使用连接池复用连接。 | 副本集 / 分片集群 |  |
规范三 | 连接池参数合理配置 | 根据业务并发量计算 `maxPoolSize`，总连接数不超过实例上限的 80% | 副本集 / 分片集群 |  |
规范四 | 根据业务场景选择读偏好 | 核心强一致业务读 Primary，非敏感业务读 Secondary，读写分离建议 `secondaryPreferred`。 | 副本集 / 分片集群 |  |
规范五 | 线上环境禁止关闭鉴权或随意暴露外网 | 必须开启鉴权，仅内网访问。 外网必须通过 CLB 并配置安全组和 IP 限制。 | 副本集 / 分片集群 |  |
规范一：正确配置连接串核心参数
连接串（URI）参数的配置直接决定了数据库的可用性。请务必遵循以下四项核心准则：
1. 接入地址：严禁单点连接。
指令：连接串必须包含集群内所有可用节点（Seed List）。
原因：避免单点故障。仅指向单个节点将导致驱动程序无法在节点切换时自动发现新的 Primary，失去高可用能力。
2. 鉴权参数：明确 authSource。
指令：必须显式指定鉴权数据库参数。
通过控制台创建的用户：固定配置 authSource=admin。
通过命令行创建的用户：配置为用户所属的逻辑数据库。
原因：确保身份验证逻辑准确，避免因默认库不一致导致的连接认证失败。
3. 架构感知：必须携带 replicaSet。
指令：副本集连接串必须包含 replicaSet=<副本集名称>。
原因：只有显式指定该参数，驱动才能在故障发生时自动将流量重定向至新主节点，实现无感知切换。
4. 容灾增强：开启自动重试（推荐）。
指令：建议追加参数 retryWrites=true 与 retryReads=true。
原因：提升网络容错率。在发生瞬时网络抖动或主从选举期间，由驱动层自动发起重试，将故障影响降至最低。
连接串关键参数说明
参数 | 必填 | 说明 | 示例值 |
`authSource` | 是 | 认证数据库，腾讯云统一为 admin | `admin` |
`replicaSet` | 副本集必填 | 副本集名称，从控制台获取 | `cmgo-xxxxxxxx` |
`readPreference` | 建议 | 读偏好设置 | `secondaryPreferred` |
`maxPoolSize` | 建议 | 连接池最大连接数 | `150` |
`retryWrites` | 建议 | 自动重试写入 | `true` |
`retryReads` | 建议 | 自动重试读取 | `true` |
`w` | 核心业务必填 | 写确认级别 | `majority` |
业务应用
某金融系统使用副本集架构（1 Primary + 2 Secondary），连接串中未指定 replicaSet 参数。由于缺少该参数，MongoDB 驱动将连接视为 Standalone 模式，即直接连接到连接串中指定的单个节点，而不会感知副本集的整体拓扑结构。
日常运行期间未出现异常，但在一次计划内的运维操作中，Primary 节点发生主从切换，原 Primary 降级为 Secondary，另一个 Secondary 被选举为新 Primary。此时，驱动仍然持续向原节点（已降级为 Secondary）发送写请求，而 Secondary 节点默认拒绝写操作，导致业务端出现大量 not master 错误，写入失败持续约15分钟。
运维人员手动重启应用并更新连接地址后恢复。在连接串中添加 replicaSet=cmgo-xxxxxxxx 参数后，驱动以副本集模式运行，自动感知拓扑变化，在 Primary 切换后的数秒内自动将写请求路由至新 Primary，业务无需重启、无需修改连接地址，实现故障的自动恢复。
规范二：必须使用连接池（长连接）
生产环境建议使用连接池（长连接），不建议使用短连接模式。
短连接模式下，每次数据库请求都需要经历 TCP 三次握手、TLS 协商（如开启加密传输）和 SCRAM 鉴权等完整流程，单次连接建立耗时通常在10-50ms。
在高并发场景下，频繁的连接创建与销毁不仅大幅增加请求延迟，还会迅速耗尽实例的连接数上限，导致后续请求无法获取连接而超时失败。
连接池通过预先建立连接并在多次请求间复用，省去了重复的握手和鉴权开销，能够在高并发下保持连接数稳定可控、响应延迟在毫秒级。
短连接 vs 长连接对比
维度 | 短连接 | 长连接（连接池） |
连接建立 | 每次请求新建 | 复用已建立连接 |
认证开销 | 每次都要认证（10-50ms） | 仅首次认证 |
连接数 | 随 QPS 线性增长 | 稳定可控 |
适用场景 | 不适用于生产 | 所有生产环境 |
业务应用
某电商平台早期使用 PHP 短连接模式，每次数据库请求都新建连接，请求结束后立即销毁。日常流量（QPS 约1000）下运行正常，但在大促期间 QPS 从 1000飙升至10000。由于每个请求都需要独占一条连接，连接建立速度远跟不上请求到达速度，MongoDB 实例的连接数在数分钟内从200飙升至3000（实例默认上限），随后所有新请求因无法获取连接而排队超时，接口平均响应时间从50ms恶化至5秒以上，大量订单提交失败。改用连接池（maxPoolSize=200）后，应用启动时预先建立一批连接并在请求间复用，省去了重复的握手和认证开销。即使在次年大促 QPS 达到50000的情况下，实际连接数也稳定在500以内，接口响应时间始终保持在毫秒级。
说明：
对于 Serverless、PHP-FPM 等无法在应用内存中维持长连接池的架构，建议在业务层与数据库之间引入中间件代理（Proxy）来实现连接池化。
规范三：连接池参数合理配置
连接池大小（maxPoolSize）并非越大越好。配置过大会导致全局连接数瞬间打满，新请求被数据库拒绝；配置过小则会在业务高峰期出现本地排队等待，徒增请求延迟。正确配置连接池，必须综合考量单次请求耗时、应用实例扩容边界以及网络接入拓扑。
不同连接方式的连接数计算
理论上的全局总连接数，不得超过 MongoDB 实例连接数上限的80%，以应对突发的业务扩容或主从重连。在使用分片集群时，底层驱动建立连接池的逻辑会因接入方式产生“乘数放大效应”。请在推算前明确以下三个关键变量：
A (Application)：当前部署的业务应用总数。
P (Pool Size)：单个应用配置的 maxPoolSize 值。
M (Mongos)：通过 SRV 解析出或在连接串中指定的 Mongos 节点总数。
连接接入方式 | 驱动连接行为 | 理论总连接数计算公式 |
LB 负载均衡（内网 VIP 等） | 驱动将 LB 视作单一节点，仅与 LB 建立一个连接池，由 LB 在底层分发请求。 | A x P |
SRV 记录连接 | 驱动会自动解析 SRV 记录，并与集群背后的每一个 Mongos 节点分别建立独立的连接池。 | A x P x M |
直连所有 Mongos | 驱动会与连接串（URI）中显式配置的每一个 Mongos 节点分别建立独立的连接池。 | A x P x M |
maxPoolSize 参数推算建议
绝大多数连接数超限的故障，都源于开发者盲目使用默认值或将 QPS 错误等同于连接数。请按照以下步骤反推单个应用的合理 maxPoolSize：
步骤一：计算单个应用基础并发需量
并发连接数取决于请求量与处理速度。公式为：单个应用基础需量 = (单个应用预期峰值 QPS × 数据库平均响应耗时秒数) × 1.5（抗抖动系数）。例如，单实例峰值1000 QPS，平均每次查询耗时0.02秒（20ms），则基础并发需量为1000 × 0.02 × 1.5 = 30。
步骤二：结合拓扑架构计算最终值
如果是 LB 负载均衡模式：直接使用基础需量即可，即 maxPoolSize ≈ 30。
如果是 SRV 或直连多 Mongos 模式：由于请求会被驱动自动分散到 M 个节点的连接池中，为了防止全局总连接数按倍数超限，必须进行等比缩减。即 maxPoolSize ≈ 基础需量 ÷ M。
连接池参数配置参考
参数 | 说明 | 建议值 | 不当配置的后果 |
`maxPoolSize` | 最大连接数 | 50-200 | 过大：超限；过小：排队 |
`minPoolSize` | 最小连接数 | 5-20 | 过小：冷启动慢 |
`maxIdleTimeMS` | 最大空闲时间 | 60000-300000 | 过小：频繁重建 |
`waitQueueTimeoutMS` | 等待超时 | 5000-10000 | 过短：正常请求被拒 |
`connectTimeoutMS` | 连接超时 | 10000-30000 | 过短：网络抖动时失败 |
业务应用
某内容平台部署了20个应用，通过 LB 负载均衡连接分片集群，每个应用的 maxPoolSize 配置为200（直接使用了驱动默认值）。理论总连接数为20 × 200 = 4000，实际上已经埋下了超过 MongoDB 实例连接数上限（3000）的隐患。
日常低峰期由于实际并发较低，连接池未被填满，运行正常。但在一次业务扩容中新增了5个应用，25个应用同时启动并初始化连接池，连接数瞬间接近 5000，触发实例连接数上限保护，后启动的5个应用全部报
connection pool exhausted 错误，无法连接数据库，新上线的功能模块完全不可用。排障后，将
maxPoolSize 从200调整为100后，总连接数上限降为25 × 100 = 2500，占实例连接数上限的83%，并预留了后续扩容至30个应用的空间。同时设置 minPoolSize=10 确保冷启动时有足够的预热连接，解决了扩容时的连接雪崩问题。规范四：根据业务场景选择读偏好
readPreference（读偏好）决定了 MongoDB 驱动将读请求发往哪个节点。不同业务场景对数据一致性的要求不同：核心交易（如转账、下单）需要读到最新数据，必须从 Primary 读取；而报表分析、历史查询等对实时性不敏感的场景，可以从 Secondary 读取以分担 Primary 压力。选择不当会导致两类问题：将强一致性要求的读请求发往 Secondary，业务可能读到过时数据引发逻辑错误；将所有读请求集中在 Primary，则 Secondary 节点资源闲置，Primary 在高并发下成为瓶颈。读偏好选择决策表
说明：
业务需要读写分离时建议使用
secondaryPreferred，可用性更高。如果有业务仅访问只读节点，建议配置两个或两个以上只读节点实现读请求负载均衡。只读节点连接串可直接在实例详情页面的网络配置中获取。读偏好 | 一致性 | 适用场景 |
`primary` | 强一致 | 转账后查余额、下单后查订单状态 |
`primaryPreferred` | 强一致优先 | 一般业务，Primary 不可用时降级到 Secondary |
`secondary` | 最终一致 | 纯读场景、报表查询、数据分析 |
`secondaryPreferred` | 最终一致优先 | 读多写少场景，分担 Primary 压力（推荐） |
`nearest` | 取决于节点 | 地理分布式部署，就近访问 |
业务应用
某银行的核心系统中，账户余额查询接口配置了
readPreference=secondary。用户在完成一笔转账（写入 Primary）后立即查询余额，由于主从同步存在 10-100ms 的延迟，Secondary 节点上的数据尚未更新，接口返回的仍是转账前的旧余额。用户看到转账成功但余额未变，频繁发起重复转账或拨打客服投诉。将该接口改为 readPreference=primary 后，余额查询直接从 Primary 读取，确保转账后立即返回准确余额，投诉量下降。而对于不要求实时性的历史账单查询和月度报表导出，仍保持 readPreference=secondaryPreferred，将约60%的读流量分流至 Secondary 节点，Primary 的 CPU 使用率从85%降至 50%，读写延迟均有所改善。说明：
启用 secondary 或 secondaryPreferred 时，业务代码必须能容忍因主从复制延迟带来的数据非强一致性（Stale Reads）风险。
规范五：线上环境禁止关闭鉴权或暴露外网
MongoDB 实例线上环境必须开启鉴权（Authentication），且仅允许通过内网（VPC）访问。未开启鉴权的实例相当于对所有能访问该 IP 的客户端完全开放读写权限，一旦被扫描发现将面临数据泄露或被勒索删库的风险。如业务确需外网访问，必须通过 CLB（负载均衡）配置外网访问服务，并同时满足以下条件：为 CLB 和 MongoDB 实例分别配置安全组，仅放通指定的客户端外网 IP；启用 SSL/TLS 加密传输，防止数据在公网传输过程中被截获；使用高强度密码（12 位以上，含大小写字母、数字和特殊字符），降低暴力破解风险。
安全配置要求
1. 网络边界隔离（VPC 与安全组）：默认仅限内网访问，公网访问必须经过严格的网络边界管控。
默认内网直连：生产环境务必仅允许通过同一 VPC（私有网络）下的应用服务器进行内网访问。
合规的公网访问架构：若业务（如跨地域调试、外部数据直连）确需公网访问，严禁为实例直接绑定公网 IP。必须通过 CLB（负载均衡）打通外网访问路径，并强制实行双层安全组管控：
CLB 安全组：仅放通特定客户端的外网 IP（如公司出口 IP）及监听器端口，实施第一道拦截。
MongoDB 安全组：仅放通指定的客户端外网 IP 以及27017端口，同时必须放通 CLB 实例的 VIP 地址（用于保障 CLB 节点对后端数据库的健康探测正常运行）。
2. 访问鉴权与最小化授权：禁止免密登录，应用账号与管理账号严格分离。
强制开启鉴权：实例必须开启 Authentication 机制。
高强度密码验证：数据库密码必须大于12位，且包含大小写字母、数字及特殊字符。杜绝使用 admin123、root 等弱口令，以防暴力破解。
遵循最小权限原则（Least Privilege）：禁止业务应用直接使用 root 或拥有 dbAdminAnyDatabase 权限的超级账号连接数据库。必须为每个具体的业务模块创建专用的数据库账号，并仅授予对应业务库的 readWrite 权限。
3. 传输层加密（TLS/SSL）：凡是涉及公网链路的传输，必须加密。
防抓包与中间人攻击：一旦启用了公网访问链路，必须在控制台开启 SSL/TLS 加密传输功能。并在应用端连接串中显式追加 tls=true，确保数据在不可信的公网传输过程中不会被明文截获或篡改。
安全配置自检清单
检查维度 | 检查项 | 合规标准 |
网络层 | 公网暴露面 | 仅允许内网访问；公网需求必须通过 CLB 代理并配置白名单。 |
网络层 | 安全组策略 | 严禁配置0.0.0.0/0全放通，仅允许明确的源 IP 访问。 |
认证层 | 身份鉴权 | 必须开启鉴权功能。 |
认证层 | 密码复杂度 | 长度 ≥ 12 位，包含大小写字母、数字及特殊符号。 |
授权层 | 最小权限 | 应用账号仅具备目标库的读写权限，无管理权限。 |
传输层 | SSL/TLS 加密 | 开启外网访问时，必须强制启用 SSL/TLS。 |
应用层 | 凭据安全存储 | 数据库账号密码禁止硬编码在代码中，应使用环境变量或 KMS 服务。 |
相关文档
开启外网访问
