Ukládání do mezipaměti

Ukládání do mezipaměti je běžná technika, jejímž cílem je zvýšit výkon a zlepšit škálovatelnost celého systému. Dosahuje se toho dočasným zkopírováním často používaných dat do rychlého úložiště umístěného v blízkosti aplikace. Pokud je toto rychlé úložiště dat umístěno blíž k aplikaci než původní zdroj, může se díky ukládání do mezipaměti výrazně zkrátit doba odezvy pro klientské aplikace, protože obsluha dat probíhá rychleji.

Ukládání do mezipaměti je nejúčinnější, když instance klienta opakovaně čte stejná data, zejména pokud původní úložiště dat splňuje všechny následující podmínky:

• Zůstává relativně statické.
• Ve srovnání s rychlostí mezipaměti je pomalé.
• Dochází v něm k velkému množství kolizí.
• Je daleko, pokud latence sítě může přístup zpomalovat.

Ukládání do mezipaměti v distribuovaných aplikacích

Distribuované aplikace při ukládání dat do mezipaměti obvykle implementují jednu nebo obě z následujících strategií:

• Použití soukromé mezipaměti, ve které jsou data uložena místně na počítači, na kterém je spuštěna instance aplikace nebo služba.
• Použití sdílené mezipaměti, která slouží jako společný zdroj, ke kterému může mít více procesů a počítačů.

V obou případech lze ukládání do mezipaměti provádět na straně klienta a serveru. Ukládání do mezipaměti na straně klienta probíhá v rámci procesu, který poskytuje uživatelské rozhraní pro systém, jako je webový prohlížeč nebo aplikace pracovní plochy. Ukládání do mezipaměti na straně serveru probíhá v rámci procesu, který poskytuje obchodní služby spuštěné vzdáleně.

Soukromé ukládání do mezipaměti

Základním typem mezipaměti je úložiště v paměti. Běží v adresním prostoru jednoho procesu a kód spuštění v tomto procesu k němu přistupuje přímo. Tento typ mezipaměti má rychlý přístup. Může také poskytovat efektivní způsob ukládání mírných objemů statických dat, protože velikost mezipaměti je obvykle omezená množstvím paměti, která je k dispozici v počítači, který je hostitelem procesu.

Pokud potřebujete ukládat do mezipaměti víc informací, než paměť fyzicky umožňuje, můžete data uložená v mezipaměti zapisovat do místního systému souborů. To bude pomalejší než při přístupu k datům uchovávaným v paměti, ale měla by být stále rychlejší a spolehlivější než načítání dat napříč sítí.

Pokud pracujete s několika současně běžícími instancemi aplikace, která tento model používá, každá instance aplikace má vlastní nezávislou mezipaměť, která obsahuje její vlastní kopii dat.

Mezipaměť si můžete představit jako snímek původních data v určitém okamžiku v minulosti. Pokud tato data nejsou statická, je pravděpodobné, že různé instance aplikace obsahují v příslušných mezipamětech různé verze data. Stejný dotaz zpracovaný těmito instancemi proto může vrátit různé výsledky, jak je znázorněno na obrázku 1.

Obrázek 1: použití mezipaměti v paměti v různých instancích aplikace.

Ukládání do sdílené mezipaměti

Použití sdílené mezipaměti může omezit riziko rozdílných dat v každé mezipaměti, které může vznikat v případě ukládání do mezipaměti umístěné v paměti. Ukládání do sdílené mezipaměti zajišťuje, že různé instance aplikace pracují se stejnými daty uloženými v mezipaměti. Dosahuje se toho tím, že je mezipaměť umístěna samostatně; obvykle je hostovaná v rámci samostatné služby, jak je znázorněno na obrázku 2.

Obrázek 2: použití sdílené mezipaměti.

Důležitou výhodou přístupu ukládání do sdílené mezipaměti je škálovatelnost, kterou poskytuje. Mnohé služby sdílené mezipaměti se implementují pomocí clusteru serverů a využívají software k distribuci dat napříč clusterem transparentně. Instance aplikace jednoduše odešle požadavek službě mezipaměti. Základní infrastruktura určuje umístění dat uložených v mezipaměti v clusteru. Mezipaměť je možné snadno škálovat přidáváním dalších serverů.

Přístup s ukládáním do sdílené mezipaměti má dvě hlavní nevýhody:

• Přístup k mezipaměti je pomalejší, protože už mezipaměť není místní pro každou instanci aplikace.
• Požadavek na implementaci samostatné služby mezipaměti může zvyšovat složitost řešení.

Aspekty využívání ukládání do mezipaměti

Následující části podrobněji popisují aspekty týkající se návrhu a používání mezipaměti.

Rozhodování o tom, kdy se data mají do mezipaměti ukládat

Ukládání do mezipaměti může výrazně zvýšit výkon a zlepšit škálovatelnost a dostupnost. Čím víc dat máte a čím vyšší je počet uživatelů, kteří k těmto datům potřebují mít přístup, tím větší jsou výhody ukládání do mezipaměti. Je to proto, že ukládání do mezipaměti snižuje latenci a množství kolizí v souvislosti se zpracováním velkých objemů souběžných požadavků v původním úložišti dat.

Databáze může například podporovat omezený počet souběžných připojení. Načítání dat ze sdílené mezipaměti namísto ze základní databáze ale klientské aplikaci poskytuje přístup k těmto datům i v případě, že je aktuálně dosažen maximální počet připojení k dispozici. Pokud navíc databáze přestane být k dispozici, může klientské aplikace pokračovat a používat data uložená v mezipaměti.

Zvažte, jestli do mezipaměti neukládat data, která se často čtou, ale upravují jen zřídka (například data s vyšším počtem operací čtení než operací zápisu). Nedoporučujeme ale používat mezipaměť jako autoritativní úložiště důležitých informací. Místo toho zajistěte, aby veškeré změny, jejichž ztrátu si vaše aplikace nemůže dovolit, byly vždy uložené do trvalého úložiště dat. To znamená, že pokud mezipaměť není k dispozici, může vaše aplikace i nadále pracovat a používat úložiště dat, takže ke ztrátě důležitých informací nedojde.

Určení způsobu efektivního ukládání dat do mezipaměti

Předpokladem efektivního používání mezipaměti je určení nejvhodnějších dat pro ukládání do mezipaměti a jejich ukládání do mezipaměti ve správnou dobu. Data je možné do mezipaměti přidat na vyžádání při prvním načtení aplikací. To znamená, že aplikace musí z úložiště dat načíst data jen jednou; všechny další přístupy může zajišťovat mezipaměť.

Mezipaměť může také být částečně nebo zcela naplněná daty už předem, obvykle při spuštění aplikace (přístup známý jako seeding). Ne vždy se ale doporučuje implementovat seeding pro velkou mezipaměť, protože tento přístup může znamenat náhlou velkou zátěž původního úložiště dat při spuštění aplikace.

Při rozhodování, jestli mezipaměť částečně nebo zcela naplnit předem, a při výběru dat, která se mají do mezipaměti uložit, často pomůže analýza schémat použití. Může být například užitečné naplnit mezipaměť statickými daty profilů uživatelů z řad zákazníků, kteří aplikaci používají pravidelně (třeba každý den), ale ne těch, kteří aplikaci používají jen jednou týdně.

Ukládání do mezipaměti obvykle funguje dobře s daty, která jsou neměnná nebo se mění zřídka. Mezi příklady patří referenční informace, například údaje o produktu a cenách v aplikaci elektronického obchodování, nebo sdílené statické prostředky, jejichž sestavování je nákladné. Některá nebo všechna tato data je možné načíst do mezipaměti při spuštění aplikace, aby se minimalizoval objem požadavků na prostředky a zvýšil se výkon. Může být také vhodné mít proces na pozadí, který pravidelně aktualizuje referenční data v mezipaměti, aby bylo zajištěno, že je aktuální, nebo když aktualizuje mezipaměť při změně referenčních dat.

Ukládání do mezipaměti je méně užitečné v případě dynamických dat, i když existují výjimky z tohoto pravidla (další informace najdete níž v tomto článku v části Ukládání vysoce dynamických dat do mezipaměti). Když se původní data mění pravidelně, informace uložené v mezipaměti velmi rychle zastarávají nebo se vzhledem k režii při synchronizaci mezipaměti s původním úložištěm dat efektivita ukládání do mezipaměti snižuje.

Všimněte si, že mezipaměť nemusí zahrnovat úplná data entity. Pokud například datovou položku představuje objekt s více hodnotami, například zákazník banky se jménem, adresou a zůstatkem na účtu, některé z těchto prvků můžou zůstat statické (například jméno a adresa), zatímco jiné (například zůstatek na účtu) můžou být dynamičtější. V těchto situacích může být užitečné ukládat do mezipaměti statické části dat a načítat (nebo počítat) jen zbývající informace, když budou požadovány.

Doporučujeme, abyste provedli testování výkonu a analýzu využití, abyste zjistili, jestli je vhodné předem naplnit nebo načítat mezipaměť nebo jejich kombinace. Rozhodnutí by mělo být založeno na proměnlivosti dat a na schématu jejich používání. Využití mezipaměti a analýza výkonu jsou obzvláště důležité v aplikacích, které mají velký objem zatížení a které musí být vysoce škálovatelné. U scénářů s vysokou škálovatelností může mít například smysl naplnit mezipaměť, aby se snížila zátěž úložiště dat ve špičkách.

Použitím ukládání do mezipaměti můžete také předcházet opakování výpočtů v době, kdy aplikace běží. Pokud operace transformuje data nebo provádí složitý výpočet, můžete výsledky operace uložit do mezipaměti. Pokud je stejný výpočet vyžadován později, aplikace může jednoduše načíst výsledky z mezipaměti.

Aplikace může upravovat data uložená v mezipaměti. Doporučujeme však pracovat s mezipamětí jako s přechodným úložištěm dat, které může kdykoli zmizet. Cenná data neukládejte jen do mezipaměti; zajistěte uchovávání informací i v původním úložišti dat. To znamená, že se minimalizuje riziko ztráty dat, pokud by mezipaměť přestala být k dispozici.

Ukládání vysoce dynamických dat do mezipaměti

Když ukládáte rychle se měnící informace v trvalém úložišti dat, může to způsobit i režii systému. Představme si třeba zařízení, které průběžně informuje o stavu nebo jiném ukazateli. Pokud aplikace rozhodne, že se tato data nemají ukládat do mezipaměti, protože by téměř vždy byla zastaralá, může se stejné hledisko uplatňovat při ukládání těchto informací do úložiště dat a načítání z něj. V průběhu času potřebného pro uložení a načtení těchto dat by mohlo dojít k jejich změně.

V podobné situaci zvažte výhody ukládání dynamických informací přímo do mezipaměti, a ne do trvalého úložiště dat. Pokud jsou data Nekritická a nevyžadují audit, nezáleží na tom, jestli dojde ke ztrátě příležitostné změny.

Správa konce platnosti dat v mezipaměti

Ve většině případů jsou data, která se nachází v mezipaměti, kopii dat, která se nachází v původním úložišti dat. Data v původním úložišti dat se po uložení do mezipaměti můžou změnit, takže data v mezipaměti jsou pak zastaralá. Mnoho systémů ukládání do mezipaměti umožňuje nakonfigurovat mezipaměť tak, aby ukončovala platnost dat a zkracovala dobu, během které mohou být data zastaralá.

Když vyprší platnost dat uložených v mezipaměti, odeberou se z mezipaměti a aplikace musí načíst data z původního úložiště dat (nově načtené informace může vložit zpátky do mezipaměti). Při konfiguraci mezipaměti můžete nastavit výchozí zásady ukončení platnosti. V mnoha službách ukládání do mezipaměti můžete také určovat dobu platnosti pro jednotlivé objekty při jejich ukládání do mezipaměti prostřednictvím kódu programu. Některé mezipaměti umožňují určit dobu platnosti jako absolutní hodnotu nebo jako klouzavou hodnotu, která způsobí, že příslušná položka bude z mezipaměti odebrána, pokud k ní nebude během určené doby zaznamenán přístup. Toto nastavení potlačí veškeré zásady ukončení platnosti pro celou mezipaměť, ale vztahuje se jen na určené objekty.

Mezipaměť se také může zaplnit, pokud v ní data můžou zůstat po dlouhou dobu. V takovém případě může u kterékoli žádosti o přidání nových položek do mezipaměti dojít k vynucení odebrání v rámci procesu nazývaného vyřazení. Služby mezipaměti obvykle vyřazují nejdéle nepoužitá data (zásada LRU), tuto zásadu ale obvykle můžete potlačit a zabránit vyřazení položek. Pokud však použijete tento přístup, riskujete zaplnění paměti, která je v mezipaměti k dispozici. Aplikace, která se pokusí o přidání položky do mezipaměti, selže s výjimkou.

V některých implementacích ukládání do mezipaměti můžou být k dispozici další zásady vyřazení. Existuje několik typů zásad vyřazení. Tady jsou některé z nich:

• Zásada naposledy použitých dat (očekává se, že nebudou vyžadována data znovu).
• Zásada fronty (nejstarší data se vyřadí jako první).
• Zásada explicitního odebrání na základě aktivované události (například úpravy dat).

Zrušení platnosti dat v mezipaměti na straně klienta

Data uložená v mezipaměti na straně klienta se obecně považují za data nechráněná službou, která poskytuje data klientovi. Služba nemůže přímo vynutit, aby klient přidal nebo odebral na své straně.

To znamená, že pokud klient používá nevhodně nakonfigurovanou mezipaměť, může i nadále používat zastaralé informace. Pokud například zásady konce platnosti pro mezipaměť nejsou implementované správně, může klient používat zastaralé informace, které jsou místně uložené, i po změně příslušných informací v původním zdroji dat.

Pokud vytváříte webovou aplikaci, která pracuje s daty prostřednictvím připojení HTTP, můžete implicitně vynutit, aby webový klient (například prohlížeč nebo webový proxy server) načetl nejnovější informace. Můžete to udělat, pokud je prostředek aktualizován změnou v identifikátoru URI prostředku. Weboví klienti obvykle používají identifikátor URI prostředku jako klíč v mezipaměti na straně klienta, takže pokud se identifikátor URI změní, webový klient ignoruje všechny verze prostředku, které byly v mezipaměti uložení dřív, a načte místo toho novou verzi.

Správa souběžnosti v mezipaměti

Mezipaměti jsou často navržené tak, aby je sdílelo víc instancí aplikace. Každá instance aplikace může číst a upravovat data v mezipaměti. V důsledku toho se stejné problémy se souběžností, které vznikají u každého úložiště sdílených dat, týkají i mezipaměti. V situaci, kdy aplikace potřebuje upravovat data uložená v mezipaměti, může být potřebné zajistit, aby se aktualizacemi provedenými jednou instancí aplikace nepřepsaly změny provedené jinou instancí.

V závislosti na charakteru dat a pravděpodobnosti kolizí můžete využít jeden ze dvou přístupů týkající se souběžnosti:

• Optimistická. Bezprostředně před aktualizací dat aplikace zkontroluje, jestli se data v mezipaměti od načtení změnila. Pokud jsou data i nadále stejná, je možné změnu provést. V opačném případě musí aplikace rozhodnout, jestli data aktualizuje. (Obchodní logika, která řídí toto rozhodnutí, bude specifická pro aplikaci.) Tento přístup je vhodný pro situace, kdy jsou aktualizace nečasté nebo kdy dochází ke kolizím.
• Pesimistická. Když aplikace načte data, uzamkne je v mezipaměti, aby zabránila jiné instanci v jejich změně. Tento proces zajišťuje, že nemůže docházet ke kolizím, může ale také blokovat jiné instance, které potřebují zpracovávat stejná data. Pesimistická souběžnost může ovlivňovat škálovatelnost řešení a doporučuje se jen pro krátkodobé operace. Tento přístup může být vhodný v situacích, kdy je pravděpodobnost kolizí vyšší, zejména pokud aplikace aktualizuje v mezipaměti několik položek a musí zajistit konzistentní provedení těchto změn.

Implementace vysoké dostupnosti a škálovatelnosti a zvýšení výkonu

Nepoužívejte mezipaměť jako primární úložiště dat; tuto roli má původní úložiště dat, ze kterého se mezipaměť naplní. Původní úložiště dat odpovídá za trvalost dat.

Dbejte na to, abyste do řešení nezaváděli kritické závislosti na dostupnosti služby sdílené mezipaměti. Aplikace by měla i nadále fungovat, pokud služba poskytující sdílenou mezipaměť nebude k dispozici. Aplikace by neměla při čekání na obnovení služby cache Service reagovat nebo se nezdařila.

Aplikace proto musí být připravená na zjišťování dostupnosti služby mezipaměti a v případě, že mezipaměť není k dispozici, se musí vrátit k používání původního úložiště dat. Pro tento scénář je užitečný model Circuit-Breaker (jistič). Službu, která poskytuje mezipaměť, lze obnovit, a jakmile je znovu k dispozici, je možné mezipaměť znovu naplňovat daty čtenými z původního úložiště dat podle strategie, jako je například model s doplňováním mezipaměti.

Škálovatelnost systému ale může být ovlivněná, pokud se aplikace vrátí k původnímu úložišti dat, když je mezipaměť dočasně nedostupná. Zatímco probíhá zotavování úložiště dat, může dojít k zaplavení původního úložiště dat požadavky na data, a v důsledku toho může docházet k vypršení časového limitu a k selhání připojení.

Společně se sdílenou mezipamětí, ke které přistupují všechny instance aplikace, zvažte implementaci místní soukromé mezipaměti v každé instanci aplikace. Když aplikace načte položku, může ji nejprve zkontrolovat v příslušné místní mezipaměti, pak ve sdílené mezipaměti, a pak v původním úložišti dat. Místní mezipaměť je možné naplnit s použitím dat buď ve sdílené mezipaměti, nebo v databázi, pokud sdílená mezipaměť není k dispozici.

Tento přístup vyžaduje pečlivou konfiguraci, aby nedocházelo k přílišnému zastarávání místní mezipaměti vzhledem ke sdílené mezipaměti. Místní mezipaměť však funguje jako vyrovnávací paměť, pokud sdílená mezipaměť není k dispozici. Tato struktura je znázorněna na obrázku 3.

Obrázek 3: použití místní soukromé mezipaměti se sdílenou mezipamětí.

Některé služby mezipaměti poskytují jako podporu velkých mezipamětí, ve kterých jsou uložena relativně dlouhodobá data, možnost vysoké dostupnosti, která implementuje automatické převzetí služeb při selhání, pokud mezipaměť přestane být k dispozici. Tento přístup obvykle zahrnuje replikaci dat uložených v mezipaměti na primárním serveru mezipaměti na sekundární server mezipaměti a přepnutí na sekundární server, pokud dojde k selhání primárního serveru nebo k přerušení připojení.

Pokud se do mezipaměti na primárním serveru zapisují data, může replikace na sekundární server probíhat asynchronně, aby se snížila latence související se zápisem do více umístění. Při tomto přístupu se může stát, že v případě selhání dojde ke ztrátě některých informací uložených v mezipaměti, objem těchto dat by však měl být v porovnání s celkovou velikostí mezipaměti malý.

Pokud je sdílená mezipaměť velká, může být užitečné při rozdělit data uložená v mezipaměti do oddílů mezi uzly, aby se snížila pravděpodobnost kolizí a zlepšila se škálovatelnost. Mnoho sdílených mezipamětí podporuje možnost dynamického přidávání (a odebírání) uzlů a obnovování rovnováhy dat mezi oddíly. Tento přístup může zahrnovat clustering, v rámci kterého je kolekce uzlů prezentována klientským aplikacím jako jediná nedělená mezipaměť. Interně jsou však data rozptýlena mezi uzly podle předem definované distribuční strategie rovnoměrného rozkládání zátěže. Další informace o možných strategiích dělení na oddíly najdete v tématu pokyny k dělení dat.

Clustering může také zvýšit dostupnost mezipaměti. Pokud selže jeden uzel, je zbytek mezipaměti i nadále přístupný. Clustering se často používá v kombinaci s replikací a převzetím služeb při selhání. Každý uzel je možné replikovat a repliku lze rychle převést do stavu online, pokud uzel selže.

Je pravděpodobné, že mnoho operací čtení a zápisu se bude týkat jednoduchých datových hodnot nebo objektů. V některých případech ale může být třeba rychle ukládat nebo načítat velké objemy dat. Naplnění mezipaměti může například zahrnovat zápis stovek nebo tisíců položek do mezipaměti. Je také možné, že aplikace bude muset v rámci téhož požadavku načítat z mezipaměti velké množství souvisejících položek.

Mnohé z velkoobjemových mezipamětí poskytují pro tyto účely dávkové operace. Díky tomu může klientská aplikace zabalit velký objem položek do jednoho požadavku a snížit režii spojenou se zpracováním velkého množství malých požadavků.

Ukládání do mezipaměti a konečná konzistence

Aby model s doplňováním mezipaměti fungoval, musí mít instance aplikace, která mezipaměť naplňuje, přístup k nejnovější a současně konzistentní verzi dat. To však nemusí být případ systému, který implementuje konečnou konzistenci (například replikované úložiště dat).

Jedna instance může upravit datovou položku a zneplatnit její verzi uloženou v mezipaměti. Jiná instance aplikace se může pokusit o čtení této položky z mezipaměti, což vede k neúspěšnému přístupu do mezipaměti, takže data načte z úložiště dat a přidá je do mezipaměti. Pokud však úložiště dat není zcela synchronizované s ostatními replikami, mohla by instance aplikace načíst předchozí hodnotu a vložit ji do mezipaměti.

Další informace o zajištění konzistence dat najdete v článku Úvod do konzistence dat.

Ochrana dat uložených v mezipaměti

Bez ohledu na službu mezipaměti, kterou používáte, zvažte, jak data, která se nachází v mezipaměti, chránit před neoprávněným přístupem. Zásadní jsou dva aspekty:

• Utajení dat v mezipaměti.
• Utajení dat při přenosu mezi mezipamětí a aplikací, která mezipaměť využívá.

K ochraně dat v mezipaměti může služba mezipaměti implementovat mechanismus ověřování, který vyžaduje, aby aplikace určily následující údaje:

• Které identity můžou přistupovat k datům v mezipaměti.
• Které operace (čtení a zápis) smějí tyto identity provádět.

Poté, co byl identitě udělen přístup k mezipaměti pro zápis nebo čtení, může příslušná identita používat libovolná data v mezipaměti, aby se snížila režie spojená se čtením a zápisem dat.

Pokud potřebujete omezit přístup k podmnožinám dat uložených v mezipaměti, můžete provést jednu z těchto akcí:

• Rozdělit mezipaměť na oddíly (s použitím různých serverů mezipaměti) a udělit identitám přístup jen k oddílům, jejichž používání mají mít povoleno.
• Zašifrovat data v každé podmnožině s použitím různých klíčů a poskytnout šifrovací klíče jen identitám, které mají mít povolen přístup k příslušné podmnožině. Klientská aplikace může i nadále načítat všechna data uložená v mezipaměti, ale dešifrovat bude moct jen data, pro která má klíče.

Je také třeba, abyste chránili data přenášená do mezipaměti a z ní. Praktická realizace závisí na funkcích zabezpečení poskytovaných síťovou infrastrukturou, kterou klientské aplikace používají pro připojení k mezipaměti. Pokud je mezipaměť implementovaná pomocí serveru v lokalitě ve stejné organizaci, která je hostitelem klientských aplikací, pak izolace samotné sítě nemusí vyžadovat další kroky. Pokud je mezipaměť ve vzdáleném umístění a vyžaduje připojení TCP nebo HTTP přes veřejnou síť (třeba internet), zvažte implementaci zabezpečení SSL.

Důležité informace o implementaci ukládání do mezipaměti v Azure

Azure Cache for Redis je implementace služby open source Redis Cache, která běží jako služba v datacentru Azure. Poskytuje službu ukládání do mezipaměti, která je přístupná z každé aplikace Azure bez ohledu na to, jestli je příslušná aplikace implementovaná jako cloudová služba či web nebo jestli běží v rámci virtuálního počítače Azure. Mezipaměti můžou být sdílené klientskými aplikacemi, které mají příslušný přístupový klíč.

Azure Cache for Redis je vysoce výkonné řešení ukládání do mezipaměti, které poskytuje dostupnost, škálovatelnost a zabezpečení. Obvykle běží jako služba rozložená mezi jeden nebo více vyhrazených počítačů. Pokouší se ukládat do paměti co nejvíce informací, aby byl zajištěn rychlý přístup. Tato architektura je navržena tak, aby díky omezování nutnosti provádět pomalé vstupně-výstupní operace dosahovala nízkou latenci a vysokou propustnost.

Azure Cache for Redis je kompatibilní s mnoha různými rozhraními API používanými klientskými aplikacemi. Pokud máte existující aplikace, které už Azure Cache for Redis spuštěné místně, poskytuje Azure Cache for Redis rychlou cestu migrace do mezipaměti v cloudu.

Funkce Redisu

Redis není jen jednoduchý server mezipaměti. Poskytuje distribuovanou databázi v paměti s rozsáhlou sadou příkazů, která podporuje mnoho běžných scénářů. Ty jsou popsány dále v tomto dokumentu v části Použití mezipaměti Redis. Tento oddíl shrnuje některé klíčové funkce, které Redis poskytuje.

Redis jako databáze v paměti

Redis podporuje operace čtení i zápisu. V Redisu je možné zápisy chránit před selháním systému, a to buď pravidelným uložením do místního souboru snímku, nebo v souboru protokolu pouze s připojením. To není případ v mnoha mezipamětích (které by se měly považovat za přechodná úložiště dat).

Všechny zápisy jsou asynchronní a neblokují čtení a zápisy dat ze strany klienta. Když se Redis spustí, načte data ze souboru snímku nebo protokolu a použije je k vytvoření mezipaměti umístěné v paměti. Další informace najdete na stránce věnované trvalosti Redisu na webu Redis.

Datové typy Redis

Redis je úložiště dvojic klíč-hodnota, kde hodnoty mohou obsahovat jednoduché typy nebo komplexní datové struktury, například hodnoty hash, seznamy a množiny. U těchto datových typů je podporována sada atomických operací. Klíče můžou být trvalé nebo můžou mít určenou omezenou životnost, po jejímž uplynutí se klíč a jeho odpovídající hodnota automaticky odeberou z mezipaměti. Další informace o hodnotách a klíčích Redis najdete na stránce s úvodem do datových typů a abstrakcí Redis na webu Redis.

Replikace a clustering Redisu

Redis podporuje primární a podřízenou replikaci, která pomáhá zajistit dostupnost a zachovat propustnost. Operace zápisu do primárního uzlu Redis se replikují do jednoho nebo více podřízených uzlů. Operace čtení mohou být obsluhou primárními nebo libovolnými podřízenými operacemi.

V případě síťového oddílu mohou podřízené servery dál obsluhovat data a po obnovení připojení transparentně znovu synchronizovat s primárním oddílem. Další podrobnosti najdete na stránce věnované replikaci na webu Redis.

Redis také poskytuje clustering, který umožňuje transparentně rozdělit data do horizontálních oddílů mezi servery a rozložit zatížení. Tato funkce zvyšuje škálovatelnost, protože lze přidávat nové servery Redis a se zvětšováním mezipaměti se může měnit rozložení dat mezi oddíly.

Každý server v clusteru se navíc může replikovat pomocí primární/podřízené replikace. Tím se zajistí dostupnosti mezi všechny uzly v clusteru. Další informace o clusteringu a horizontálním dělení najdete na stránce s kurzem ke clusteru Redis na webu Redis.

Využití paměti Redis

Mezipaměť Redis má konečnou velikost závislou na prostředcích, které jsou k dispozici na hostitelském počítači. Při konfigurování serveru Redis můžete zadat maximální velikost paměti, kterou smí používat. Můžete také nakonfigurovat klíč v mezipaměti Redis tak, aby měl nastavený čas vypršení platnosti, po jehož uplynutí se z mezipaměti automaticky odebere. Tato funkce může pomoci bránit tomu, aby se mezipaměť umístěná v paměti zaplnila starými nebo zastaralými daty.

Když se paměť plní, Redis může automaticky vyřazovat klíče a jejich hodnoty podle mnoha zásad. Výchozí zásadou je LRU (nejdéle nepoužitá data), ale můžete vybrat i jiné zásady, například náhodné vyřazování klíčů nebo úplné vypnutí vyřazování (v takovém případě dojde při pokusu o přidání položek do mezipaměti k selhání, pokud je mezipaměť plná). Další informace najdete na stránce věnované použití Redisu jako mezipaměti se zásadou LRU (nejdéle nepoužitá data).

Transakce a dávky Redis

Redis umožňuje klientské aplikaci odeslat posloupnost operací, které čtou a zapisují data v mezipaměti, jako jednu atomickou transakci. Je zaručené sekvenční spuštění všech příkazů v transakci a nedostanou se mezi ně žádné příkazy vydané ostatními souběžně spuštěnými klienty.

Nejsou to ale skutečné transakce, protože je bude provádět relační databáze. Zpracování transakcí se skládá ze dvou fází – první spočítá v zařazení příkazů do fronty a druhá v jejich spuštění. Ve fázi zařazení příkazů do fronty jsou příkazy, které tvoří transakci, odeslány klientem. Pokud v tomto okamžiku dojde k nějaké chyby (jako je například chyba syntaxe nebo nesprávný počet parametrů), Redis odmítne zpracovat celou transakce a zahodí ji.

Ve fázi spuštění Redis provede jednotlivé příkazy z fronty v příslušném pořadí. Pokud příkaz selže v průběhu této fáze, Redis pokračuje dalším příkazem zařazeným do fronty a nevrací zpět efekty žádných příkazů, které už byly spuštěny. Ta zjednodušená forma transakcí pomáhá udržovat výkon a vyhnout se problémům s výkonem, které jsou způsobené kolizemi.

Jako pomůcku pro zachování konzistence Redis implementuje formu optimistického zamykání. Podrobné informace o transakcích a zamykání s využitím Redisu najdete na stránce věnované transakcím na webu Redis.

Redis podporuje také netransakční dávkování požadavků. Protokol Redis, který klienti používají k odesílání příkazů do serveru Redis, umožňuje klientovi umožní odeslat posloupnost operací v rámci jednoho požadavku. To napomáhá snížení fragmentace paketů v síti. Když se zpracovává dávka, provedou se všechny příkazy. Pokud některý z těchto příkazů je poškozený, zamítne se (to se u transakce nestane), ale zbývající příkazy se provedou. Není také zaručené pořadí, ve kterém se příkazy v rámci dávky zpracují.

Zabezpečení Redisu

Redis se zaměřuje výhradně na poskytování rychlého přístupu k datům a je určený ke spouštění uvnitř důvěryhodného prostředí, ke kterému mají přístup jenom důvěryhodní klienti. Redis podporuje model omezeného zabezpečení na základě ověření hesla. (Ověřování je možné úplně odebrat, ale nedoporučujeme to.)

Všichni ověření klienti sdílejí stejné globální heslo a mají přístup ke stejným prostředkům. Pokud potřebujete komplexnější zabezpečení přihlášení, musíte implementovat vlastní vrstvu zabezpečení před server Redis. Přes tuto dodatečnou vrstvu by měly procházet všechny klientské požadavky. Redis by neměl být přímo vystavený nedůvěryhodným nebo neověřeným klientům.

Přístup k příkazům můžete omezit tak, že je zakážete nebo přejmenujete (a nové názvy poskytnete jenom oprávněným klientům).

Redis přímo nepodporuje žádnou formu šifrování dat, veškeré kódování proto musí provádět klientské aplikace. Nadto Redis také neposkytuje žádný způsob zabezpečení přenosu. Pokud potřebujete chránit data při průchodu sítí, doporučujeme implementovat SSL proxy.

Další informace najdete na stránce věnované zabezpečení Redisu na webu Redis.

Azure Redis Cache

Azure Cache for Redis poskytuje přístup k serverům Redis hostovaným v datacentru Azure. Slouží jako adaptační vrstva, která poskytuje řízení přístupu a zabezpečení. Mezipaměť můžete zřídit pomocí Azure Portal.

Tento portál poskytuje řadu předdefinovaných konfigurací. Jsou nejrůznější, od 53GB mezipaměti spuštěné jako vyhrazená služba, která podporuje komunikace SSL (pro zajištění ochrany údajů) a replikaci typu hlavní/podřízený se smlouvou SLA s 99,9% dostupností, až po 250MB mezipaměť bez replikace (bez záruky dostupnosti), která je spuštěná na sdíleném hardwaru.

Pomocí webu Azure Portal můžete také nakonfigurovat zásady vyřazení mezipaměti a řídit přístupu k mezipaměti přidáváním uživatelů do zadaných rolí. Tyto role definují operace, které mohou členové provádět, včetně vlastníka, přispěvatele a čtenáře. Například členové role Vlastník mají plnou kontrolu nad mezipamětí (včetně zabezpečení) a jejím obsahem, členové role Přispěvatel mohou v mezipaměti číst a zapisovat informace a členové role Čtenář mohou z mezipaměti jenom načítat data.

Většina úkolů správy se provádí prostřednictvím webu Azure Portal. Z tohoto důvodu není k dispozici řada příkazů správy, které jsou k dispozici ve standardní verzi Redisu, včetně možnosti změnit konfiguraci prostřednictvím kódu programu, vypnout server Redis, nakonfigurovat další podřízené uzly nebo vynutit uložení dat na disk.

Web Azure Portal poskytuje praktické grafické zobrazení, které umožňuje sledovat výkon mezipaměti. Můžete například zobrazit počet vytvářených připojení, počet zpracovávaných požadavků, objem operací čtení a zápisu a počet úspěšných a neúspěšných přístupů k mezipaměti. Na základě těchto informací můžete určit efektivitu mezipaměti a v případě potřeby přepnout na jinou konfiguraci nebo změnit zásady vyřazování.

Kromě toho můžete také vytvářet upozornění, která správci odešlou e-mailovou zprávy v případě, pokud jedna nebo několik důležitých metrik spadá mimo očekávaný rozsah. Správce můžete například chtít upozornit v případě, že počet nezdařených přístupů k mezipaměti za poslední hodinu překročil zadanou hodnotu, protože to může znamenat, že mezipaměť je příliš malá nebo data se vyřazují příliš rychle.

Pro mezipaměť můžete také sledovat využití procesoru, paměti a sítě.

Další informace a příklady, které ukazují, jak vytvořit a nakonfigurovat Azure Cache for Redis, najdete na stránce Lap around Azure Cache for Redis na blogu Azure.

Uložení výstupu HTML a stavu relace do mezipaměti

Pokud při vytváření webových ASP.NET, které běží pomocí webových rolí Azure, můžete uložit informace o stavu relace a výstup HTML do Azure Cache for Redis. Zprostředkovatel stavu relace pro Azure Cache for Redis umožňuje sdílet informace o relacích mezi různými instancemi webové aplikace ASP.NET ASP.NET je velmi užitečný v situacích, kdy není k dispozici spřažení mezi klientem a serverem a ukládání dat relace do mezipaměti v paměti by nebylo vhodné.

Použití zprostředkovatele stavu relací s Azure Cache for Redis přináší několik výhod, mezi které patří:

• Sdílení stavu relace s velký počet instancí webových aplikací ASP.NET.
• Zajištění vylepšené škálovatelnosti.
• Podpora řízeného souběžného přístupu ke stejným údajům o stavu relací pro několik čtenářů a jednoho zapisovatele.
• Použití komprese k úspoře paměti a zlepšení výkonu sítě.

Další informace najdete v tématu ASP.NET stavů relací pro Azure Cache for Redis.

Podobně zprostředkovatel výstupní mezipaměti pro Azure Cache for Redis umožňuje ukládat odpovědi HTTP vygenerované webovou aplikací ASP.NET mezipaměti. Použití zprostředkovatele výstupní mezipaměti s Azure Cache for Redis může zlepšit dobu odezvy aplikací, které vykreslují komplexní výstup HTML. Instance aplikace, které generují podobné odpovědi, mohou místo generování tohoto výstupu HTML znovu použít sdílené výstupní fragmenty v mezipaměti. Další informace najdete v tématu ASP.NET výstupní mezipaměti pro Azure Cache for Redis.

Vytvoření vlastní mezipaměti Redis

Azure Cache for Redis funguje jako průčelí základních serverů Redis. Pokud potřebujete pokročilou konfiguraci, kterou Azure Redis Cache nezajišťuje (například mezipaměť větší než 53 GB), můžete sestavit a hostovat vlastní servery Redis s využitím virtuálních počítačů Azure.

Jedná se o potenciálně složitý proces, protože pokud chcete implementovat replikaci, možná budete muset vytvořit několik virtuálních počítače, které se mají chovat jako primární a podřízené uzly. Kromě toho, pokud chcete vytvořit cluster, budete potřebovat více primárních a podřízených serverů. Minimální clusterovaná replikační topologie, která poskytuje vysoký stupeň dostupnosti a škálovatelnosti, se skládá alespoň ze šesti virtuálních počítače uspořádaných jako tři páry primárních a podřízených serverů (cluster musí obsahovat alespoň tři primární uzly).

Každý pár primární/podřízený by měl být umístěný blízko sebe, aby se minimalizovala latence. Pokud chcete data v mezipaměti umístit blízko aplikací, které je s největší pravděpodobností budou používat, můžete každou sadu párů spustit v jiném datovém centru Azure umístěném v jiné oblasti. Příklad vytvoření a konfigurace uzlu Redis spuštěného jako virtuální počítač Azure najdete v tématu věnovaném spuštění Redisu na virtuálním počítači se systémem CentOS Linux v Azure.

Dělení mezipaměti Redis

Vytváření oddílů mezipaměti zahrnuje rozdělení mezipaměti mezi několik počítačů. Tato struktura poskytuje ve srovnání s použitím jednoho serveru mezipaměti několik výhod, včetně následujících:

• Vytvoření mezipaměti, která je mnohem větší, než by bylo možné uložit na jednom serveru.
• Distribuce dat mezi servery, zlepšení dostupnosti. Pokud jeden server selže nebo je nepřístupný, data, která obsahuje, jsou nedostupná, ale k datům na ostatních serverech se dá i nadále dostat. Pro mezipaměť to není zásadní, protože data uložená v mezipaměti jsou jenom přechodná kopie dat, která se nacházejí v databázi. Data uložená v mezipaměti na serveru, který přestane být přístupný, mohou být místo toho uložená v mezipaměti na jiném serveru.
• Rozložení zátěže mezi servery a následné vylepšení výkonu a škálovatelnosti.
• Geografické umístění dat blízko uživatelů, kteří k nim přistupují, a související snížení latence.

Nejběžnější metodou dělení mezipaměti je horizontální dělení (sharding). V této strategii každý oddíl (nebo horizontální oddíl) je mezipaměť Redis sama o sobě. Data se směrují do konkrétního oddílu na základě logiky horizontálního dělení, která může pro distribuci data využívat různé přístupy. Model horizontálního dělení poskytuje další informace o implementaci horizontálního dělení.

Pokud chcete implementovat vytváření oddílů v mezipaměti Redis, můžete použít jeden z následujících postupů:

• Směrování dotazů na straně serveru. Při použití této techniky klientská aplikace odešle požadavek libovolnému ze serverů Redis, které tvoří mezipaměť (pravděpodobně nejbližšímu serveru). Každý server Redis ukládá metadata popisující oddíl, který obsahuje, a také obsahuje informace o tom, které oddíly jsou umístěné na jiných serverech. Server Redis prozkoumá požadavek klienta. Pokud se dá vyřešit místně, provede požadovanou operaci. V opačném případě předá požadavek na příslušný server. Tento model je implementovaný clusteringem Redis a je podrobněji popsaný na stránce věnované kurzu ke cluster Redis na webu Redis. Clustering Redis je pro klientské aplikace transparentní. Do clusteru je možné přidat další servery Redis (a data znovu rozdělit do oddílů), aniž by bylo potřeba znovu nakonfigurovat klienty.
• Dělení na straně klienta. V tomto modelu klientská aplikace obsahuje logiku (například ve formě knihovny), která směruje požadavky na příslušný server Redis. Tento přístup je možné použít s Azure Cache for Redis. Vytvořte více Azure Cache for Redis (jeden pro každý oddíl dat) a implementujte logiku na straně klienta, která směruje požadavky do správné mezipaměti. Pokud se schéma dělení změní (například Azure Cache for Redis další soubory), může být potřeba překonfigurovat klientské aplikace.
• Dělení s asistencí proxy-. V tomto schématu klientské aplikace odesílají žádosti zprostředkující službě proxy, která ví, jak jsou data rozdělená na oddíly, a potom přesměruje požadavek na příslušný server Redis. Tento přístup lze použít také s Azure Cache for Redis. Službu proxy je možné implementovat jako cloudovou službu Azure. Tento postup vyžaduje další úroveň složitosti pro implementaci této služby a zpracování požadavků může trvat déle než při použití dělení na straně klienta.

Stránka věnovaná dělení dat mezi několik instancí Redisu na webu Redis poskytuje další informace o implementaci dělení s využitím Redisu.

Implementace klientských aplikací mezipaměti Redis

Redis podporuje klientské aplikace napsané v řadě programovacích jazyků. Pokud vytváříte nové aplikace pomocí rozhraní .NET Framework, doporučeným přístupem je použití klientské knihovny StackExchange.Redis. Tato knihovna nabízí objektový model rozhraní .NET Framework, který získává podrobnosti pro připojení k serveru Redis, odesílání příkazů a příjem odpovědí. Je dostupná v sadě Visual Studio jako balíček NuGet. Stejnou knihovnu můžete použít pro připojení k Azure Cache for Redis nebo vlastní mezipaměti Redis hostované na virtuálním počítači.

Pro připojení k serveru Redis použijete statickou metodu Connect třídy ConnectionMultiplexer. Připojení, které tato metoda vytvoří, je určené k použití v průběhu životního cyklu klientské aplikace. Stejné připojení může využívat několik souběžných vláken. Nepřipojujte se a znovu neodpojujte po každém provedení operace Redis, protože to může snížit výkon.

Můžete zadat parametry připojení, třeba adresu hostitele Redis a heslo. Pokud používáte Azure Cache for Redis, je heslo primárním nebo sekundárním klíčem, který se vygeneruje pro Azure Cache for Redis pomocí Azure Portal.

Po připojení k serveru Redis můžete získat popisovač databáze Redis, která funguje jako mezipaměť. Připojení Redis k tomuto účelu poskytuje metodu GetDatabase. Potom můžete k načítání položek z mezipaměti a ukládání dat do mezipaměti využít metody StringGet a StringSet. Tyto metody očekávají klíč jako parametr a buď vrací položku v mezipaměti, která má odpovídající hodnotu (StringGet), nebo přidají položku do mezipaměti s tímto klíčem (StringSet).

V závislosti na umístění serveru Redis může řada operací způsobit určitou latenci při přenášení požadavku na server a vracení odpovědi klientovi. Knihovna StackExchange poskytuje pro mnoho metod asynchronní verze, jejichž zpřístupněním pomáhá zajistit rychlost odezvy klientských aplikací. Tyto metody podporují asynchronní vzor založený na úlohách v .NET Framework.

Následující fragment kódu ukazuje metodu s názvem RetrieveItem. Ukazuje implementaci modelu s doplňováním mezipaměti na základě Redisu a knihovny StackExchange. Tato metoda vezme řetězcovou hodnotu klíče a pokusí se načíst příslušnou položku z mezipaměti Redis voláním metody StringGetAsync (asynchronní verze metody StringGet).

Pokud se položka nenajde, načte se z podkladového zdroje dat pomocí metody GetItemFromDataSourceAsync (tato metoda je místní a není součástí knihovny StackExchange). Potom se pomocí metody StringSetAsync přidá do mezipaměti, takže se příště dá načíst rychleji.

// Connect to the Azure Redis cache
ConfigurationOptions config = new ConfigurationOptions();
config.EndPoints.Add("<your DNS name>.redis.cache.windows.net");
config.Password = "<Redis cache key from management portal>";
ConnectionMultiplexer redisHostConnection = ConnectionMultiplexer.Connect(config);
IDatabase cache = redisHostConnection.GetDatabase();
...
private async Task<string> RetrieveItem(string itemKey)
{
    // Attempt to retrieve the item from the Redis cache
    string itemValue = await cache.StringGetAsync(itemKey);

    // If the value returned is null, the item was not found in the cache
    // So retrieve the item from the data source and add it to the cache
    if (itemValue == null)
    {
        itemValue = await GetItemFromDataSourceAsync(itemKey);
        await cache.StringSetAsync(itemKey, itemValue);
    }

    // Return the item
    return itemValue;
}

Metody StringGet a StringSet se neomezují na načítání nebo ukládání řetězcových hodnot. Mohou zpracovat libovolnou položku, která je serializovaná jako pole bajtů. Pokud je nutné uložit objekt .NET, můžete ho serializovat jako datový proud bajtů a k jeho zápisu do mezipaměti použít metodu StringSet.

Podobně můžete číst objekt z mezipaměti pomocí metody StringGet a deserializovat ho jako objekt .NET. Následující kód ukazuje sadu rozšiřujících metod pro rozhraní IDatabase (metoda GetDatabase připojení Redis vrací objekt IDatabase) a část ukázkového kódu, který používá tyto metody pro čtení a zápis objektu BlogPost do mezipaměti:

public static class RedisCacheExtensions
{
    public static async Task<T> GetAsync<T>(this IDatabase cache, string key)
    {
        return Deserialize<T>(await cache.StringGetAsync(key));
    }

    public static async Task<object> GetAsync(this IDatabase cache, string key)
    {
        return Deserialize<object>(await cache.StringGetAsync(key));
    }

    public static async Task SetAsync(this IDatabase cache, string key, object value)
    {
        await cache.StringSetAsync(key, Serialize(value));
    }

    static byte[] Serialize(object o)
    {
        byte[] objectDataAsStream = null;

        if (o != null)
        {
            BinaryFormatter binaryFormatter = new BinaryFormatter();
            using (MemoryStream memoryStream = new MemoryStream())
            {
                binaryFormatter.Serialize(memoryStream, o);
                objectDataAsStream = memoryStream.ToArray();
            }
        }

        return objectDataAsStream;
    }

    static T Deserialize<T>(byte[] stream)
    {
        T result = default(T);

        if (stream != null)
        {
            BinaryFormatter binaryFormatter = new BinaryFormatter();
            using (MemoryStream memoryStream = new MemoryStream(stream))
            {
                result = (T)binaryFormatter.Deserialize(memoryStream);
            }
        }

        return result;
    }
}

Následující kód ukazuje metodu s názvem RetrieveBlogPost, která tyto rozšiřující metody používá pro čtení a zápis serializovatelného objektu BlogPost do mezipaměti s využitím doplňování mezipaměti:

// The BlogPost type
[Serializable]
public class BlogPost
{
    private HashSet<string> tags;

    public BlogPost(int id, string title, int score, IEnumerable<string> tags)
    {
        this.Id = id;
        this.Title = title;
        this.Score = score;
        this.tags = new HashSet<string>(tags);
    }

    public int Id { get; set; }
    public string Title { get; set; }
    public int Score { get; set; }
    public ICollection<string> Tags => this.tags;
}
...
private async Task<BlogPost> RetrieveBlogPost(string blogPostKey)
{
    BlogPost blogPost = await cache.GetAsync<BlogPost>(blogPostKey);
    if (blogPost == null)
    {
        blogPost = await GetBlogPostFromDataSourceAsync(blogPostKey);
        await cache.SetAsync(blogPostKey, blogPost);
    }

    return blogPost;
}

Redis podporuje paralelní zpracování příkazů, pokud klientská aplikace odešle více asynchronní požadavků. Redis může multiplexovat požadavky pomocí stejného připojení a nemusí příkazy přijímat a reagovat na ně v pevně daném pořadí.

Tento přístup pomáhá snížit latenci, neboť zajišťuje efektivnější využití sítě. Následující fragment kódu ukazuje příklad, který načte podrobné informace o dvou zákaznících současně. Kód předá dva požadavky, provede další zpracování (není vidět) a potom čeká na příjem výsledků. Metoda Wait objektu mezipaměti je podobná metodě Task.Wait rozhraní .NET Framework:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
var task1 = cache.StringGetAsync("customer:1");
var task2 = cache.StringGetAsync("customer:2");
...
var customer1 = cache.Wait(task1);
var customer2 = cache.Wait(task2);

Další informace o psaní klientských aplikací, které mohou Azure Cache for Redis, najdete v Azure Cache for Redis dokumentaci. Další informace najdete také na StackExchange.Redis.

Stránka na stejném webu, která je věnovaná kanálům a multiplexorům, poskytuje další informace o asynchronních operacích a paralelním zpracováním využitím Redisu a knihovny StackExchange.

Použití mezipaměti Redis

Nejjednodušší použití Redisu pro ukládání do mezipaměti spočívá v párech klíč-hodnota, kde hodnota je neinterpretovaný řetězec libovolné délky, který může obsahovat libovolná binární data. (V podstatě se jedná o pole bajtů, které lze považovat za řetězec). Tento scénář jsme ukázali v části Implementace klientských aplikací mezipaměti Redis dříve v tomto článku.

Všimněte si, že klíče také obsahují neinterpretovaná data, takže jako klíč můžete použít libovolné binární informace. Čím delší ale tento klíč je, tím více místa zabere jeho uložení a tím déle budou trvat operace vyhledávání. Pro zajištění použitelnosti a snadné údržby pečlivě navrhněte prostor klíčů a používejte smysluplné (ale ne příliš dlouhé) klíče.

K reprezentaci zákazníka s ID 100 můžete například místo jednoduchého klíče „100“ použít strukturovaný klíč „customer:100“. Toto schéma umožňuje snadno rozlišit mezi hodnotami, které obsahují různé datové typy. Můžete například také použít klíč „order:100“ k reprezentaci objednávky s ID 100.

Kromě jednorozměrných binárních řetězců může pár klíč-hodnota ukládat také strukturovanější informace, včetně seznamů, sad (seřazených i neseřazených) a hodnot hash. Redis poskytuje komplexní sadu příkazů, které umožňují manipulovat s těmito typy, a řada těchto příkazů je pro aplikace .NET Framework dostupná pomocí klientských knihoven, jako je například StackExchange. Stránka s úvodem do datových typů a abstrakcí Redis na webu Redis poskytuje podrobnější přehled těchto typů a příkazů, které můžete při manipulaci s nimi využít.

Tento oddíl obsahuje přehled běžných případů použití pro tyto datové typy a příkazy.

Provádění atomických a dávkových operací

Redis podporuje pro řetězcové hodnoty řadu atomických operací typu get a set. Tyto operace zajistí, že nenastane možné soupeření o pořadí, ke kterému může dojít při použití samostatných příkazů GET a SET. Mezi dostupné operace patří:

• INCR, INCRBY, DECR, a DECRBY, které provádějí atomické operace inkrementace a dekrementace pro celočíselné datové hodnoty. Knihovna StackExchange poskytuje pro provedení těchto operací přetížené verze metod IDatabase.StringIncrementAsync a IDatabase.StringDecrementAsync a vrátí výslednou hodnotu, která je uložená v mezipaměti. Následující fragment kódu ukazuje, jak tyto metody používat:

  ConnectionMultiplexer redisHostConnection = ...;
  IDatabase cache = redisHostConnection.GetDatabase();
  ...
  await cache.StringSetAsync("data:counter", 99);
  ...
  long oldValue = await cache.StringIncrementAsync("data:counter");
  // Increment by 1 (the default)
  // oldValue should be 100
  
  long newValue = await cache.StringDecrementAsync("data:counter", 50);
  // Decrement by 50
  // newValue should be 50
  

• GETSET načte hodnotu, která je přidružená ke klíči, a změní ji na novou hodnotu. Knihovna StackExchange zpřístupňuje tuto operaci prostřednictvím metody IDatabase.StringGetSetAsync. Následující fragment kódu ukazuje příklad této metody. Tento kód vrátí aktuální hodnotu, která je přidružená ke klíči „data:counter“ z předchozího příkladu. Potom resetuje hodnotu pro tento klíč zpátky na nulu, a to všechno v rámci stejné operace:

  ConnectionMultiplexer redisHostConnection = ...;
  IDatabase cache = redisHostConnection.GetDatabase();
  ...
  string oldValue = await cache.StringGetSetAsync("data:counter", 0);
  

• MGET a MSET mohou vrátit nebo změnit sadu řetězcových hodnot jako jednu operaci. Metody IDatabase.StringGetAsync a IDatabase.StringSetAsync jsou pro podporu této funkce přetížené, jak ukazuje následující příklad:

  ConnectionMultiplexer redisHostConnection = ...;
  IDatabase cache = redisHostConnection.GetDatabase();
  ...
  // Create a list of key-value pairs
  var keysAndValues =
      new List<KeyValuePair<RedisKey, RedisValue>>()
      {
          new KeyValuePair<RedisKey, RedisValue>("data:key1", "value1"),
          new KeyValuePair<RedisKey, RedisValue>("data:key99", "value2"),
          new KeyValuePair<RedisKey, RedisValue>("data:key322", "value3")
      };
  
  // Store the list of key-value pairs in the cache
  cache.StringSet(keysAndValues.ToArray());
  ...
  // Find all values that match a list of keys
  RedisKey[] keys = { "data:key1", "data:key99", "data:key322"};
  // values should contain { "value1", "value2", "value3" }
  RedisValue[] values = cache.StringGet(keys);
  
  

Můžete také zkombinovat několik operací do jedné transakce Redis, jak je popsáno v části Transakce a dávky Redis dříve v tomto článku. Knihovna StackExchange poskytuje podporu pro transakce prostřednictvím rozhraní ITransaction.

K vytvoření objektu ITransaction použijete metodu IDatabase.CreateTransaction. K vyvolání příkazů pro transakci použijete metody, které poskytuje objekt ITransaction.

Rozhraní ITransaction poskytuje přístup k sadě metod, které jsou podobné metodám, k nimž přistupuje rozhraní IDatabase, ale s tím rozdílem, že všechny metody jsou asynchronní. To znamená, že se provádějí jenom při volání metody ITransaction.Execute. Hodnota, kterou vrátí metoda ITransaction.Execute, určuje, jestli se transakce úspěšně vytvořila (true) nebo jestli selhala (false).

Následující fragment kódu ukazuje příklad, který inkrementuje a dekrementuje dva čítače v rámci stejné transakce:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
ITransaction transaction = cache.CreateTransaction();
var tx1 = transaction.StringIncrementAsync("data:counter1");
var tx2 = transaction.StringDecrementAsync("data:counter2");
bool result = transaction.Execute();
Console.WriteLine("Transaction {0}", result ? "succeeded" : "failed");
Console.WriteLine("Result of increment: {0}", tx1.Result);
Console.WriteLine("Result of decrement: {0}", tx2.Result);

Nezapomeňte, že jsou transakce Redis jsou jiné než transakce v relačních databázích. Metoda Execute jednoduše zařadí do fronty všechny příkazy, které tvoří příslušnou transakci ke spuštění, a pokud je některý z nich poškozený, transakce se zastaví. Pokud jsou všechny příkazy úspěšně zařazené ve frontě, každý příkaz běží asynchronně.

Pokud některý příkaz selže, zpracování ostatních pokračuje i nadále. Pokud je třeba ověřit, jestli se příkaz úspěšně dokončil, musíte načíst výsledky tohoto příkazu pomocí vlastnosti Result odpovídající úlohy, jak je uvedené v předchozím příkladu. Čtení vlastnosti Result bude blokovat volající vlákno, dokud se úloha nedokončí.

Další informace najdete v tématu transakce v Redis.

Při provádění dávkových operací můžete použít rozhraní IBatch knihovny StackExchange. Toto rozhraní poskytuje přístup k sadě metod, které jsou podobné metodám, k nimž přistupuje rozhraní IDatabase, ale s tím rozdílem, že všechny metody jsou asynchronní.

Vytvoříte objekt IBatch pomocí metody IDatabase.CreateBatch a potom spustíte dávku pomocí metody IBatch.Execute, jak ukazuje následující příklad. Tento kód jednoduše nastaví řetězcovou hodnotu, inkrementuje a dekrementuje čítače použité v předchozím příkladu a zobrazí výsledky:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
IBatch batch = cache.CreateBatch();
batch.StringSetAsync("data:key1", 11);
var t1 = batch.StringIncrementAsync("data:counter1");
var t2 = batch.StringDecrementAsync("data:counter2");
batch.Execute();
Console.WriteLine("{0}", t1.Result);
Console.WriteLine("{0}", t2.Result);

Je důležité si uvědomit, že pokud příkaz v dávce selže, protože je poškozený, na rozdíl od transakce mohou další příkazy stále běžet. Metoda IBatch.Execute nevrací žádné informace o úspěchu nebo neúspěchu.

Provedení operací typu „spustit a zapomenout“

Redis podporuje operace typu „spustit a zapomenout“ pomocí příznaků příkazů. V této situaci klient jednoduše inicializuje operaci, ale nemá zájem o výsledek a nečeká na dokončení příkazu. Následující příklad ukazuje, jak provést příkaz INCR jako operaci typu „spustit a zapomenout“:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
await cache.StringSetAsync("data:key1", 99);
...
cache.StringIncrement("data:key1", flags: CommandFlags.FireAndForget);

Zadání klíčů s automatickým vypršením platnosti

Když ukládáte položky v mezipaměti Redis, můžete zadat časový limit, po kterém se položky z mezipaměti automaticky odeberou. Můžete taky zadat dotaz, kolik času klíči ještě zbývá, než vyprší jeho platnost, a to pomocí příkazu TTL. Tento příkaz pro aplikace StackExchange dostupný pomocí metody IDatabase.KeyTimeToLive.

Následující fragment kódu ukazuje, jak nastavit dobu vypršení platnosti klíče na 20 sekund a jak zadat dotaz na zbývající dobu životnosti klíče:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
// Add a key with an expiration time of 20 seconds
await cache.StringSetAsync("data:key1", 99, TimeSpan.FromSeconds(20));
...
// Query how much time a key has left to live
// If the key has already expired, the KeyTimeToLive function returns a null
TimeSpan? expiry = cache.KeyTimeToLive("data:key1");

Dobu vypršení platnosti můžete také nastavit na konkrétní datum a čas pomocí příkazu EXPIRE, který je v knihovně StackExchange k dispozici jako metoda KeyExpireAsync:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
// Add a key with an expiration date of midnight on 1st January 2015
await cache.StringSetAsync("data:key1", 99);
await cache.KeyExpireAsync("data:key1",
    new DateTime(2015, 1, 1, 0, 0, 0, DateTimeKind.Utc));
...

Použití značek ke vzájemné korelaci položek v mezipaměti

Sada Redis je kolekce několik položek, které sdílejí jeden klíč. K vytvoření sady můžete použít příkaz SADD. Položky v sadě můžete načíst pomocí příkazu SMEMBERS. Knihovna StackExchange implementuje příkaz SADD pomocí metody IDatabase.SetAddAsync a příkaz SMEMBERS pomocí metody IDatabase.SetMembersAsync.

Můžete také kombinovat existující sady a vytvořit nové sady pomocí příkazů SDIFF (rozdíl množin), SINTER (průnik) a SUNION (sjednocení). Knihovna StackExchange unifikuje tyto operace v rámci metody IDatabase.SetCombineAsync. První parametr této metody určuje, jaká množinová operace se má provést.

Následující fragmenty kódu ukazují, že sady mohou být užitečné pro rychlé ukládání a načítání kolekcí souvisejících položek. Tento kód využívá typ BlogPost, který byl popsaný v části Implementace klientských aplikací mezipaměti Redis dříve v tomto článku.

BlogPostObjekt obsahuje čtyři pole — a ID, název, skóre hodnocení a kolekci značek. První fragment kódu ukazuje ukázková data použitá k naplnění seznamu objektů BlogPost v jazyce C#:

List<string[]> tags = new List<string[]>
{
    new[] { "iot","csharp" },
    new[] { "iot","azure","csharp" },
    new[] { "csharp","git","big data" },
    new[] { "iot","git","database" },
    new[] { "database","git" },
    new[] { "csharp","database" },
    new[] { "iot" },
    new[] { "iot","database","git" },
    new[] { "azure","database","big data","git","csharp" },
    new[] { "azure" }
};

List<BlogPost> posts = new List<BlogPost>();
int blogKey = 1;
int numberOfPosts = 20;
Random random = new Random();
for (int i = 0; i < numberOfPosts; i++)
{
    blogKey++;
    posts.Add(new BlogPost(
        blogKey,                  // Blog post ID
        string.Format(CultureInfo.InvariantCulture, "Blog Post #{0}",
            blogKey),             // Blog post title
        random.Next(100, 10000),  // Ranking score
        tags[i % tags.Count]));   // Tags--assigned from a collection
                                  // in the tags list
}

Značky pro každý objekt BlogPost můžete uložit jako sadu v mezipaměti Redis a ke každé sadě přidružit ID BlogPost. To aplikaci umožňuje rychle najít všechny značky, které patří ke konkrétnímu blogovému příspěvku. Pokud chcete povolit vyhledávání v opačném směru a najít všechny blogové příspěvky, které sdílejí konkrétní značku, můžete vytvořit jinou sadu, která obsahuje blogové příspěvky odkazující na příslušné ID značky v klíči:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
// Tags are easily represented as Redis Sets
foreach (BlogPost post in posts)
{
    string redisKey = string.Format(CultureInfo.InvariantCulture,
        "blog:posts:{0}:tags", post.Id);
    // Add tags to the blog post in Redis
    await cache.SetAddAsync(
        redisKey, post.Tags.Select(s => (RedisValue)s).ToArray());

    // Now do the inverse so we can figure out which blog posts have a given tag
    foreach (var tag in post.Tags)
    {
        await cache.SetAddAsync(string.Format(CultureInfo.InvariantCulture,
            "tag:{0}:blog:posts", tag), post.Id);
    }
}

Tyto struktury umožňují velmi efektivně provádět řadu běžných dotazů. Tímto způsobem můžete například najít a zobrazit všechny značky pro blogový příspěvek 1:

// Show the tags for blog post #1
foreach (var value in await cache.SetMembersAsync("blog:posts:1:tags"))
{
    Console.WriteLine(value);
}

Všechny značky, které jsou společné pro blogový příspěvek 1 a blogový příspěvek 2, můžete najít tak, že následujícím způsobem provedete operaci průniku:

// Show the tags in common for blog posts #1 and #2
foreach (var value in await cache.SetCombineAsync(SetOperation.Intersect, new RedisKey[]
    { "blog:posts:1:tags", "blog:posts:2:tags" }))
{
    Console.WriteLine(value);
}

A můžete také najít všechny blogové příspěvky, které obsahují konkrétní značku:

// Show the ids of the blog posts that have the tag "iot".
foreach (var value in await cache.SetMembersAsync("tag:iot:blog:posts"))
{
    Console.WriteLine(value);
}

Vyhledání nedávno použitých položek

Běžnou úlohou řady aplikací je vyhledání naposledy použitých položek. Například blogovací web může chtít zobrazit informace o naposledy přečtených příspěvcích.

Tuto funkci můžete implementovat pomocí seznamu Redis. Seznam Redis obsahuje několik položek, které sdílejí stejný klíč. Tento seznam funguje jako fronta se dvěma konci. Na oba konce tohoto seznamu můžete vkládat položky pomocí příkazů LPUSH (vložení vpravo) a RPUSH (vložení vlevo). Položky můžete z obou konců seznamu načítat pomocí příkazů LPOP a RPOP. Pomocí příkazů LRANGE a RRANGE můžete také vrátit sadu elementů.

Uvedené fragmenty kódu ukazují, jak se tyto operace dají provést pomocí knihovny StackExchange. Tento kód používá typ BlogPost z předchozích příkladů. Když čtenář čte blogový příspěvek, metoda IDatabase.ListLeftPushAsync vloží název tohoto příspěvku do seznamu, který je přidružený ke klíči „blog:recent_posts“ v mezipaměti Redis.

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
string redisKey = "blog:recent_posts";
BlogPost blogPost = ...; // Reference to the blog post that has just been read
await cache.ListLeftPushAsync(
    redisKey, blogPost.Title); // Push the blog post onto the list

Jak se čtou další blogové příspěvky, jejich názvy se vkládají do stejného seznamu. Tento seznam je uspořádaný v pořadí, ve kterém byly přidány jednotlivé názvy. Poslední blogové příspěvky najdete na levém konci seznamu. (Pokud je blogový příspěvek přečtený několikrát, bude mít v tomto seznamu několik položek.)

Názvy naposledy přečtených příspěvků můžete zobrazit pomocí metody IDatabase.ListRange. Tato metoda používá klíč, který obsahuje příslušný seznam, a počáteční a koncový bod. Následující kód načte názvy 10 blogových příspěvků (položky od 0 do 9) na levém konci seznamu:

// Show latest ten posts
foreach (string postTitle in await cache.ListRangeAsync(redisKey, 0, 9))
{
    Console.WriteLine(postTitle);
}

Všimněte si, že metoda ListRangeAsync neodebírá položky ze seznamu. K tomuto účelu můžete použít metody IDatabase.ListLeftPopAsync a IDatabase.ListRightPopAsync.

Abyste zabránili tomu, že tento seznam bude narůstat donekonečna, můžete položky pravidelně probírat ořezáváním tohoto seznamu. Následující fragment kódu ukazuje, jak odebrat všechny položky ze seznamu až na posledních pět položek nejvíce vlevo:

await cache.ListTrimAsync(redisKey, 0, 5);

Implementace tabulky výsledků

Ve výchozím nastavení se položky v sadě neuchovávají v žádném konkrétním pořadí. Seřazené sady můžete vytvořit pomocí příkazu ZADD (metoda IDatabase.SortedSetAdd v knihovně StackExchange). Položky jsou uspořádané pomocí číselné hodnoty nazvané skóre, která se poskytuje jako parametr tohoto příkazu.

Následující fragment kódu přidá název blogového příspěvku do uspořádaného seznamu. V tomto příkladu má každý blogový příspěvek také pole skóre, které obsahuje pozici tohoto blogového příspěvku.

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
string redisKey = "blog:post_rankings";
BlogPost blogPost = ...; // Reference to a blog post that has just been rated
await cache.SortedSetAddAsync(redisKey, blogPost.Title, blogPost.Score);

Názvy a skóre blogových příspěvků můžete načíst ve vzestupném pořadí pomocí metody IDatabase.SortedSetRangeByRankWithScores:

foreach (var post in await cache.SortedSetRangeByRankWithScoresAsync(redisKey))
{
    Console.WriteLine(post);
}

Položky můžete také načíst podle skóre v sestupném pořadí a omezit počet vrácených položek tím, že metodě IDatabase.SortedSetRangeByRankWithScoresAsync poskytnete další parametry. Následující příklad zobrazuje názvy a skóre 10 nejlépe hodnocených blogových příspěvků:

foreach (var post in await cache.SortedSetRangeByRankWithScoresAsync(
                               redisKey, 0, 9, Order.Descending))
{
    Console.WriteLine(post);
}

Následující příklad používá metodu IDatabase.SortedSetRangeByScoreWithScoresAsync, pomocí které můžete omezit vracené položky jenom na ty, které spadají do určeného rozsahu skóre:

// Blog posts with scores between 5000 and 100000
foreach (var post in await cache.SortedSetRangeByScoreWithScoresAsync(
                               redisKey, 5000, 100000))
{
    Console.WriteLine(post);
}

Zpráva s využitím kanálů

Server Redis kromě toho, že funguje jako mezipaměť dat, poskytuje také zasílání zpráv prostřednictvím vysoce výkonného mechanismu vydavatel/odběratel. Klientské aplikace se mohou přihlásit k odběru kanálu, do kterého mohou publikovat zprávy jiné aplikace nebo služby. Aplikace přihlášené k odběru potom obdrží tyto zprávy a mohou je zpracovávat.

Redis poskytuje pro klientské aplikace příkaz SUBSCRIBE, který umožňuje přihlásit se k odběru kanálů. Tento příkaz očekává název jednoho nebo několika kanálů, ze kterých bude aplikace přijímat zprávy. Knihovna StackExchange zahrnuje rozhraní ISubscription, které aplikaci rozhraní .NET Framework umožňuje přihlásit se k odběru kanálů a publikovat do nich.

Pomocí metody GetSubscriber připojení k serveru Redis vytvoříte objekt ISubscription. Potom můžete pomocí metody SubscribeAsync tohoto objektu naslouchat zprávám v kanálu. Následující příklad kódu ukazuje, jak se přihlásit k odběru kanálu s názvem „messages: blogPosts“:

ConnectionMultiplexer redisHostConnection = ...;
ISubscriber subscriber = redisHostConnection.GetSubscriber();
...
await subscriber.SubscribeAsync("messages:blogPosts", (channel, message) => Console.WriteLine("Title is: {0}", message));

Prvním parametrem metody Subscribe je název kanálu. Pro kanály se používají stejné konvence pojmenování jako pro klíče v mezipaměti. Název může obsahovat libovolná binární data, ale doporučuje se používat poměrně krátké a smysluplné řetězce, aby se zajistil výkon a udržovatelnost na odpovídající úrovni.

Všimněte si také, že je obor názvů, který používají kanály, je oddělený od oboru názvů, který používají klíče. To znamená, že můžete mít kanály a klíče, které mají stejný název, i když to může představovat obtížnější údržbu kódu aplikace.

Druhým parametrem je delegát akce. Tento delegát se spustí asynchronně vždy, když na kanálu se objeví nová zpráva. Tento příklad jednoduše zobrazí zprávu na konzole (zpráva bude obsahovat název blogového příspěvku).

K publikování do kanálu může aplikace v Redisu využít příkaz PUBLISH. Knihovna StackExchange poskytuje k provedení této operace metodu IServer.PublishAsync. Další fragment kódu ukazuje, jak publikovat zprávu do kanálu „messages:blogPosts“:

ConnectionMultiplexer redisHostConnection = ...;
ISubscriber subscriber = redisHostConnection.GetSubscriber();
...
BlogPost blogPost = ...;
subscriber.PublishAsync("messages:blogPosts", blogPost.Title);

Existuje několik věcí, které byste o mechanismu publikování/odebírání měli vědět:

• K odběru jednoho kanálu se může přihlásit několik odběratelů a ti všichni dostanou zprávy publikované do tohoto kanálu.
• Odběratelé dostanou jenom zprávy publikované potom, co se k odběru přihlásili. Kanály nevyužívají vyrovnávací paměť. Infrastruktura Redis zprávu po publikování předá jednotlivým odběratelům a potom ji odstraní.
• Ve výchozím nastavení odběratelé dostávají zprávy v pořadí, ve kterém byly odeslány. Ve vysoce aktivním systému s velkým počtem zpráv a mnoha odběrateli a vydavateli může garantované sekvenční doručování zpráv snížit výkon systému. Pokud jsou jednotlivé zprávy nezávislé a jejich pořadí není důležité, můžete systému Redis povolit souběžné zpracování a zlepšit tak rychlost odezvy. Provede to tak, že v klientovi StackExchange nastavíte vlastnost PreserveAsyncOrder připojení použitého odběratelem na hodnotu false:

ConnectionMultiplexer redisHostConnection = ...;
redisHostConnection.PreserveAsyncOrder = false;
ISubscriber subscriber = redisHostConnection.GetSubscriber();

Aspekty serializace

Při volbě formátu serializace zvažte kompromis mezi výkonem, interoperabilitou, správou verzí, kompatibilitou s existujícími systémy, kompresí dat a režijními náklady na paměť. Při hodnocení výkonu mějte na paměti, že srovnávací testy jsou vysoce závislé na kontextu. Nemusejí odpovídat skutečným úlohám a brát v úvahu novější knihovny nebo verze. Nic takového jako „nejrychlejší“ serializátor pro všechny scénáře neexistuje.

Měli byste zvážit mimo jiné tyto možnosti:

• Protocol Buffers (také označovaný jako protobuf) je serializační formát vyvinutý Googlem pro efektivní serializaci strukturovaných dat. K definování struktur zpráv používá definiční soubory silného typu. Z těchto definičních souborů se potom zkompiluje kód pro serializaci a deserializaci zpráv pro konkrétní jazyk. Protobuf je možné využít přes stávající mechanismy RPC nebo může vygenerovat službu RPC.

• Apache Thrift používá podobný přístup – definiční soubory silného typu a kompilační krok pro vygenerování serializačního kódu a služeb RPC.

• Apache Avro poskytuje podobné funkce jako Protocol Buffers a Thrift, ale bez kompilačního kroku. Místo toho serializovaná data vždycky obsahují schéma, které popisuje strukturu.

• JSON je otevřený standard, který používá uživatelsky čitelná textová pole. Nabízí širokou podporu pro různé platformy. JSON nevyužívá schémata zpráv. Vzhledem k tomu, že tento formát je založený na textu, není velmi efektivní při přenosu. V některých případech ale můžete vracet položky v mezipaměti přímo do klienta prostřednictvím protokolu HTTP a v takovém případě ukládání ve formátu JSON může snížit náklady na deserializaci z jiného formátu a následnou serializaci do formátu JSON.

• BSON je binární serializační formát, který používá strukturou podobnou JSON. Formát BSON je navržený tak, aby byl jednoduchý a umožňoval snadné procházení a rychlou serializaci a deserializaci (ve srovnání s formátem JSON). Velikost datových částí je srovnatelná s formátem JSON. V závislosti na datech může být datová část BSON menší nebo větší než datová část JSON. BSON má některé další datové typy, které nejsou ve formátu JSON k dispozici, zejména typy BinData (pro pole bajtů) a Date.

• MessagePack je binární serializační formát, který je navržený pro kompaktní přenos linkou. Nevyužívá žádná schémata zpráv ani kontrolu typu zpráv.

• Bond je architektura pro práci se schematizovanými daty pro různé platformy. Podporuje serializaci a deserializaci napříč jazyky. Významný rozdíl oproti ostatním systémům spočívá v podpoře dědičnosti, aliasů typů a obecných typů.

• gRPC je open source systém RPC vyvinutý Googlem. Jako svůj definiční jazyk a základní formát pro výměnu zpráv ve výchozím nastavení používá Protocol Buffers.

Související modely a pokyny

Při implementaci ukládání do mezipaměti v aplikacích můžou být pro váš scénář relevantní také následující vzory:

• Model s doplňováním mezipaměti: Tento model popisuje načítání dat na vyžádání do mezipaměti z úložiště dat. Tento model také pomáhá zachovat konzistenci mezi daty uloženými v mezipaměti a daty v původním úložišti dat.

• Model horizontálního dělení poskytuje informace o implementaci horizontálního dělení, které pomáhá vylepšit škálovatelnost při ukládání a využívání velkých objemů dat.

Další informace

• Azure Cache for Redis dokumentace
• Nejčastější dotazy ke službě Azure Cache for Redis
• Asynchronní vzor založený na úlohě
• Dokumentace k Redisu
• StackExchange.Redis
• Průvodce dělením dat