Асинхронный журнал

В настоящее время в моем приложении в некоторых случаях мы записываем некоторые тяжелые вещи в файлы журнала.

В основном для ведения журнала мы создаем JSON доступных данных, а затем регистрируемся в файлах журнала. Это бизнес-требование для регистрации данных в формате JSON.

Теперь создание JSON из доступных данных, а затем регистрация в FILE занимает много времени и влияет на время возврата первоначального запроса. Теперь идея состоит в том, чтобы улучшить положение.

Одна из вещей, которые мы обсуждали, заключается в создании пула потоков с использованием

Executors.newSingleThreadExecutor()

в нашем коде, а затем отправляет ему задачу, которая преобразует данные в JSON и последующее ведение журнала.

Является ли это хорошим подходом для этого? Поскольку мы управляем самим пулом потоков, он собирается создать некоторые проблемы?

Буду признателен, если кто-то сможет поделиться лучшими решениями. В некотором смысле использовать Log4j для этого. Я пытался использовать AsyncAppender, но не достиг желаемого результата. Мы используем EJB 3, Jboss 5.0, Log4j, java6.

Ответ 1

Я считаю, что вы на правильном пути с точки зрения использования отдельного пула потоков для ведения журнала. Во многих продуктах вы увидите асинхронную функцию ведения журнала. Журналы накапливаются и помещаются в файлы журнала с использованием отдельного потока, кроме потока запросов. Особенно в средах разработки, где миллионы входящих запросов и время отклика должны быть меньше нескольких секунд. Вы не можете позволить себе ничего такого, как ведение журнала, чтобы замедлить работу системы. Таким образом, используемый подход заключается в том, чтобы добавлять журналы в буфер памяти и асинхронно их асинхронно перемещать в куски разумного размера.

Предупреждение при использовании пула потоков для ведения журнала Поскольку несколько потоков будут работать с файлами (-ами) журнала и в буфере журнала памяти, вам нужно быть осторожным в регистрации. Вам нужно добавить журналы в виде FIFO буфера, чтобы быть уверенным, что журналы печатаются в файлах журналов, отсортированных по метке времени. Также убедитесь, что доступ к файлам синхронизирован, и вы не сталкиваетесь с ситуацией, когда файл журнала перевернут или испорчен.

Ответ 2

Посмотрите Logback, AsyncAppender уже предоставляет отдельный поток, очередь и т.д. и легко настраивается, он почти делает то же самое, что и вы, но спасает вас от повторного создания колеса.

Ответ 3

Использует MongoDB для ведения журнала?

Вставки MongoDB могут выполняться асинхронно. Один из них не хотел бы, чтобы пользователи перестали останавливаться, если регистрация была медленной, застопорилась или вниз. MongoDB обеспечивает способность для запуска вставки в коллекцию журналов и не дожидаться ответа кода ответа. (Если один хочет получить ответ, один вызывает getLastError() - мы пропустим это здесь.)
Старые данные журнала автоматически выдают LRU. Используя ограниченные коллекции, мы предварительно выделяем пространство для журналов, и как только он будет заполнен, обертки журнала и повторно использует указанное пространство. Отсутствие риска заполнения диска чрезмерная информация о журнале, и нет необходимости записывать архивные/ сценарии удаления.
Его достаточно быстро для проблемы. Во-первых, MongoDB очень быстро работает в общий, достаточно быстрый для таких проблем. Во-вторых, при использовании ограниченная коллекция, порядок вставки автоматически сохраняется: мы не нужно создавать индекс по метке времени. Это делает вещи даже быстрее, и это важно, учитывая, что случай использования журнала имеет очень большое количество записей по сравнению с чтением (напротив большинства баз данных проблемы).
Document-oriented/JSON - отличный формат для информации журнала. Очень гибкая и "схематичная" в том смысле, что мы можем добавить лишнюю поле в любое время.

Ответ 4

Существует также log4j 2: http://logging.apache.org/log4j/2.x/manual/async.html Кроме того, прочитайте эту статью о том, почему она так быстро: http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html#.UzwywI9Bow4

Ответ 5

Вы также можете попробовать CoralLog асинхронно регистрировать данные с использованием шаблона разрушителя. Таким образом, вы тратите минимальное время на поток журнала, и вся тяжелая работа передается потоку, выполняющему фактический ввод-вывод файлов. Он также предоставляет файлы с памятью, чтобы ускорить поток потребителей и уменьшить конкуренцию в очереди.

Отказ от ответственности: Я один из разработчиков CoralLog