为什么build议不要在Node.js代码中的任何地方closuresMongoDB连接？
考虑以下是Node.js代码：
function My_function1(_params) { db.once('open', function (err){ //Do some task 1 }); } function My_function2(_params) { db.once('open', function (err){ //Do some task 2 }); } 请参阅最佳实践链接，其中说不要closures任何连接
https://groups.google.com/forum/#!topic/node-mongodb-native/5cPt84TUsVg
我已经看到日志文件包含以下数据：
Fri Jan 18 11:00:03 Trying to start Windows service 'MongoDB' Fri Jan 18 11:00:03 Service running Fri Jan 18 11:00:03 [initandlisten] MongoDB starting : pid=1592 port=27017 dbpath=\data\db\ 64-bit host=AMOL-KULKARNI Fri Jan 18 11:00:03 [initandlisten] db version v2.2.1, pdfile version 4.5 Fri Jan 18 11:00:03 [initandlisten] git version: d6...e0685521b8bc7b98fd1fab8cfeb5ae Fri Jan 18 11:00:03 [initandlisten] build info: windows sys.getwindowsversion(major=6, minor=1, build=7601, platform=2, service_pack='Service Pack 1') BOOST_LIB_VERSION=1_49 Fri Jan 18 11:00:03 [initandlisten] options: { config: "c:\mongodb\mongod.cfg", logpath: "c:\mongodb\log\mongo.log", service: true } Fri Jan 18 11:00:03 [initandlisten] journal dir=/data/db/journal Fri Jan 18 11:00:03 [initandlisten] recover begin Fri Jan 18 11:00:04 [initandlisten] recover lsn: 6624179 Fri Jan 18 11:00:04 [initandlisten] recover /data/db/journal/j._0 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:59343 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:118828 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:238138 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:835658 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:955218 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:3467218 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:3526418 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:3646154 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:3705844 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section more... Fri Jan 18 11:00:05 [initandlisten] recover cleaning up Fri Jan 18 11:00:05 [initandlisten] removeJournalFiles Fri Jan 18 11:00:05 [initandlisten] recover done Fri Jan 18 11:00:10 [initandlisten] query MYDB.system.namespaces query: { options.temp: { $in: [ true, 1 ] } } ntoreturn:0 ntoskip:0 nscanned:5 keyUpdates:0 nreturned:0 reslen:20 577ms Fri Jan 18 11:00:10 [initandlisten] waiting for connections on port 27017 Fri Jan 18 11:00:10 [websvr] admin web console waiting for connections on port 28017 Fri Jan 18 11:01:10 [PeriodicTask::Runner] task: WriteBackManager::cleaner took: 32ms Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50076 #1 (1 connection now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50077 #2 (2 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50078 #3 (3 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50079 #4 (4 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50080 #5 (5 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50081 #6 (6 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50082 #7 (7 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50083 #8 (8 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50084 #9 (9 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50085 #10 (10 connections now open) ........................................... Fri Jan 18 13:36:48 [initandlisten] connection accepted from 192.168.0.1:50092 #97 (97 connections now open)
这是不是通过打开多个连接而不是closures它在服务器上创build开销，它是否在内部处理连接池？
但在MongoDB文档中提到“这是不使用请求池的应用程序的正常行为”
有人能帮助我理解这一点。
您使用MongoClient打开一个Db连接一次，然后在您的应用程序中重复使用它。 如果您需要使用多个数据库，则可以使用Db对象上的.db函数使用相同的基础连接池来处理不同的数据库。 保留一个池以确保单个阻塞操作不能冻结你的node.js应用程序。 如果池中有5个连接，则默认大小。
http://mongodb.github.com/node-mongodb-native/driver-articles/mongoclient.html
我也忘了补充。 正如另一个答案指出，build立一个新的TCP连接是时间和内存明智的EXPENSIVE，这就是为什么你重用连接。 另外一个新的连接将导致在Db上使用内存在MongoDB上创build一个新的线程。
我不是node.js专家，但我认为大多数语言之间的原因是相同的。
build立连接是：
这是司机所做的最重量级的事情之一。 即使在快速networking上，也可能需要几百毫秒才能正确build立连接。
（ http://php.net/manual/en/mongo.connecting.pools.php ）
如果是PHP，且文档已经过时了，那么即使是现在和大多数（即使不是全部）驱动程序，该部分仍然适用。
每个连接也可以使用一个单独的线程，导致明显的开销。
这似乎来自：
该node.js仍然使用连接池来尝试和停止进行连接的开销。 这当然不再适用于PHP之类的其他驱动程序。
它将向您的数据库服务器打开x个连接（默认值为5 ），并在需要数据时将工作转移到空闲连接，以便重新使用旧连接避免可能导致这些日志的恶意进程： http : //docs.mongodb.org / manual / faq / developers /＃why-does-mongodb-log-so-many-connection-accepted-events并增加连接开销。
MongoDB使数据库连接更加高效，因此在mongodb.log中打开多个连接并不罕见
但是，当您的应用程序完全closures时，closures所有连接将非常有用。 这个代码是非常好的做这个。
process.on('SIGINT', function() { mongoose.connection.close(function () { console.log('Mongoose disconnected on app termination'); process.exit(0); }); });
