Разница между использованием Listeners и MBean для отправки уведомлений?

Я читал о том, как распределенная система хранения/управления/кэширования данных GemFire ​​выполняет уведомления. Во время чтения у меня возник такой вопрос.

Похоже, что Gemfire использует MBeans для создания уведомлений во время событий. Насколько отличается/подходит использование MBeans для создания уведомлений вместо реализации подхода на основе прослушивателя? (не только в GemFire, но и вообще)

Примечание. Я новичок в теме MBean. Просто с пониманием того, что его основная цель - предоставить ресурсы для управления.


person yathirigan    schedule 18.03.2015    source источник


Ответы (1)


КОНТЕКСТ

... тема MBean ... его основная цель - предоставить ресурсы для управления.

Это правильно. (GemFire) Ресурсы, представленные как MBean, можно как запрашивать, так и изменять, в зависимости от того, что MBean предоставляет для ресурса (например, регион, DiskStore, шлюз, AEQ и т. д.), используя JMX.

Затем интерфейс JMX GemFire ​​может использоваться приложениями и инструментами, использующими JMX API. GemFire ​​Gfsh (оболочка командной строки и инструмент управления) вместе с Pulse (инструмент веб-мониторинга) являются примерами JMX-клиентов и типов приложений, которые вы могли бы написать с использованием JMX.

Вы также можете использовать стандартные инструменты JDK, такие как jconsole или jvisualvm, для подключения к GemFire ​​Manager (управляющий узел в кластере, который объединяет представление всех участников в кластере, а также возможность управлять любым отдельным участником из Manager). См. раздел GemFire ​​в Руководстве пользователя по управлению для более подробной информации.

В отличие от обратных вызовов GemFire. , обратные вызовы (например, CacheListener) могут использоваться одноранговыми/клиентскими приложениями кэширования для регистрации интересов в определенных типах событий, таких как создание/обновление записи региона и т. д. Другие обратные вызовы, такие как CacheLoader можно использовать для чтения из внешнего источника данных (например, СУБД) в кэше. скучать. Аналогично, CacheWriter может использоваться для «сквозной записи» во внешний источник данных при создании/обновлении кэша (региона) или, возможно, асинхронно с AEQ/AsyncEventListener выполняет отложенную запись во внешний источник данных.

Существует множество других обратных вызовов и способов их использования, но почти все они используются программно в клиентском/равноправном кэш-приложении GemFire ​​для «получения» уведомлений того или иного типа.

Дополнительные сведения см. в Руководстве пользователя GemFire ​​по адресу События и обработка событий.

ОТВЕЧАТЬ

Теперь, когда дело доходит до «отправки» уведомлений, GemFire ​​выполняет значительную часть рассылки от имени вашего приложения. JMX в основном используется для отправки уведомлений об изменениях в управлении... был добавлен регион, изменена политика исключения, развернута функция и т. д. В отличие от этого, GemFire ​​отправляет события распределения, когда данные изменяются, другим членам кластера, которые заинтересованы в событие. «Заинтересованные» члены обычно включают в себя другие узлы в кластере, которые размещают тот же регион и имеют те же ключи/значения, которые необходимо обновить, а в некоторых случаях атомарно (в TX) для обеспечения согласованности.

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

Конечно, доступны и другие варианты, включая JMS, который Spring обеспечивает поддержку интеграции.

В общем и целом, отправляемые события/уведомления и используемый механизм распространения сильно зависят от типа события/уведомления. Кроме того, способ уведомления (уведомление JMX или обратный вызов GemFire) также зависит от типа сообщения и цели.

Извините за длинное объяснение; это загруженный/широкий вопрос и сложная тема, которая может сильно различаться в зависимости от варианта использования.

Надеюсь, это поможет (немного ;-)

person John Blum    schedule 18.03.2015
comment
вау, это было подробно. спасибо .. теперь позвольте мне перейти на следующий уровень чтения с данными ссылками - person yathirigan; 19.03.2015