1. 一些重要概念
- 一个进程在运行中会打开很多资源，包括文件file、连接socket（包括http连接）、正在监听的端口等，我们把这些统称为句柄（handle）
- linux系统对每个用户以及系统总的句柄数是有限制的
- linux中任何东西都是文件，一个新的句柄也是打开一个新的文件，所以当一个进程打开的句柄数超过系统限制时，我们会收到告警：too many open files
2. 产生问题的系统描述
现在有A、B、C三个微服务，A发送任务，B接收任务并分发，C是多个节点负责任务的具体执行。C执行任务完成后，通过http请求发送消息通知B任务完成，B再通过http请求发送消息通知A任务完成。
B在接收到任务完成得消息后，需要做一些处理，再通知A，整个流程如果用一个同步方法就是：
显然C对B得http请求非常容易超时。将这个方法改为异步方法，B接收到消息后新开一个子线程做处理工作以及通知A，然后立即通知C收到消息了，如下：
3. 产生的问题
因为系统做的是视频转码任务，任务的压力主要来自于C节点的转码计算算力，任务发送与回调不会特别密集，即A-->B-->C的http请求以及回调http都不会很密集，因此没认真考虑这部分优化，测试也很容易通过了。但是上线一段时间后，某一天开始突然频繁报数据库连接池耗尽（使用的连接池是Druid）的问题，然后服务器句柄数飙升直至耗尽程序被终止。
4. 句柄飙升的原因
B中处理消息以及回调给A的线程，使用的是new Thread().start;，没有使用线程池；线程中使用原生的RestTemplate发送http请求，没有设置超时时间。本来回调请求不是很频繁，所以没有出问题。但是后来出现了两个状况：
- 北京的线上环境因为网络问题，http请求从发出到接收消息需要六分钟甚至更长（不清楚为什么）；
- 后来增加了一个回调定时任务，以及可以在运维控制台批量发送回调任务，将回调失败的任务批量回调，瞬间发出很多HTTP请求。
在这种情况下，不断地新开子线程，每个子线程里面都是一个回调的http请求，每个http请求都要打开一个句柄，并且因为http等待时间太长，句柄无法释放，系统显示仍是回调失败，下一次批量回调又要回调一次。于是句柄数量飙升很快就用完了（系统默认单个进程可以打开1024个文件），程序被强制退出。
解决办法：
使用线程池，通过线程池容量来限制http请求的并发数量；设置http请求超时时间，使得超时后能自动关闭请求并退出（也可以设置线程定时自动结束）。
5. 数据库连接耗尽产生的原因
因为回调线程使用的是事务，只有中台回调http请求完成，数据入库，事务才能提交，数据库连接才能释放。所以http请求一直不能释放导致数据库连接也不能释放并且不断占用新的数据库连接，数据库连接池就耗尽了。与上面是同一个原因。
解决办法：
http请求可以正常超时释放时，这个问题已经不出现了。但是，经过考虑，回调线程调用的service并不需要使用事务，可以判断http请求是否成功，然后决定需不需要去写入数据库。
