【问题标题】:Rebus with MSMQ: Erratic delivery-time使用 MSMQ 的 Rebus:不稳定的交付时间
【发布时间】:2016-09-29 17:06:32
【问题描述】:

我们将 Rebus 与 MSMQ 一起用于应用程序组件之间的基于消息的通信。组件都在同一台机器上运行。

发送和接收消息之间的时间通常保持在 1 秒以下。但是如果系统空闲一分钟左右(意味着没有消息正在发送),接下来的一两条消息有时需要大约五秒钟才能传递。 MSMQ 性能计数器显示这些消息在此期间保留在队列中。

对于我们的应用程序,希望消息具有恒定的传递时间(小于一秒)。

这种行为的原因可能是什么? 有没有办法影响 MSMQ 或 Rebus 中消息的传递时间? 我们是否应该选择其他运输类型以获得更稳定的交货时间?

【问题讨论】:

    标签: rebus


    【解决方案1】:

    默认情况下,Rebus 会根据 BackoffBehavior 中的时间跨度逐渐停止对队列的轮询 - 如您所见,如果它保持足够长的空闲时间,它将最终每 5 秒轮询一次队列。

    您可以通过以下方式更改为低延迟退避策略

    Configure.With(...)
        .(...)
        .Behavior(b => b. SetLowLatencyBackoffBehavior())
        .(...)
    

    在配置中。


    更新:在更高版本的 Rebus(即版本 >= 2)中,可以像这样自定义回退时间:

    Configure.With(...)
        .(...)
        .Options(o => {
            o.SetBackoffTimes(
                TimeSpan.FromMilliseconds(100),
                TimeSpan.FromMilliseconds(200),
                TimeSpan.FromSeconds(1)
            );
        })
    

    在这种情况下,在空闲运行的前两秒以 100 毫秒和 200 毫秒的间隔轮询,然后在其余时间以 1 秒的间隔轮询。

    如果这个级别的自定义还不够,可以通过上面的.Options 配置器中的o.Register<ISyncBackoffStrategy>(c => new YourOwn SyncBackoffStrategy()) 来实现和使用ISyncBackoffStrategy

    【讨论】:

      【解决方案2】:

      据我所知,当 Rebus 注意到队列中没有消息时,它会逐渐增加它在下次查看之前等待的秒数。

      您提到的 5 秒似乎与我之前在调试模式下运行 Rebus 时所经历的最大等待时间非常吻合(您可以看到,它增加了时间跨度)。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2013-06-17
        • 2017-08-15
        • 2012-01-26
        • 1970-01-01
        • 1970-01-01
        • 2013-06-28
        相关资源
        最近更新 更多