Аннулирование кэша — Является там Общим Решением?
Или можно сравнить эти два байта для байта файлов....
5 ответов
Я работаю с .NET, но часто с открытым исходным кодом, например Umbraco . Они не исключают друг друга.
Поскольку я работал как с PHP, так и с .NET, я предпочитаю последнее (в основном потому, что C # намного лучше, чем PHP, а платформа .NET более последовательна), но это личное предпочтение.
Если вы выбрали 1, то у вас есть свобода, которую вы предоставили себе, и, таким образом, вы можете кэшировать больше, но должны помнить о допустимости кэшированного значения b . Если вы выбрали 2, вы все равно должны проверять b каждый раз, но можете использовать кеш для a , если b проверяется.
Если вы накладываете кеши вы должны подумать, не нарушили ли вы «правила» системы в результате комбинированного поведения.
Если вы знаете, что a всегда имеет силу, если b имеет силу, тогда вы можете организовать свой кэш следующим образом (псевдокод):
private map<b,map<a,c>> cache //
private func realFunction // (a,b) -> c
get(a, b)
{
c result;
map<a,c> endCache;
if (cache[b] expired or not present)
{
remove all b -> * entries in cache;
endCache = new map<a,c>();
add to cache b -> endCache;
}
else
{
endCache = cache[b];
}
if (endCache[a] not present) // important line
{
result = realFunction(a,b);
endCache[a] = result;
}
else
{
result = endCache[a];
}
return result;
}
Очевидно последовательное наслоение (скажем, x ) тривиально до тех пор, пока на каждом этапе достоверность вновь добавленных входных данных совпадает с соотношением a : b для x : b и x : a .
Однако вполне возможно, что вы можете получить три входа, действительность которых была полностью независимой (или была циклической), поэтому наслоение невозможно. Это будет означать, что строка с пометкой // important должна измениться на
, если (endCache [a] истек или отсутствует)
Если вы собираетесь использовать getData () каждый раз, когда выполняете преобразование, то вы полностью исключили преимущества кеширования.
Для вашего примера это похоже на решение будет для того, когда вы генерируете преобразованные данные, чтобы также сохранить имя файла и время последнего изменения файла, из которого были сгенерированы данные (вы уже сохранили это в любой структуре данных, возвращенной getData (), поэтому вы просто копируете эту запись в структура данных, возвращаемая функцией transformData ()), а затем, когда вы снова вызываете transformData (), проверьте время последнего изменения файла.
Я сейчас работаю над подходом, основанным на PostSharp и запоминании функции . Я пропустил его мимо своего наставника, и он согласился, что это хорошая реализация кеширования, независимого от контента.
Каждая функция может быть помечена атрибутом, который указывает срок ее действия. Каждая отмеченная таким образом функция запоминается, а результат сохраняется в кеше с хешем вызова функции и параметрами, используемыми в качестве ключа. Я использую Скорость для серверной части, которая обрабатывает распределение данных кеша.
Есть ли общее решение или метод для создания кеша, чтобы знать, когда запись устарела, чтобы вы гарантированно всегда получали свежие данные?
Нет, потому что все данные разные . Некоторые данные могут «устареть» через минуту, некоторые через час, а некоторые могут сохраняться в течение нескольких дней или месяцев.
Что касается вашего конкретного примера, самым простым решением является наличие функции «проверки кеша» для файлов, которая вы вызываете как getData , так и transformData .
Возможно, алгоритмы без учета кеша будут наиболее общими (или, по крайней мере, менее зависимыми от конфигурации оборудования), поскольку они сначала будут использовать самый быстрый кеш и перейдут от там. Вот лекция MIT об этом: Cache Oblivious Algorithms