我们产品的体系结构是典型的三层解决方案:
C客户端
WCF Web服务
SQL Server数据库
客户端从web服务请求信息。web服务点击数据库获取信息并将其返回给客户机。
这就是问题所在。有些查询可能需要很长很长的时间,我们不知道前面的哪个会慢。我们知道一些通常比其他慢,但即使是最简单的请求也会很慢,因为有足够的数据。有时对大量数据使用查询或运行报告。只有在数据量减慢它们之前,查询才能被优化。
如果数据库中的查询达到了SQL Server中的最大查询超时,则数据库查询将终止,Web服务将向客户端返回错误。这是可以理解的。我们可以处理这些错误。
客户端正在等待Web服务调用完成。如果数据库调用需要很长时间,则客户端对web服务的调用可能会超时。客户端放弃,但数据库请求继续处理。此时,客户端与数据库不同步。数据库调用可能成功,也可能失败。可能有错误。客户永远不会知道。在某些情况下,我们不希望我们的用户启动另一个请求,这可能会导致无效的状态,前提是前一个请求已完成。
我很好奇其他人是如何处理这个问题的。您使用了哪些策略来防止Web服务超时影响数据库调用?
我能想出的最好的办法是在某个地方建立一个实际的数据库层——在Web服务内部,附加到一个消息队列中。将每个查询卸载到另一个进程似乎太过了。(再说一遍,我们并不总是知道给定的请求是快是慢。)
如果我们能够将发出http请求的行为与启动和运行数据库进程的行为分离开来,那将是非常好的。我以前在一个公司看到过定制服务器,但是它使用的是直接套接字通信,我宁愿避免用一些定制的应用来替换Web服务。
注意,考虑到我们处理的数据量,我们都在进行查询优化。查询优化、索引等,只在数据量很大的情况下才进行。有时候事情需要很长时间。

最佳答案

我以前也遇到过类似的问题,并用以下三种方法之一解决:
将所有长时间运行的查询添加到队列中,并按顺序处理这些查询。
在我的案例中,这些都是复杂的报告,然后通过电子邮件发送给客户,或者存储在永久的“临时”表中,供客户在收到通知后查看。
我们使用jquery调用调用了一个webservice,然后在它完成时调用javascript回发方法。
当我们不想让页面加载与web服务所做的同步时,这个方法很有效。
但是,这确实意味着,在长时间运行的进程完成之前,这一功能是不可用的。
最复杂的一个。
我们弹出了另一个显示进度条的窗口,该窗口还定期轮询服务器。
这使用一个会话变量来确定显示进度条的进度。
启动进度条后,将启动一个新线程,该线程将定期更新同一会话变量。
会话变量值设置为100后,弹出窗口将自动关闭。
客户喜欢这种方法。
不管怎样,我希望其中一个对你有帮助。

08-26 18:56
查看更多