История изменений

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

Скрытый кэш:

Вы можете создать дополнительный кэш для каждого обновляемого набора данных. Это будет «скрытым» кэшем, который будет использоваться во время обновления данных. Когда обновление завершено, данные из «скрытого» кэша могут быть перенесены в основной кэш, и «скрытый» кэш очищен.

Временная заморозка обновлений:

Вы можете временно «заморозить» обновление группы, пока данные не будут готовы для использования. Это можно сделать, помечая группу как «не активную», и затем только после того, как обновление завершено, активировать группу снова.

Управление TTL и обновлениями:

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

Параллельное управление обновлениями и поиском:

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

Использование консистентного кэша:

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

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

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

Скрытый кэш:

Вы можете создать дополнительный кэш для каждого обновляемого набора данных. Это будет «скрытым» кэшем, который будет использоваться во время обновления данных. Когда обновление завершено, данные из «скрытого» кэша могут быть перенесены в основной кэш, и «скрытый» кэш очищен.

Временная заморозка обновлений:

Вы можете временно «заморозить» обновление группы, пока данные не будут готовы для использования. Это можно сделать, помечая группу как «не активную», и затем только после того, как обновление завершено, активировать группу снова.

Управление TTL и обновлениями:

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

Параллельное управление обновлениями и поиском:

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

Использование консистентного кэша:

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

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