liuhailiang

@icebear0 亲测无效

压测过程中关注下系统资源状态，常规的 cpu 、io 、链接数、先寻找瓶颈在哪里，在根据资源类型寻找参数配置调优。盲猜是前端的 nginx 机器链接数问题，尝试看看机器的最大 tcp 链接数、nginx 开启长链接、链接复用等；

三个接口
1 、创建导出任务接口：接口立即返回 jobid ，同时开启线程执行导出追加写入文件，线程内执行逻辑先计算总行数，按数量定期更新已导出行数以便能算出导出进度，
2 、查询导出进度接口：前端通过接口 1 得到 jobid 后，轮训此接口，内部查询 job 的导出进度（已导出行数/总行数）
3 、下载 job 文件接口：通过接口 2 轮训结果为完成时，通过此接口下载文件

大体逻辑如上，过程中增加一些安全性、健壮性校验，比如如果表数据会随时增加，那导出时的最大 id 要记录；比如同一人多次点击导出的重复性（进行中任务）校验；比如多人同时导出是否可共用同一个 job ，防止大量导出任务搞挂程序；再比如，2 和 3 和可合并成一个接口，2 为 100%时候，附带下载链接；在比如下载的文件增加一些截止时间什么的好让用户知道下载到的文件截止时间；再比如，提供增量下载巴拉巴拉的节约服务器开销

满足业务要求即可，业务没要求？那就怎么简单怎么做。。

每隔一两个星期和你的同学或者好友喝一顿，扯扯天南海北

如果你是老板，需要给人发工资，那就巴拉巴拉考虑投入产出；
如果你也是打工的，那就看能力是否匹配职位要求，啥年龄不年龄的，聊得来就行，管那么多干啥