为何MongoDB没有类似PgBouncer、Pgpool的连接池中间件？

首先澄清认知：Mongo存在同类连接池中间件 #

开源生态和官方都有对应的实现，比如官方Atlas服务内置了连接池代理组件，开源社区也有mongoproxy、Percona配套的Mongo代理实现，国内很多大规模用Mongo的大厂也都有自研的连接池代理层，只是这类工具的适用场景比较窄，所以普通用户接触得少。

普及度低的核心原因 #

• 服务端连接模型的差异：PG的服务端是进程级连接模型，每新建一个连接就要fork独立进程，资源开销极高，单实例一般最多承载数百个活跃连接就到瓶颈，连接池代理属于刚需工具。而MongoDB 3.0之后切换为线程级连接模型，单个连接仅对应服务端一个轻量级线程，内存开销只有几百KB，单实例默认就能承载上万级别的连接，绝大多数中小使用场景下根本不会遇到连接数打满的问题，对代理的需求很低。
• 分布式架构自带连接复用能力：Mongo分片集群自带mongos路由层，mongos本身就内置了连接池管理能力，会自动复用和后端mongod节点的连接，大部分场景下已经承担了连接收敛的作用，不需要额外再加一层代理。
• 官方更推荐应用侧配置优化：Mongo所有官方驱动都内置了高度可配置的连接池组件，支持最大连接数、闲置连接驱逐、连接超时等全量参数，这类故障本质是应用设计缺陷，盲目配置大容量连接池导致的，只要合理调整应用连接池配置（单个应用实例的连接数一般控制在10~50之间即可满足绝大多数场景的QPS需求），完全可以避免这类问题，调整配置的成本和收益都远高于搭建代理层。

哪些场景需要用Mongo连接池代理 #

• 接入的应用数量极多，且没有权限推动所有业务方调整连接池配置
• 需要统一做连接审计、权限管控、流量熔断等额外管控能力
• 超大规模分片集群下，需要进一步收敛mongos到mongod的连接数开销

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