如何避免阻止相关消息

在 BizTalk Server 中排队的消息（例如，通过接收位置或通过业务流程）可以通过以下方式之一进行处理：

• 它们可以激活订户的新实例（即，业务流程或发送端口）

• 它们可以通过相关路由到现有订户实例。 有关相关性的详细信息，请参阅 在业务流程中使用相关性。

  许多开发人员都考虑使用某一解决方案的接收位置来通过同一端口同时接收该解决方案的激活和相关消息。 这种想法很自然，因为这可以大幅减少消息发送方需要跟踪的地址数目。 但是，使用 BizTalk Server 中的限制，在限制方面，单独考虑激活消息流和相关消息流可能会有好处。

  在激活消息和相关消息通过相同接收位置到达时，它们会处于同一阻止状态，因为在主机级别应用阻止。 因此，到达主机中的接收位置的所有消息都将作为一个单位被阻止。 在许多情况下这都不会导致问题，但是，可能存在将相关与激活一起阻止而导致某种类型的系统死锁的情况。

示例

例如，假设您的方案包含一个业务流程，该业务流程接收一个激活并且使用该激活来初始化某一相关集，然后接收跟随在该相关集后的由另外 10 个消息构成的一组消息。 此外，假定在负载下，随着激活消息和相关消息混杂在一起到达，在后台处理中开始出现积压，从而导致阻止本来可被接收的消息量。 不利的是，相关消息随激活一起被阻止，这将减慢业务流程的完成速度，导致进一步的积压和额外的阻止。 再进一步，这可能导致系统的吞吐量下降到接近零。

如果将单个接收位置拆分为两个（一个用于激活，一个用于相关）并且将两个位置配置于不同的主机中，则激活的数据库大小阻止阈值可以保持在低于相关的阻止阈值的水平，这将导致降低整体积压量，并保持消息顺畅流动。

因此，你可能会问：“为什么我不能只提高单个接收位置的数据库大小阈值来解决问题？”答案是，你可以，但它并不总是会导致所需的行为。 阻止在系统中主要用于保护系统以免过载。 如果您将阈值增加得过高，或者将它们全都禁用，就将消除上述保护作用。

建议

就上述对阻止相关消息敏感的方案而言，最佳做法就是将接收位置划分到可以单独执行阻止的多个主机中。

在为接收位置配置单独的主机时，将接收位置使用的主机的数据库大小阻止阈值设置为比业务流程或相关使用的主机的数据库大小阻止阈值更小的值。

如果您知道您的负载将永远不会高于系统的最大可承受吞吐量 (MST)，或者吞吐量峰值在峰值事件之间可恢复，则升高阻止阈值也将行之有效，但所承受的吞吐量将不会高于将单独的主机用于激活和相关所能承受的吞吐量。