我正在玩Node.js,我创建了一个简单的脚本,将文件从目录上传到服务器:
var request = require('request');
var file = require('file');
var fs = require('fs');
var path = require('path');
VERSION = '0.1'
CONFIG_FILE = path.join(__dirname, 'etc', 'sender.conf.json');
var config = JSON.parse(
fs.readFileSync(CONFIG_FILE).toString()
);
var DATA_DIR = __dirname
config['data_dir'].forEach(function(dir) {
DATA_DIR = path.join(DATA_DIR, dir)
});
console.log('sending data from root directory: ' + DATA_DIR);
file.walk(
DATA_DIR,
function(err, dir_path, dirs, files) {
if(err) {
return console.error(err);
}
sendFiles(dir_path, files);
}
);
function sendFiles(dir_path, files)
{
files
.filter(function(file) {
return file.substr(-5) === '.meta';
})
.forEach(function(file) {
var name = path.basename(file.slice(0, -5));
sendFile(dir_path, name);
})
;
}
function sendFile(dir_path, name)
{
console.log("reading file start: " + dir_path + "/" + name);
fs.readFile(
path.join(dir_path, name + '.meta'),
function(err, raw_meta) {
if(err) {
return console.error(err);
}
console.log("reading file done: " + dir_path + "/" + name);
sendData(
name,
JSON.parse(raw_meta),
fs.createReadStream(path.join(dir_path, name + '.data'))
);
}
);
console.log("reading file async: " + dir_path + "/" + name);
}
function sendData(name, meta, data_stream)
{
meta['source'] = config['data_source'];
var req = request.post(
config['sink_url'],
function(err, res, body) {
if(err) {
console.log(err);
}
else {
console.log(name);
console.log(meta);
console.log(body);
}
}
);
var form = req.form();
form.append(
'meta',
JSON.stringify(meta),
{
contentType: 'application/x-www-form-urlencoded'
}
);
form.append(
'data',
data_stream
);
}
只运行少量文件时,它运行正常。但是当我在包含大量文件的目录上运行它时,它就会窒息。这是因为它不断创建大量的任务来从文件中读取,但从来没有实际进行读取(因为文件太多)。这可以在输出中观察到:
sending data from root directory: .../data
reading file start: .../data/ac/ad/acigisu-adruire-sabeveab-ozaniaru-fugeef-wemathu-lubesoraf-lojoepe
reading file async: .../data/ac/ad/acigisu-adruire-sabeveab-ozaniaru-fugeef-wemathu-lubesoraf-lojoepe
reading file start: .../data/ac/ab/acodug-abueba-alizacod-ugvut-nucom
reading file async: .../data/ac/ab/acodug-abueba-alizacod-ugvut-nucom
reading file start: .../data/ac/as/acigisu-asetufvub-liwi-ru-mitdawej-vekof
reading file async: .../data/ac/as/acigisu-asetufvub-liwi-ru-mitdawej-vekof
reading file start: .../data/ac/av/ace-avhad-bop-rujan-pehwopa
reading file async: .../data/ac/av/ace-avhad-bop-rujan-pehwopa
...
对于每个文件,在调用"reading file start"
之前立即生成控制台输出fs.readFile
,并在安排异步读取后立即生成"reading file async"
。但即使我让它运行很长时间也没有"reading file done"
消息,这意味着任何文件的读取可能从未被安排过(这些文件大约是100个字节的顺序,因此一旦安排,那些读取可能会单续完成。)
这引导我进行以下思考过程。 Node.js中的异步调用已完成,因为事件循环本身是单线程的,我们不想阻止它。 但是,一旦满足此要求,将进一步的异步调用嵌套到本身嵌套在异步调用中的异步调用是否有意义?它是否可以用于任何特定目的?此外,由于不是真正需要的调度开销而不是实际的代码悲观化,如果单个文件的完整处理只包含同步调用,那么可以完全避免吗?
鉴于上述思考过程,我的行动方针是使用this question的解决方案:
async.queue
queue.concurrency
这是我第一次尝试使用Node.js和/或JavaScript,因此很可能我完全错了(请注意,例如sync-request package非常清楚同步调用是不可取的,这是与我上面的思考过程相矛盾 - 问题是为什么)。任何关于上述思维过程的有效性以及所提出的解决方案的可行性及其最终替代方案的评论都将非常受欢迎。
答案 0 :(得分:0)
==更新==
非常好article直接在Node.js的文档中详细解释了这一切。
至于手头的特定问题,确实在文件系统 - walker-module的选择中。解决方案是使用例如walk代替file:
@@ -4,7 +4,7 @@
var request = require('request');
-var file = require('file');
+var walk = require('walk');
var fs = require('fs');
var path = require('path');
@@ -24,13 +24,19 @@ config['data_dir'].forEach(function(dir) {
console.log('sending data from root directory: ' + DATA_DIR);
-file.walk(
- DATA_DIR,
- function(err, dir_path, dirs, files) {
- if(err) {
- return console.error(err);
- }
- sendFiles(dir_path, files);
+var walker = walk.walk(DATA_DIR)
+walker.on(
+ 'files',
+ function(dir_path, files, next) {
+ sendFiles(dir_path, files.map(function(stats) { return stats.name; }));
+ next();
+ }
+);
+walker.on(
+ 'errors',
+ function(dir_path, node_stats, next) {
+ console.error('file walker:', node_stats);
+ next();
}
);
==原始帖子==
经过一番研究,我会尝试回答我自己的问题。这个答案仍然只是一个部分解决方案(非常感谢具有Node.js实际经验的人的更完整答案)。
上面主要问题的简短回答是确实不仅是可取的,而且几乎总是需要从已经异步的函数安排更多的异步函数。下面是长篇解释。
这是因为Node.js的调度工作原理:"Everything runs on a different thread except our code."。在链接的博客文章下面的讨论中有两个非常重要的评论:
还有一个注释在process.nextTick
:"的文档中提到了这一点。在处理额外的I / O之前,下一个滴答队列在事件循环的每次传递中完全耗尽。因此,递归设置nextTick回调将阻止任何I / O发生,就像一段时间(true); 。环路"
因此,总而言之,脚本本身的所有代码仅在单线程和单线程上运行。计划运行的异步回调在同一个单线程上执行,并且只有在排除了整个当前下一个滴答队列后才执行它们。当可以安排运行某些其他功能时,使用异步回调提供唯一的点。如果文件上传处理程序不会按照问题中的描述安排任何其他异步任务,则其执行将阻止其他所有操作,直到整个文件上载处理程序完成为止。这是不可取的。
这也解释了为什么输入文件的实际读取永远不会发生("递归设置nextTick回调会阻止任何I / O发生" - 见上文)。最终会在遍历完所有遍历目录层次结构的任务后进行调度。 但是,如果没有进一步研究,我无法回答如何限制调度的文件上传任务数量(有效地确定任务队列大小)的问题,并阻止调度循环,直到其中一些任务被处理完毕为止(任务队列中的某个空间已被释放)。因此,这个答案仍然不完整。