为了实现多活，在每个机房都部署有对应代理，对应机房客户端链接对应机房的mongos 代理，每个机房多个代理。代理层部署 IP:PORT 地址列表 ( 注意：不是真实 IP 地址 ) 如下：
A 机房代理地址列表： 1.1.1.1:111,2.2.2.2:1111,3.3.3.3:1111
B 机房代理地址列表： 4.4.4.4:1111,4.4.4.4:2222
A 机房三个代理部署在三台不同物理机， B 机房 2 个代理部署在同一台物理机。此外， A 机房和 B 机房为同城机房，跨机房访问时延可以忽略。
集群存储层和config server 都采用同样的架构： A 机房 (1 主节点 +1 从节点 ) + B 机房 (2 从节点 )+C 机房 (1 个选举节点 arbiter) ，即 2( 数据节点 )+2( 数据节点 )+1( 选举节点 ) 模式。
该机房多活架构可以保证任一机房挂了，对另一机房的业务无影响，具体机房多活原理如下：
1. 如果A 机房挂掉，由于代理是无状态节点， A 机房挂掉不会影响 B 机房的代理。
2. 如果A 机房挂掉，同时主节点在 A 机房，这时候 B 机房的 2 个数据节点和 C 机房的选举节点一共三个节点，可以保证新选举需要大于一半以上节点这个条件，于是 B 机房的数据节点会在短时间内选举出一个新的主节点，这样整个存储层访问不受任何影响。
本文重点分析如下6 个疑问点：
1. 为什么突发流量业务会抖动？
2. 为什么数据节点没有任何慢日志，但是代理负载缺100% ？
3. 为何mongos 代理引起数小时的“雪崩”，并且长时间不可恢复？
4. 为何一个机房代理抖动，对应机房业务切到另一个机房后，还是抖动？
5. 为何异常时候抓包分析，客户端频繁建链断链，并且同一个链接建链到断链间隔很短？
6. 理论上代理就是七层转发，消耗资源更少，相比mongod 存储应该更快，为何 mongod 存储节点无任何抖动， mongos 代理缺有抖动？
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/69986194/viewspace-2729660/ ，如需转载，请注明出处，否则将追究法律责任。
