我已经找到了一个关于大文件事件循环的Stack Overflow帖子,但它主要是关于下载。我从那篇文章中得出的结论是,对于下载而言,node.js可能已经足够了,但Nginx是一个经过实战考验的解决方案,非常稳定。
但是上传呢?我们需要上传巨大的文件。我们从事基因组学研究,人类基因组数据集的大小可达200GB。据我所知,Nginx始终会在将请求(包括头部和正文)转发给后端之前缓存完整个请求。当同时处理三个上传请求时,我们的内存就不够用了。
我们的应用程序中有一堆小型的“只做一件事并且做好”的服务器,其中之一负责上传(并将其转换为内部格式)基因组数据,另一个则提供socket.io处理,以便客户了解上传进度和其他应用程序生态系统中正在进行的事件。其他服务器则处理身份验证、客户数据处理和媒体服务等任务。
如果我正确地阅读了node.js的http/https模块代码,那么node.js是处理这些问题的理想工具:它本地支持HTTP/1.1,因此WebSockets通过将起作用,并且在处理HTTP HEAD后,它将
我们的服务具有基于URL的良好分段命名空间:"/import"、"/events"、"/users"、"/api"、"/media"等。Nginx只能正确处理最后三个。用node.js应用程序来处理它们所有是否难以或不合适?或者是否已经存在一些模糊的反向代理(Nginx、Pound和Varnish都具有类似的限制),可以满足我所有的要求?
但是上传呢?我们需要上传巨大的文件。我们从事基因组学研究,人类基因组数据集的大小可达200GB。据我所知,Nginx始终会在将请求(包括头部和正文)转发给后端之前缓存完整个请求。当同时处理三个上传请求时,我们的内存就不够用了。
我们的应用程序中有一堆小型的“只做一件事并且做好”的服务器,其中之一负责上传(并将其转换为内部格式)基因组数据,另一个则提供socket.io处理,以便客户了解上传进度和其他应用程序生态系统中正在进行的事件。其他服务器则处理身份验证、客户数据处理和媒体服务等任务。
如果我正确地阅读了node.js的http/https模块代码,那么node.js是处理这些问题的理想工具:它本地支持HTTP/1.1,因此WebSockets通过将起作用,并且在处理HTTP HEAD后,它将
(request, response)
元组传递给处理程序函数,但在绑定request.on('data', ...)
事件以排空BODY缓冲区之前,会暂停BODY的处理。我们的服务具有基于URL的良好分段命名空间:"/import"、"/events"、"/users"、"/api"、"/media"等。Nginx只能正确处理最后三个。用node.js应用程序来处理它们所有是否难以或不合适?或者是否已经存在一些模糊的反向代理(Nginx、Pound和Varnish都具有类似的限制),可以满足我所有的要求?
client_body_buffer_size
决定了当客户端请求超过给定大小时会发生什么,但它不是一种流式解决方案。 - Elf Sternbergnode-http-proxy
,并且编写了自己的转接板。 - Elf Sternberg