Ну, главная проблема в вашем сценарии заключается в том, что у вашего брокера сообщений JMS (поставщика услуг) есть проблемы со стабильностью.Распределенная регистрация через JMS, безусловно, будет работать, если она рассматривается как критическая часть вашей инфраструктуры, которая не должна быть отключена, а должна контролироваться и работать в кластерной конфигурации, которая гарантирует, что хотя бы один экземпляр всегда работает.
Асинхронное ведение журнала не сильно поможет, если JMS-брокер не работает.например, если вы используете log4j AsyncAppender, он либо станет блокирующим приложением после заполнения буфера приложения, либо выбросит сообщения регистрации (если у вас блокировка = false).
Тем не менее, в моем опыте регистрацииЧерез JMS почти всегда было излишним, особенно если это единственная причина, по которой вы создали JMS-брокера.
Если вы хотите «распределить» ваши журналы по нескольким блокам, есть несколько простых способов сделать это:
- запись в файл с переворотом каждый час или около того (с использованием прокруткифайл appender в log4j или backlog), а затем просто rsync каждый час в другие блоки
- запись журналов в каталог NFS или в общий каталог SAN, смонтированный на всех боксах (каждый файл журнала должен использовать конкретное имя экземпляра дляизбегайте переопределения друг друга)
регистрируйте в БД непосредственно из приложения - возможно, вы захотите передать его через AsyncAppender, хотя, чтобы избежать блокировки.Надеемся, что ваша БД имеет более высокую доступность, чем JMS-провайдер
Ed Y.