连环触发！MongoDB核心集群雪崩故障背后竟是……( 六 ) 作者介绍杨亚洲

答：由于采用分片架构，所有mongod存储节点前面都有一层mongos代理， mongos代理作为mongod存储节点的客户端，超时时间默认秒级，不会出现超时现象，也就不会出现频繁的建链断链过程。
Q7：如果MongoDB集群采用普通复制集模式，客户端频繁建链断链是否可能引起mongod存储节点同样的”雪崩”？
答：会。如果客户端过多，操作系统内核版本过低，同时超时时间配置过段，直接访问复制集的mongod存储节点，由于客户端和存储节点的认证过程和与mongos代理的认证过程一样，所以还是会触发引起频繁读取"/dev/urandom"文件，引起CPU sy%负载过高，极端情况下引起雪崩。
四、 “雪崩”解决方法
从上面的一系列分析，问题在于客户端配置不合理，加上MongoDB内核认证过程读取随机数在极端情况下存在缺陷，最终造成雪崩。如果没有MongoDB内核研发能力，可以通过规范化客户端配置来避免该问题。当然，如果客户端配置规范化，同时MongoDB内核层面解决极端情况下的随机数读取问题，这样问题可以得到彻底解决。
1、JAVA SDK客户端配置规范化
在业务接口很多，客户端机器很多的业务场景，客户端配置一定要做到如下几点：

超时时间设置为秒级，避免超时时间设置过端引起反复的建链断链。
客户端需要配置所有mongos代理地址，不能配置单点，否则流量到一个mongos很容易引起瞬间流量峰值的建链认证。
增加mongos代理数量，这样可以分流，保证同一时刻每个代理的新键链接尽可能的少，客户端在多代理配置时，默认是均衡流量分发的，如果某个代理负载高，客户端会自动剔除。

如果没有MongoDB内核源码研发能力，可以参考该客户端配置方法，同时淘汰linux-2.6版本内核，采用linux-3.10或者更高版本内核，基本上可以规避踩同样类型的坑。
2、MongoDB内核源码优化（摈弃内核态获取随机数，选择用户随机数算法）
详见2.5.2章节。
3、PHP短链接业务，如何规避踩坑？
由于PHP业务属于短链接业务，如果流量很高，不可避免的要频繁建链断链，也就会走sasl认证流程，最终多线程频繁读取"/dev/urandom"文件，很容易引起前面的问题。这种情况，可以采用4.1 java客户端类似的规范，同时不要使用低版本的Linux内核，采用3.x以上内核版本，就可以规避该问题的存在。
五、MongoDB内核源码设计与实现分析
本文相关的MongoDB线程模型及随机数算法实现相关源码分析如下：
MongoDB动态线程模型源码设计与实现分析：
MongoDB一个链接一个线程模型源码设计与实现分析
MongoDB内核态及用户态随机数算法实现分析
作者丨杨亚洲
来源丨Mongoing中文社区（ID：mongoing-mongoing）
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
2020 DAMS中国数据智能管理峰会即将于10月30日在上海举办，部分精彩议题先睹为快：

腾讯《腾讯游戏大数据资产管理实战：元数据管理与数据治理》
京东《京东EB级全域大数据平台建设和治理之路》
阿里《大规模容器云基础设施环境架构、管理与运维》
工商银行《DevOps转型的探索与实践》
中国银联《从自研演进看分布式数据库》
民生银行《开源数据库MySQL在民生银行的应用实践》
平安银行《“传统+互联网”混合CMDB及运营中台实践》
中国联通《大数据资产管理平台的设计、研发、运营实践》
AWS《基于数据湖构建云上的数据分析架构》
今日头条《字节跳动数据治理实践》
苏宁《苏宁大规模智能告警收敛与告警根因的实践》
滴滴《万亿级消息队列Kafka在滴滴的实践》

文章插图