我正在寻找有关如何解决此问题的建议，以及我是否正在使用适合该工作的工具。我主要从事BizTalk的工作，我们目前正在将BizTalk 2013 R2与SQL 2014一起使用。
问题：
我们每天（大约50个）都会收到来自各个合作伙伴的定位平面文件，理论上收到的记录总数将超过一百万条。每个记录都有一些识别信息，需要将这些识别信息发送到Web服务，该服务本质上会以YES或NO返回，基于此信息，传入文件被分为两个文件。
最初，每日预期记录的范围为1万，后来增加到10万，现在达到了100万。
尝试1：分散聚集模式
我正在使用文件反汇编器在自定义管道中分批处理记录，为分散部分添加了几个端口可配置的属性（遵循Richard Seroter提出的实现循环分配的建议），在此我控制旋转的分散/工作流程的数量调用Web服务并标记要发送到“机构A”或“机构B”的记录，最后推送控制消息，该消息将启动Gather / Aggregator编排，以将所有从工作人员处理的消息收集到通过关联的消息框，并创建两个文件以路由到代理商A和代理商B。
因此，每个被删除的文件将拥有自己的一组工作器和一个聚合器来处理该文件。
这对于记录数量较少的文件效果很好，但是如果一个文件具有超过100k的记录，我会看到出现节流并且该文件需要很长时间来处理和生成两个文件。
我已将接收位置/工作人员和聚合器/发送端口放在单独的主机上。
看来，收集器似乎已脱水，并且直到所有工人全部处理完毕后才真正汇总工人处理的记录，我认为由于已发布的消息与已处理的消息之比非常大，因此很麻烦。
方法二：
假定聚合器流程是瓶颈，而不是将其累积在流程中，我将处理后的记录推送到SQL db，然后将记录“拆分”为两个XML文件（基本上是将msg串联到代理商A / B并进行包装）以XML声明的形式使用，并根据将某些上下文属性与记录一起写入SQL表的方式使用正确的msg类型）。
这些汇总的XML记录将被轮询并路由到正确的代理机构。
这似乎可以处理10万条记录，并且可以在可接受的时间内完成。现在，目标发布/需求在预期数量方面再次发生了变化，我正在尝试查看BizTalk是否甚至不再是可行的选择。
我已经指出，BT不是执行此任务的正确工具，但是客户建议我们添加更多服务器以使其工作。我正在看SSIS。
同时，在进行一些测试时，一些观察结果：
工人数量的增加改善了加工（duh）：
如果每个工作人员处理的队列/预订中的记录数量较少，则看起来他们很快完成了队列。测试此100k记录文件时，需要使用100名工人在3小时内完成。这样，服务器上其他应用程序的活动最少。
我正在尝试让Web服务托管团队为我提供他们可以处理的最大理论并发连接数。我倾向于让他们看看他们是否可以处理1000个电话，也许现有的解决方案可以根据我的观察进行扩展。
我已经针对邮件计数和物理内存阈值调整了主机的一些设置，因此它不会影响音量，但是我仍然不确定。我以前不必弄乱这些设置，可以使用建议来监视任何特定的计数器。
这篇文章有点长，但是我希望这能给我到目前为止的想法提供一个思路。在解决此问题方面的任何帮助/见解均表示赞赏。如果您建议替代方案，我将限于基于.NET或MS的工具/框架，但也希望听到其他选择。
如果您想澄清或理解我不清楚的内容，我将尝试回答或提供更多细节。
最佳答案
首先，一百万条记录/消息不是问题，但是如果处理不当，可能会成为问题。
这是我首先要设计的模式。
使用SSIS将记录加载到SQL Server中。这将非常快。
将记录处理/导出到BizTalk应用中以进行...好吧，无论需要做什么。致电服务等
用结果更新SQL记录。
该过程完成后，将“是”和“否”批次分别作为一条（大）消息进行查询，然后进行转换和发送。
我的猜测是，除非Web Service专门针对这种负载而设计，否则它将成为瓶颈。您可能只需要在必要时调整BizTalk的速度即可，但现在不必担心。良好的应用程式模式更为重要。
关于sql-server - 在BizTalk中批量处理一百万条记录，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44793950/