当服务器需要很多时间去计算的时候，如何处理前后端交互的问题

[abcbuzhiming]

绝大部分web服务请求——响应最多几秒的时间，web请求也设置了超时时间，但是现在假设有一个来自客户端的请求，服务端整个算完必须很久，比如我之前遇到的一个业务，客户端只点了三个位置，输入了一段话（实际上是短信），，然后提交上去，服务端要读取1000w条记录，并把短信内容加载1000w条记录里去，并且插入到新表去，这个操作服务器算完怎么也要几分钟，这种情况下该怎么设计前后端交互问题，超时只是一方面，另外一方面我不希望客户在那傻等

[疯狂之程序员]

新开启一个线程处理这些东西

[abcbuzhiming]

引用 1 楼 q502515319 的回复:

新开启一个线程处理这些东西

但是前端怎么办，前端发出一个请求后是有超时的时间的好吗

[大雨将至]

可以直接插到任务队列，然后通知用户稍后查询操作结果 后台开一个线程去处理，处理完成后更新一个表记录的状态。友好点的话可以把处理进度也写入结果表，随时供用户查询 如果希望用户停留在浏览器界面等待，其实也是一样的原理，只不过用setInterval开启一个ajax每隔一定时间查询一次处理结果，直到处理完成

[tianfang]

异步处理 用户提交后，再点查询按钮的方式交互

[Derick-L]

楼上的两种方法都采用，友好交互，不影响去做其他事，并且可以主动查询结果，或者 也可以推送，提交请求以后 假如需要很长时间才能完成，那就开启线程，一直跑，但还需要再开启一个监控线程，监控完成状态。完成以后要怎么操作 就看你自己的想法了。监控其实可以提取出来，

[zhuweisyyc]

用户提交后，跳转到等待页面上，让页面轮训处理结果，应该够友好了吧，就根平时的支付场景

[reyoreyoreyo]

Java web实时进度条整个系统共用(如java上传进度条、导入excel进度条等)
你可以看看这个 http://www.cnblogs.com/interdrp/p/5677874.html

[reyoreyoreyo]

[oxcow]

还是异步吧，弄个进度条没意义，好几分钟，用户应该不会傻了吧唧的在那等着。 用户提交后，直接提示，大概需要几分钟进行处理，请稍候再来查看结果。这样用户可以去干其他事情了。 上面提的的拉和推都可以，NB点可以搞推送，只要用户不关闭浏览器。次一点的，让用户自己去查吧。这两种方式可有利弊，你可以权衡下实现难度和用户对交互的迫切程度来觉得。 个人觉得这种需要服务端大量计算的，走异步，结果让用户来查就行，没必要搞得那么花哨（推送）！

[oxcow]

在用户不要求立即看到结果的情况下，还有一种就是将用户的操作数据放到缓存中，比如redis中，然后快速响应。 服务端在重启线程将缓存中的数据放到数据库中

[oxcow]

引用 10 楼 oxcow 的回复:

在用户不要求立即看到结果的情况下，还有一种就是将用户的操作数据放到缓存中，比如redis中，然后快速响应。 服务端在重启线程将缓存中的数据放到数据库中

看你的具体场景了。无外乎就是同步和异步，推和拉了!

[IAmObject]

如果必须想立马看见的话，可以把数据先预先存到缓存，这样每次直接用缓存的数据去处理，就基本不会耗时了。但是这种情况比较占内存，可是鱼与熊掌不可兼得嘛

[及时雨送浆]

参考12306

[爱吃火锅的S]

个人理解，参考新浪微博的处理方式，采用异步推拉的方式，用户提交之后直接推到消息队列中，此时给用户返回处理结果，然后点击查询已有的记录时再从数据库拉出来。

[清风文人]

设置等待弹框

[pois]

先进缓存，然后异步持久化

[青年卫大师]

可以使用请求推送模式 前端发送一个请求 后台处理完了推送到前端

[grrrrrowth]

可以去用消息队列！参考电商秒杀。

[新技术追求者]

异步是最好的选择，让客户觉得他已经处理好了，但是实际上我们的工单还是在后台跑着，还在处理，作为一个运营着，这个样的话，给客户的感觉很好，而不是让客户取等待！