在处理大型文件上传时，Node.js会被阻止吗？ [英] Will Node.js get blocked when processing large file uploads?
问题描述
在处理大型文件上传时Node.js是否会被阻止？
Will Node.js get blocked when processing large file uploads?
由于Node.js只有一个线程，所以在进行大型文件上传时这是真的吗请求会被阻止？
Since Node.js only has one thread, is that true that when doing large file uploads all other requests will get blocked?
如果是这样，我应该如何处理nodejs中的文件上传？
If so, how should I handle file uploads in nodejs?
推荐答案
所有I / O操作都由Node.js处理，内部使用多个线程;它是I / O功能的编程接口，它是单线程，基于事件和异步的。
All the I/O operations is handled by Node.js is using multiple threads internally; it's the programming interface to that I/O functionality that's single threaded, event-based, and asynchronous.
所以你的例子的大上传是由一个单独的线程执行的由Node.js管理，当该线程完成其工作时，您的回调被放到事件循环队列中。
So the big upload of your example is performed by a separate thread that's managed by Node.js, and when that thread completes its work, your callback is put onto the event loop queue.
当您执行CPU密集型任务时，它会阻塞。假设我们有一个任务compute（）需要几乎连续运行，并进行一些CPU密集型计算。
回答主要问题如何处理nodejs中的文件上传？
检入您的代码（或库）保存服务器上的文件，是依赖于
writefile（）还是 writeFileSync（）？如果是正在使用
writefile（） 然后它的异步;但如果是 writeFileSync（） 它是同步版本。
When you do CPU intensive task it blocks. Let's say we have a task compute() which needs to run almost continuously, and does some CPU intensive calculations.
Answer to the main question "How should I handle file uploads in nodejs?"
Check in your code (or the library) where you save file on the server, is it dependent on
writefile() or writeFileSync()?If it is using
writefile() then its asynchronous; But if it is writeFileSync() its is synchronous version.
更新：回复评论：
答案不，它不会阻止是正确的但解释是
完全错误.JS是在一个线程和I / O在一个（相同的）
线程中。事件循环/异步处理/回调使这成为可能。不需要多线程。 - 通过 andrey-sidorov
文件操作没有异步API，因此Node.js使用线程池那。您可以在 libuv 的代码中看到它。您可以在 lib / fs.js ，你会看到binding.read。每当你在Node的核心模块中看到绑定时，你就会看到一个进入C ++领域的门户。使用NODE_SET_METHOD（目标，读取，读取）可以使用此绑定。如果您知道任何C，您可能会认为这是一个宏 - 它最初是，但它现在是一个函数。
There is no async API for file operations so Node.js uses a thread pool for that. You can see it in the code of libuv. You can look at the source for fs.readFile in lib/fs.js, you’ll see binding.read. Whenever you see binding in Node’s core modules you’re looking at a portal into the land of C++. This binding is made available using NODE_SET_METHOD(target, "read", Read). If you know any C, you might think this is a macro – it was originally, but it’s now a function.
返回 ASYNC_CALL 在读取中，其中一个参数是读取：系统调用读取。但是等等，这个功能不阻止吗？
Going back to ASYNC_CALL in Read, one of the arguments is read: the syscall read. But wait, doesn't this function block?
是，但这不是故事的结尾。 libuv简介表示以下内容：
Yes, but that’s not the end of the story. An Introduction to libuv denotes the following:
libuv文件系统操作与套接字操作不同。套接字操作使用操作系统提供的非阻塞操作。文件系统操作在内部使用阻塞函数，但是调用这些操作函数在线程池中，并在需要应用程序交互时通知在事件循环中注册的观察者。
摘要：
节点API方法 writeFile（） 是异步的，但这并不一定意味着它在下面是非阻塞的。由于libuv 书籍指出，套接字（网络）代码是非阻塞的，但是文件系统更复杂。有些东西是基于事件的（kqueue），有些则使用线程池（如本例所示）。
Summary:
Node API method writeFile() is asynchronous, but that doesn’t necessarily mean it’s non-blocking underneath. As the libuv book points out, socket (network) code is non-blocking, but filesystems are more complicated. Some things are event-based (kqueue), others use thread pool (as in this case).
考虑通过开发Node.js的C代码，以获取更多信息：
Consider going through C code on which Node.js is developed, for more information:
- Unix fs.c
- Windows fs.c
这篇关于在处理大型文件上传时，Node.js会被阻止吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
