我刚刚开始评估ServiceBroker，以确定它是否可以在非常特定的上下文中作为可靠队列执行。这是场景：
（1）需要预先计算大量（数百万）计算上昂贵的值并存储在队列中。
（2）多个进程将根据需要尝试在运行时读取/出列这些值。可能是每秒几百次读取。
（3）监视进程偶尔会轮询队列并确定是否已达到总体最小阈值，然后重新填充队列。
由于某些基础设施/成本限制，工业强度Queue（websphere）可能不是一种选择。到目前为止我所看到的Service Broker并不令人鼓舞，因为它似乎与2个端点的“对话”隔离开来，在我的场景中，我的读取完全独立于我的写入。有没有人知道SQL Service Broker是否可以实现这一点？
答案 0 :(得分：0)
虽然Service Broker并不是针对这种情况而设计的，但我认为只需稍加调整就可以解决这个问题。
一种方法是预先创建一个会话池，然后在存储值时使这些会话之间的计算过程循环。由于从队列接收会锁定会话，因此会话数基本上设置了有多少进程可以同时将值出列的上限。我不确定这一点，但你可能需要接收器端的一些逻辑来明确告诉要接收的对话（为了实现比默认接收行为更好的负载平衡）。
如果perf不是一个问题，那么你甚至可以放弃对话池的想法，并在单独的对话框上发送每条消息，这将使实现方式变得更简单，代价是显着的性能损失。
以上所有内容均假设值可能以随机顺序出列，否则您需要使用单个对话来保证接收顺序。