突然接到通知，线上环境出现了系统故障，用户无法扫码进行下单了。查看了下服务器的内存，发现某个java进程的CPU占用到了100%左右，维持了十几秒，随后恢复正常，随后发现这期间有客户在进行大文件的下载。
...
- 对于文件下载的处理，如果说能够在业务层面限制下载的规模，那是最好的，对于IO、网络、数据库的影响都小些。一般来说，可能通过时间、机构层级、区域等维度来限制数据的规模；
- 如果上一步没有达到限制大文件的目的，那么可以考虑对下载文件进行异步处理。
比如，用户点击申请下载，那么对于该下载目标构建一个任务并讲这个任务发送到消息队列，然后这个任务的状态设置为等待下载（该状态在页面可查），在队列处理完这个文件的构建之后，给出该文件的下载链接，并修改任务的状态，此时给用户提供下载链接地址，用户真正下载该大文件。
- 在一个用户频繁访问的服务中，其实是不适合一起提供类似大文件下载的服务的，一旦由于该服务占用资源，那么该服务内其它接口势必会受到影响。这一次的生产事故就是因为将这个文件下载与其它用户频繁调用的接口写到了同一个服务中，所以将他们进行分开治理是比较好的思路。
- 另外，相同用户可能会由于各种原因导致短时间内频繁地调用该接口，一定要做好判断，避免短时间内的重复调用。