MongoDB分片集群如何配置高可用？Mongos多实例部署与Keepalived负载均衡

先明确几个核心原则：mongos进程必须独立部署，并且要禁用localhost绑定；健康检查不能只看进程是否活着，更要验证其内部状态是否正常；config server副本集节点数必须是奇数，并且必须启用majority写关注。这些是构建稳定高可用架构的基石。

mongos 实例必须独立部署，不能和 config server 或 shard 同机

mongos本质上是一个无状态的路由进程，它本身不存储数据，但会缓存整个集群的元数据，比如数据块（chunk）的分布、分片（shard）的列表等等。问题就出在这里：如果把它和config server或者shard部署在同一台物理机上，一旦这台机器宕机，带来的就是连锁反应——不仅对应的数据分片服务中断，连带着mongos也会失联。更麻烦的是，其他存活的mongos实例可能因为无法及时刷新元数据，导致路由信息过时甚至出错。

具体怎么操作？这里有几个关键点：

• 资源隔离：每个mongos实例最好独占一台物理机或容器。CPU和内存资源需要根据预期的并发量来预留，通常4核8GB可以作为起步配置。如果预估的查询每秒并发数（QPS）超过5000，那就一定要进行压测来验证资源是否足够。
• 绑定地址：启动mongos时，务必避免使用localhost或127.0.0.1作为--bind_ip的参数。在生产环境中，必须绑定具体的内网IP地址，否则客户端将无法从其他机器进行访问。
• 连接配置：启动命令中，config server的地址必须显式、完整地指定。格式应该是配置副本集名称/配置服务器01地址:端口,配置服务器02地址:端口,...，那个副本集的名称千万不能省略。

Keepalived + VIP 方案只解决 mongos 接入层单点，不替代 mongos 自身高可用逻辑

这是一个常见的理解误区。Keepalived配合虚拟IP（VIP）确实能解决接入层的单点故障问题，但它无法感知mongos进程内部的健康状态。什么意思呢？比如，一个mongos进程虽然还在运行，但它内部的元数据可能已经过期了，或者连接config server超时，又或者对后端某个shard的心跳检测失败了。这些内部故障，Keepalived默认的端口连通性检查是发现不了的。

如果健康检查脚本只是简单地用kill -9命令探测进程是否存在，那很可能出现一种尴尬局面：VIP漂移到了一个“活着但已病入膏肓”的mongos实例上，导致客户端请求持续发往一个实际上不可用的路由节点。

那么，正确的姿势是什么？

• 深度健康检查：Keepalived配置中的vrrp_script必须调用真实的业务健康检查。例如，通过mongo --host 127.0.0.1:27017 --eval "db.runCommand({ping:1})"这样的命令，不仅要看返回码是否为0，还要判断命令的响应时间。通常建议将超时阈值设置在500毫秒以内。
• 接入层抽象：不建议让应用直接连接VIP。更好的做法是，应用通过DNS解析一个固定的服务域名（比如mongos-prod.example.com），而这个域名通过CNAME记录指向承载VIP的负载均衡器域名。这样，未来如果需要更换负载均衡方案，对应用层就是透明的。
• 防抖动策略：在Keepalived的主备模式下，建议将preempt_delay（抢占延迟）参数设置为30秒以上，这样可以有效避免因网络短暂波动而引发的VIP频繁切换，提升稳定性。

多个 mongos 实例间不共享连接池或查询计划缓存

这是由mongos的设计架构决定的，并非缺陷。每个mongos实例都是完全独立的，它们各自维护着自己的连接池、查询计划缓存以及数据块缓存。这带来的直接影响就是，当客户端在多个mongos实例之间进行轮询访问时，相同的查询可能会在不同的mongos上被重复解析，并且会重复建立到后端shard的连接，从而产生额外的开销。

这种设计会带来哪些具体影响，又该如何应对？

• 连接数膨胀：假设应用每秒需要建立100个新连接，如果有3个mongos实例，那么后端shard就可能面临每秒300个连接请求的压力。应对策略是，必须在应用侧限制最大连接数，同时别忘了启用mongos的--maxConns参数来限制其自身的最大连接数。
• 查询计划不一致：同一条查询语句，在不同mongos上可能因为缓存命中情况不同而选择不同的索引执行路径，导致性能表现不稳定。排查方法是，可以通过explain(“executionStats”)命令分别在各个mongos上执行并对比结果。如果发现不一致且影响性能，可能需要考虑使用hint()强制指定索引，或者重新审视索引设计。
• 会话粘滞缺失：MongoDB本身没有提供跨mongos的会话粘滞机制。这意味着，如果一个事务内的操作被打到了不同的mongos上，事务将会失败。因此，应用层必须自己保证事务内的所有操作都路由到同一个mongos实例。实现方式可以是在负载均衡器（如Keepalived）上配置基于客户端IP的source_hash策略，或者由应用自己来维护与某个mongos端点的绑定关系。

config server replica set 必须是奇数节点且开启 majority write concern

config server堪称整个分片集群的“大脑”，所有关键的元数据都存储于此。一旦它不可用，mongos就无法获取到数据块分裂、迁移等变更信息，最终会导致写入阻塞或路由错误。为了保证这个“大脑”的高可用和决策一致性，副本集的成员数量必须为奇数（推荐3个或5个），这是为了防止在选举主节点时出现票数平局而无法选出主节点的情况。

在配置上，有几个细节必须敲黑板：

• 初始化标记：初始化config server副本集时，必须通过replSetInitiate命令显式设置configsvr: true这个参数。如果没有这个标记，mongos会拒绝连接。
• 写关注级别：所有对config server的写操作（包括自动的数据块分裂和迁移），默认都要求w: “majority”的写关注级别。这意味着，如果config server副本集中有节点长期离线，导致无法满足“大多数”节点确认的条件，那么元数据的写入操作就会被卡住。因此，必须及时排查网络或磁盘问题，确保副本集健康。
• 操作禁区：绝对禁止在config server上直接执行任何针对用户集合的操作（比如use config; db.xxx.find()）。对配置数据的访问，必须通过mongos进行。直接连接config server只应该用于运维诊断，例如执行rs.status()查看副本集状态。

说到底，部署多个mongos实例并用Keepalived做负载均衡，方案听起来简单，但真正的挑战在于如何让每一个mongos实例都能持续保持健康——元数据时刻新鲜、连接始终稳定、路由绝对准确。这背后，依赖的是config server提供的强一致性、各个shard的高可用性，以及那个能真实反映mongos内部状态的健康检查脚本。这三环，缺了任何一环，所谓的VIP漂移高可用，也不过是把“全部瘫痪”的故障，变成了“部分服务不可用”的尴尬局面而已。