Моя команда работает над большим приложением промежуточного программного обеспечения, которое предназначено для доступа к базе данных и предоставления определенного объема данных другому приложению, к которому очень часто будут обращаться в форме веб-службы, и поэтому оно будет отправлять большое количество данных. запросов к нашему приложению.
В настоящее время мы находимся на этапе планирования и думаем о том, как мы собираемся внедрить ведение журнала. Мы привязаны к «частной» (в том смысле, что мы не можем ее изменить) структуре ведения журнала, созданной организацией, в которой мы работаем, которая сама по себе не поддерживает асинхронность. Наша библиотека журналов позволяет нам регистрироваться как в базе данных, так и в файле трассировки, и мы обязаны регистрироваться в обоих, несколько раз для каждого запроса пользователя.
Основная идея, которая у нас была, заключается в том, что мы собираемся создать одноэлементный класс, который создает отдельный поток с очередью, и всякий раз, когда мы хотим что-то записать, мы просто отправляем сообщение в очередь, и поток регистрации обрабатывает это. Это гарантирует, что сообщения записываются в БД и в журнал трассировки в том же порядке, в котором они были получены. Здесь также может возникнуть проблема, заключающаяся в том, что мы также хотим, чтобы наши веб-сервисы вызывались асинхронно, чтобы максимизировать скорость отклика нашего веб-сервиса, и тогда они могли бы писать сообщения в очередь не по порядку. Но я здесь просто мозговой штурм, и я не настолько опытен в параллелизме, поэтому я хотел бы знать, имеет ли смысл то, что я думаю, и что было бы самым умным в этом случае.