保证WCF服务中的数据处理

时间:2010-12-10 17:20:21

标签: c# wcf batch-processing

我有一个WCF服务,可以处理来自SAP的数万条记录的订阅源。服务调用将XElement作为其主要参数,并处理XML以更新数据库中的记录。目前的意图是异步调用WCF服务,并让服务调用向处理者发回与处理的每条记录的状态相同的文档。

我也正在研究多线程处理数据的方法,虽然这可能不会给我带来什么。

因为这可能需要一段时间,我担心如果WCF服务死亡,重新启动等会发生什么。我需要知道我处理了哪些记录,哪些记录没有,哪些记录能够完成剩余记录的处理。

我能够想到的最好的方法是使用状态更新每个节点(无论如何,我必须这样做才能发回给调用者),并将此文件保存到硬盘驱动器中。但是保存一个可能超过100,000次的文件似乎并不可行。

在处理这些记录时,我可以使用哪些其他策略来跟踪这些记录?

TIA!
詹姆斯

4 个答案:

答案 0 :(得分:3)

我认为使用MSMQ是满足您概述的大部分需求的绝佳方式。如果将节点分解为消息并在事务队列中输入它们。

  • 缩放数据处理 拥有更多的东西会更容易 机器处理队列一 你最大限度地发挥了它的能力 之一。
  • 如果WCF“死亡,重新启动等”,你就不会丢失任何东西。
  • 您将在此方案中遇到的真正问题是让客户端确定服务在处理过程中的位置。队列消息只是一种方式。您可能需要另一个服务调用来评估处理队列的状态。

指向MSMQ WCF操作方法的链接:

http://msdn.microsoft.com/en-us/library/ms789048.aspx

http://code.msdn.microsoft.com/msmqpluswcf

答案 1 :(得分:1)

也许您可以先将记录(来自您的XML)放入数据库中,也可以放在特殊的“待处理记录”表中。每行也可能以某种方式标记,以将它们与特定请求相关联。处理数据库中的行。在处理每个时,更新状态字段(对应于您在XmlElement上更新的节点状态)。完成后,你可以返回并更新XML(如果你还没有在此期间崩溃),或者你可以生成新的XML(如果你不能转换转换XML->数据库,可能会有问题 - > XML

如果服务中断,检查数据库以查找尚未处理的记录并完成处理它们应该相对简单。

或者,可以将XML文件写入磁盘一次,在数据库中保留一个只包含“status”字段的表(以及一个或多个键,以便您再次在XML文件中找到相应的记录),进程记录,随时更新数据库“状态”表。完成后,通过从“状态”表中读取状态,一步更新XML文件中的状态字段。

同样,如果服务中断,它应该足够简单,以检查“状态”表,以查看哪些行已处理,哪些行未处理。

祝你好运!

答案 2 :(得分:1)

如果您的源数据库和目标数据库是SQL Server,那么您应该忘记中间人并直接进入数据库中的内置排队支持:Service Broker。与MSMQ相比,您获得了许多优势:

  • 高可用性。 Service Broker内置于数据库中,因此您已实施的数据库高可用性和灾难恢复性解决方案也将自动获取您的消息传递解决方案。您的群集或数据库镜像解决方案将开箱即用,并且消息传递将在数据库故障转移时透明地进行故障转移。
  • 恢复一致性。将消息和数据放在同一个恢复单元(“数据库”)中,可以进行简单的备份 - 恢复。使用存储在MSMQ中的消息,除非您冻结处理,否则无法保存一致的备份。
  • 路由。 SSB允许队列移动到新的物理位置,而不会中断消息流。见Service Broker Routing
  • 增加容量。 MSMQ具有非常小的大小限制(每个队列4GB),可以在生产中快速超支,并带来灾难性的结果。每个消息的SSB限制为2GB ,队列大小限制是数据库大小限制。
  • 由于本地事务而非分布式事务导致吞吐量显着提高。使用MSMQ,您必须将数据库和MSMQ注册到分布式事务中,机器人在您入队的最后,并在您出列的最后。这大大降低了MSMQ情况下的吞吐量。

还有其他优点:

您放弃的一件事是WCF服务模型编程。 WCF使得编写演示应用程序确实非常容易,你会放松它。

答案 3 :(得分:0)

您是否考虑过消息服务器,例如Microsoft Message Queuing