Альтернатива для состояния записи опроса - PullRequest
Новая
       16

Альтернатива для состояния записи опроса

0 голосов
/ 04 июля 2018

В настоящее время у нас есть система отслеживания платежей, которая использует MS SQL Server Enterprise. Когда клиент запрашивает услугу, он должен будет произвести оплату в течение 24 часов, в противном случае мы отправим ему SMS-напоминание. Наша текущая реализация просто записывает дату и время покупки и постоянно опрашивает записи, чтобы найти «просроченные» покупки.

Это создает настолько большую нагрузку на базу данных, что нам приходится реализовывать некоторую форму репликации, чтобы перенести эти операции на другой сервер.

Я думал: есть ли способ объединить триггеры CLR с каким-то планировщиком, который будет срабатывать только один раз, то есть через 24 часа после создания покупки?

Пожалуйста, имейте в виду, что у нас десятки тысяч транзакций в час.

1 Ответ

0 голосов
/ 04 июля 2018

Я не уверен, как вы думаете, что SQLCLR решит эту проблему. Я не думаю, что это вообще нужно обрабатывать в БД.

Поскольку время запроса не меняется, почему бы не загрузить все запросы в хранилище на основе памяти, в которое можно постоянно обращаться. Вы бы загрузили 24-часовое время от запроса, так что вам нужно только сравнить это время с Сейчас. Если клиент платит до 24-часового периода, вы удаляете запись из кэша. Иначе процесс опроса в конечном итоге найдет его, обработает и удалит из кеша.

ИЛИ аналогичным образом вы можете использовать планировщик и загружать будущее событие в виде SMS-сообщения, основываясь на времени 24 часа с момента запроса, при каждом запросе. Аналогично планированию действия с использованием «AT». Опять же, если кто-то платит до этого времени, просто удалите запланированное задание / событие / напоминание.

Вы будете хранить только 24 часа в сутки и RequestID. Если время истекло, служба обратится к БД, используя эту RequestID, чтобы получить текущую информацию.

Необходимо просто удалить элементы из кэша / планировщика, если оплата была произведена до 24-часового периода позже.

И если система дает сбой / перезапускается, вы просто загружаете все записи, которые а) не оплачены, и б) еще не достигли своего 24-часового периода ожидания.

...