Гарантии доставки Orion Context Broker?

Размышляя о «производственном» использовании Orion Context Broker, мне интересно, какие гарантии предоставляет Orion Context Broker в отношении доставки сообщений - как с точки зрения производителя, так и с точки зрения потребителя? В частности, принимая во внимание различные возможные сценарии отказа (отказ / перезапуск CB, временный отказ сети, отказ / перезапуск потребителя и т. Д.), А также возможность перегрузки ресурсов в CB. Несколько примеров:

1) если операция обновления контекста завершается успешно, гарантируется ли, что последующие запросы будут возвращать самые последние данные (например, даже если CB завершился неудачно сразу после подтверждения запроса на обновление, а затем перезапустился)?

2) если потребитель подписался на определенную контекстную информацию, гарантировано ли, что он получит все соответствующие обновления - ровно один раз, хотя бы один раз или даже вообще? (например, в случае временного сбоя сети между CB и потребителем)

3) если потребитель обновил свою подписку, гарантировано ли, что последующие обновления точно отразят это? (например, если CB вышел из строя сразу после подтверждения запроса на подписку, а затем перезапустился)

4) если потребитель подписан на изменения контекста ('onchange', без дросселирования), и есть несколько последовательных обновлений от производителя, влияющих на один и тот же атрибут, гарантировано ли, что каждое из изменений будет отправлено (или некоторые из них могут быть пропущены - например, из-за слишком большого количества уведомлений, которые CB должен отправить в течение определенного периода времени), в любом конкретном порядке?

так далее...

Спасибо!


person Alex Glikson    schedule 06.12.2015    source источник


Ответы (1)


Отвечая пуля за пулей:

  1. Обычно, если клиент получает ответ 2xx (внутри ответа полезная нагрузка в случае NGSIv1, код ответа HTTP в случае NGSIv2) можно предположить, что обновление было сохранено в базе данных контекста, поэтому последующие запросы вернут эти данные (за исключением случая выполнения CB с -writeConcern 0 если БД выходит из строя до того, как обновление может быть сохранено из памяти БД на диск).

  2. Чтобы упростить задачу, CB использует политику уведомлений «запустил и забыл». Однако CB можно комбинировать с программным обеспечением ретрансляции HTTP (например, Rush, автобусами событий и т. Д.), Чтобы реализовать повторные попытки и т. д.

  3. Как и в случае 1, если клиент получает ответ 2xx (внутри полезная нагрузка ответа в случае NGSIv1, код ответа HTTP в случае NGSIv2) можно предположить, что обновление было сохранено в базе данных контекста (за исключением случая выполнения CB с -writeConcern 0, если БД выходит из строя до того, как обновление может сохраняться из памяти БД на диск), поэтому уведомления о таких данных (из-за существующих или новых подписок) будут использовать новое значение.

  4. Все уведомления будут отправляться, пока поток насыщения (в случае -notificationMode transient) или насыщения очереди (-notification threadpool:q:n) не происходит. Дополнительную информацию о режимах уведомлений можно найти в Документация по Ориону.

person fgalan    schedule 09.12.2015