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

Если версия в кэше устаревает по таймауту, то есть стандартное решение:

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

Если обновление нужно «прямо срочно вот», то хорошее универсальное решение мне не известно.

Можно предложить такое:

Для каждой записи кэша хранится поле update_started типа timestamp («начал подготовливать данные в... (время)»).

1. Обнаружив устаревший кэш, поток проверяет поле update_started.
2. Если update_started отличается от текущего времени меньше, чем на N миллисекунд, засыпаем на M миллисекунд. Проснувшись, идём в п.1 и проверяем состояние кэша.
3. Если update_started отличается от текущего времени больше чем на N миллисекунд, записываем в update_started текущее время и начинаем обновлять данные. Обновленные данные записываем в кэш.

N и M подбираем экспериментально под нагрузку.

Алгоритм не особождает от гонок, но несколько уменьшит количество процессов, дублирующих работу и нагружающих кэш апдейтами.

Если версия устаревает по таймауту, то есть стандартное решение:

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

Если обновление нужно «прямо срочно вот», то хорошее универсальное решение мне не известно.

Можно предложить такое:

Для каждой записи кэша хранится поле update_started типа timestamp («начал подготовливать данные в... (время)»).

1. Обнаружив устаревший кэш, поток проверяет поле update_started.
2. Если update_started отличается от текущего времени меньше, чем на N миллисекунд, засыпаем на M миллисекунд. Проснувшись, идём в п.1 и проверяем состояние кэша.
3. Если update_started отличается от текущего времени больше чем на N миллисекунд, записываем в update_started текущее время и начинаем обновлять данные. Обновленные данные записываем в кэш.

N и M подбираем экспериментально под нагрузку.

Алгоритм не особождает от гонок, но несколько уменьшит количество процессов, дублирующих работу и нагружающих кэш апдейтами.

Если версия устаревает по таймауту, то есть стандартное решение:

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

Если обновление нужно «прямо срочно вот», то хорошее универсальное решение мне не известно.

Можно предложить такое:

Для каждой записи кэша хранится поле update_started типа timestamp («начал подготовливать данные в... (время)»).

1. Обнаружив устаревший кэш, поток проверяет поле update_started.
2. Если update_started отличается от текущего времени меньше, чем на N миллисекунд, засыпаем на M милилсекунд. Проснувшись, идём в п.1 и проверяем состояние кэша.
3. Если update_started отличается от текущего времени больше чем на N миллисекунд, записываем в update_started текущее время и начинаем обновлять данные. Обновленные данные записываем в кэш.

N и M подбираем экспериментально под нагрузку.

Алгоритм не особождает от гонок, но несколько уменьшит количество процессов, дублирующих работу и нагружающих кэш апдейтами.

Если версия устаревает по таймауту, то есть стандартное решение:

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

Если обновление нужно «прямо срочно вот», то хорошее универсальное решение мне не известно.

Можно предложить такое:

Для каждой записи кэша хранится поле update_started типа timestamp («начал модифицировать подготовливать данные в... (время)»).

1. Обнаружив устаревший кэш, поток проверяет поле update_started.
2. Если update_started отличается от текущего времени меньше, чем на N миллисекунд, засыпаем на M милилсекунд. Проснувшись, идём в п.1 и проверяем состояние кэша.
3. Если update_started отличается от текущего времени больше чем на N миллисекунд, записываем в update_started текущее время и начинаем обновлять данные. Обновленные данные записываем в кэш.

N и M подбираем экспериментально под нагрузку.

Алгоритм не особождает от гонок, но несколько уменьшит количество процессов, дублирующих работу и нагружающих кэш апдейтами.

Если версия устаревает по таймауту, то есть стандартное решение:

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

Если обновление нужно «прямо срочно вот», то хорошее универсальное решение мне не известно.

Можно предложить такое:

Для каждой записи кэша хранится поле update_started типа timestamp («начал модифицировать подготовливать данные в... (время)»).

1. Обнаружив устаревший кэш, поток проверяет поле update_started.
2. Если update_started отличается от текущего времени меньше, чем на N миллисекунд, засыпаем на M милилсекунд. Проснувшись, идём в п.1 и проверяем состояние кэша.
3. Если update_started отличается от текущего времени больше чем на N миллисекунд, записываем в update_started текущее время и начинаем обновлять данные. Обновленные данные записываем в кэш.

N и M подбираем экспериментально под нагрузку.

Алгоритм не особождает от гонок, но несколько уменьшит количество процессов, дублирующих работу и нагружающих кэш апдейтами.