Каково будет поведение подписок и уведомлений в сценарии балансировки нагрузки Orion?

Question

На основании этого ответа о том, как масштабировать Orion Context Broker с балансировкой нагрузки /questions/33887921/kak-masshtabirovat-orion-ge/33887924#33887924 каким должно быть поведение подписок, а также уведомлений?

Сервер ведьм, откуда он взялся? Каков рабочий процесс?

Может ли это привести к нарушению или клонированию подписок?

Answer 1

Рассмотрим разные случаи в зависимости от использования кэша подписки. Давайте рассмотрим два узла Orion (A и B) без потери общности, оба совместно используют один и тот же экземпляр MongoDB.

Использование кеша подписки (т.е. -noCache не установлено)

Запрос на создание подписки отправляется некоторым узлам (предположим, что это узел A). Узел A сохранит подписку в общей базе данных и в локальном (то есть узле A) кеше подписки. Обратите внимание, что узел B не узнает о новой подписке до следующего обновления кэша подписки, что означает. Это столько же, сколько интервал секунд равен -subCacheIval параметр.

Давайте теперь рассмотрим обновление (для объекта / атрибута, который соответствует условиям подписки для запуска уведомления). Определение того, какому узлу балансировщик нагрузки отправляет обновление и в какой момент оно поступает (относительно времени запроса на создание подписки), может произойти в одном из следующих случаев:

• Обновление поступает на узел B, до следующего обновления подписки (т.е. столько, сколько -subCacheIval секунд). Учитывая, что узел B ничего не знает о подписке, уведомление не отправляется.

• Обновление поступает на узел B, после следующего обновления подписки (т.е. столько, сколько -subCacheIval секунд). Узел B знает о новой подписке как о последовательности обновления, поэтому уведомление отправляется.

• Обновление поступает на узел A, независимо от того, до или после следующего обновления подписки. Узел А был тем, кто создавал подписку, поэтому его кэш обновлен с самого начала. Таким образом, уведомление отправлено.

Coloral: ожидание -subCacheIval после создания подписки убедитесь, что подписка распространена на все узлы CB, таким образом, уведомление будет отправлено всегда. Тем не менее, обратите внимание, что установка слишком мала -subCacheIval значение может иметь негативные последствия. Компромисс анализируется в разделе документации по производительности Orion.

Наконец, что касается регулирования, обратите внимание на следующее замечание в примечаниях по реализации Orion:

Кроме того, Орион осуществляет регулирование на местном уровне. В конфигурациях с несколькими CB принимайте во внимание, что мера последнего уведомления является локальной для каждого узла Orion. Хотя каждый узел периодически синхронизируется с БД для получения потенциально новых значений (подробнее об этом здесь), может случиться так, что конкретный узел имеет старое значение, поэтому регулирование не является точным на 100%.

Таким образом, если вам нужно точное регулирование, лучше реализовать его в конечной точке приема уведомителя, чем использовать ту, которая предоставляется Orion.

Не использовать кеш подписки (т.е. -noCache установлено)

В этом случае оценка подписки всегда выполняется по запросу в БД. Таким образом, независимо от того, какой узел (A или B) создал подписку, так как она хранится в БД. Таким образом, независимо от того, обрабатывает ли обновление A или B, так как он будет проверять в БД соответствие подписок, и в этом случае всегда отправляется уведомление.

Однако обратите внимание, что этот режим (без использования кэша подписки) может иметь серьезные недостатки производительности (особенно в случае использования подписок на основе шаблонов), поэтому он не рекомендуется.

Я не совсем уверен, но проблема регулирования, описанная для другого сценария, вероятно, не происходит в этом случае.