Tibco RV：消息生命周期 + 扇出无副本

Question

1、消息在监听队列中存活多久？直到调度程序在“1 个发布者 1 个消费者”场景中从队列中读取消息？

Listener listener = new Listener(Queue.Default, transport, subject, new object());
listener.MessageReceived += OnMessageReceived;
Dispatcher dispatcher = new Dispatcher(listener.Queue);

2，Tibco RV 通常用于大型扇出系统，对交付可靠性的要求相对宽松，例如发布到企业中 20 个应用程序的市场数据。我听说 Tibco RV 为扇出实现了“无副本”解决方案——这怎么可能？我假设我们至少需要遍历该队列的所有已注册侦听器并通知每个侦听器，在该过程中消息被复制 20 次。请赐教。

3，结合问题 1 和 2，在所有注册的侦听器都消费完消息之前，将消息存在于侦听器队列中是没有意义的 - 如果 20 个应用程序中有 1 个下线会发生什么情况？由于不断增加的消息，它将关闭 rv 守护进程。 Tibco RV 是否对每条消息都有生命周期限制 (ttl)？如何检查它并将其设置为新值？

Google 上没有太多相关信息，请大家帮忙。

谢谢。

Answer 1

好问题。

1. 请记住，除非您使用 RV 认证的消息传递，否则不会持久保存到磁盘。发送的消息将保留在发送 Rendezvous 守护进程的内存中，直到它们被传递给所有消费者。

   也就是说，要理解的另一件事是，RV 是一个 乐观 协议，而不是说 TCP 是一个 悲观 协议。使用 TCP 发送的每个数据包都必须得到确认。这种往返协议会减慢速度。另一方面，Rendezvous 使用位于 UDP 之上的协议，该协议是无会话且不需要确认的。因此，当 Rendezvous 守护进程发送消息时，假定它已成功传递除非收到重传请求。因此，要完全回答您的第一个问题，Rendezvous 守护程序的默认行为是在发送消息后将其已发送的消息保留在内存中 60 秒。这允许它遵守重传请求。

2. 在 UDP 之上使用广播或多播协议实现扇出。不鼓励使用广播，鼓励使用多播。使用多播组使用的网络资源要少得多。在网络接口级别，只有那些已加入多播组的主机才能接收与 Rendezvous 流量相关的数据包。同样，在网络交换机级别，多播占用的资源要少得多。

   底线是发送 Rendezvous 守护进程只发送一次消息，如果使用广播，网络将关联数据包的副本发送到子网上的每个主机，或者如果使用多播，则向注册感兴趣的主机发送相关数据包的副本。用过。

3. 在 pub-sub 中，通常消费者会收到在他们处于活动状态和消费状态时发送的消息。因此，对于纯 Rendezvous，如果某个消费者宕机，该消费者的订阅将​​被取消。如果我们考虑您的市场数据示例，这正是我们想要的行为。 IBM 每秒交易数千次，所以如果我错过报价也没什么大不了的。我会得到下一个。此外，我不想要过时的价格。

   也就是说，有时消费者确实希望在他们宕机时发送消息。这可以通过使用经过认证的消息传递和设置持久通讯者来实现。有关这方面的更多信息，请参阅Rendezvous Concepts Guide。最后，我在第 1 点中提到的 60 秒行为可以在启动 Rendezvous 守护程序时使用 -reliability 参数进行更改。在某些情况下，这可能是有意义的（尽管默认值最适合大多数常见情况）。有关这方面的更多详细信息，请查看Rendezvous Admin Guide。