以下列方式之一处理已排队进入 BizTalk Server 的消息（例如，通过接收位置或业务流程处理）：
他们可以激活订阅者的新实例（即编排或发送端口）
可以通过关联将其路由到现有订阅者实例。 有关相关性的详细信息，请参阅 在业务流程中使用相关性。
许多开发人员将解决方案的接收位置视为通过同一端口接收解决方案的激活和关联消息。 这是自然的，因为它尽量减少邮件发件人需要跟踪的地址数。 但是，借助 BizTalk Server 中的资源分配限制，在处理激活消息流和相关消息流时分别考虑它们，各自管理的方式可能会带来一些优势。
当激活和关联消息通过同一接收位置到达时，它们受到相同的节流状态影响，因为节流是在主机级别应用的。 因此，到达主机接收位置的所有消息都将作为一个整体受到抑制。 对于许多方案来说，这不是一个问题，但在某些情况下，限制与激活的相关性可能会导致一种类型的系统死锁。
示例：
例如，假设你有一个场景，其中包含一个接收一次激活的编排，利用激活来初始化关联集，然后接收一组后续归于该关联集的 10 个附加消息。 此外，假设在负载状态下，激活和关联消息的混合到达会导致后台积压，因此限制了可以接收的消息量。 不幸的是，关联消息与激活一起被限制，这减缓了编排完成的速度，从而导致进一步的积压和额外的限制。 如果任其继续下去，这将导致系统的吞吐量被削减至接近零。
通过将单个接收位置拆分为两个位置——一个用于激活，另一个用于关联——并在不同主机上分别配置这些位置，可以将激活的数据库大小节流阈值保持在低于关联的水平，从而总体上减少积压，并确保消息流畅传输。
因此，你可能会问：“为什么我不能只提高单个接收位置的数据库大小阈值来解决问题？答案是，你可以，但它并不总是导致所需的行为。 限制主要是为了保护系统免受重载。 如果提高阈值高到足够高，或完全关闭阈值，将消除此保护。
建议
对于如上文描述的对限流关联消息敏感的方案，最佳做法是将接收位置分隔到可以独立限流的不同主机中。
为接收位置配置单独的主机时，将接收位置使用的主机的数据库大小限制阈值设置为低于业务流程或关联使用的主机的数据库大小限制阈值。
如果你知道负载永远不会高于系统的最大可持续吞吐量（MST），或者知道吞吐量峰值在峰值事件之间是可恢复的，那么提高限流阈值也会有作用，但无法像采用单独主机进行启动和关联时那样实现较高的吞吐量。