Кэширование для последующей записи в базу данных в веб-сервисе asp.net?

Question

Я пишу веб-сервис, который для каждого вызова метода должен записывать запись журнала в базу данных. В определенное время вызов этого метода может быть очень интенсивным (до 1-2 тыс. Запросов / мин), и наш сервер не такой сильный.

Я хочу использовать List<Log> для кэширования записей журнала, а затем:

• Пакетная вставка 30-40 строк в базу данных, что значительно снижает накладные расходы
• когда больше нет запросов в течение более 30 секунд или 1 минуты, весь оставшийся кэш будет записан в базу данных.

Первое условие в порядке, но я не знаю, как реализовать второе условие.

Как я могу это сделать, не добавляя слишком много накладных расходов на мой веб-сервис?

РЕДАКТИРОВАТЬ: Я решил это на основе предложения Пшеницы.

• Для каждой записи журнала я отправляю ее непосредственно в очередь MSMQ и забываю об этом
• Отдельная служба работает непрерывно, принимает все записи журнала, находящиеся в данный момент в очереди, массово вставляет их в базу данных и затем спит в течение 30 секунд.

MSMQ очень помог в этом случае!

Answer 1

Вы можете использовать MSMQ или SQL Server Service Broker .

Answer 2

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

Answer 3

Звучит так, как будто вы хотите запустить задачу на каком-то интервале (30-60 секунд). Хитрость заключается в том, чтобы ASP.NET открывал и выполнял итерацию в кеше с заданным интервалом (30 или 60 секунд), при этом входящий веб-запрос не вызывал этого. Некоторые обсуждения этой статьи: Простые фоновые задачи с ASP.NET .

При таком подходе я предложу 2 варианта хранения:

1 .. Для решения только для ASP.NET и IIS вы можете записать в кэш приложений ASP.NET .

List<Log> myLogs = new List<Log>();
myLogs.Add(new Log{ Text = "foo"});
Cache["MyLogs"] = myLogs;

Рассмотрим эту проблему, хотя. Кэш приложений ASP.NET не является надежным хранилищем. Что происходит, когда ваше приложение умирает, или IIS сбрасывается, или аппарат теряет питание? Вас волнует, что было в кеше?

2 .. Встроить базу данных SQL Compact в свое приложение. Напишите свои журналы там. Объедините этот механизм хранения с Простыми фоновыми задачами с ASP.NET .

IMO, я бы полностью согласился с вариантом MSMQ или SQL Server Service Broker, предложенным в другом ответе. Это гарантирует долговечность для вас. Надеюсь, у вас есть полный контроль над этим веб-сервером для использования этих компонентов. Один требует установки / включения / защиты компонентов Windows, а другой - специфической функции SQL Server.

Answer 4

Я бы использовал HttpUtility.Cache и его события, чтобы получать информацию через определенное время без доступа к объекту в кеше (скользящий срок действия).Таким образом, вы можете «дотронуться» до объекта LoggerInformation в кэше всякий раз, когда вы добавляете что-то в ваш список журналов.Когда истекает срок действия, просто вставьте данные журнала.Когда появляется новая запись в журнале, вы (заново) создаете объект LoggerInformation в кэше с новым скользящим сроком действия.

Классы IIS Cache предоставят вам все, что вам нужно для скользящего срока действия и событий удаления,см. соответствующую документацию msdn ...

, но, как уже было сказано, это не сохраняется, и все журналы будут потеряны, если ваш веб-сервер выйдет из строя до того, как журнал будет записан в базу данных.

Answer 5

Я предлагаю вам использовать System.Timers для создания таймера, который время от времени проверяет время от времени, если вы не работаете, а затем сохраняйте данные в базе данных.

System.Timers ив другое время , потому что этот тип таймера может выполнять ту работу, которую вы просите.

Answer 6

Таким образом, вы хотите сохранить данные где-нибудь и медленно сливать их в базу данных. Это звучит как работа для Redis или Memcached. По сути, у вас есть cron или запланированная задача, которая запускается каждые 30 секунд, находит до 40 ключей, ожидающих записи, а затем записывает их в базу данных.

Redis может легко обрабатывать 1-2 тыс. Запросов в минуту и ​​имеет примитив LIST, который прекрасно работает для строк журнала.