我正在创建一个接受许多连续请求的wcf Web服务，Web服务需要保留这些请求，直到内部应用程序（每隔几秒钟将轮询Web服务）发出请求用于确定是否存在任何请求的Web服务，如果存在则检索它们。然后，内部应用程序将响应发送回Web服务，该响应将响应传递回初始调用者。
IE：
客户--- 1）请求---＆gt; Web服务＆lt; --- 2）请求---内部申请
客户＆lt; - 4）响应--- Web服务＆lt; --- 3）响应---内部应用
我正在尝试设计Web服务的实现，并试图想出实现接受请求的机制的方法，保留它直到内部应用程序发出数据请求并且Web服务等待对于内部应用程序的响应。
我主要担心的是：
1）如果在内部应用程序提出请求之前有数千个请求进入，应如何保留？
2）如果内部应用程序死亡并且大量请求累积怎么办？ （我将需要超时这些请求）
3）如何将初始请求与客户端连接以及内部应用程序的响应？
4）客户将等待等待回复。
WCF消息队列会在这种情况下提供帮助吗？ Web服务是否能够在内部管理Message Queue，例如，当Web服务中的消息将消息添加到队列时，类似地，当内部应用程序发出请求时，Web服务从顶部抓取消息队列并将其传递给内部应用程序并等待内部应用程序的响应并将其传递回客户端？
甚至可能吗？
如果2000客户端请求同时进入，因为客户端将同步等待响应，上述方案是否有效？我是否能够将原始请求与内部应用程序线程的响应进行匹配，以便将响应提供给客户端？
消息队列方法看起来有些过分吗？我可以在一些静态字典中保存请求吗？
你还有其他建议吗？
答案 0 :(得分：0)
首先，坦率地说，轮询式架构对于实时请求处理来说听起来非常错误。如果可以将请求直接转发到将要处理它们的应用程序，那将是无限可取的。你正在为自己打开一大堆额外的问题，你甚至将你的最佳案例响应时间限制在“几秒钟”，这是非常糟糕的。
但是。假设您无法对架构执行任何操作，则将消息排队以供内部应用程序检索不是问题。内存中的队列结构可以处理这种情况（只需将队列的大小限制为几千，如果填满则返回错误）。您真正的瓶颈将是Web服务上的打开请求数。我只是没有看到如果每个请求的最小打开时间为“几秒钟”，指定的体系结构将如何能够处理数千个请求/秒。服务器不是为了保持打开许多请求而设计的。能够处理数千个请求/秒的那些通过在几毫秒内响应每个请求然后清除它来做到这一点。如果每个请求都打开了几秒钟，那么它将会破坏你的服务器 - 请求将排队，并且90％的请求将最终超时，假设你的服务器本身没有在重量下崩溃。