起因
前几日正常版本发布后，经过发布验证，一个不在本次发布功能范围中的文件导出功能不能正常执行，具体表现为，任务启动后一直卡在执行中状态，无法完成且不会自动异常中断，就这么一直卡在执行中的状态，同时后续更多导出任务仍然在排队持续积压。接下来就是在众多业务部门狂轰滥炸的问询之下，顶住压力进行排查处理。
排查过程
首先初步排查确认故障范围，首先第一步想到的是去异常日志监管平台和统计平台查看有无明显的新增异常，翻了一圈无果，这就很奇怪了。接下来我只能去根据功能逻辑的特点去逐排查。同事去申请下载完整的近期应用日志，这个要走流程，很慢，就先不管他了。
交代下这个下载服务功能的基础逻辑，然后我们根据不同部分验证来排查确认。
该下载服务根据平台用户提交的下载请求创建导出任务，再有任务调度系统来定时执行启动导出任务执行。导出任务的执行是一个基本的生产者消费者模型，启动后分两部分，一部分为生产者线程，根据用户提交的查询参数去对应的ES索引或者MYSQL表查询数据。另外一方面启动消费者线程来消费这些数据，写入到一个或者多个csv文件中，消费完毕后将文件提交到OSS对象存储服务中，得到对应的文件下载地址。之后标记导出任务完成，并更新下载地址到导出任务信息中。那么就对这些步骤分别排查验证。
逐步排查第一步，任务状态能从排队中更新为执行中状态，且后续任务能保持在排队中状态，说明任务调度系统到当前执行导出任务的应用直接的通信应该是正常的。
第二步，任务启动后会首先查询待导出总数据量，经过测试，导出任务的该字段能正确更新，说明一方面具体的执行线程能正确查询到对应ES/MYSQL中的数据，另一方面也能反过来正确更新导出任务中的总数据量字段，说明这两个路径之间是正常。那么如果任务发生异常中断了的话，按照代码逻辑应当能正确进入Exception处理分支，去更新导出任务的状态为失败。到这里合理的怀疑是不是任务哪边进入了死循环不能中断跳出
第三步，去到最终的OSS服务器目录上查看下，确认没有对应的文件上传，到这里怀疑是不是上传OSS的时候网络问题导致文件上传非常慢从而卡在了这里，任务一直无法结束
第四步，回到我们的应用服务器，简单申请个权限看下对应的应用服务的临时文件夹，确认下文件是否正确生成了，从而确认第三步的怀疑是否正确。但是在应用服务器上的临时文件目录看了下后发现，对应的csv文件生成了，但是文件大小是0，是个空文件（看不到文件内容，涉及敏感信息管理，查看文件内容需要另外申请权限）。
最初是想看下是不是有什么异常数据导致写入文件失败的，但是一看只生成了空文件，那么可以确认应该是往文件写入的这部分代码的问题了。这样也就排除掉前面第三步的向OSS上传问题猜测。
Continue reading