Когда сделать кеш недействительным - .net core api - PullRequest
0 голосов
/ 07 ноября 2018

Как узнать, когда сделать кеш недействительным, если изменение таблицы произведено из внешнего источника?

У меня есть вызов API, который возвращает таблицу сотрудников. При первом вызове я буду кэшировать результаты, чтобы при последующих вызовах он извлекал данные из кэша, а не из базы данных. Это имеет смысл, однако, что произойдет, если кто-то добавит новую запись в таблицу сотрудников из за пределами API , как кэш узнает, что она теперь недействительна?

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

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

Ответы [ 3 ]

0 голосов
/ 08 ноября 2018

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

Если ваш кеш не является локальным для API, что, как я полагаю, не будет, если триггеры смогут получить доступ. Не могли бы вы получить к нему доступ из настольного приложения? Вы можете сделать недействительным свой кэш, удалив запись сотрудника из кэша с помощью приложения для настольного компьютера, когда оно успешно выполнит изменение таблицы сотрудников.

Это сводится к ..

У вас есть кеш (по сути, хранилище для чтения). У вас есть два варианта, чтобы обновить его - Либо время ожидания и выборки (что нормально, если вам не нужны данные в режиме реального времени) - Или имеет , чтобы сообщить, что его данные больше не действительны.

0 голосов
/ 15 ноября 2018

Два способа решить эту проблему

  1. Толкающая модель
  2. Модель Pull

Модель Push: Использование триггера базы данных для таблицы сервера SQL для заполнения промежуточной таблицы аудита и опроса, использующего фоновую задачу.

Модель извлечения: Использование CLR Trigger и отправка обновлений в API. Всякий раз, когда происходит DML, триггер CLR будет вызывать API, в свою очередь qhich может обновить кэш!

Надеюсь, это поможет!

0 голосов
/ 07 ноября 2018

Да, вы можете добавить триггер, как предложено. Или вы можете использовать систему кэширования, которая поддерживает истечение времени / скользящего истечения. Так что вы будете время от времени подавать устаревшие данные, но не всегда.

...