换个思路，你的所有问题都在超时上面！ 为什么超时，因为等待时间过长。那为什么要等待呢？？？

你可以发出请求，服务器端执行，告诉用户，正在执行，表示就成功了。然后就是用户接受邮件的等待。

这个时候，你可以告诉用户需要等待，或者加一个消息通知，成功后通知用户

边读数据，边写数据，比如分页读写，这样就不会超时了

需要服务端生成报表,由于数据量过大。往往会导致下载过程中504错误。

看你的意思，超时的原因不是产生报表耗时太久，而是因为报表文件过大造成的。

3种做法

1.压缩报表文件，例如：tar,gzip,zip……

2.修改web服务器的超时时间设定。

3.导出的文件放到另外一个目录用其他工具下载，例如:ftp,samba,sftp……

最直接的办法便是，压缩数据(例如导出时进行压缩)，调整 CGI 超时时间。这其中，可以考虑节省 CGI 进程(因为即使输出成果已经完成，按照题主的说明，fast_cgi 的 response buffer 肯定是远远小于这次输出的大小)，在最后输出的过程上用其他服务(例如直接用nginx)代劳。

其实，例如在问题中的这种从产品设计的角度解决问题在我看来最优解，实时下载真的是那么必要吗？

谢谢各位的回答。
这边我自己总结了一下,根据我自己的实际情况主要

1. 前台异步提交一个请求，后台进行异步组合报表。然后通过1. 邮件的方式通知用户2. 通过定时器将消息PUSH给用户,让用户去相应的地址上下载
2. 查询时间精确到秒。在用户请求之前,先告诉用户在这个时间段订单个数。我们可以设定一个合理的值来提示用户(改动最小)
3. 采取任务的形式,前台提交一个任务给后台,后台创建一个任务，并且存入数据库。前台可以每隔30s向后台请求,获取任务的状态,以防止超时。相应的前台有一个loading框(这里也可以改成将文件的生成过程放在服务端,然后这里给用户返回的是一个连接,用户可以直接点连接来下载文件)(这个类似使用AJAX的长连接模式)
4. 把分析过程放在服务端。服务端起一个定时任务,隔段时间去分析这些数据。直接生产文件放在服务端。可以提供给用户一个下载列表直接提供给用户下载
   5.优化流程,采取dubbo批量数据请求。采取dubbo异步请求。多线程处理数据。多个dubbo服务合并(性能优化)