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, чтобы сообщение не имело смысла жить в очереди прослушивателя, пока ВСЕ зарегистрированные зарегистрированные прослушиватели не сожрут сообщение. Что произойдет, если 1 из 20 приложений отключится? Он собирается остановить процесс демона rv из-за постоянно увеличивающихся сообщений. Есть ли у Tibco RV лимит времени жизни (ttl) для каждого сообщения? Как мне проверить это и установить новые значения?

В Google не так много связанной информации, поэтому, пожалуйста, помогите.

Благодарю.

Answer 1

Великолепные вопросы.

1. Имейте в виду, что если вы не используете сообщения, сертифицированные RV, сохранение на диске не будет. Отправленные сообщения останутся в памяти отправляющего демона Rendezvous, пока они не будут доставлены всем потребителям.

   Тем не менее, еще одна вещь, которую нужно понять, это то, что RV - это оптимистичный протокол, в отличие от TCP, который является пессимистичным протоколом. Каждый пакет, отправленный с использованием TCP, должен быть подтвержден. Этот двусторонний протокол замедляет работу. С другой стороны, рандеву использует протокол, который находится поверх UDP, который не требует сеансов и не требует подтверждений. Поэтому, когда демон Rendezvous отправляет сообщение, предполагается, что он был успешно доставлен, если не получен запрос на повторную передачу. Таким образом, чтобы полностью ответить на ваш первый вопрос, поведение демона Rendezvous по умолчанию заключается в том, чтобы хранить сообщения, отправленные им, в памяти в течение 60 секунд после отправки сообщения. Это позволяет ему выполнять запросы на повторную передачу.

2. Разветвление достигается с помощью широковещательных или многоадресных протоколов поверх UDP. Использование широковещательной рассылки не рекомендуется, а многоадресная рассылка приветствуется. Использование групп многоадресной рассылки потребляет значительно меньше сетевых ресурсов. На уровне сетевого интерфейса только те узлы, которые присоединились к многоадресной группе, будут получать пакеты, связанные с трафиком Rendezvous. Аналогично, на уровне сетевых коммутаторов многоадресная рассылка намного менее ресурсоемка.

   Суть в том, что отправляющий демон Rendezvous отправляет сообщение только один раз, и сеть доставляет копию связанных пакетов либо каждому хосту в подсети, если используется широковещательная рассылка, либо хостам, которые имеют зарегистрированный интерес, если используется многоадресная рассылка.

3. В pub-sub, как правило, потребители получают сообщения, которые отправляются, пока они живы и потребляют. Таким образом, в случае чисто рандеву, если потребитель потерпит неудачу, подписка для него будет отменена. Если мы подумаем о вашем примере рыночных данных, это именно то поведение, которое мы хотим. IBM торгует тысячи раз в секунду, поэтому, если я пропущу ценовое предложение, это не проблема. Я получу следующий. Кроме того, я не хочу устаревших цен.

   Тем не менее, иногда потребители хотят получать сообщения, когда они не работают. Это может быть достигнуто с помощью сертифицированных сообщений и настройки постоянных корреспондентов. Подробнее об этом см. В Руководстве по концепциям рандеву. Наконец, 60-секундное поведение, которое я упомянул в пункте № 1, можно изменить с помощью параметра -reliability при запуске демона Rendezvous. В некоторых случаях это может иметь смысл (хотя по умолчанию лучше всего подходит для большинства распространенных случаев). Подробнее об этом смотрите в Руководстве администратора Rendezvous.