Model doplňování mezipaměti

Azure Spravovaný Redis

Načtěte data na vyžádání do mezipaměti z úložiště dat. Tento přístup může zvýšit výkon a pomáhá udržovat konzistenci mezi daty uloženými v mezipaměti a daty v podkladovém úložišti dat.

Kontext a problém

Aplikace používají mezipaměť ke zlepšení výkonu pro opakovaný přístup k informacím v úložišti dat. Data uložená v mezipaměti ale nemůžou vždy zůstat konzistentní s úložištěm dat. Aplikace by měly implementovat strategii, která uchovává data v mezipaměti co nejaktuálnější. Strategie by také měla zjistit, kdy jsou data uložená v mezipaměti zastaralá, a správně je zpracovat.

Řešení

Mnoho komerčních systémů pro ukládání do mezipaměti poskytuje operace čtení a zápisu typu write-through nebo write-behind. V těchto systémech aplikace načte data odkazováním na mezipaměť. Pokud data nejsou v mezipaměti, aplikace je načte z úložiště dat a přidá je do mezipaměti. Systém automaticky zapíše všechny změny provedené v mezipaměti dat zpět do úložiště dat.

U mezipamětí, které tuto funkci neposkytují, musí aplikace, které mezipaměť používají, udržovat data.

Aplikace může emulovat funkčnost čtení skrze cache implementací vzoru Cache-Aside. Tato strategie načte data do mezipaměti na vyžádání. Následující diagram používá vzor Cache-Aside k ukládání dat do mezipaměti.

Diagram obsahuje aplikaci, mezipaměť a úložiště dat. Mezipaměť odkazuje na aplikaci označenou jako krok 1. Úložiště dat odkazuje na aplikaci označený jako krok 2. Aplikace odkazuje na mezipaměť označenou jako krok 3.

1. Aplikace určuje, zda se položka aktuálně nachází v mezipaměti pokusem o čtení z mezipaměti.

2. Pokud položka není v mezipaměti, označovaná také jako neúspěšná mezipaměť, aplikace načte položku z úložiště dat.

3. Aplikace přidá položku do mezipaměti a pak ji vrátí volajícímu.

Když aplikace aktualizuje informace, zapíše změnu do úložiště dat a potom zneplatní odpovídající položku v mezipaměti. Jakmile je položka znovu potřebná, vzor Cache-Aside načte aktualizovaná data z úložiště dat a přidá je do mezipaměti.

Problémy a důležité informace

Při rozhodování o implementaci tohoto modelu zvažte následující body:

• Životnost dat uložených v mezipaměti: Mnoho mezipamětí používá zásadu vypršení platnosti k zneplatnění dat a odebrání dat z mezipaměti, pokud k ní není po nastavenou dobu přístup. Aby bylo cache-aside efektivní, ujistěte se, že politika vypršení platnosti odpovídá vzoru přístupu aplikací, které data používají. Nevytvádejte období vypršení platnosti příliš krátké, protože předčasné vypršení platnosti může způsobit, že aplikace budou průběžně načítat data z úložiště dat a přidávat je do mezipaměti. Podobně neudělávejte období vypršení platnosti tak dlouho, aby data uložená v mezipaměti byla zastaralá. Ukládání do mezipaměti je nejvhodnější pro relativně statická data nebo data, která aplikace často čtou.

• Vyřazení dat: Většina mezipamětí má v porovnání s úložištěm dat, odkud data pocházejí, omezenou velikost. Pokud mezipaměť překročí limit velikosti, vyřadí data. Většina vyrovnávacích pamětí používá zásadu nejméně nedávno použité položky k výběru položek pro vyřazení, ale některé umožňují přizpůsobení.

• Konfigurace: Chování mezipaměti můžete nakonfigurovat globálně nebo pro každou položku v mezipaměti. Jedna globální zásada vyřazení nemusí vyhovovat všem položkám. Pokud je načtení položky nákladné, nakonfigurujte položku mezipaměti jednotlivě. V této situaci je vhodné zachovat položku v mezipaměti, i když se k ní dostanete méně často než levnější položky.

• Primace mezipaměti: Mnoho řešení předem naplní mezipaměť daty, která aplikace pravděpodobně vyžaduje jako součást zpracování po spuštění. Vzor Cache-Aside zůstává užitečný, když některým z těchto dat vyprší platnost nebo se vyřadí.

• Konzistence: Model Cache-Aside nezaručuje konzistenci mezi úložištěm dat a mezipamětí. Externí proces může například kdykoli změnit položku v úložišti dat. Tato změna se v mezipaměti nezobrazí, dokud se položka znovu nenačte. V systému, který replikuje data napříč úložišti dat, může častá synchronizace komplikovat konzistenci.

• Zastaralost dat po zápisu: Vzor Cache-Aside při zápisu zneplatní položku v mezipaměti a při dalším čtení ji znovu naplní daty. Mezi zápisem a dalším čtením může čtenář zaznamenat chybějící mezipaměť nebo krátce zobrazit zastaralá data. Toto chování odlišuje vzor Cache-Aside od mezipaměti se zápisem, která aktualizuje úložiště dat i mezipaměť v rámci téže operace zápisu, takže čtecí operace vidí novou hodnotu ihned po úspěšném zápisu. Pokud cesty s převahou čtení vyžadují konzistenci čtení po zápisu, zvažte místo toho write-through ukládání do mezipaměti.

• Místní ukládání do mezipaměti: Mezipaměť může být místní pro instanci aplikace a může být uložena v paměti. Přístup cache-aside funguje dobře v tomto prostředí, pokud aplikace opakovaně přistupuje ke stejným datům. Místní mezipaměť je ale soukromá, takže různé instance aplikací můžou mít kopii stejných dat uložených v mezipaměti. Tato data se můžou rychle stát nekonzistentní mezi mezipamětí, takže možná budete muset ukončit platnost dat v privátní mezipaměti a aktualizovat je častěji. V těchto scénářích zvažte použití sdíleného nebo distribuovaného mechanismu ukládání do mezipaměti.

• Sémantické ukládání do mezipaměti: Některé úlohy můžou těžit z načítání mezipaměti na základě sémantického významu, nikoli přesných klíčů. Tento přístup snižuje počet požadavků a tokenů odesílaných do jazykových modelů. Ukládání do sémantické mezipaměti používejte pouze v případě, že data podporují sémantickou ekvivalenci, neriskuje vrácení nesouvisejících odpovědí a neobsahuje soukromá a citlivá data. Například "Jaký je můj čistý roční příjem?" je sémanticky podobné "Jaký je můj čistý roční plat?" Pokud se ale na tyto otázky ptají různí uživatelé, odpovědi by se měly lišit. Tato citlivá data byste také neměli zahrnout do mezipaměti.

Kdy se má tento model použít

Tento model použijte v těchto případech:

• Mezipaměť neposkytuje nativní operace přímého čtení a zápisu.

• Požadavky na prostředky jsou nepředvídatelné. Tento model umožňuje aplikacím načítat data na vyžádání. Nepředpokládá, která data aplikace vyžaduje předem.

Tento vzor nemusí být vhodný v těchto případech:

• Data jsou citlivá nebo související se zabezpečením. Ukládání dat do mezipaměti může být nevhodné, zejména když mezipaměť sdílí více aplikací nebo uživatelů. Vždy načtěte tento typ dat z primárního zdroje.

• Datová sada uložená v mezipaměti je statická. Pokud se data vejdou do dostupného prostoru mezipaměti, předejte mezipaměť datům při spuštění a použijte zásadu, která brání vypršení platnosti dat.

• U většiny požadavků nedochází k zasažení cache. V takovém případě by režijní náklady na kontrolu mezipaměti a načítání dat do ní mohly převažovat nad výhodami ukládání do mezipaměti.

• Informace o stavu relace ukládáte do mezipaměti ve webové aplikaci hostované ve webové farmě. V tomto prostředí nepoužívejte závislosti založené na spřažení klient-server.

Návrh úloh

Vyhodnoťte, jak použít vzor Cache-Aside v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

Pilíř	Jak tento model podporuje cíle pilíře
Spolehlivostní rozhodnutí o návrhu pomáhají vaší pracovní zátěži stát se odolná proti poruchám a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Ukládání do mezipaměti replikuje data. Omezené způsoby může zachovat dostupnost často přístupných dat, pokud je úložiště dat původu dočasně nedostupné. Pokud mezipaměť nefunguje správně, může se úloha vrátit do původního úložiště dat. - RE:05 Redundance
efektivita výkonu pomáhá vašim úlohám efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Ukládání do mezipaměti zlepšuje výkon dat náročných na čtení, která se mění zřídka a toleruje určitou nestarost. - Datový výkon PE:08 - PE:12 Průběžná optimalizace výkonu

Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.

Příklad

Zvažte použití Azure Managed Redis k vytvoření distribuované mezipaměti, kterou může sdílet více instancí aplikací.

Následující příklad používá klienta StackExchange.Redis, což je knihovna klienta Redis napsaná pro .NET. Pokud se chcete připojit k instanci Azure Managed Redis, zavolejte statickou ConnectionMultiplexer.Connect metodu a předejte připojovací řetězec. Metoda vrátí ConnectionMultiplexer představující připojení.

Jedním ze způsobů, jak sdílet ConnectionMultiplexer instanci v aplikaci, je mít statickou vlastnost, která vrací připojenou instanci, podobně jako v následujícím příkladu. Tento přístup poskytuje způsob inicializace jedné připojené instance, který je bezpečný pro přístup z více vláken.

private static ConnectionMultiplexer Connection;

// Redis connection string information
private static Lazy<ConnectionMultiplexer> lazyConnection = new Lazy<ConnectionMultiplexer>(() =>
{
    string cacheConnection = ConfigurationManager.AppSettings["CacheConnection"].ToString();
    return ConnectionMultiplexer.Connect(cacheConnection);
});

public static ConnectionMultiplexer Connection => lazyConnection.Value;

Metoda GetMyEntityAsync v následujícím příkladu ukazuje implementaci modelu Cache-Aside. Tato metoda načte objekt z mezipaměti pomocí strategie čtení za běhu.

Metoda identifikuje objekt pomocí celočíselného ID jako klíče. Pokusí se načíst položku z mezipaměti pomocí tohoto klíče. Pokud mezipaměť obsahuje odpovídající položku, vrátí položku. Pokud mezipaměť neobsahuje shodu, GetMyEntityAsync metoda načte objekt z úložiště dat, přidá ho do mezipaměti a vrátí ji. Tento příklad vynechá kód, který čte data z úložiště dat, protože tato logika závisí na úložišti dat. Položka uložená v mezipaměti je nakonfigurovaná tak, aby vypršela, aby se zabránilo jeho zastaralí, pokud ji aktualizuje jiná služba nebo proces.

// Set five minute expiration as a default
private const double DefaultExpirationTimeInMinutes = 5.0;

public async Task<MyEntity> GetMyEntityAsync(int id)
{
  // Define a unique key for this method and its parameters.
  var key = $"MyEntity:{id}";
  var cache = Connection.GetDatabase();

  // Try to get the entity from the cache.
  var json = await cache.StringGetAsync(key).ConfigureAwait(false);
  var value = string.IsNullOrWhiteSpace(json)
                ? default(MyEntity)
                : JsonConvert.DeserializeObject<MyEntity>(json);

  if (value == null) // Cache miss
  {
    // If there's a cache miss, get the entity from the original store and cache it.
    // Code has been omitted because it is data store dependent.
    value = ...;

    // Avoid caching a null value.
    if (value != null)
    {
      // Put the item in the cache with a custom expiration time that
      // depends on how critical it is to have stale data.
      await cache.StringSetAsync(key, JsonConvert.SerializeObject(value)).ConfigureAwait(false);
      await cache.KeyExpireAsync(key, TimeSpan.FromMinutes(DefaultExpirationTimeInMinutes)).ConfigureAwait(false);
    }
  }

  return value;
}

Poznámka:

Příklady používají Azure Managed Redis pro přístup k úložišti a načítání informací z mezipaměti. Další informace najdete v tématu Vytvoření instance Azure Managed Redis a Use Azure Managed Redis v .NET.

Následující UpdateEntityAsync metoda ukazuje, jak zneplatnit objekt v mezipaměti, když aplikace změní hodnotu. Kód aktualizuje původní úložiště dat a pak z mezipaměti odebere položku v ní uloženou.

public async Task UpdateEntityAsync(MyEntity entity)
{
    // Update the object in the original data store.
    await this.store.UpdateEntityAsync(entity).ConfigureAwait(false);

    // Invalidate the current cache object.
    var cache = Connection.GetDatabase();
    var id = entity.Id;
    var key = $"MyEntity:{id}"; // The key for the cached object.
    await cache.KeyDeleteAsync(key).ConfigureAwait(false); // Delete this key from the cache.
}

Poznámka:

Pořadí kroků je velmi důležité. Aktualizujte úložiště dat předtím, než položku odeberete z mezipaměti. Pokud nejprve odeberete položku uloženou v mezipaměti, bude k dispozici malé časové období, kdy klient může položku načíst před aktualizací úložiště dat. V této situaci výsledkem načtení je "cache miss", protože položka není v mezipaměti. Chybějící mezipaměť způsobí, že aplikace načte zastaralou položku z úložiště dat a přidá ji zpět do mezipaměti. Tato posloupnost vede k zastaralým datům v mezipaměti.

Další kroky

• Úvod do konzistence dat: Tento úvod popisuje problémy s konzistencí napříč distribuovanými daty. Shrnuje také, jak může aplikace implementovat konečnou konzistenci pro zachování dostupnosti dat. Cloudové aplikace obvykle ukládají data napříč několika úložišti dat a umístěními. V tomto prostředí musíte efektivně spravovat a udržovat konzistenci dat, zejména kvůli souběžnosti a problémům s dostupností, ke kterým může dojít.

• Použití Azure Managed Redis jako sémantické mezipaměti: V tomto kurzu se dozvíte, jak implementovat sémantické ukládání do mezipaměti pomocí Azure Managed Redis.

Související prostředky

• Pokyny k ukládání do mezipaměti: V těchto doprovodných materiálech najdete další informace o ukládání dat do mezipaměti v cloudovém řešení a o problémech, které je potřeba vzít v úvahu při implementaci mezipaměti.

Načtěte data na vyžádání do mezipaměti z úložiště dat. Tento přístup může zvýšit výkon a pomáhá udržovat konzistenci mezi daty uloženými v mezipaměti a daty v podkladovém úložišti dat.

Kontext a problém

Aplikace používají mezipaměť ke zlepšení výkonu pro opakovaný přístup k informacím v úložišti dat. Data uložená v mezipaměti ale nemůžou vždy zůstat konzistentní s úložištěm dat. Aplikace by měly implementovat strategii, která uchovává data v mezipaměti co nejaktuálnější. Strategie by také měla zjistit, kdy jsou data uložená v mezipaměti zastaralá, a správně je zpracovat.

Řešení

Mnoho komerčních systémů pro ukládání do mezipaměti poskytuje operace čtení a zápisu typu write-through nebo write-behind. V těchto systémech aplikace načte data odkazováním na mezipaměť. Pokud data nejsou v mezipaměti, aplikace je načte z úložiště dat a přidá je do mezipaměti. Systém automaticky zapíše všechny změny provedené v mezipaměti dat zpět do úložiště dat.

U mezipamětí, které tuto funkci neposkytují, musí aplikace, které mezipaměť používají, udržovat data.

Aplikace může emulovat funkčnost čtení skrze cache implementací vzoru Cache-Aside. Tato strategie načte data do mezipaměti na vyžádání. Následující diagram používá vzor Cache-Aside k ukládání dat do mezipaměti.

Diagram obsahuje aplikaci, mezipaměť a úložiště dat. Mezipaměť odkazuje na aplikaci označenou jako krok 1. Úložiště dat odkazuje na aplikaci označený jako krok 2. Aplikace odkazuje na mezipaměť označenou jako krok 3.

1. Aplikace určuje, zda se položka aktuálně nachází v mezipaměti pokusem o čtení z mezipaměti.

2. Pokud položka není v mezipaměti, označovaná také jako neúspěšná mezipaměť, aplikace načte položku z úložiště dat.

3. Aplikace přidá položku do mezipaměti a pak ji vrátí volajícímu.

Když aplikace aktualizuje informace, zapíše změnu do úložiště dat a potom zneplatní odpovídající položku v mezipaměti. Jakmile je položka znovu potřebná, vzor Cache-Aside načte aktualizovaná data z úložiště dat a přidá je do mezipaměti.

Problémy a důležité informace

Při rozhodování o implementaci tohoto modelu zvažte následující body:

• Životnost dat uložených v mezipaměti: Mnoho mezipamětí používá zásadu vypršení platnosti k zneplatnění dat a odebrání dat z mezipaměti, pokud k ní není po nastavenou dobu přístup. Aby bylo cache-aside efektivní, ujistěte se, že politika vypršení platnosti odpovídá vzoru přístupu aplikací, které data používají. Nevytvádejte období vypršení platnosti příliš krátké, protože předčasné vypršení platnosti může způsobit, že aplikace budou průběžně načítat data z úložiště dat a přidávat je do mezipaměti. Podobně neudělávejte období vypršení platnosti tak dlouho, aby data uložená v mezipaměti byla zastaralá. Ukládání do mezipaměti je nejvhodnější pro relativně statická data nebo data, která aplikace často čtou.

• Vyřazení dat: Většina mezipamětí má v porovnání s úložištěm dat, odkud data pocházejí, omezenou velikost. Pokud mezipaměť překročí limit velikosti, vyřadí data. Většina vyrovnávacích pamětí používá zásadu nejméně nedávno použité položky k výběru položek pro vyřazení, ale některé umožňují přizpůsobení.

• Konfigurace: Chování mezipaměti můžete nakonfigurovat globálně nebo pro každou položku v mezipaměti. Jedna globální zásada vyřazení nemusí vyhovovat všem položkám. Pokud je načtení položky nákladné, nakonfigurujte položku mezipaměti jednotlivě. V této situaci je vhodné zachovat položku v mezipaměti, i když se k ní dostanete méně často než levnější položky.

• Primace mezipaměti: Mnoho řešení předem naplní mezipaměť daty, která aplikace pravděpodobně vyžaduje jako součást zpracování po spuštění. Vzor Cache-Aside zůstává užitečný, když některým z těchto dat vyprší platnost nebo se vyřadí.

• Konzistence: Model Cache-Aside nezaručuje konzistenci mezi úložištěm dat a mezipamětí. Externí proces může například kdykoli změnit položku v úložišti dat. Tato změna se v mezipaměti nezobrazí, dokud se položka znovu nenačte. V systému, který replikuje data napříč úložišti dat, může častá synchronizace komplikovat konzistenci.

• Zastaralost dat po zápisu: Vzor Cache-Aside při zápisu zneplatní položku v mezipaměti a při dalším čtení ji znovu naplní daty. Mezi zápisem a dalším čtením může čtenář zaznamenat chybějící mezipaměť nebo krátce zobrazit zastaralá data. Toto chování odlišuje vzor Cache-Aside od mezipaměti se zápisem, která aktualizuje úložiště dat i mezipaměť v rámci téže operace zápisu, takže čtecí operace vidí novou hodnotu ihned po úspěšném zápisu. Pokud cesty s převahou čtení vyžadují konzistenci čtení po zápisu, zvažte místo toho write-through ukládání do mezipaměti.

• Místní ukládání do mezipaměti: Mezipaměť může být místní pro instanci aplikace a může být uložena v paměti. Přístup cache-aside funguje dobře v tomto prostředí, pokud aplikace opakovaně přistupuje ke stejným datům. Místní mezipaměť je ale soukromá, takže různé instance aplikací můžou mít kopii stejných dat uložených v mezipaměti. Tato data se můžou rychle stát nekonzistentní mezi mezipamětí, takže možná budete muset ukončit platnost dat v privátní mezipaměti a aktualizovat je častěji. V těchto scénářích zvažte použití sdíleného nebo distribuovaného mechanismu ukládání do mezipaměti.

• Sémantické ukládání do mezipaměti: Některé úlohy můžou těžit z načítání mezipaměti na základě sémantického významu, nikoli přesných klíčů. Tento přístup snižuje počet požadavků a tokenů odesílaných do jazykových modelů. Ukládání do sémantické mezipaměti používejte pouze v případě, že data podporují sémantickou ekvivalenci, neriskuje vrácení nesouvisejících odpovědí a neobsahuje soukromá a citlivá data. Například "Jaký je můj čistý roční příjem?" je sémanticky podobné "Jaký je můj čistý roční plat?" Pokud se ale na tyto otázky ptají různí uživatelé, odpovědi by se měly lišit. Tato citlivá data byste také neměli zahrnout do mezipaměti.

Kdy se má tento model použít

Tento model použijte v těchto případech:

• Mezipaměť neposkytuje nativní operace přímého čtení a zápisu.

• Požadavky na prostředky jsou nepředvídatelné. Tento model umožňuje aplikacím načítat data na vyžádání. Nepředpokládá, která data aplikace vyžaduje předem.

Tento vzor nemusí být vhodný v těchto případech:

• Data jsou citlivá nebo související se zabezpečením. Ukládání dat do mezipaměti může být nevhodné, zejména když mezipaměť sdílí více aplikací nebo uživatelů. Vždy načtěte tento typ dat z primárního zdroje.

• Datová sada uložená v mezipaměti je statická. Pokud se data vejdou do dostupného prostoru mezipaměti, předejte mezipaměť datům při spuštění a použijte zásadu, která brání vypršení platnosti dat.

• U většiny požadavků nedochází k zasažení cache. V takovém případě by režijní náklady na kontrolu mezipaměti a načítání dat do ní mohly převažovat nad výhodami ukládání do mezipaměti.

• Informace o stavu relace ukládáte do mezipaměti ve webové aplikaci hostované ve webové farmě. V tomto prostředí nepoužívejte závislosti založené na spřažení klient-server.

Návrh úloh

Vyhodnoťte, jak použít vzor Cache-Aside v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

Pilíř	Jak tento model podporuje cíle pilíře
Spolehlivostní rozhodnutí o návrhu pomáhají vaší pracovní zátěži stát se odolná proti poruchám a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Ukládání do mezipaměti replikuje data. Omezené způsoby může zachovat dostupnost často přístupných dat, pokud je úložiště dat původu dočasně nedostupné. Pokud mezipaměť nefunguje správně, může se úloha vrátit do původního úložiště dat. - RE:05 Redundance
efektivita výkonu pomáhá vašim úlohám efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Ukládání do mezipaměti zlepšuje výkon dat náročných na čtení, která se mění zřídka a toleruje určitou nestarost. - Datový výkon PE:08 - PE:12 Průběžná optimalizace výkonu

Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.

Příklad

Zvažte použití Azure Managed Redis k vytvoření distribuované mezipaměti, kterou může sdílet více instancí aplikací.

Následující příklad používá klienta StackExchange.Redis, což je knihovna klienta Redis napsaná pro .NET. Pokud se chcete připojit k instanci Azure Managed Redis, zavolejte statickou ConnectionMultiplexer.Connect metodu a předejte připojovací řetězec. Metoda vrátí ConnectionMultiplexer představující připojení.

Jedním ze způsobů, jak sdílet ConnectionMultiplexer instanci v aplikaci, je mít statickou vlastnost, která vrací připojenou instanci, podobně jako v následujícím příkladu. Tento přístup poskytuje způsob inicializace jedné připojené instance, který je bezpečný pro přístup z více vláken.

private static ConnectionMultiplexer Connection;

// Redis connection string information
private static Lazy<ConnectionMultiplexer> lazyConnection = new Lazy<ConnectionMultiplexer>(() =>
{
    string cacheConnection = ConfigurationManager.AppSettings["CacheConnection"].ToString();
    return ConnectionMultiplexer.Connect(cacheConnection);
});

public static ConnectionMultiplexer Connection => lazyConnection.Value;

Metoda GetMyEntityAsync v následujícím příkladu ukazuje implementaci modelu Cache-Aside. Tato metoda načte objekt z mezipaměti pomocí strategie čtení za běhu.

Metoda identifikuje objekt pomocí celočíselného ID jako klíče. Pokusí se načíst položku z mezipaměti pomocí tohoto klíče. Pokud mezipaměť obsahuje odpovídající položku, vrátí položku. Pokud mezipaměť neobsahuje shodu, GetMyEntityAsync metoda načte objekt z úložiště dat, přidá ho do mezipaměti a vrátí ji. Tento příklad vynechá kód, který čte data z úložiště dat, protože tato logika závisí na úložišti dat. Položka uložená v mezipaměti je nakonfigurovaná tak, aby vypršela, aby se zabránilo jeho zastaralí, pokud ji aktualizuje jiná služba nebo proces.

// Set five minute expiration as a default
private const double DefaultExpirationTimeInMinutes = 5.0;

public async Task<MyEntity> GetMyEntityAsync(int id)
{
  // Define a unique key for this method and its parameters.
  var key = $"MyEntity:{id}";
  var cache = Connection.GetDatabase();

  // Try to get the entity from the cache.
  var json = await cache.StringGetAsync(key).ConfigureAwait(false);
  var value = string.IsNullOrWhiteSpace(json)
                ? default(MyEntity)
                : JsonConvert.DeserializeObject<MyEntity>(json);

  if (value == null) // Cache miss
  {
    // If there's a cache miss, get the entity from the original store and cache it.
    // Code has been omitted because it is data store dependent.
    value = ...;

    // Avoid caching a null value.
    if (value != null)
    {
      // Put the item in the cache with a custom expiration time that
      // depends on how critical it is to have stale data.
      await cache.StringSetAsync(key, JsonConvert.SerializeObject(value)).ConfigureAwait(false);
      await cache.KeyExpireAsync(key, TimeSpan.FromMinutes(DefaultExpirationTimeInMinutes)).ConfigureAwait(false);
    }
  }

  return value;
}

Poznámka:

Příklady používají Azure Managed Redis pro přístup k úložišti a načítání informací z mezipaměti. Další informace najdete v tématu Vytvoření instance Azure Managed Redis a Use Azure Managed Redis v .NET.

Následující UpdateEntityAsync metoda ukazuje, jak zneplatnit objekt v mezipaměti, když aplikace změní hodnotu. Kód aktualizuje původní úložiště dat a pak z mezipaměti odebere položku v ní uloženou.

public async Task UpdateEntityAsync(MyEntity entity)
{
    // Update the object in the original data store.
    await this.store.UpdateEntityAsync(entity).ConfigureAwait(false);

    // Invalidate the current cache object.
    var cache = Connection.GetDatabase();
    var id = entity.Id;
    var key = $"MyEntity:{id}"; // The key for the cached object.
    await cache.KeyDeleteAsync(key).ConfigureAwait(false); // Delete this key from the cache.
}

Poznámka:

Pořadí kroků je velmi důležité. Aktualizujte úložiště dat předtím, než položku odeberete z mezipaměti. Pokud nejprve odeberete položku uloženou v mezipaměti, bude k dispozici malé časové období, kdy klient může položku načíst před aktualizací úložiště dat. V této situaci výsledkem načtení je "cache miss", protože položka není v mezipaměti. Chybějící mezipaměť způsobí, že aplikace načte zastaralou položku z úložiště dat a přidá ji zpět do mezipaměti. Tato posloupnost vede k zastaralým datům v mezipaměti.

Další kroky

• Úvod do konzistence dat: Tento úvod popisuje problémy s konzistencí napříč distribuovanými daty. Shrnuje také, jak může aplikace implementovat konečnou konzistenci pro zachování dostupnosti dat. Cloudové aplikace obvykle ukládají data napříč několika úložišti dat a umístěními. V tomto prostředí musíte efektivně spravovat a udržovat konzistenci dat, zejména kvůli souběžnosti a problémům s dostupností, ke kterým může dojít.

• Použití Azure Managed Redis jako sémantické mezipaměti: V tomto kurzu se dozvíte, jak implementovat sémantické ukládání do mezipaměti pomocí Azure Managed Redis.

Související prostředky

• Pokyny k ukládání do mezipaměti: V těchto doprovodných materiálech najdete další informace o ukládání dat do mezipaměti v cloudovém řešení a o problémech, které je potřeba vzít v úvahu při implementaci mezipaměti.