确保在WCF服务中处理数据

Question

我有一个WCF服务，该服务处理来自SAP的成千上万条记录。 服务调用将XElement作为其主要参数，并处理XML以更新数据库中的记录。 当前的目的是使WCF服务被异步调用，并使服务调用将相同的文档发送回调用者，并带有处理的每个记录的状态。

我也在寻找对数据进行多线程处理的方法，尽管这最终可能不会给我买任何东西。

因为这可能需要一段时间，所以我担心如果WCF服务死机，重新启动等情况会发生什么。我需要知道已处理哪些记录，未处理哪些记录以及能够完成处理在剩余的记录上。

我能提出的最好的办法就是用状态更新每个节点（无论如何，我必须这样做以发送回调用方），然后将此文件保存到硬盘中。 但是保存一个可能有100,000次大的文件似乎并不可行。

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

TIA！
詹姆士

Answer 1

我认为使用MSMQ是满足您概述的大多数需求的好方法。 如果将节点分解为消息并将它们输入到事务性队列中。

• 通过在队列上处理更多的计算机，您可以最大程度地扩展一台计算机的功能，从而更轻松地扩展数据处理的规模。
• 如果WCF“死亡，重新启动等”，您将不会丢失任何东西。
• 在这种情况下，您将遇到的真正问题是让客户端弄清楚服务在处理中的位置。 队列消息只是一种方式。 您可能需要另一个服务调用，该服务调用将评估处理队列的状态。

链接到MSMQ WCF的操作方法：

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

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

Answer 2

也许您可以首先将记录（来自XML）放入数据库中，也可以放入特殊的“要处理的记录”表中。 每行还可以通过某种方式进行标记，以使其与特定请求相关联。 处理数据库中的行。 当您处理每个节点时，请更新状态字段（对应于您在XmlElement上已更新的节点状态）。 完成后，您可以返回并更新XML（如果同时没有崩溃），也可以生成新的XML（如果无法往返转换XML-> database->，则可能会出现问题。 XML。

如果该服务终止，则检查数据库以查找尚未处理的记录并完成对其的处理应该相对简单。

或者，可以将XML文件一次写入磁盘，在数据库中保留一个仅包含“状态”字段的表（以及一个或多个键，使您可以再次在XML文件中找到相应的记录），处理记录，随时更新数据库的“状态”表。 完成后，一口气通过从“状态”表中读取状态来更新XML文件中的状态字段。

同样，如果服务终止，则应该足够简单地检查“状态”表，以查看哪些行已处理，哪些行未处理。

祝好运！

Answer 3

如果您的源数据库和目标数据库是SQL Server，那么您应该忘掉中间人，直接去数据库中的内置队列支持： Service Broker 。 与MSMQ相比，您可以获得许多优势：

• 高可用性。 Service Broker内置于数据库中，因此您已经实现的数据库高可用性和灾难可恢复性解决方案也将自动采用您的消息传递解决方案。 您的群集或数据库镜像解决方案将立即可用，并且消息传递将随着数据库故障转移而透明地进行故障转移。
• 恢复一致性。 将消息和数据存储在同一恢复单元（“数据库”）中，可以进行简单的备份-还原。 除非冻结处理，否则无法将消息存储在MSMQ中和数据库中存储的数据进行一致的备份。
• 路由。 SSB允许队列移动到新的物理位置，而不会中断消息流。 请参阅Service Broker路由 。
• 增加容量。 MSMQ的大小限制非常小（每个队列4GB），可以在生产中迅速超负荷运行，从而造成灾难性的后果。 SSB限制是每条消息 2GB，队列大小限制是数据库大小限制。
• 由于本地事务而不是分布式事务，因此吞吐量显着提高。 使用MSMQ，您必须将数据库和MSMQ注册到分布式事务中，在入队末尾和出队末尾是bot。 这极大地降低了MSMQ情况下的吞吐量。

还有其他优点：

• 队列可查询性：可以使用T-SQL SELECT查询消息队列
• 一种编程API：T-SQL。 你并不需要了解MSMQ接口（和WCF通道上随着MSMQ不过是一个浅垫片在MSMQ API， 没有像其他渠道你可能已经使用过）。 通过SSB，您可以使用现有的T-SQL专业知识在T-SQL中进行编程。
• 激活 。 当消息到达时，存储过程将启动并执行。
• 会话语义：对话
• 消息相关并发保护： 会话组锁 。
• 状态管理
• 可伸缩性： MySpace使用SQL Server Service Broker保护1 PB数据的完整性

您松散的一件事是WCF服务模型编程。 WCF确实使编写演示应用程序变得异常容易，您将无法使用它。

Answer 4

您是否考虑过消息传递服务器，例如Microsoft Message Queuing 。