仅378条数据居然导致合服失败？！

作者：伍旭飞，腾讯云数据库高级工程师，主要负责腾讯云redis、MongoDB开发。

十年专注成都网站制作，成都企业网站建设，个人网站制作服务，为大家分享网站制作知识、方案，网站设计流程、步骤,成功服务上千家企业。为您提供网站建设,网站制作,网页设计及定制高端网站建设服务,专注于成都企业网站建设,高端网页制作,对成都工商代办等多个方面，拥有丰富设计经验。

故事从一个MongoDB数据库连接超时案例说起。该异常导致2次合服失败，前面已在服务器上抓包并dump下来，下方是客户端超时现场截图：

仅378条数据居然导致合服失败？！

从截图不难看出，这是一个Nodejs服务出错信息，推测DBA应该是用的nodejs mongodb来实现连接数据库并进行操作，找到这个driver的官网 https:// -mongodb-native ，clone了一份代码下来。简单看了下，再结合上图，初步分析出错连接是在第38个连接超时的。

1. 分析抓包内容

由于前面已经在出错服务器上抓包了，因此，首先我用wireShark打开从服务器上dump下来的文件，wireShark很智能，能分析多种常用协议，很方便，但是也容易带来误判。比如我们的数据库连接很多地方都被误判为X11协议：

仅378条数据居然导致合服失败？！

一开始很纠结这个错误，其实这当然不是什么x11协议，只是碰巧模式匹配上了，到wireShark设置了下，取消了X11的分析，很容易从端口和连接看出，就是数据库连接。

仔细检查了抓包内容，大致如下:

(1)开始有个连接从数据库拉取了大概3M多的数据。

(2)后面陆续有常规的三次握手连接建立成功，但是都基本没有实质性的数据传输，就走了正常的tcp结束流程了。

(3)从抓包内容来看，服务器不存在未回应客户端syn连接包的情况。

好了，到这里分析的内容，似乎完全解释不了为什么会超时，那么下一步就是和用户沟通，获取更多的信息了。

(4)所有的tcp链接均为客户端发起FIN主动关闭，不存在服务器主动关闭客户端连接的情况。

2. 出错代码

通过沟通，拿到了出错部分工具的代码片段（最开始没有完整的函数，后面才拿到完整函数）：

function merge_union_info(dbs) {
    var union_data = [];
    async.each(
        dbs,
        function(path, cb) {
            mongodb.connect(path, (err, db) => {
                if (err) {
                    cb(err);
                    return
                }
                db.collection('union').find().sort({level: -1, exp: -1}).toArray((err1, v) => {
                    if (err1) {
                        db.close();
                        console.log(err1);
                        return
                    }
                    let loop = v.length > 50 ? 50 : v.length;
                    let u_data = [];
                    for (let i = 0; i < loop; i++) {
                        v[i].merge_flag = 1;
                        u_data.push(v[i]);
                    }
                    union_data.push(u_data);
                    db.close();
                    cb();
                });
            })
        },
        function(err) {
            if (err) {
                console.log("[ERROR]merge union-data failed !!!");
                return
            }
            async.waterfall([
                function(cb1) {
                    mongodb.connect(dbs[0], (err1, db) => {
                        if (err1) {
                            cb1(`[ERROR]gen union-data [drop] failed for ${err1}`)
                            return
                        }
                        var col = db.collection('union');
                        db.collection('union').drop((err2, r2) => {
                            db.close();
                            cb1(err2);
                        });
                    }); 
                },
                function(cb1) {
                    async.each(
                        union_data, 
                        function(u_data, cb2) {
                            mongodb.connect(dbs[0], (err1, db) => {
                                if (err1) {
                                    cb2(`[ERROR]gen union-data [insert] failed for ${err1}`)
                                    return
                                }
                                var col = db.collection('union');
                                col.insertMany(u_data, (err2, r2) => {
                                    db.close();
                                    cb2(err2);
                                });
                            }); 
                        },
                        function(errN) {
                            cb1(errN);
                        }
                    );
                },
            ], function(errX, r) {
                if (errX) {
                    console.log("[ERROR]gen union-data failed for ", errX);
                }else {
                    console.log("4 - update union-data ok !!!");
                }
            });
        }
    );
}

熟悉nodejs的都知道，nodejs的优点是无同步操作，所以性能相对高。所以通过代码分析，第一反应是数据量太大导致建立了太多的tcp连接，而mongodb是每用户一个线程的处理模型，极有可能造成tcp连接达到max open file数量或者线程太多，导致整个系统性能下降，以至于无回应。

3. 尝试重现

通过代码分析，我简单写了个函数，希望能重现，mongodb用的是虚拟机上自己搭建，代码如下：

function doLoopInsertTest(mongourl:string){
    for(var i = 0; i < maxInsertCount/500; i++){
        
        mongodb.MongoClient.connect(mongourl, function(err, client) {
            if (err != null){
                console.log("error:", err, "\n")
                return
            }
                    
            console.log("Connected successfully to server");
            const db = client.db("testdb");
            db.collection("testfei").insertMany(getNewDoc(i*500), (err, result:mongodb.InsertWriteOpResult)=>{
                if (err != null){
                    console.log("write error:", err)
                    return
                }
            })
            
        })
    }
}

这里模拟了用户是每500个合并插入的代码，在自建的mongodb上，很快就超过了1024的max fd限制。unlimit修改后，重启mongodb进程，再次测试，很快客户端这边无响应，但是出错信息和用户不完全相同，尝试了好几次，其中有一次出现了timeout的错误信息。

4. 用户反馈

似乎大功告成，于是第二天把相关信息和用户沟通，用户反馈出错的部分没有那么多数据，而且总共就插入了100条数据，并提供了要合并的2个表的数据。

我在测试环境mongodbrestore看了下，一个表示257条，一个表示121条，总共加起来378条数据！！这根本不可能出错，就算是每个插入建立一个连接，也不会出错。

出于谨慎的考虑，我还是写了个小代码片段，在本地的虚拟机环境下测试了下，当然是完全没问题。万一是真的云服务器独有的问题呢，我申请了一个测试的mongodb，把数据导入，然后用nodejs代码测试了下，依然没有任何问题！

于是，与用户进一步沟通，是否是mongodb driver代码版本不够新？

得到反馈是：mongodb driver代码确实不够新，但是，他们前几次合服也是这个代码，都能成功。用户不认为代码有问题，也不认可是库的版本问题。

用户也不适合用我提供的代码直接测试，因为每次测试都要发公告停服合服，合服失败后，部分数据要手工回档，风险太大。

5. 柳暗花明

似乎陷入了死胡同，我们不相信300多条数据插入会有问题，用户不认同我们的结论，我甚至询问用户，有没有可能真的ip和端口写错了（其实也说不同，错误日志里的端口是对的）。

这个时候，突然想起来，合服不可能只合并工会(前面的代码是工会合并的部分)，前面应该还有角色这些合并吧。用户确认了，发了代码截图：

仅378条数据居然导致合服失败？！

并且标注了出错代码是update_union_info。

这里就比较明显能看出问题了：数据量最大的是update_user_info，而基于nodejs的特点，update_user_info应该也是异步操作的，也就是说，执行到update_union_info的时候，update_user_info一定是没有执行完毕的！而nodejs是单线程!!! 单线程!!! 单线程!!!重要的事情3遍。

所以，假如update_user_info的运算量非常大，那么，即使网络层tcp连接成功，也极有可能得不到运行机会，等到cpu释放出来，很可能已经超时了。