Node.js处理大量请求的运行机制是什么？高并发分析数据上报如何保障送达？

Node.js 的垃圾回收只会清理没有任何引用指向、且已经不会被后续逻辑访问的JS对象：

• 如果你用Promise.allSettled持有了所有上报请求对应的Promise实例，那么在所有请求完成/失败之前，请求关联的HTTP客户端、回调等对象都不会被GC回收
• 只要请求已经被Node.js底层提交到系统内核的TCP发送缓冲区，就算上层JS对象被回收，内核也会正常把请求报文发送到服务端
• 只有两种场景会出现请求丢失：一是进程在请求提交到内核前意外终止（如未捕获异常、OOM被系统杀死、进程被手动停止），二是请求过载导致系统文件描述符耗尽、无法新建网络连接。你当前每秒仅3次业务请求，对应总共24次以内的上报请求，远低于Node.js的处理阈值，不会出现过载问题。

你的核心需求是保证上报数据尽可能送达、不影响主业务逻辑，可以做以下优化：

• 替换Promise.allSettled为独立异步队列：所有上报任务先写入本地内存队列，和主业务逻辑解耦，后台用固定并发数（建议设置为5_{10）的worker消费队列，请求失败的话按照指数退避策略重试3}5次
• 增加进程退出兜底逻辑：监听进程的SIGINT、beforeExit等事件，进程退出前暂停接收新请求，把队列中未完成的上报任务全部发送完成后再退出；如果是Serverless短生命周期场景，可以把未发送的任务写入本地磁盘持久化，下次进程启动后重发
• 批量合并上报：如果6~8次上报的数据没有毫秒级的实时性要求，可以把同个用户会话的多次上报数据合并为单次批量请求发送，降低连接开销和请求量
• 选择更适配的传输协议：如果分析服务端支持，上报场景可以用UDP协议替代TCP，UDP无需握手、无需等待响应，资源开销远低于TCP，更适合不要求100%可靠、低开销的上报场景
• 严格配置请求超时：所有上报请求设置5~10s的超时时间，避免僵死请求占用连接和内存资源

内容的提问来源于stack exchange，提问作者The D