1

我刚刚开始评估 ServiceBroker 以确定它是否可以在非常特定的上下文中作为可靠队列执行。这是场景：

(1) 需要预先计算大量（数百万）计算成本高的值并存储在队列中。

(2) 多个进程将根据需要在运行时尝试读取/出列这些值。每秒可能有数百次读取。

(3) 一个监控进程会偶尔轮询队列并确定是否达到了人口最小阈值，然后将重新填充队列。

由于一些基础设施/成本限制，工业强度的队列（websphere）可能不是一个选择。到目前为止，我所看到的 Service Broker 并不令人鼓舞，因为它似乎被隔离为具有 2 个端点的“对话”，并且在我的场景中，我的读取完全独立于我的写入。有没有人知道这是否可以通过 SQL Service Broker 实现？

4

1 回答 1

0

尽管 Service Broker 并非针对此类场景而设计，但我认为只需稍作调整，它就可以在您的情况下使用。

一种方法是预先创建一个对话池，然后在存储值时在这些对话之间循环计算过程。由于从队列中接收会锁定对话，因此对话的数量本质上设置了有多少进程可以同时出列值的上限。我不确定这一点，但您可能需要在接收方有一些逻辑来明确告诉从哪个对话接收（为了实现比默认接收行为更好的负载平衡）。

如果性能不是问题，那么您甚至可以放弃对话池的想法，并在单独的对话框中发送每条消息，这将以显着的性能命中为代价使实现方式更简单。

以上所有内容都是假设值可以以随机顺序出队，否则您需要通过使用单个对话来保证接收顺序。

于 2010-07-19T07:07:09.090 回答