Model doplňování mezipaměti

Azure Cache for Redis

Na vyžádání načte data z úložiště dat do mezipaměti. To může zlepšit výkon a také pomoct se zachováním konzistence mezi daty drženými v mezipaměti a daty v základním úložišti.

Kontext a problém

Aplikace využívají mezipaměť ke zlepšení opakovaného přístupu k informacím uloženým v datovém úložišti. Není ale možné očekávat, že data uložená v mezipaměti budou vždy konzistentní s úložištěm dat. Aplikace by měly implementovat strategii, která pomáhá zajistit, aby data v mezipaměti byla co nejvíce up-todata. Strategie by také měla být schopná rozpoznat, kdy se data uložená v mezipaměti stanou zastaralá a odpovídajícím způsobem je zpracují.

Řešení

Řada komerčních systémů pro ukládání do mezipaměti umožňuje operace přímého čtení a přímého zápisu / opožděného zápisu. 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. Všechny úpravy dat v mezipaměti se automaticky zapíší zpět do úložiště dat.

V případě mezipamětí, které tuto funkci nemají, jsou za správu dat zodpovědné aplikace, které mezipaměť používají.

Aplikace můžou emulovat funkci přímého čtení z mezipaměti implementací strategie doplňování mezipaměti. Tato strategie načte data do mezipaměti na vyžádání. Obrázek znázorňuje ukládání dat do mezipaměti pomocí modelu Doplňování mezipaměti.

1. Aplikace určuje, zda je položka aktuálně uložena v mezipaměti pokusem o čtení z mezipaměti.
2. Pokud položka není aktuální v mezipaměti (zmeška mezipaměti), 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.

Pokud aplikace aktualizuje informace, může postupovat podle strategie přímého zápisu tím, že provede změnu v úložišti dat a zneplatní odpovídající položku v mezipaměti.

Jakmile je položka znovu nutná, strategie doplňování mezipaměti načte aktualizovaná data z úložiště dat a přidá je do mezipaměti.

Problémy a důležité informace

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

Doba platnosti 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 doplňování mezipaměti účinné, zajistěte, že zásada vypršení platnosti odpovídá modelu 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. Stejně tak nenastavujte dobu vypršení platnosti tak dlouhou, aby se data uložená v mezipaměti stala zastaralými. Mějte na paměti, že ukládání do mezipaměti je nejúčinnější pro relativně statická data nebo data, která jsou často načítaná.

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 mezipamětí používá nejméně nedávno použitou zásadu pro výběr položek, které se mají vyřadit, ale může být přizpůsobitelná.

Konfigurace. Konfiguraci mezipaměti je možné nastavit globálně i pro každou položku v mezipaměti. Jedna globální zásada vyřazení nemusí vyhovovat všem položkám. Konfigurace položky mezipaměti může být vhodná, pokud je načtení položky nákladné. 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.

Příprava mezipaměti. Mnoho řešení předvyplní mezipaměť daty, které aplikace bude pravděpodobně potřebovat jako součást počátečního zpracování. Doplňování mezipaměti může být přesto užitečné, pokud u některých z těchto dat vyprší platnost nebo dojde k jejich vyřazení.

Konzistence. Implementace modulu Doplňování mezipaměti 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 být konzistence náročná, pokud k synchronizaci dochází často.

Místní ukládání do mezipaměti (v paměti). Mezipaměť může být pro instanci aplikace místní a uložená v paměti. V tomto prostředí může být model Doplňování mezipaměti užitečný, pokud aplikace opakovaně přistupuje ke stejným datům. Místní mezipaměť je však soukromá, takže různé instance aplikace můžou mít kopii stejných dat uložených v mezipaměti. Tato data můžou být zanedlouho mezi jednotlivými mezipamětmi nekonzistentní, takže pravděpodobně bude nutné častěji nechat vypršet platnost dat v soukromé mezipaměti a obnovovat je. 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íčů. Tím se sníží počet požadavků a tokenů odesílaných do jazykových modelů. Ujistěte se, že data uložená v mezipaměti mají výhody sémantické ekvivalence a neriskují vrácení nesouvisejících odpovědí nebo obsahují soukromá a citlivá data. Například "Jaký je můj roční plat domů?" je sémanticky podobný "Co je můj roční příjem domů?" ale pokud se zobrazí dotaz dvou různých uživatelů, takže odpověď by neměla být stejná, ani byste chtěli zahrnout tato citlivá data 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 model nebude pravděpodobně vhodný v následujících případech:

• Pokud jsou data citlivá nebo souvisí se zabezpečením. Může být nevhodné ho uložit do mezipaměti, zejména pokud je mezipaměť sdílená mezi více aplikacemi nebo uživateli. Vždy přejděte k primárnímu zdroji dat.
• Sada dat 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.
• Když většina požadavků nezísáhne přístup do mezipaměti. 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.
• Při ukládání informací o stavu relace do mezipaměti ve webové aplikaci hostované ve webové farmě. V tomto prostředí byste se měli vyhnout vzniku závislostí podle vztahu klient-server.

Návrh úloh

Architekt by měl vyhodnotit způsob použití modelu Cache-Aside v návrhu k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected. Příklad:

Pilíř	Jak tento model podporuje cíle pilíře
Rozhodnutí o návrhu spolehlivosti pomáhají vaší úloze stát se odolnou proti selhání a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Ukládání do mezipaměti vytváří replikaci dat a v omezeném rozsahu je možné použít k zachování dostupnosti často používaných dat, pokud je úložiště dat původu dočasně nedostupné. Kromě toho, pokud v mezipaměti dojde k selhání, může se úloha vrátit do původního úložiště dat. - RE:05 Redundance
Efektivita výkonu pomáhá vaší úloze efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Použití cab mezipaměti zlepšuje výkon pro data s velkými nároky na čtení, která se mění zřídka a může tolerovat neakutnost. - Výkon dat PE:08 - PE:12 Průběžná optimalizace výkonu

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

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 kódu používá klienta StackExchange.Redis , což je klient 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í. Jeden ze způsobů sdílení instance ConnectionMultiplexer v aplikaci je pomocí statické vlastnosti, 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 kódu ukazuje implementaci modelu Cache-Aside. Tato metoda načte objekt z mezipaměti pomocí přístupu pro čtení.

Objekt je identifikovaný pomocí celočíselného ID, který se použije jako klíč. Metoda GetMyEntityAsync se pokusí načíst položku s tímto klíčem z mezipaměti. Pokud se najde odpovídající položka, mezipaměť ji vrátí. Pokud v mezipaměti není nalezena žádná shoda, metoda GetMyEntityAsync načte objekt z úložiště dat, přidá jej do mezipaměti a pak jej vrátí. Kód, který čte data z úložiště dat, se tady nezobrazuje, protože 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;
}

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í spravovaného Redis Azure a použití Azure Redis v .NET Core.

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 neúspěšná mezipaměť (protože položka byla odebrána z mezipaměti). Chybějící mezipaměť způsobí, že se starší verze položky načte z úložiště dat a přidá se zpět do mezipaměti. Výsledkem je zastaralá data mezipaměti.

Související prostředky

Při implementaci tohoto modelu můžou být relevantní následující informace:

• Model spolehlivé webové aplikace ukazuje, jak použít model doplňování mezipaměti na webové aplikace konvergující v cloudu.

• Pokyny k ukládání do mezipaměti. Obsahují další informace o tom, jak můžete v cloudovém řešení ukládat data do mezipaměti a o problémech, které byste měli při implementaci mezipaměti zvážit.

• Úvod do konzistence dat. Cloudové aplikace obvykle ukládají data napříč několika úložišti dat a umístěními. Správa a údržba konzistence dat v tomto prostředí je důležitým aspektem systému, zejména souběžnosti a problémů s dostupností, které mohou nastat. Tento úvod popisuje problémy s konzistencí napříč distribuovanými daty a shrnuje, jak aplikace může implementovat případnou konzistenci a zachovat dostupnost dat.

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

Na vyžádání načte data z úložiště dat do mezipaměti. To může zlepšit výkon a také pomoct se zachováním konzistence mezi daty drženými v mezipaměti a daty v základním úložišti.

Kontext a problém

Aplikace využívají mezipaměť ke zlepšení opakovaného přístupu k informacím uloženým v datovém úložišti. Není ale možné očekávat, že data uložená v mezipaměti budou vždy konzistentní s úložištěm dat. Aplikace by měly implementovat strategii, která pomáhá zajistit, aby data v mezipaměti byla co nejvíce up-todata. Strategie by také měla být schopná rozpoznat, kdy se data uložená v mezipaměti stanou zastaralá a odpovídajícím způsobem je zpracují.

Řešení

Řada komerčních systémů pro ukládání do mezipaměti umožňuje operace přímého čtení a přímého zápisu / opožděného zápisu. 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. Všechny úpravy dat v mezipaměti se automaticky zapíší zpět do úložiště dat.

V případě mezipamětí, které tuto funkci nemají, jsou za správu dat zodpovědné aplikace, které mezipaměť používají.

Aplikace můžou emulovat funkci přímého čtení z mezipaměti implementací strategie doplňování mezipaměti. Tato strategie načte data do mezipaměti na vyžádání. Obrázek znázorňuje ukládání dat do mezipaměti pomocí modelu Doplňování mezipaměti.

1. Aplikace určuje, zda je položka aktuálně uložena v mezipaměti pokusem o čtení z mezipaměti.
2. Pokud položka není aktuální v mezipaměti (zmeška mezipaměti), 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.

Pokud aplikace aktualizuje informace, může postupovat podle strategie přímého zápisu tím, že provede změnu v úložišti dat a zneplatní odpovídající položku v mezipaměti.

Jakmile je položka znovu nutná, strategie doplňování mezipaměti načte aktualizovaná data z úložiště dat a přidá je do mezipaměti.

Problémy a důležité informace

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

Doba platnosti 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 doplňování mezipaměti účinné, zajistěte, že zásada vypršení platnosti odpovídá modelu 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. Stejně tak nenastavujte dobu vypršení platnosti tak dlouhou, aby se data uložená v mezipaměti stala zastaralými. Mějte na paměti, že ukládání do mezipaměti je nejúčinnější pro relativně statická data nebo data, která jsou často načítaná.

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 mezipamětí používá nejméně nedávno použitou zásadu pro výběr položek, které se mají vyřadit, ale může být přizpůsobitelná.

Konfigurace. Konfiguraci mezipaměti je možné nastavit globálně i pro každou položku v mezipaměti. Jedna globální zásada vyřazení nemusí vyhovovat všem položkám. Konfigurace položky mezipaměti může být vhodná, pokud je načtení položky nákladné. 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.

Příprava mezipaměti. Mnoho řešení předvyplní mezipaměť daty, které aplikace bude pravděpodobně potřebovat jako součást počátečního zpracování. Doplňování mezipaměti může být přesto užitečné, pokud u některých z těchto dat vyprší platnost nebo dojde k jejich vyřazení.

Konzistence. Implementace modulu Doplňování mezipaměti 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 být konzistence náročná, pokud k synchronizaci dochází často.

Místní ukládání do mezipaměti (v paměti). Mezipaměť může být pro instanci aplikace místní a uložená v paměti. V tomto prostředí může být model Doplňování mezipaměti užitečný, pokud aplikace opakovaně přistupuje ke stejným datům. Místní mezipaměť je však soukromá, takže různé instance aplikace můžou mít kopii stejných dat uložených v mezipaměti. Tato data můžou být zanedlouho mezi jednotlivými mezipamětmi nekonzistentní, takže pravděpodobně bude nutné častěji nechat vypršet platnost dat v soukromé mezipaměti a obnovovat je. 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íčů. Tím se sníží počet požadavků a tokenů odesílaných do jazykových modelů. Ujistěte se, že data uložená v mezipaměti mají výhody sémantické ekvivalence a neriskují vrácení nesouvisejících odpovědí nebo obsahují soukromá a citlivá data. Například "Jaký je můj roční plat domů?" je sémanticky podobný "Co je můj roční příjem domů?" ale pokud se zobrazí dotaz dvou různých uživatelů, takže odpověď by neměla být stejná, ani byste chtěli zahrnout tato citlivá data 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 model nebude pravděpodobně vhodný v následujících případech:

• Pokud jsou data citlivá nebo souvisí se zabezpečením. Může být nevhodné ho uložit do mezipaměti, zejména pokud je mezipaměť sdílená mezi více aplikacemi nebo uživateli. Vždy přejděte k primárnímu zdroji dat.
• Sada dat 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.
• Když většina požadavků nezísáhne přístup do mezipaměti. 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.
• Při ukládání informací o stavu relace do mezipaměti ve webové aplikaci hostované ve webové farmě. V tomto prostředí byste se měli vyhnout vzniku závislostí podle vztahu klient-server.

Návrh úloh

Architekt by měl vyhodnotit způsob použití modelu Cache-Aside v návrhu k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected. Příklad:

Pilíř	Jak tento model podporuje cíle pilíře
Rozhodnutí o návrhu spolehlivosti pomáhají vaší úloze stát se odolnou proti selhání a zajistit, aby se po selhání obnovila do plně funkčního stavu.	Ukládání do mezipaměti vytváří replikaci dat a v omezeném rozsahu je možné použít k zachování dostupnosti často používaných dat, pokud je úložiště dat původu dočasně nedostupné. Kromě toho, pokud v mezipaměti dojde k selhání, může se úloha vrátit do původního úložiště dat. - RE:05 Redundance
Efektivita výkonu pomáhá vaší úloze efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Použití cab mezipaměti zlepšuje výkon pro data s velkými nároky na čtení, která se mění zřídka a může tolerovat neakutnost. - Výkon dat PE:08 - PE:12 Průběžná optimalizace výkonu

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

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 kódu používá klienta StackExchange.Redis , což je klient 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í. Jeden ze způsobů sdílení instance ConnectionMultiplexer v aplikaci je pomocí statické vlastnosti, 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 kódu ukazuje implementaci modelu Cache-Aside. Tato metoda načte objekt z mezipaměti pomocí přístupu pro čtení.

Objekt je identifikovaný pomocí celočíselného ID, který se použije jako klíč. Metoda GetMyEntityAsync se pokusí načíst položku s tímto klíčem z mezipaměti. Pokud se najde odpovídající položka, mezipaměť ji vrátí. Pokud v mezipaměti není nalezena žádná shoda, metoda GetMyEntityAsync načte objekt z úložiště dat, přidá jej do mezipaměti a pak jej vrátí. Kód, který čte data z úložiště dat, se tady nezobrazuje, protože 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;
}

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í spravovaného Redis Azure a použití Azure Redis v .NET Core.

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 neúspěšná mezipaměť (protože položka byla odebrána z mezipaměti). Chybějící mezipaměť způsobí, že se starší verze položky načte z úložiště dat a přidá se zpět do mezipaměti. Výsledkem je zastaralá data mezipaměti.

Související prostředky

Při implementaci tohoto modelu můžou být relevantní následující informace:

• Model spolehlivé webové aplikace ukazuje, jak použít model doplňování mezipaměti na webové aplikace konvergující v cloudu.

• Pokyny k ukládání do mezipaměti. Obsahují další informace o tom, jak můžete v cloudovém řešení ukládat data do mezipaměti a o problémech, které byste měli při implementaci mezipaměti zvážit.

• Úvod do konzistence dat. Cloudové aplikace obvykle ukládají data napříč několika úložišti dat a umístěními. Správa a údržba konzistence dat v tomto prostředí je důležitým aspektem systému, zejména souběžnosti a problémů s dostupností, které mohou nastat. Tento úvod popisuje problémy s konzistencí napříč distribuovanými daty a shrnuje, jak aplikace může implementovat případnou konzistenci a zachovat dostupnost dat.

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