Как разрешить конфликт в сквозном кэше, используя оптимистичный контроль параллелизма?

Question

В настоящее время у нас есть сквозной кэш, который использует оптимистичный контроль параллелизма при заполнении кеша при пропадании кеша. Мы не ожидаем много конфликтов, поэтому решили использовать оптимистичный контроль параллелизма. Я немного не уверен, что делать, когда у нас на самом деле конфликт.

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

Для справки, мы используем Redis для нашего уровня кэша и MySQL для нашего резервного хранилища.

Answer 1

Если конфликты малочисленны, то почему бы просто не набрать WATCH ключ снова, сгенерировать данные кеша снова и попытаться снова заполнить Redis .Просто продолжайте повторять этот процесс, пока ваш EXEC наконец не вернется чистым.Вы можете установить максимальное количество попыток для чего-то вменяемого, и, если оно когда-либо будет превышено, просто аннулируйте кеш и уведомите ваших администраторов.Шаг уведомления кажется важным, потому что, если ваша оптимистическая блокировка дает сбой более чем примерно в 5 раз, то, вероятно, происходит что-то странное, и вам следует присмотреться.