Request使用proxy导致的socket连接数泄漏问题
这是一篇快餐文章，源于前天接到了服务器预警邮件，提示：连接数超过阀值。
快速定位问题，发现是因为之前跑的一个nodejs开发的小程序，该程序用于定时去指定网站采集相关数据的。
由于要采集的网站需要设置翻墙代理，很麻烦的。之前直接使用Request来发http请求也没碰到这个问题。所以归结为是由于使用proxy不稳定，导致大量的socket异常。
在进入主题之前，先吐槽一下 Request 这个库，它的文档看似详实，但如果你仔细阅读就会发现很简陋。很多地方感觉欲言又止，很是让人烦躁。
尝试去看它的源码，发现它返回异常的方式采用了2种不同的方法：
- 沿用nodejs的回调返回异常风格
- 发布异常事件
这也是一开始总是被无法捕获的异常导致程序crash的原因。
去github上的issues翻到别人的异常捕获异常方法，也是醉了：
Request
.get({/*some config*/}, function(err, response){/*回调逻辑，第一个参数为error*/})
.on('error', function(error){
// 再次绑定error事件
console.error('Request on error');
console.error(error.stack);
});
不晓得这是要闹哪样。不过经过绑定了这个error事件后，发现几乎Request触发的所有异常都被其捕获到了。至少确实管用，不会再因为无法捕获的异常而导致程序crash了（还存在一些异常，我建议 process.on('uncaughtException') 还是不能省）。
接下来主题，先看一下一个 issue ，题主已经详细描述了问题也给了解决方案。
实测了一天，感觉确实解决了，至少从图标中观测正常许多了：
如果去看源码，会发现很绕，毕竟到处可见的回调和事件流。不过从解决方案上来看， 很直观 。思路就是在: 确保在链接出现异常后也触发回调，在回调中来处理善后工作，最终会回收相关资源，而不是直接清除掉必要的事件监听器 。
去看源码吧，你将会收获更多。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
