我需要为WCF服务请求实现排队机制。客户将以单向方式调用该服务。这些请求消息应存储在SQL Server数据库中,Windows服务将对消息进行排队。处理请求的时间是可配置的。如果在处理消息时发生错误,则需要重试最多100次,如果仍然失败则需要终止。
此外,应该有一种机制来监控一天的交易次数和失败次数。
问题
如果我使用的是MSMQ,客户端可能会在不知道服务端点的情况下将消息转发到队列。但我使用SQL Server来存储请求消息。客户端如何将请求发送到SQL Server?
解决方案是否可行?我们是否有任何文章/书籍解释如何实施上述内容?
在这种情况下,阻止服务和客户端到达故障状态的步骤是什么?
将传入消息存储到数据库的最佳方法是什么?
实施重试机制的最佳方法是什么?任何已经存在的东西,以便我不必重新发明轮子?
是否有任何书/文章解释此实施?
注意
阅读
答案 0 :(得分:3)
我是一名DBA,因此我的回答有点味道,但这就是我要做的事情:
请注意,没有任何计划的回滚。 Service Broker中的回滚可能很糟糕;如果在没有成功接收的情况下回滚5次,则队列将因排队和出列而被禁用。但是,当您的消息处理器在处理过程中死亡(即服务器崩溃)时,您仍希望获得事务处理。
答案 1 :(得分:2)
1。如果我使用的是MSMQ,客户端可能会在不知道服务端点的情况下将消息转发到队列。
是 - 但是他们需要知道 MSMQ端点才能将他们的消息发送到队列.....
但我使用SQL Server来存储请求消息。客户端如何将请求发送到SQL Server?
客户端不会将他们的请求放入SQL Server - 这就是服务器上的服务所做的事情。客户端只调用一个服务方法,其中的代码将请求存储到SQL Server表中。
2。解决方案可行吗?我们是否有任何文章/书籍解释如何实施上述内容?
当然,我没有看到任何大问题。我现在唯一不清楚的一点是:客户如何知道他们的结果?他们是否需要从其他服务或其他服务获得结果?
3。在这种情况下,阻止服务和客户端到达故障状态的步骤是什么?
一如既往 - 只需确保您的服务代码捕获所有异常并在内部处理它们,或者返回可互操作的SOAP错误而不是.NET异常。
答案 2 :(得分:2)
听起来你想要做的就是这样:
在这种情况下,您可以在服务和服务使用者之间使用netMsmqBinding。
你唯一不会开箱即用的是重试。但是,如果您将队列设置为事务性,则可以在服务代码中实现此功能。
如果您的出队操作失败,则不会从队列中删除该消息。因此,它可用于进一步的出队尝试。
但是,您需要实现重试尝试阈值代码,该代码在一定次数的尝试后失败。