我们其中一款产品的架构是典型的 3 层解决方案:
- C# 客户端
- WCF 网络服务
- SQL Server 数据库
客户端从 Web 服务请求信息。Web 服务访问数据库以获取信息并将其返回给客户端。
这就是问题所在。其中一些查询可能需要很长时间,而且我们预先不知道哪些查询会很慢。我们知道一些通常比其他的慢,但即使是最简单的请求也可能会因为足够的数据而变慢。有时对大量数据使用查询或运行报告。查询只能在庞大的数据量减慢查询速度之前进行优化。
如果数据库中的查询达到 SQL Server 中的最大查询超时,则数据库查询终止,并且 Web 服务向客户端返回错误。这是可以理解的。我们可以处理这些错误。
客户端正在等待 Web 服务调用完成。如果数据库调用需要很长时间,客户端可能会在调用 Web 服务时超时。客户端放弃,但数据库请求继续处理。此时,客户端与数据库不同步。数据库调用可能会也可能不会成功。可能有错误。客户永远不会知道。在某些情况下,我们不希望我们的用户发起另一个请求,这可能会在前一个请求完成后导致无效状态。
我很好奇其他人是如何处理这个问题的。 您使用了哪些策略来防止 Web 服务超时影响数据库调用?
我能想到的最好的想法是在某处建立一个实际的数据库层——在 Web 服务内部,连接到消息队列——一些东西。将每一个查询卸载到另一个进程似乎是多余的。(再说一次,我们并不总是知道给定的请求是快还是慢。)
如果我们可以将发出 HTTP 请求的行为与启动和运行数据库进程的行为分开,那就太好了。我在以前的公司看到过使用自定义服务器完成此操作,但它使用的是直接套接字通信,我宁愿避免用一些自定义应用程序替换 Web 服务。
请注意,考虑到我们处理的数据量,我们已经完成了查询优化。查询优化、索引等,仅在数据量大的情况下才带您到此为止。有时事情只需要很长时间。