Ни к чему не призываю, просто факт такой имеет место.

Мы беларусы мирные люди, не баним никого

да ну, спамеров - регулярно

Добрый вечер.
Подскажите пожалуйста мб кто-нибудь сталкивался с такой проблемой: есть несколько инстансов приложения и один централизованный кэш(redis) в каждом приложении происходит переодическое обновление значений в кэше, и может случится так что одно из приложений будет сетить в кэш неактуальные значения. т е запросы на обновление определенного ключа были отправлены одновременно с обоих приложений, один запрос с актуальным значением, второй - с устаревшим. По какой либо причине запрос с актуальными данными обновит кэш раньше, а потом придет второй запрос с неактуальными данными и тоже проапдейтит кэш но уже неактельными данными. и по итогу в кэше останеься лежать неактуальное значение. Собственно сам вопрос, как в такой ситуации поддерживать кэш в актуальном состоянии?

Использовать очередь например. Ну и что значит актуальное значение, кто последний тот и актуальный.

Это не всегда так

Это сложная задача, решается тоже не просто. Рекомендую книгу Мартина Клепманна

По сути, это проблема разрешения конфликтов в распределенных системах. Тут миллион решений: просто версия записи, векторные часы, crdt, etc

Не зная специфики задачи посоветовать что-то сложно.

А, да, старые добрые транзакции с блокировками - классический способ решения этой проблемы

Ну ток придётся на редисе свои транзакции и блокировки городить?

Имхо, товарищ выше предложил неплохое решение с очередью. Искоробочная блокировка получается на инфраструктуре очереди.

Там из коробки есть

А, ок, я не знал.

Только если last writer wins подходит

Если у тебя выгребатор из очереди один, то действительно подходит

Т.к. не будет рейсов

Ну или балансер умный

Это если ты в очередь дельты пишешь, т.е. команды

А не конечное состояние