node Server 开启，server 可能因为各种各样的问题异常退出，虽然我能够通过线程监控手段让Server在短时间内起死回生，但Server死之前的那些用户请求附带繁杂的数据库请求以及文件请求怎么处理？
我觉得你应该想想怎么不让你的server挂。这有很多方案可以实现，而且也是必须要解决的问题 而挂了之后，能用的办法太有限了。 redis中一个办法是根据log redo，但前提有机会把内存dump到log文件
这东西没统一说法的，要不就是你的代码有问题，譬如用 readFileSync 等同步阻塞等方式，导致系统处理不够快，要不就是你的量确实大的机器扛不住。
前者用朴老师的 https://www.aliyun.com/product/nodejs 来分析热点代码，然后改进吧。 后者加机器咯。不过我觉得你更大的可能是前者。
node Server 开启，server 可能因为各种各样的问题异常退出
如果你用的是现成的框架，这几乎不可能发生。或者，是系统层面的其它问题。（比如你说的内存问题之类的，那肯定是你代码有问题。 nodejs 这种天生异步的结构下，连接把内存吃完更是不可思议）
虽然我能够通过线程监控手段让Server在短时间内起死回生
应该是“进程”不是“线程”吧。
但Server死之前的那些用户请求附带繁杂的数据库请求以及文件请求怎么处理？
数据库的操作，如果涉及状态，应该挂在“事务”里，事务没有提交，数据不会有影响。下次新的请求，重新来过即可。 文件请求不知道你说的什么， server 死了，连接就 hold 住了（或者直接断了），客户端应该有机制超时断掉连接（如果连接是 hold 住），这不是你一个挂掉的服务端需要考虑的。
数据库是跟你程序独立进程的。
你的应用怎么蹦都行，都不管数据库的事。 如果说有其中一个操作，执行到一半，然后程序蹦快掉，那么数据库再进行的操作还会进行.
只是说，你用事务包裹住了操作，怎么操作都行，没commit就不会生效。然后进程退出，跟数据库的链接就断开。事物没有被commit，那啥事没有…
这些问题，做为一款企业级框架，Egg.js 都有考虑到的。
侦测未捕获异常，优雅退出，cluster。
上面三种方案都用上了，还不能解决问题就是你自己的问题了。
server 可能因为各种各样的问题异常退出
case by case，就不应该异常退出。
虽然我能够通过线程监控手段让Server在短时间内起死回生，但Server死之前的那些用户请求附带繁杂的数据库请求以及文件请求怎么处理？
都不在乎异常退出了，还在乎一两个用户的请求么？让他们重新刷新下不就好了。
我比较懒，不喜欢用框架什么的，直接手写啥的。完全不会写的时候才回去找相关的模块补充。
程序猿都是懒的，但至少要懒得其所吧，要不就是站在前人的肩膀上用现成的框架，要不就自己填掉这些坑。 自己搞不定这些坑，甚至没能具体定位出问题，抛出一个笼统的问题，让其他人来猜测，这类「伸手」行为可要不得。
先排查下有没有内存泄漏; 如果没有，看看是不是短时间内任务太多，导致node处理不过来，可以用一些缓存技术; 如果你的服务器负载在长时间里负载都很高，考虑使用多进程或者将需要大量计算的逻辑用其他语言实现; 最后，服务器上线要做压测啊老铁。
有下面两个措施, 我就不信你的"各种各样的问题"能让server挂掉
app.use((err, req, res, next) => {
console.log('Error: ', err)
})
process.on('unhandledRejection', err => {
console.log('Unhandled Rejection: ', err)
})
