CachelagringCaching

Cachelagring är en vanlig teknik för att förbättra prestanda och skalbarhet i system.Caching is a common technique that aims to improve the performance and scalability of a system. Data som används ofta kopieras till snabb lagring som ligger nära programmet.It does this by temporarily copying frequently accessed data to fast storage that's located close to the application. Om den snabba datalagringen ligger närmare än originalkällan kan cachelagring förbättra svarstiden för klientprogram betydligt. Det går helt enkelt att komma åt data snabbare.If this fast data storage is located closer to the application than the original source, then caching can significantly improve response times for client applications by serving data more quickly.

Cachelagring är allra mest effektivt när en klientinstans läser samma data upprepade gånger, och i synnerhet om samtliga av följande punkter gäller för det ursprungliga datalagret:Caching is most effective when a client instance repeatedly reads the same data, especially if all the following conditions apply to the original data store:

  • det förblir relativt statisktIt remains relatively static.
  • det är långsamt jämfört med cacheminnetIt's slow compared to the speed of the cache.
  • det har hög konkurrensnivåIt's subject to a high level of contention.
  • det är avlägset och nätverksfördröjning kan orsaka långsam åtkomst.It's far away when network latency can cause access to be slow.

Cachelagring i distribuerade programCaching in distributed applications

För distribuerade program används vanligtvis en eller båda av följande strategier när data cachelagras:Distributed applications typically implement either or both of the following strategies when caching data:

  • En privat cache används. Data lagras lokalt på den dator som kör instansen av programmet eller tjänsten.Using a private cache, where data is held locally on the computer that's running an instance of an application or service.
  • Använda en delad cache som fungerar som en gemensam källa som kan nås av flera processer och datorer.Using a shared cache, serving as a common source that can be accessed by multiple processes and machines.

I båda fallen kan cachelagring utföras på klient sidan och på Server sidan.In both cases, caching can be performed client-side and server-side. Cachelagring på klientsidan sker via processen som tillhandahåller användargränssnittet för ett system. Det kan vara en webbläsare eller ett skrivbordsprogram (lokalt program).Client-side caching is done by the process that provides the user interface for a system, such as a web browser or desktop application. Cachelagring på serversidan sker via processen som tillhandahåller företagstjänsterna av fjärrtyp.Server-side caching is done by the process that provides the business services that are running remotely.

Privat cachelagringPrivate caching

Den enklaste typen av cachelagring är minnesintern lagring.The most basic type of cache is an in-memory store. Den ligger i adressutrymmet i en enskild process och koms åt direkt av den kod som körs i processen.It's held in the address space of a single process and accessed directly by the code that runs in that process. Den här typen av cache är snabb åtkomst.This type of cache is quick to access. Det kan också vara ett effektivt sätt att lagra små mängder statiska data, eftersom storleken på ett cacheminne vanligt vis är begränsad av mängden minne som är tillgängligt på den dator som är värd för processen.It can also provide an effective means for storing modest amounts of static data, since the size of a cache is typically constrained by the amount of memory available on the machine hosting the process.

Om du behöver lagra mer i cachen än vad som är fysiskt möjligt i minnet kan du skriva cachelagrade data till det lokala filsystemet.If you need to cache more information than is physically possible in memory, you can write cached data to the local file system. Detta kommer att vara långsammare för att komma åt data som lagras i minnet, men det bör fortfarande vara snabbare och mer tillförlitligt än att hämta data i ett nätverk.This will be slower to access than data held in memory, but should still be faster and more reliable than retrieving data across a network.

Om flera instanser av ett program som använder den här modellen körs samtidigt har varje programinstans sin egen oberoende cache med en egen datakopia.If you have multiple instances of an application that uses this model running concurrently, each application instance has its own independent cache holding its own copy of the data.

Du kan tänka på cachedata som en ögonblicksbild av den ursprungliga informationen vid en tidigare tidpunkt.Think of a cache as a snapshot of the original data at some point in the past. Om dessa data inte är statiska är det troligt att olika programinstanser har olika versioner av samma data i sin cache.If this data is not static, it is likely that different application instances hold different versions of the data in their caches. Det innebär att en fråga som utförs av dessa instanser kan returnera olika resultat. Se bild 1.Therefore, the same query performed by these instances can return different results, as shown in Figure 1.

Använda en minnesintern cache i olika instanser av ett program

Bild 1: använda en minnes intern cache i olika instanser av ett program.Figure 1: Using an in-memory cache in different instances of an application.

Delad cachelagringShared caching

Med en delad cache undviker du att data skiljer sig mellan olika cacheminnen, vilket kan hända vid minnesintern, privat, cachelagring.Using a shared cache can help alleviate concerns that data might differ in each cache, which can occur with in-memory caching. Delad cachelagring säkerställer att olika programinstanser ser samma vy av cachelagrade data.Shared caching ensures that different application instances see the same view of cached data. Det sker genom att cacheminnet läggs på en separat plats, vanligtvis som del i en separat tjänst. Se bild 2.It does this by locating the cache in a separate location, typically hosted as part of a separate service, as shown in Figure 2.

Använda en delad cache

Bild 2: använda en delad cache.Figure 2: Using a shared cache.

En viktig fördel med delad cachelagring är skalbarheten.An important benefit of the shared caching approach is the scalability it provides. Många delade cache-tjänster implementeras med hjälp av ett kluster med servrar och använder program vara för att distribuera data över klustret transparent.Many shared cache services are implemented by using a cluster of servers and use software to distribute the data across the cluster transparently. En programinstans skickar helt enkelt en begäran till cachetjänsten.An application instance simply sends a request to the cache service. Den underliggande infrastrukturen fastställer platsen för cachelagrade data i klustret.The underlying infrastructure determines the location of the cached data in the cluster. Det är enkelt att utöka cachen genom att lägga till servrar.You can easily scale the cache by adding more servers.

Det finns två huvudsakliga nackdelarna med delad cachelagring:There are two main disadvantages of the shared caching approach:

  • Det tar längre tid att komma åt cachen eftersom den inte lagrar lokalt för varje programinstans.The cache is slower to access because it is no longer held locally to each application instance.
  • Kravet på en separat cachetjänst kan göra lösningen mer komplex.The requirement to implement a separate cache service might add complexity to the solution.

Överväganden kring cachelagringConsiderations for using caching

I följande avsnitt beskriver vi i detalj vad du ska tänka på när du skapar och använder cachelagring.The following sections describe in more detail the considerations for designing and using a cache.

När ska du cachelagra dataDecide when to cache data

Cachelagring kan kraftigt förbättra prestanda, skalbarhet och tillgänglighet.Caching can dramatically improve performance, scalability, and availability. Ju mer data du har och ju större antal användare som behöver åtkomst till dem, desto större blir fördelarna med cachelagring.The more data that you have and the larger the number of users that need to access this data, the greater the benefits of caching become. Det beror på att latensen och konkurrensen vid cachelagring är lägre än när stora volymer samtidiga begäranden hanteras i det ursprungliga datalagret.That's because caching reduces the latency and contention that's associated with handling large volumes of concurrent requests in the original data store.

En databas kanske bara klarar ett begränsat antal samtidiga anslutningar.For example, a database might support a limited number of concurrent connections. Om data hämtas från en delad cache, i stället för den underliggande databasen, kommer klientprogram åt dessa data även om inga tillgängliga anslutningar finns.Retrieving data from a shared cache, however, rather than the underlying database, makes it possible for a client application to access this data even if the number of available connections is currently exhausted. Om själva databasen blir otillgänglig går det dessutom eventuellt att fortsätta att använda cachade data.Additionally, if the database becomes unavailable, client applications might be able to continue by using the data that's held in the cache.

Överväg att cachelagra data som läses ofta men ändras sällan (till exempel data som har en högre andel läsåtgärder än skrivåtgärder).Consider caching data that is read frequently but modified infrequently (for example, data that has a higher proportion of read operations than write operations). Vi rekommenderar däremot inte att du använder cachen som huvudsaklig förvaring av viktig information.However, we don't recommend that you use the cache as the authoritative store of critical information. Se till att alla ändringar som programmet inte har råd att förlora i stället alltid sparas i ett lager för beständiga data.Instead, ensure that all changes that your application cannot afford to lose are always saved to a persistent data store. Om cachen inte är tillgänglig fungerar program fortfarande med hjälp av datalagret och du förlorar ingen viktig information.This means that if the cache is unavailable, your application can still continue to operate by using the data store, and you won't lose important information.

Cachelagra data på ett effektivt sättDetermine how to cache data effectively

Nyckeln till effektiv cachelagring ligger i att fastställa vilka data som är lämpligast att lagra i cachen och att cachelagra vid rätt tidpunkt.The key to using a cache effectively lies in determining the most appropriate data to cache, and caching it at the appropriate time. Data kan läggas till i cacheminnet på begäran första gången den hämtas av ett program.The data can be added to the cache on demand the first time it is retrieved by an application. Det innebär att programmet endast måste hämta data från datalagret en gång. Efterföljande åtkomst genomförs med hjälp av cachen.This means that the application needs to fetch the data only once from the data store, and that subsequent access can be satisfied by using the cache.

Cachelagringen kan annars helt eller delvis fyllas med data i förväg, vanligtvis när programmet startas. Den här metoden kallas seeding.Alternatively, a cache can be partially or fully populated with data in advance, typically when the application starts (an approach known as seeding). Seeding är eventuellt inte lämpligt för stora cacheminnen. Metoden kan innebära en plötslig, hög belastning på den ursprungliga datalagringen när programmet börjar köras.However, it might not be advisable to implement seeding for a large cache because this approach can impose a sudden, high load on the original data store when the application starts running.

Ofta kan en analys av användningsmönster hjälpa dig att besluta om en cache ska förkonfigureras, helt eller delvis, och vilka data som ska cachelagras.Often an analysis of usage patterns can help you decide whether to fully or partially prepopulate a cache, and to choose the data to cache. Det vara till exempel vara praktiskt att seeda cacheminnet med statiska användarprofildata för dem som kanske använder programmet varje dag, men inte för dem som använder programmet bara en gång i veckan.For example, it can be useful to seed the cache with the static user profile data for customers who use the application regularly (perhaps every day), but not for customers who use the application only once a week.

Cachelagring fungerar vanligtvis väl med data som inte kan ändras eller som ändras sällan.Caching typically works well with data that is immutable or that changes infrequently. Det kan till exempel vara referensinformation, som produkt- och prisinformation i ett e-handelsprogram, eller delade statiska resurser som är dyra att konstruera.Examples include reference information such as product and pricing information in an e-commerce application, or shared static resources that are costly to construct. Vissa eller alla dessa data kan läsas in i cacheminnet när programmet startas, för minimerad resursanvändning och bättre prestanda.Some or all of this data can be loaded into the cache at application startup to minimize demand on resources and to improve performance. Det kan också vara lämpligt att ha en bakgrunds process som regelbundet uppdaterar referens data i cacheminnet för att säkerställa att den är uppdaterad eller uppdaterar cachen när referens data ändras.It might also be appropriate to have a background process that periodically updates reference data in the cache to ensure it is up-to-date, or that refreshes the cache when reference data changes.

Cachelagring är mindre användbart för dynamiska data, även om det finns vissa undantag. Läs mer i avsnittet Cachelagra dynamiska data nedan.Caching is less useful for dynamic data, although there are some exceptions to this consideration (see the section Cache highly dynamic data later in this article for more information). När ursprungliga data ändras regelbundet blir den cachelagrade informationen snabbt föråldrad. Arbetet med att synkronisera cachen med den ursprungliga datalagringen gör cachen mindre effektiv.When the original data changes regularly, either the cached information becomes stale very quickly or the overhead of synchronizing the cache with the original data store reduces the effectiveness of caching.

Observera att en cache inte behöver omfatta fullständiga data för en entitet.Note that a cache does not have to include the complete data for an entity. Du kanske har ett dataobjekt med flera värden, till exempel en bankkund med namn, adress och saldo. Här kan vissa element vara statiska, till exempel namn och adress, och andra mer dynamiska, till exempel kontosaldo.For example, if a data item represents a multivalued object such as a bank customer with a name, address, and account balance, some of these elements might remain static (such as the name and address), while others (such as the account balance) might be more dynamic. I sådana fall är det praktiskt att cachelagra statiska delar och bara hämta, eller beräkna, den återstående informationen vid behov.In these situations, it can be useful to cache the static portions of the data and retrieve (or calculate) only the remaining information when it is required.

Vi rekommenderar att du utför prestanda testning och användnings analys för att avgöra om förväntad inläsning av cacheminnet eller en kombination av båda är lämpligt.We recommend that you carry out performance testing and usage analysis to determine whether prepopulating or on-demand loading of the cache, or a combination of both, is appropriate. Beslutet bör baseras på hur ofta data ändras och användningsmönstret.The decision should be based on the volatility and usage pattern of the data. Användning av cache-och prestanda analys är särskilt viktigt i program som drabbar tung belastning och måste vara mycket skalbara.Cache utilization and performance analysis are particularly important in applications that encounter heavy loads and must be highly scalable. Det kan till exempel vara klokt att seeda cachen om du vill minska belastningen på datalagret vid högbelastningstider i mycket skalbara scenarier.For example, in highly scalable scenarios it might make sense to seed the cache to reduce the load on the data store at peak times.

Cacheminnen kan också användas för att undvika att upprepa beräkningar medan programmet körs.Caching can also be used to avoid repeating computations while the application is running. Om en åtgärd omvandlar data eller utför en komplicerad beräkning kan resultatet av åtgärden sparas i cacheminnet.If an operation transforms data or performs a complicated calculation, it can save the results of the operation in the cache. Om samma beräkning krävs igen kan programmet hämta resultatet från cacheminnet.If the same calculation is required afterward, the application can simply retrieve the results from the cache.

Ett program kan ändra data som lagras i ett cacheminne.An application can modify data that's held in a cache. Vi rekommenderar dock att du tänker på cacheminnet som ett tillfälligt datalager som kan försvinna när som helst.However, we recommend thinking of the cache as a transient data store that could disappear at any time. Lagra inte känsliga data i cacheminnet. Se till att du underhåller informationen även i den ursprungliga datalagringen.Do not store valuable data in the cache only; make sure that you maintain the information in the original data store as well. Då minimerar du risken för att förlora data om cacheminnet blir otillgänglig.This means that if the cache becomes unavailable, you minimize the chance of losing data.

Cachelagra dynamiska dataCache highly dynamic data

När du lagrar snabb ändring av information i ett beständigt data lager kan det medföra att systemet är i gång.When you store rapidly changing information in a persistent data store, it can impose an overhead on the system. Ta till exempel en enhet som kontinuerligt rapporterar status eller andra mått.For example, consider a device that continually reports status or some other measurement. Om ett program väljer att inte cachelagra dessa data eftersom den cachelagrade informationen hela tiden blir inaktuell så kan detsamma gälla när dessa data lagras och hämtas från datalagret.If an application chooses not to cache this data on the basis that the cached information will nearly always be outdated, then the same consideration could be true when storing and retrieving this information from the data store. Under den tid det tar att spara och hämta dessa data kan de ha ändrats.In the time it takes to save and fetch this data, it might have changed.

Överväg här att lagra den dynamiska informationen direkt i cachen i stället för i lagret för beständiga data.In a situation such as this, consider the benefits of storing the dynamic information directly in the cache instead of in the persistent data store. Om data är icke-kritiska och inte kräver granskning spelar det ingen roll om den tillfälliga ändringen förloras.If the data is noncritical and does not require auditing, then it doesn't matter if the occasional change is lost.

Hantera förfallotid i cacheminnenManage data expiration in a cache

I de flesta fall är data i ett cacheminne en kopia av data som finns i det ursprungliga datalagret.In most cases, data that's held in a cache is a copy of data that's held in the original data store. Data i det ursprungliga datalagret kan ha ändrats efter cachelagringen, vilket innebär att dessa cachelagrade data blir inaktuella.The data in the original data store might change after it was cached, causing the cached data to become stale. I många system går det att konfigurera cachen så att data löper ut. Det minskar den tid under vilken data kan vara inaktuella.Many caching systems enable you to configure the cache to expire data and reduce the period for which data may be out of date.

När cachelagrade data förfaller, tas de bort från cachen och programmet måste hämta data från det ursprungliga data lagret (det kan placera den nyligen hämtade informationen i cachen igen).When cached data expires, it's removed from the cache, and the application must retrieve the data from the original data store (it can put the newly fetched information back into cache). Du kan ange en princip för hur data ska löpa ut när du konfigurerar cachen.You can set a default expiration policy when you configure the cache. I många cachetjänster kan du fastställa utgångsperioden för enskilda objekt via programmering i cacheminnet när du lagrar dem.In many cache services, you can also stipulate the expiration period for individual objects when you store them programmatically in the cache. I vissa cacheminnen kan du ange förfalloperioden som ett absolut värde. Den kan också vara ett glidande värde som innebär att objektet tas bort om det inte efterfrågas inom en angiven tid.Some caches enable you to specify the expiration period as an absolute value, or as a sliding value that causes the item to be removed from the cache if it is not accessed within the specified time. Den här inställningen åsidosätter eventuella principer som gäller för hela cachen, men endast för angivna objekt.This setting overrides any cache-wide expiration policy, but only for the specified objects.

Anteckning

Överväg noggrant utgångstiden för cachen och objekten i den.Consider the expiration period for the cache and the objects that it contains carefully. Om du gör den för kort upphör objekten att gälla för snabbt, och då minskar du fördelarna med cachen.If you make it too short, objects will expire too quickly and you will reduce the benefits of using the cache. Om du gör perioden för lång riskerar data att bli inaktuella.If you make the period too long, you risk the data becoming stale.

Det är också möjligt att cacheminnet blir fullt om data ligger kvar för länge.It's also possible that the cache might fill up if data is allowed to remain resident for a long time. I det fallet kan ett begärande om att lägga till nya objekt i cacheminnet orsaka att andra objekt tvingas bort i en process som kallas avlägsning.In this case, any requests to add new items to the cache might cause some items to be forcibly removed in a process known as eviction. Cachetjänster avlägsnar typiskt sett data enligt principen tidigast använd (LRU), men du kan vanligtvis åsidosätta den här principen och förhindra att objekt tas bort.Cache services typically evict data on a least-recently-used (LRU) basis, but you can usually override this policy and prevent items from being evicted. Om du gör det riskerar du att överskrida utrymmet i cacheminnet.However, if you adopt this approach, you risk exceeding the memory that's available in the cache. Det betyder att försök att lägga till objekt i cacheminnet misslyckas med ett undantag.An application that attempts to add an item to the cache will fail with an exception.

I vissa cachelagringsimplementeringar finns ytterligare avlägsningsprinciper.Some caching implementations might provide additional eviction policies. Det finns flera typer av avlägsningsprinciper.There are several types of eviction policies. Dessa omfattar:These include:

  • senast använda (när använda data inte förväntas behövas igen)A most-recently-used policy (in the expectation that the data will not be required again).
  • först in först ut (när äldsta data avlägsnas först)A first-in-first-out policy (oldest data is evicted first).
  • händelseutlöst avlägsningsprincip (till exempel att data ändras).An explicit removal policy based on a triggered event (such as the data being modified).

Ogiltigförklara data i klientbaserat cacheminneInvalidate data in a client-side cache

Data som lagras i ett cacheminne på klientsidan anses vanligtvis ligga utanför ramen för den tjänst som tillhandahåller data till klienten.Data that's held in a client-side cache is generally considered to be outside the auspices of the service that provides the data to the client. En tjänst kan inte direkt tvinga en klient att lägga till och ta bort information från klientcachen.A service cannot directly force a client to add or remove information from a client-side cache.

Det innebär att det är möjligt för en klient som använder ett felaktigt konfigurerat cacheminne att fortsätta använda gammal information.This means that it's possible for a client that uses a poorly configured cache to continue using outdated information. Om exempelvis principer för förfallodatum inte implementeras kan en klient använda gammal information som cachelagrats lokalt, även om informationen i den ursprungliga datakällan har ändrats.For example, if the expiration policies of the cache aren't properly implemented, a client might use outdated information that's cached locally when the information in the original data source has changed.

Om du skapar ett webbprogram som skickar data via en HTTP-anslutning kan du därigenom tvinga en webbklient (till exempel en webbläsare eller en webbproxy) att hämta den senaste informationen.If you are building a web application that serves data over an HTTP connection, you can implicitly force a web client (such as a browser or web proxy) to fetch the most recent information. Det här kan du göra om en resurs uppdateras av en ändring i URI:t för den resursen.You can do this if a resource is updated by a change in the URI of that resource. Webbklienter använder vanligtvis URI:t för en resurs som nyckel i klientcacheminnet. Om URI:t ändras ignorerar webbklienten eventuella tidigare cachelagrade versioner av en resurs och hämtar den nya versionen i stället.Web clients typically use the URI of a resource as the key in the client-side cache, so if the URI changes, the web client ignores any previously cached versions of a resource and fetches the new version instead.

Hantera samtidighet i cacheminnenManaging concurrency in a cache

Cacheminnen är ofta utformade för att delas av flera programinstanser.Caches are often designed to be shared by multiple instances of an application. Varje programinstans kan läsa och ändra data i cacheminnet.Each application instance can read and modify data in the cache. Det innebär samma samtidighetsproblem i cacheminnen som i andra delade datalager.Consequently, the same concurrency issues that arise with any shared data store also apply to a cache. Om ett program behöver ändra data som finns i cacheminnet kan du behöva se till att uppdateringar som görs via en programinstans inte skriver över ändringar som görs via en annan instans.In a situation where an application needs to modify data that's held in the cache, you might need to ensure that updates made by one instance of the application do not overwrite the changes made by another instance.

Beroende på datatypen och sannolikheten för kollisioner finns två metoder för samtidighet:Depending on the nature of the data and the likelihood of collisions, you can adopt one of two approaches to concurrency:

  • Optimistiskt.Optimistic. Precis innan data uppdateras kontrollerar programmet om data i cacheminnet har ändrats sedan de hämtades.Immediately prior to updating the data, the application checks to see whether the data in the cache has changed since it was retrieved. Om alla data är desamma kan ändringen göras.If the data is still the same, the change can be made. Programmet måste annars bestämma om de ska uppdateras.Otherwise, the application has to decide whether to update it. (Affärs logiken som driver det här beslutet är programspecifik.) Den här metoden är lämplig för situationer där uppdateringar är ovanliga eller där kollisioner är osannolika.(The business logic that drives this decision will be application-specific.) This approach is suitable for situations where updates are infrequent, or where collisions are unlikely to occur.
  • Pessimistiskt.Pessimistic. När data hämtas låser programmet in dem i cacheminnet för att förhindra att någon annan instans ändrar dem.When it retrieves the data, the application locks it in the cache to prevent another instance from changing it. Med den här processen undviker du kollisioner, men den kan också blockera andra instanser som behöver bearbeta samma data.This process ensures that collisions cannot occur, but they can also block other instances that need to process the same data. Pessimistisk samtidighet kan påverka skalbarheten i lösningar och rekommenderas endast för tillfälligt bruk.Pessimistic concurrency can affect the scalability of a solution and is recommended only for short-lived operations. Den här metoden kan vara lämplig i situationer där kollisioner är sannolika. Det kan i synnerhet vara om ett program uppdaterar flera objekt i cacheminnet och måste se till att ändringarna tillämpas konsekvent.This approach might be appropriate for situations where collisions are more likely, especially if an application updates multiple items in the cache and must ensure that these changes are applied consistently.

Implementera hög tillgänglighet och skalbarhet och förbättra prestandaImplement high availability and scalability, and improve performance

Undvik att använda ett cacheminne som primärt datalager. Den rollen har det ursprungliga datalagret, varifrån cacheminnet fylls.Avoid using a cache as the primary repository of data; this is the role of the original data store from which the cache is populated. Det ursprungliga datalagret är din garanti för att det finns data.The original data store is responsible for ensuring the persistence of the data.

Var noga med att inte införa kritiska beroenden, som kräver att en delad cachetjänst är tillgänglig, i lösningar.Be careful not to introduce critical dependencies on the availability of a shared cache service into your solutions. Ett program bör fortsätta att fungera även om tjänsten som tillhandahåller den delade cachen inte är tillgängligt.An application should be able to continue functioning if the service that provides the shared cache is unavailable. Programmet får inte svara eller sluta fungera under väntan på att cache tjänsten ska återupptas.The application should not become unresponsive or fail while waiting for the cache service to resume.

Du måste därför se till att programmet kan identifiera tillgängligheten för cachetjänsten och återgå till det ursprungliga datalagret om den inte är tillgänglig.Therefore, the application must be prepared to detect the availability of the cache service and fall back to the original data store if the cache is inaccessible. Circuit-Breaker-mönstret (kretsbrytare) är användbart för att hantera det här scenariot.The Circuit-Breaker pattern is useful for handling this scenario. Den tjänst som tillhandahåller cacheminnet kan återskapas. När den blir tillgänglig kan cacheminnet fyllas igen när data läses in från det ursprungliga datalagret, efter en strategi som Cache aside-mönstret (cache åsidosatt).The service that provides the cache can be recovered, and once it becomes available, the cache can be repopulated as data is read from the original data store, following a strategy such as the Cache-aside pattern.

Systemets skalbarhet kan dock påverkas om programmet återgår till det ursprungliga data lagret när cachen är tillfälligt otillgänglig.However, system scalability may be affected if the application falls back to the original data store when the cache is temporarily unavailable. Medan datalagret återställs kan det ursprungliga datalagret översköljas med databegäranden, vilket resulterar i uppnådda tidsgränser och misslyckade anslutningar.While the data store is being recovered, the original data store could be swamped with requests for data, resulting in timeouts and failed connections.

Överväg att implementera en lokal, privat cache i varje instans av ett program, tillsammans med den delade cachen som alla programinstanser har åtkomst till.Consider implementing a local, private cache in each instance of an application, together with the shared cache that all application instances access. När programmet hämtar ett objekt kan det först söka i det lokala cacheminnet, därefter i det delade cacheminnet och slutligen i det ursprungliga datalagret.When the application retrieves an item, it can check first in its local cache, then in the shared cache, and finally in the original data store. Det lokala cacheminnet kan fyllas med data från det delade. Om det inte är tillgängligt fylls det via databasen.The local cache can be populated using the data in either the shared cache, or in the database if the shared cache is unavailable.

Den här metoden kräver noggrann konfigurering för att förhindra att den lokala cachen blir inaktuell jämfört med det delade cacheminnet.This approach requires careful configuration to prevent the local cache from becoming too stale with respect to the shared cache. Den lokala cachen fungerar dock som buffert om den delade cachen inte kan nås.However, the local cache acts as a buffer if the shared cache is unreachable. Bild 3 visar den här strukturen.Figure 3 shows this structure.

Använda en lokal privat cache med en delad cache

Bild 3: använda en lokal privat cache med en delad cache.Figure 3: Using a local private cache with a shared cache.

I vissa cachetjänster finns ett alternativ för hög tillgänglighet med automatisk redundans om cachen inte är tillgänglig. Det här syftar till att stödja stora cacheminnen som innehåller relativt långlivade data.To support large caches that hold relatively long-lived data, some cache services provide a high-availability option that implements automatic failover if the cache becomes unavailable. Det innebär vanligtvis att data som lagras på en primär cacheserver replikeras till en sekundär cacheserver. Om ett fel uppstår på den primära servern eller om anslutningen bryts växlar systemet till den sekundära servern.This approach typically involves replicating the cached data that's stored on a primary cache server to a secondary cache server, and switching to the secondary server if the primary server fails or connectivity is lost.

För att undvika fördröjning kopplad till skrivning till flera mål kan replikeringen till den sekundära servern ske asynkront när data skrivs till cachen på den primära servern.To reduce the latency that's associated with writing to multiple destinations, the replication to the secondary server might occur asynchronously when data is written to the cache on the primary server. Den här metoden innebär att viss cachelagrad information kan gå förlorad vid fel, men andelen bör vara liten jämfört med den totala storleken på cacheminnet.This approach leads to the possibility that some cached information might be lost in the event of a failure, but the proportion of this data should be small compared to the overall size of the cache.

Om en delad cache är stor kan det vara bra att partitionera lagrade data mellan noder. Det här gör du för att minska risken för konkurrens och förbättra skalbarheten.If a shared cache is large, it might be beneficial to partition the cached data across nodes to reduce the chances of contention and improve scalability. I många delade cacheminnen kan du dynamiskt lägga till och ta bort noder och balansera om data över partitioner.Many shared caches support the ability to dynamically add (and remove) nodes and rebalance the data across partitions. Den här metoden kan omfatta klustring. Uppsättningen noder presenteras då för klientprogram som en enda sammanhängande cache.This approach might involve clustering, in which the collection of nodes is presented to client applications as a seamless, single cache. Internt sprids dock data mellan noder enligt en fördefinierad distributionsstrategi som fördelar belastningen jämnt.Internally, however, the data is dispersed between nodes following a predefined distribution strategy that balances the load evenly. Mer information om möjliga partitionerings strategier finns i rikt linjer för data partitionering.For more information about possible partitioning strategies, see Data partitioning guidance.

Klustring kan också öka tillgängligheten för cachen.Clustering can also increase the availability of the cache. Om en nod inte fungerar är resten av cachen fortfarande tillgänglig.If a node fails, the remainder of the cache is still accessible. Klustring används ofta tillsammans med replikering och redundans.Clustering is frequently used in conjunction with replication and failover. Varje nod kan replikeras och repliken kan snabbt tas i bruk om en nod misslyckas.Each node can be replicated, and the replica can be quickly brought online if the node fails.

Många läs- och skrivåtgärder omfattar sannolikt enkla datavärden och objekt.Many read and write operations are likely to involve single data values or objects. Ibland är det dock nödvändigt att lagra och hämta stora mängder data snabbt.However, at times it might be necessary to store or retrieve large volumes of data quickly. Att seeda ett cacheminne kan till exempel innebära att skriva hundratals eller tusentals objekt till cachen.For example, seeding a cache could involve writing hundreds or thousands of items to the cache. Ett program kan också behöva hämta ett stort antal relaterade objekt från cacheminnet, kopplat till samma begäran.An application might also need to retrieve a large number of related items from the cache as part of the same request.

Många stora cacheminnen har batchåtgärder för dessa ändamål.Many large-scale caches provide batch operations for these purposes. Det innebär att klientprogram kan packa ihop stora mängder objekt i en enskild begäran. Det går då att undvika nackdelar kopplade till att utföra ett stort antal små begäranden.This enables a client application to package up a large volume of items into a single request and reduces the overhead that's associated with performing a large number of small requests.

Cachelagring och slutlig konsekvensCaching and eventual consistency

För att cache-aside-mönstret ska fungera måste den programinstans som fyller cacheminnet ha åtkomst till den senaste och konsekventa dataversionen.For the cache-aside pattern to work, the instance of the application that populates the cache must have access to the most recent and consistent version of the data. I ett system som implementerar slutlig konsekvens (till exempel en replikerad databas) är det inte säkert att så är fallet.In a system that implements eventual consistency (such as a replicated data store) this might not be the case.

En instans av ett program kan ändra ett dataobjekt och ogiltigförklara den cachelagrade versionen av objektet.One instance of an application could modify a data item and invalidate the cached version of that item. En annan instans av programmet kan försöka läsa objektet från ett cacheminne, vilket orsakar en cachemiss. Data läses istället från datalagret och läggs till i cacheminnet.Another instance of the application might attempt to read this item from a cache, which causes a cache-miss, so it reads the data from the data store and adds it to the cache. Om datalagret inte har synkroniserats helt med andra repliker kan programinstansen dock läsa och fylla i cachen med det gamla värdet.However, if the data store has not been fully synchronized with the other replicas, the application instance could read and populate the cache with the old value.

Mer information om hur du hanterar datakonsekvens finns i introduktionen till datakonsekvens.For more information about handling data consistency, see the Data consistency primer.

Skydda cachelagrade dataProtect cached data

Oavsett cachetjänst bör du överväga att skydda de data som lagras i cacheminnet från obehörig åtkomst.Irrespective of the cache service you use, consider how to protect the data that's held in the cache from unauthorized access. Det finns två huvudsakliga frågeställningar:There are two main concerns:

  • sekretessen för data i cacheminnetThe privacy of the data in the cache.
  • säkerheten för de data som flödar mellan cacheminnet och det program som använder det.The privacy of data as it flows between the cache and the application that's using the cache.

För att skydda data i cacheminnet kan cachetjänsten använda en autentiseringsfunktion som kräver att programmet anger följande:To protect data in the cache, the cache service might implement an authentication mechanism that requires that applications specify the following:

  • vilka identiteter som kan komma åt data i cacheminnetWhich identities can access data in the cache.
  • vilka åtgärder (läsa, skriva) som dessa identiteter ska kunna utföra.Which operations (read and write) that these identities are allowed to perform.

För att minska effekterna kopplade till att läsa och skriva data kan en identitet använda alla data som finns i cachen när identiteten har beviljats skriv- eller läsbehörighet.To reduce overhead that's associated with reading and writing data, after an identity has been granted write and/or read access to the cache, that identity can use any data in the cache.

Om du vill begränsa åtkomsten till undergrupper av cachelagrade data kan du göra något av följande:If you need to restrict access to subsets of the cached data, you can do one of the following:

  • Dela cacheminnet i partitioner (genom att använda olika cacheservrar) och bevilja endast åtkomst till partitioner som identiteten i fråga ska kunna använda.Split the cache into partitions (by using different cache servers) and only grant access to identities for the partitions that they should be allowed to use.
  • Kryptera data i varje undergrupp med olika nycklar. Tillhandahåll endast krypteringsnycklar till de identiteter som ska ha åtkomst till varje undergrupp.Encrypt the data in each subset by using different keys, and provide the encryption keys only to identities that should have access to each subset. Eventuellt kan ett klientprogram fortfarande hämta alla data i cacheminnet, men det kan bara dekryptera data som det har nycklarna till.A client application might still be able to retrieve all of the data in the cache, but it will only be able to decrypt the data for which it has the keys.

Du måste också skydda informationen när den förs vidare till och från cacheminnet.You must also protect the data as it flows in and out of the cache. Det gör du med hjälp av säkerhetsfunktionerna i nätverksinfrastrukturen som klientprogram använder för att ansluta till cacheminnet.To do this, you depend on the security features provided by the network infrastructure that client applications use to connect to the cache. Om cachen implementeras med hjälp av en lokal server i samma organisation som är värd för klient programmen, kanske isoleringen av själva nätverket inte kräver ytterligare åtgärder.If the cache is implemented using an on-site server within the same organization that hosts the client applications, then the isolation of the network itself might not require you to take additional steps. Om cachen är fjärrplacerad och kräver en TCP- eller HTTP-anslutning via ett offentligt nätverk (till exempel internet) rekommenderar vi du överväger SSL.If the cache is located remotely and requires a TCP or HTTP connection over a public network (such as the Internet), consider implementing SSL.

Att tänka på vid implementering av cachelagring i AzureConsiderations for implementing caching in Azure

Azure cache för Redis är en implementering av Redis-cachen med öppen källkod som körs som en tjänst i ett Azure-datacenter.Azure Cache for Redis is an implementation of the open source Redis cache that runs as a service in an Azure datacenter. Det ger en cachelagringstjänst som kan nås från alla Azure-program, oavsett om programmet har implementerats som molntjänst, webbplats eller i en virtuell Azure-dator.It provides a caching service that can be accessed from any Azure application, whether the application is implemented as a cloud service, a website, or inside an Azure virtual machine. Cacheminnen kan delas av klientprogram som har rätt åtkomstnyckel.Caches can be shared by client applications that have the appropriate access key.

Azure cache för Redis är en lösning för cachelagring med hög prestanda som ger tillgänglighet, skalbarhet och säkerhet.Azure Cache for Redis is a high-performance caching solution that provides availability, scalability and security. Den körs vanligtvis som tjänst, fördelad på en eller flera dedikerade datorer.It typically runs as a service spread across one or more dedicated machines. Den försöker lagra så mycket data som möjligt minnesinternt, för att säkerställa snabb åtkomst.It attempts to store as much information as it can in memory to ensure fast access. Den här arkitekturen är avsedd att ge låg latens och hög genomströmning genom att minska behovet av långsamma I/O-åtgärder.This architecture is intended to provide low latency and high throughput by reducing the need to perform slow I/O operations.

Azure cache för Redis är kompatibelt med många av de olika API: er som används av klient program.Azure Cache for Redis is compatible with many of the various APIs that are used by client applications. Om du har befintliga program som redan använder Azure cache för Redis som körs lokalt ger Azure-cachen för Redis en snabb migrerings väg för cachelagring i molnet.If you have existing applications that already use Azure Cache for Redis running on-premises, the Azure Cache for Redis provides a quick migration path to caching in the cloud.

Funktioner i RedisFeatures of Redis

Redis är mer än en enkel cacheserver.Redis is more than a simple cache server. Det är en distribuerad minnesintern databas med en omfattande kommandouppsättning som stöder många vanliga scenarier.It provides a distributed in-memory database with an extensive command set that supports many common scenarios. Dessa beskrivs senare i det här dokumentet, i avsnittet Använda Redis-cachelagring.These are described later in this document, in the section Using Redis caching. I det här avsnittet sammanfattas några av de viktigaste funktionerna i Redis.This section summarizes some of the key features that Redis provides.

Redis som minnesintern databasRedis as an in-memory database

Redis stöder både läs- och skrivåtgärder.Redis supports both read and write operations. I Redis kan skrivningar skyddas från systemfel, antingen genom att regelbundet lagras i en lokal ögonblicks bild fil eller i en logg fil för tillägg.In Redis, writes can be protected from system failure either by being stored periodically in a local snapshot file or in an append-only log file. Detta är inte fallet i många cacheminnen (som bör betraktas som transit data lager).This is not the case in many caches (which should be considered transitory data stores).

Alla skrivåtgärder är asynkrona och blockerar inte klienter från att läsa och skriva data.All writes are asynchronous and do not block clients from reading and writing data. När Redis startar läses data från ögonblicksbilden eller loggfilen in och används till att skapa den minnesinterna cachen.When Redis starts running, it reads the data from the snapshot or log file and uses it to construct the in-memory cache. Mer information finns i dokumentationen ombeständighet i Redis på Redis webbplats.For more information, see Redis persistence on the Redis website.

Anteckning

Redis garanterar inte att alla skrivåtgärder sparas i händelse av ett oåterkalleligt fel, men du förlorar som mest några sekunders data.Redis does not guarantee that all writes will be saved in the event of a catastrophic failure, but at worst you might lose only a few seconds worth of data. Kom ihåg att cacheminnen inte är avsedda att fungera som auktoritativa datakällor. Det är det program som använder cachen som ansvarar för att säkerställa att viktiga data har sparats i ett lämpligt dataarkiv.Remember that a cache is not intended to act as an authoritative data source, and it is the responsibility of the applications using the cache to ensure that critical data is saved successfully to an appropriate data store. Mer information finns i cache-undan mönster.For more information, see the Cache-aside pattern.

Redis-datatyperRedis data types

Redis är ett nyckelvärdeslager där värden kan innehålla enkla typer eller komplexa datastrukturer som hashvärden, listor och uppsättningar.Redis is a key-value store, where values can contain simple types or complex data structures such as hashes, lists, and sets. Det stöder en uppsättning atomiska operationer för dessa datatyper.It supports a set of atomic operations on these data types. Nycklar kan vara permanenta. De kan också taggas med en begränsad utgångstid. Nyckeln och dess motsvarande värde tas då automatiskt bort från cachen.Keys can be permanent or tagged with a limited time-to-live, at which point the key and its corresponding value are automatically removed from the cache. Mer information om Redis nycklar och värden finns i presentationen av datatyper och abstraktioner i Redis på Redis webbplats.For more information about Redis keys and values, visit the page An introduction to Redis data types and abstractions on the Redis website.

Redis-replikering och klustringRedis replication and clustering

Redis stöder primär/underordnad replikering för att säkerställa tillgängligheten och upprätthålla data flödet.Redis supports primary/subordinate replication to help ensure availability and maintain throughput. Skriv åtgärder till en Redis primär nod replikeras till en eller flera underordnade noder.Write operations to a Redis primary node are replicated to one or more subordinate nodes. Läs åtgärder kan hanteras av den primära eller någon av de underordnade.Read operations can be served by the primary or any of the subordinates.

I händelse av en nätverks partition kan underordnade servrar fortsätta att betjäna data och sedan transparent omsynkroniseras transparent med den primära när anslutningen återupprättas.In the event of a network partition, subordinates can continue to serve data and then transparently resynchronize with the primary when the connection is reestablished. Mer information finns på sidan om replikering på Redis webbplats.For further details, visit the Replication page on the Redis website.

Redis tillhandahåller också klustring, som gör att du transparent kan partitionera data i Shards över servrar och sprida belastningen.Redis also provides clustering, which enables you to transparently partition data into shards across servers and spread the load. Funktionen ger bättre skalbarhet. Nya Redis-servrar kan läggas till och data partitioneras om allt eftersom cacheminnet växer.This feature improves scalability, because new Redis servers can be added and the data repartitioned as the size of the cache increases.

Dessutom kan varje server i klustret replikeras med hjälp av primär/underordnad replikering.Furthermore, each server in the cluster can be replicated by using primary/subordinate replication. Det säkerställer tillgänglighet för varje nod i klustret.This ensures availability across each node in the cluster. Mer information om kluster och horisontell partitionering finns i Redis-kursen om kluster på Redis webbplats.For more information about clustering and sharding, visit the Redis cluster tutorial page on the Redis website.

Minnesanvändning i RedisRedis memory use

Ett Redis-cacheminne har en begränsad storlek som beror på vilka resurser som finns på värddatorn.A Redis cache has a finite size that depends on the resources available on the host computer. När du konfigurerar Redis-servern anger du den maximala mängden minne som kan användas.When you configure a Redis server, you can specify the maximum amount of memory it can use. Du kan också ge nycklar i Redis-cacheminnen en förfallotid, efter vilken de automatiskt avlägsnas från cachen.You can also configure a key in a Redis cache to have an expiration time, after which it is automatically removed from the cache. Via den här funktionen kan du förhindra att cachen fylls med gamla och inaktuella data.This feature can help prevent the in-memory cache from filling with old or stale data.

När minnet fylls kan Redis automatiskt avlägsna nycklar och deras värden genom att följa ett antal principer.As memory fills up, Redis can automatically evict keys and their values by following a number of policies. Standardprincipen är tidigast använd (LRU). Du kan också välja andra principer, exempelvis att avlägsna nycklar slumpmässigt eller att helt stänga av avlägsning. I det senare nämnda fallet går det inte att lägga till fler objekt i cachen när den är full.The default is LRU (least recently used), but you can also select other policies such as evicting keys at random or turning off eviction altogether (in which, case attempts to add items to the cache fail if it is full). Mer information finns på sidan om att använda Redis som LRU-cache.The page Using Redis as an LRU cache provides more information.

Redis-transaktioner och -batcharRedis transactions and batches

Med Redis kan klientprogram skicka ett antal åtgärder som läs- och skrivdata i cacheminnet som en atomisk transaktion.Redis enables a client application to submit a series of operations that read and write data in the cache as an atomic transaction. Alla kommandon i transaktionen körs garanterat sekventiellt. Inga kommandon som utfärdas av andra samtidiga klienter vävs in mellan dem.All the commands in the transaction are guaranteed to run sequentially, and no commands issued by other concurrent clients will be interwoven between them.

Dessa är dock inte sanna transaktioner som en relationsdatabas skulle utför dem.However, these are not true transactions as a relational database would perform them. Transaktionsbearbetning består av två faser: den första inträffar när kommandon ställs i kö och den andra när dessa kommandon körs.Transaction processing consists of two stages--the first is when the commands are queued, and the second is when the commands are run. Under fasen när kommandon ställs i kö skickas de kommandon som ingår i transaktionen in av klienten.During the command queuing stage, the commands that comprise the transaction are submitted by the client. Om ett fel inträffar nu (till exempel ett syntaxfel eller fel antal parametrar) vägrar Redis sedan att bearbeta hela transaktionen och tar bort den.If some sort of error occurs at this point (such as a syntax error, or the wrong number of parameters) then Redis refuses to process the entire transaction and discards it.

Under körningsfasen utför Redis varje köat kommando i följd.During the run phase, Redis performs each queued command in sequence. Om ett kommando misslyckas under den här fasen fortsätter Redis med nästa köade kommando och återställer inte effekten av alla eventuella kommandon som redan har körts.If a command fails during this phase, Redis continues with the next queued command and does not roll back the effects of any commands that have already been run. Den här förenklade transaktionsformen hjälper till att undvika prestandaproblem orsakade av konkurrens.This simplified form of transaction helps to maintain performance and avoid performance problems that are caused by contention.

Redis implementerar en form av optimistisk låsning för att göra det enklare att upprätthålla konsekvens.Redis does implement a form of optimistic locking to assist in maintaining consistency. Du hittar mer information om transaktioner och låsningar i Redis på sidan om transaktioner på Redis-webbplatsen.For detailed information about transactions and locking with Redis, visit the Transactions page on the Redis website.

Redis stöder även transaktionell batchbearbetning av begär Anden.Redis also supports nontransactional batching of requests. Redis-protokollet som klienter använder för att skicka kommandon till en Redis-server gör att klienter kan skicka serier med åtgärder i samma begäran.The Redis protocol that clients use to send commands to a Redis server enables a client to send a series of operations as part of the same request. Det här kan minska fragmenteringen av paket i nätverket.This can help to reduce packet fragmentation on the network. När batchen bearbetas utförs varje kommando.When the batch is processed, each command is performed. Om något av dessa kommandon är felaktigt utformat avvisas det. (Det händer inte med en transaktion). Resterande kommandon utförs.If any of these commands are malformed, they will be rejected (which doesn't happen with a transaction), but the remaining commands will be performed. Det finns inga garantier om i vilken ordning de kommandon som ingår i batchen bearbetas.There is also no guarantee about the order in which the commands in the batch will be processed.

Redis-säkerhetRedis security

Redis fokuserar enbart på att ge snabb åtkomst till data. Systemet är avsett att köras i en betrodd miljö som endast kan användas av betrodda klienter.Redis is focused purely on providing fast access to data, and is designed to run inside a trusted environment that can be accessed only by trusted clients. I Redis finns funktioner för en begränsad säkerhetsmodell baserad på lösenordsautentisering.Redis supports a limited security model based on password authentication. (Det går att ta bort autentisering helt, men vi rekommenderar det inte.)(It is possible to remove authentication completely, although we don't recommend this.)

Alla autentiserade klienter delar samma globala lösenord och har åtkomst till samma resurser.All authenticated clients share the same global password and have access to the same resources. Om du behöver mer omfattande inloggningssäkerhet måste du implementera ett eget säkerhetsskikt framför Redis-servern. Alla begäranden från klienter behöver sedan passera detta ytterligare lager.If you need more comprehensive sign-in security, you must implement your own security layer in front of the Redis server, and all client requests should pass through this additional layer. Redis bör inte exponeras direkt för ej betrodda eller oautentiserade klienter.Redis should not be directly exposed to untrusted or unauthenticated clients.

Du kan begränsa åtkomsten till kommandon genom att inaktivera dem eller byta namn på dem. Ge endast de nya namnen till privilegierade klienter.You can restrict access to commands by disabling them or renaming them (and by providing only privileged clients with the new names).

Redis stöder inte någon form av datakryptering, så all kodning måste utföras av klientprogram.Redis does not directly support any form of data encryption, so all encoding must be performed by client applications. Redis erbjuder inte heller någon form av transportsäkerhet.Additionally, Redis does not provide any form of transport security. Om du behöver skydda data i nätverket rekommenderar vi en SSL-proxy.If you need to protect data as it flows across the network, we recommend implementing an SSL proxy.

Mer information finns på sidan om säkerhet i Redis på Redis webbplats.For more information, visit the Redis security page on the Redis website.

Anteckning

Azure cache för Redis tillhandahåller ett eget säkerhets lager som klienterna ansluter till.Azure Cache for Redis provides its own security layer through which clients connect. De underliggande Redis-servrarna exponeras inte för det offentliga nätverket.The underlying Redis servers are not exposed to the public network.

Azure Redis CacheAzure Redis cache

Azure cache för Redis ger åtkomst till Redis-servrar som finns i ett Azure-datacenter.Azure Cache for Redis provides access to Redis servers that are hosted at an Azure datacenter. Systemet fungerar som en fasad som ger åtkomstkontroll och säkerhet.It acts as a façade that provides access control and security. Du kan etablera ett cacheminne med hjälp av Azure Portal.You can provision a cache by using the Azure portal.

Portalen tillhandahåller ett antal fördefinierade konfigurationer.The portal provides a number of predefined configurations. Det högsta är ett cacheminne på 53 GB som körs som dedikerad tjänst med funktioner för SSL-kommunikation (för sekretess) och huvudreplikering och underordnad replikering med ett SLA på 99,9 % tillgänglighet. Det lägsta är ett cacheminne på 250 MB utan replikering (inga tillgänglighetsgarantier) som körs på delad maskinvara.These range from a 53 GB cache running as a dedicated service that supports SSL communications (for privacy) and master/subordinate replication with an SLA of 99.9% availability, down to a 250 MB cache without replication (no availability guarantees) running on shared hardware.

Med Azure-portalen kan du också konfigurera avlägsningsprincipen för cachen och styra åtkomsten genom att lägga till användare till de roller som tillhandahålls.Using the Azure portal, you can also configure the eviction policy of the cache, and control access to the cache by adding users to the roles provided. De här rollerna, som definierar vilka åtgärder som medlemmar kan utföra, inkluderar ägare, deltagare och läsare.These roles, which define the operations that members can perform, include Owner, Contributor, and Reader. Medlemmar med rollen Owner (ägare) har fullständig kontroll över cacheminnet, inklusive säkerhet, och dess innehåll. Medlemmar med rollen Contributor (deltagare) kan läsa och skriva information i cacheminnet. Medlemmar med rollen Reader (läsare) kan bara hämta data från cacheminnet.For example, members of the Owner role have complete control over the cache (including security) and its contents, members of the Contributor role can read and write information in the cache, and members of the Reader role can only retrieve data from the cache.

De flesta administrativa uppgifter utförs via Azure-portalen.Most administrative tasks are performed through the Azure portal. Många administrativa kommandon som är tillgängliga i standardversionen av Redis är därför inte tillgängliga. Det här omfattar att ändra konfigurationen programmässigt, stänga Redis-servern, konfigurera ytterligare underordnade servrar och tvinga spara data till disk.For this reason, many of the administrative commands that are available in the standard version of Redis are not available, including the ability to modify the configuration programmatically, shut down the Redis server, configure additional subordinates, or forcibly save data to disk.

Azure-portalen har ett praktiskt grafiskt gränssnitt där du kan övervaka prestanda för cacheminnet.The Azure portal includes a convenient graphical display that enables you to monitor the performance of the cache. Du kan till exempelvis visa antalet anslutningar som görs, antalet begäranden som utförs, mängden läs- och skrivåtgärder och antalet cacheträffar jämfört med cachemissar.For example, you can view the number of connections being made, the number of requests being performed, the volume of reads and writes, and the number of cache hits versus cache misses. Med den här informationen kan du avgöra effektiviteten i cacheminnet. Vid behov kan du växla till en annan konfiguration eller ändra avlägsningsprincipen.Using this information, you can determine the effectiveness of the cache and if necessary, switch to a different configuration or change the eviction policy.

Du kan dessutom skapa aviseringar som skickar e-postmeddelanden till en administratör om ett eller flera kritiska mått faller utanför ett förväntat intervall.Additionally, you can create alerts that send email messages to an administrator if one or more critical metrics fall outside of an expected range. Du kanske vill varna en administratör om antalet cachemissar överskrider ett angivet värde under den senaste timmen, eftersom det innebär att cacheminnet kanske är för litet eller att data avlägsnas för snabbt.For example, you might want to alert an administrator if the number of cache misses exceeds a specified value in the last hour, because it means the cache might be too small or data might be being evicted too quickly.

Du kan också övervaka CPU, minne och nätverksanvändning för cacheminnet.You can also monitor the CPU, memory, and network usage for the cache.

Mer information och exempel som visar hur du skapar och konfigurerar en Azure-cache för Redis finns på sidan om Azure-cache för Redis på Azure-bloggen.For further information and examples showing how to create and configure an Azure Cache for Redis, visit the page Lap around Azure Cache for Redis on the Azure blog.

Sessionstillstånd för cachelagring och HTML-utdataCaching session state and HTML output

Om du skapar ASP.NET-webbappar som körs med hjälp av Azure Web roles kan du spara information om sessionstillstånd och HTML-utdata i ett Azure-cacheminne för Redis.If you're building ASP.NET web applications that run by using Azure web roles, you can save session state information and HTML output in an Azure Cache for Redis. Providern för sessionstillstånd för Azure cache för Redis gör att du kan dela sessionsinformation mellan olika instanser av ett ASP.NET-webbprogram och är mycket användbart i webb server grupps situationer där klient server tillhörighet inte är tillgänglig och cachelagring av sessionens data i minnet inte är lämpligt.The session state provider for Azure Cache for Redis enables you to share session information between different instances of an ASP.NET web application, and is very useful in web farm situations where client-server affinity is not available and caching session data in-memory would not be appropriate.

Att använda providern för sessionstillstånd med Azure cache för Redis ger flera fördelar, inklusive:Using the session state provider with Azure Cache for Redis delivers several benefits, including:

  • delade sessionstillstånd med ett stort antal instanser av ASP.NET-webbapparSharing session state with a large number of instances of ASP.NET web applications.
  • förbättrad skalbarhetProviding improved scalability.
  • funktioner för kontrollerad, samtidig åtkomst till samma sessionstillståndsdata för flera läsare och en enda skrivareSupporting controlled, concurrent access to the same session state data for multiple readers and a single writer.
  • komprimering för att spara minne och förbättra nätverkets prestanda.Using compression to save memory and improve network performance.

Mer information finns i ASP.net för session State för Azure cache för Redis.For more information, see ASP.NET session state provider for Azure Cache for Redis.

Anteckning

Använd inte providern för sessionstillstånd för Azure cache för Redis med ASP.NET-program som körs utanför Azure-miljön.Do not use the session state provider for Azure Cache for Redis with ASP.NET applications that run outside of the Azure environment. Latensen för att komma åt cachen utanför Azure kan utesluta prestandafördelarna med cachelagring av data.The latency of accessing the cache from outside of Azure can eliminate the performance benefits of caching data.

På samma sätt kan du använda providern för utgående cache för Azure cache för Redis för att spara de HTTP-svar som genereras av ett ASP.NET-webbprogram.Similarly, the output cache provider for Azure Cache for Redis enables you to save the HTTP responses generated by an ASP.NET web application. Att använda providern för utgående cache med Azure cache för Redis kan förbättra svars tiderna för program som återger komplexa HTML-utdata.Using the output cache provider with Azure Cache for Redis can improve the response times of applications that render complex HTML output. Program instanser som genererar liknande svar kan använda delade fragment i cacheminnet i stället för att generera den här HTML-afresh.Application instances that generate similar responses can use the shared output fragments in the cache rather than generating this HTML output afresh. Mer information finns i ASP.net output cache Provider för Azure cache för Redis.For more information, see ASP.NET output cache provider for Azure Cache for Redis.

Skapa en anpassad Redis-cacheBuilding a custom Redis cache

Azure cache för Redis fungerar som en fasad till de underliggande Redis-servrarna.Azure Cache for Redis acts as a façade to the underlying Redis servers. Om du behöver en avancerad konfiguration som inte omfattas av Azure Redis-cachen (till exempel ett cacheminne som är större än 53 GB) kan du skapa och vara värd för dina egna Redis-servrar med hjälp av virtuella Azure-datorer.If you require an advanced configuration that is not covered by the Azure Redis cache (such as a cache bigger than 53 GB) you can build and host your own Redis servers by using Azure virtual machines.

Detta är en potentiellt komplex process eftersom du kan behöva skapa flera virtuella datorer som fungerar som primära och underordnade noder om du vill implementera replikering.This is a potentially complex process because you might need to create several VMs to act as primary and subordinate nodes if you want to implement replication. Om du vill skapa ett kluster behöver du dessutom flera presidentval och underordnade servrar.Furthermore, if you wish to create a cluster, then you need multiple primaries and subordinate servers. En minimal klustrad replikeringstopologi som ger hög tillgänglighet och skalbarhet består av minst sex virtuella datorer som är ordnade som tre par primära/underordnade servrar (ett kluster måste innehålla minst tre primära noder).A minimal clustered replication topology that provides a high degree of availability and scalability comprises at least six VMs organized as three pairs of primary/subordinate servers (a cluster must contain at least three primary nodes).

Varje primärt/underordnat par bör ligga nära varandra för att minimera svars tiden.Each primary/subordinate pair should be located close together to minimize latency. Varje uppsättning par kan dock köras i olika Azure-datacenter som finns i olika regioner, om du vill söka efter cachelagrade data nära de program som mest sannolikt använder dem.However, each set of pairs can be running in different Azure datacenters located in different regions, if you wish to locate cached data close to the applications that are most likely to use it. Ett exempel på hur du bygger och konfigurerar en Redis-nod som körs som virtuell Azure-dator finns i inlägget om att köra Redis på en virtuell CentOS Linux-dator i Azure.For an example of building and configuring a Redis node running as an Azure VM, see Running Redis on a CentOS Linux VM in Azure.

Anteckning

Om du implementerar din egen Redis-cache på det här sättet ansvarar du för att övervaka, hantera och säkra tjänsten.If you implement your own Redis cache in this way, you are responsible for monitoring, managing, and securing the service.

Partitionera ett Redis-cacheminnePartitioning a Redis cache

Att partitionera en cache innebär att dela cachen på flera datorer.Partitioning the cache involves splitting the cache across multiple computers. Den här strukturen ger många fördelar jämfört med en enda cacheserver:This structure gives you several advantages over using a single cache server, including:

  • Du kan skapa ett cacheminne som är mycket större än det som kan lagras på en enskild server.Creating a cache that is much bigger than can be stored on a single server.
  • Du kan distribuera data på flera servrar och förbättra tillgängligheten.Distributing data across servers, improving availability. Om en server slutar fungera eller blir otillgänglig blir de data som den innehåller otillgängliga. Data på de återstående servrarna kan fortfarande nås.If one server fails or becomes inaccessible, the data that it holds is unavailable, but the data on the remaining servers can still be accessed. För ett cacheminne är det här inte viktigt. Cachelagrade data är endast en tillfällig kopia av de data som finns i en databas.For a cache, this is not crucial because the cached data is only a transient copy of the data that's held in a database. Cachelagrade data på en server som blir otillgänglig kan cachelagras på en annan server i stället.Cached data on a server that becomes inaccessible can be cached on a different server instead.
  • Du kan sprida belastningen över servrarna, vilket ger bättre prestanda och skalbarhet.Spreading the load across servers, thereby improving performance and scalability.
  • Du kan placera data fysiskt nära de användare som använder dem, vilket förkortar svarstiden.Geolocating data close to the users that access it, thus reducing latency.

För cacheminnen är det vanligast att partitionera med horisontell partitionering.For a cache, the most common form of partitioning is sharding. I den här strategin är varje partition (eller fragment) en Redis-cache i sig.In this strategy, each partition (or shard) is a Redis cache in its own right. Data omdirigeras till en specifik partition med hjälp av logiken för horisontell partitionering. Den kan använda olika metoder för att distribuera data.Data is directed to a specific partition by using sharding logic, which can use a variety of approaches to distribute the data. I dokumentationen om mönster för horisontell partitionering finns mer information om hur du implementerar horisontell partitionering.The Sharding pattern provides more information about implementing sharding.

Om du vill implementera partitionering i ett Redis-cacheminne kan du använda någon av följande metoder:To implement partitioning in a Redis cache, you can take one of the following approaches:

  • Routning för frågor på serversidan.Server-side query routing. I den här tekniken skickar ett klientprogram en begäran till någon av de Redis-servrar som ingår i cacheminnet (sannolikt den närmaste servern).In this technique, a client application sends a request to any of the Redis servers that comprise the cache (probably the closest server). Varje Redis-server lagrar metadata som beskriver den partition som den innehåller, och som även innehåller information om vilka partitioner som finns på andra servrar.Each Redis server stores metadata that describes the partition that it holds, and also contains information about which partitions are located on other servers. Redis-servern undersöker klientbegäran.The Redis server examines the client request. Om det går att lösa lokalt utförs den begärda åtgärden.If it can be resolved locally, it will perform the requested operation. Annars vidarebefordras begäran till rätt server.Otherwise it will forward the request on to the appropriate server. Den här modellen implementeras av Redis-klustring och beskrivs närmare i Redis-kursen om kluster på Redis webbplats.This model is implemented by Redis clustering, and is described in more detail on the Redis cluster tutorial page on the Redis website. Redis-klustring är transparent för klientprogram. Ytterligare Redis-servrar kan läggas till i klustret, och data kan partitioneras om, utan att du konfigurerar om klienterna.Redis clustering is transparent to client applications, and additional Redis servers can be added to the cluster (and the data re-partitioned) without requiring that you reconfigure the clients.
  • Partitionering på klientsidan.Client-side partitioning. I den här modellen innehåller klientprogrammet logik (eventuellt i form av ett bibliotek) som skickar begäranden till rätt Redis-server.In this model, the client application contains logic (possibly in the form of a library) that routes requests to the appropriate Redis server. Den här metoden kan användas med Azure cache för Redis.This approach can be used with Azure Cache for Redis. Skapa flera Azure-cache för Redis (en för varje datapartition) och implementera klient sidans logik som vidarebefordrar begär anden till rätt cache.Create multiple Azure Cache for Redis (one for each data partition) and implement the client-side logic that routes the requests to the correct cache. Om partitionerings schemat ändras (om ytterligare Azure-cache för Redis skapas, till exempel) kan klient program behöva konfigureras om.If the partitioning scheme changes (if additional Azure Cache for Redis are created, for example), client applications might need to be reconfigured.
  • Proxystödd partitionering.Proxy-assisted partitioning. I det här schemat skickar klientprogram begäranden till en mellanliggande proxytjänst som förstår hur data är partitionerad och sedan dirigerar begäran till rätt Redis-server.In this scheme, client applications send requests to an intermediary proxy service which understands how the data is partitioned and then routes the request to the appropriate Redis server. Den här metoden kan också användas med Azure cache för Redis; Proxy-tjänsten kan implementeras som en moln tjänst i Azure.This approach can also be used with Azure Cache for Redis; the proxy service can be implemented as an Azure cloud service. Den här metoden kräver en extra nivå av komplexitet när du implementerar tjänsten. Begäranden kan ta längre tid att genomföra än partitionering på klientsidan.This approach requires an additional level of complexity to implement the service, and requests might take longer to perform than using client-side partitioning.

Sidan om partitionering och om att dela data mellan flera Redis-instanser på Redis webbplats innehåller ytterligare information om hur du implementerar partitionering med Redis.The page Partitioning: how to split data among multiple Redis instances on the Redis website provides further information about implementing partitioning with Redis.

Implementera Redis-cacheklientprogramImplement Redis cache client applications

Redis stöder klientprogram på många programmeringsspråk.Redis supports client applications written in numerous programming languages. Om du skapar nya program med hjälp av .NET Framework rekommenderar vi att du använder StackExchange.Redis-klientbiblioteket.If you are building new applications by using the .NET Framework, the recommended approach is to use the StackExchange.Redis client library. Det här biblioteket innehåller en .NET Framework-objektmodell som tar fram informationen för att ansluta till en Redis-server, skickar kommandon och ta emot svar.This library provides a .NET Framework object model that abstracts the details for connecting to a Redis server, sending commands, and receiving responses. Den finns i Visual Studio som NuGet-paket.It is available in Visual Studio as a NuGet package. Du kan använda samma bibliotek för att ansluta till en Azure-cache för Redis, eller en anpassad Redis-cache som finns på en virtuell dator.You can use this same library to connect to an Azure Cache for Redis, or a custom Redis cache hosted on a VM.

När du vill ansluta till en Redis-server använder du den statiska Connect-metoden för klassen ConnectionMultiplexer.To connect to a Redis server you use the static Connect method of the ConnectionMultiplexer class. Den anslutning som skapas med den här metoden är avsedd att användas under hela klientprogrammets livslängd. Samma anslutning kan användas av flera samtidiga trådar.The connection that this method creates is designed to be used throughout the lifetime of the client application, and the same connection can be used by multiple concurrent threads. Du ska inte ansluta och koppla från igen varje gång som du utför en Redis-åtgärd. Det kan orsaka sämre prestanda.Do not reconnect and disconnect each time you perform a Redis operation because this can degrade performance.

Du kan ange anslutningsparametrar, som adressen till Redis-värden och lösenordet.You can specify the connection parameters, such as the address of the Redis host and the password. Om du använder Azure cache för Redis är lösen ordet antingen den primära eller sekundära nyckeln som genereras för Azure cache för Redis med hjälp av Azure Portal.If you are using Azure Cache for Redis, the password is either the primary or secondary key that is generated for Azure Cache for Redis by using the Azure portal.

När du har anslutit till Redis-servern kan du hämta en referens till den Redis-databas som fungerar som cache.After you have connected to the Redis server, you can obtain a handle on the Redis database that acts as the cache. Redis-anslutning tillhandahåller metoden GetDatabase för att göra det här.The Redis connection provides the GetDatabase method to do this. Du kan sedan hämta objekt från cacheminnet och lagra data i cacheminnet via metoderna StringGet och StringSet.You can then retrieve items from the cache and store data in the cache by using the StringGet and StringSet methods. Dessa metoder förväntar sig en nyckel som parameter. De returnerar antingen objektet i cacheminnet som har ett motsvarande värde (StringGet) eller lägger till objektet i cachen med den här nyckeln (StringSet).These methods expect a key as a parameter, and return the item either in the cache that has a matching value (StringGet) or add the item to the cache with this key (StringSet).

Beroende på Redis-serverns plats kan många åtgärder orsaka viss fördröjning när en begäran skickas till servern och ett svar returneras till klienten.Depending on the location of the Redis server, many operations might incur some latency while a request is transmitted to the server and a response is returned to the client. StackExchange-biblioteket innehåller asynkrona versionerna av många av de metoder som det visar, i syfte att hjälpa klientprogram att svara snabbt.The StackExchange library provides asynchronous versions of many of the methods that it exposes to help client applications remain responsive. Dessa metoder stöder det uppgiftsbaserade asynkrona mönstret i .NET Framework.These methods support the Task-based Asynchronous pattern in the .NET Framework.

Följande kodavsnitt visar en metod med namnet RetrieveItem.The following code snippet shows a method named RetrieveItem. Det illustrerar en implementering av cache-aside-mönstret baserat på Redis och StackExchange-biblioteket.It illustrates an implementation of the cache-aside pattern based on Redis and the StackExchange library. Metoden tar ett strängnyckelvärde och försöker att hämta motsvarande objekt från Redis-cacheminnet genom att anropa metoden StringGetAsync (den asynkrona versionen av StringGet).The method takes a string key value and attempts to retrieve the corresponding item from the Redis cache by calling the StringGetAsync method (the asynchronous version of StringGet).

Om objektet inte hittas hämtas det från den underliggande datakällan med metoden GetItemFromDataSourceAsync (som är en lokal metod och inte ingår i StackExchange-biblioteket).If the item is not found, it is fetched from the underlying data source using the GetItemFromDataSourceAsync method (which is a local method and not part of the StackExchange library). Det läggs sedan till i cachen via metoden StringSetAsync, så att det kan hämtas snabbare nästa gång.It's then added to the cache by using the StringSetAsync method so it can be retrieved more quickly next time.

// 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;
}

Metoderna StringGet och StringSet är inte begränsade till strängvärden för hämtning och lagring.The StringGet and StringSet methods are not restricted to retrieving or storing string values. De kan ta alla objekt som är serialiserade som en matris bestående av byte.They can take any item that is serialized as an array of bytes. Om du behöver spara ett .NET-objekt kan du serialisera som en byte-dataström och använda metoden StringSet för att skriva till cachen.If you need to save a .NET object, you can serialize it as a byte stream and use the StringSet method to write it to the cache.

Du kan på liknande sätt läsa ett objekt från cacheminnet genom att använda metoden StringGet och avserialisera det som ett .NET-objekt.Similarly, you can read an object from the cache by using the StringGet method and deserializing it as a .NET object. Följande kod visar en uppsättning tilläggsmetoder för gränssnittet IDatabase (metoden GetDatabase i en Redis-anslutning returnerar ett IDatabase-objekt), och viss exempelkod som använder dessa metoder för att läsa och skriva ett BlogPost-objekt till cachen:The following code shows a set of extension methods for the IDatabase interface (the GetDatabase method of a Redis connection returns an IDatabase object), and some sample code that uses these methods to read and write a BlogPost object to the cache:

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;
    }
}

Följande kod illustrerar en metod som kallas RetrieveBlogPost och som använder dessa tilläggsmetoder för att läsa och skriva ett serialiserbart BlogPost-objekt till cacheminnet efter cache-aside-mönstret:The following code illustrates a method named RetrieveBlogPost that uses these extension methods to read and write a serializable BlogPost object to the cache following the cache-aside pattern:

// 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 stöder pipelining av kommandon om ett klientprogram skickar flera asynkrona begäranden.Redis supports command pipelining if a client application sends multiple asynchronous requests. Redis kan multiplexbehandla begäranden med samma anslutning i stället för att ta emot och svara på kommandon i en strikt sekvens.Redis can multiplex the requests using the same connection rather than receiving and responding to commands in a strict sequence.

Det här minskar svarstiden genom att nätverket används effektivare.This approach helps to reduce latency by making more efficient use of the network. Följande kodavsnitt visar ett exempel där information om två kunder hämtas samtidigt.The following code snippet shows an example that retrieves the details of two customers concurrently. Koden skickar två begäranden och utför vissa andra bearbetningar (visas inte) innan den väntar på att ta emot resultaten.The code submits two requests and then performs some other processing (not shown) before waiting to receive the results. Metoden Wait för cacheobjektet liknar .NET Framework-metoden Task.Wait:The Wait method of the cache object is similar to the .NET Framework Task.Wait method:

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);

Mer information om hur du skriver klient program som kan Azure cache för Redis finns i Azure-cache för Redis-dokumentationen.For additional information on writing client applications that can the Azure Cache for Redis, see the Azure Cache for Redis documentation. Mer information finns också på StackExchange.Redis.More information is also available at StackExchange.Redis.

Sidan om pipelines och multiplex på samma webbplats innehåller mer information om asynkrona åtgärder och pipelining med Redis och StackExchange-biblioteket.The page Pipelines and multiplexers on the same website provides more information about asynchronous operations and pipelining with Redis and the StackExchange library.

Använda Redis-cachelagringUsing Redis caching

Det enklaste användningsområdet för Redis för cachelagring är nyckelvärdepar där värdet är en otolkad sträng av godtycklig längd som kan innehålla alla binära data.The simplest use of Redis for caching concerns is key-value pairs where the value is an uninterpreted string of arbitrary length that can contain any binary data. (Det är i stort sett en matris med byte som kan behandlas som en sträng).(It is essentially an array of bytes that can be treated as a string). Det här scenariot visades i avsnittet Implementera Redis-cacheklientprogram tidigare i den här artikeln.This scenario was illustrated in the section Implement Redis Cache client applications earlier in this article.

Observera att nycklarna även innehåller otolkade data, så du kan använda valfri binär information som nyckel.Note that keys also contain uninterpreted data, so you can use any binary information as the key. Ju längre nyckeln är, desto mer diskutrymme tar den upp och desto längre tid tar det för att utföra sökåtgärder.The longer the key is, however, the more space it will take to store, and the longer it will take to perform lookup operations. Utforma nyckelutrymmet noggrant, med tanke på användbarhet och enkelt underhåll, och använd beskrivande (men inte för utförliga) nycklar.For usability and ease of maintenance, design your keyspace carefully and use meaningful (but not verbose) keys.

Du kan till exempel använda strukturerade nycklar som "customer:100" för att referera till nyckeln för kund nummer 100, istället för bara "100".For example, use structured keys such as "customer:100" to represent the key for the customer with ID 100 rather than simply "100". Med det här schemat kan du enkelt skilja mellan värden som lagrar olika datatyper.This scheme enables you to easily distinguish between values that store different data types. Du skulle till exempel kunna använda nyckeln "orders:100" för att referera till nyckeln för beställning nummer 100.For example, you could also use the key "orders:100" to represent the key for the order with ID 100.

Förutom endimensionella binära strängar kan ett värde i ett Redis-nyckelvärdespar också hålla mer strukturerad information, inklusive listor, uppsättningar (sorterade och osorterade) och hashvärden.Apart from one-dimensional binary strings, a value in a Redis key-value pair can also hold more structured information, including lists, sets (sorted and unsorted), and hashes. Redis tillhandahåller en omfattande kommandouppsättning som kan ändra dessa typer. Många av dessa kommandon är tillgängliga för .NET Framework-program via ett klientbiblioteket, till exempel StackExchange.Redis provides a comprehensive command set that can manipulate these types, and many of these commands are available to .NET Framework applications through a client library such as StackExchange. I presentationen av datatyper och abstraktioner i Redis på Redis webbplats finns en detaljerad beskrivning av dessa typer och de kommandon du kan använda för att hantera dem.The page An introduction to Redis data types and abstractions on the Redis website provides a more detailed overview of these types and the commands that you can use to manipulate them.

I det här avsnittet beskrivs några vanliga användningsområden för dessa typer av data och kommandon.This section summarizes some common use cases for these data types and commands.

Utföra atomiska åtgärder och batchåtgärderPerform atomic and batch operations

Redis stöder ett antal atomiska get-and-set-åtgärder för strängvärden.Redis supports a series of atomic get-and-set operations on string values. Dessa åtgärder ta bort eventuella konkurrensproblem som kan uppstå när du använder separata kommandon för GET och SET.These operations remove the possible race hazards that might occur when using separate GET and SET commands. De tillgängliga åtgärderna är bland andra:The operations that are available include:

  • INCR, INCRBY, DECR och DECRBY, som utför atomiska öknings- och minskningsåtgärder på datavärden av heltalstyp.INCR, INCRBY, DECR, and DECRBY, which perform atomic increment and decrement operations on integer numeric data values. StackExchange-biblioteket innehåller överbelastade versioner av metoderna IDatabase.StringIncrementAsync och IDatabase.StringDecrementAsync för att utföra de här åtgärderna och returnera resultatvärdet som lagras i cacheminnet.The StackExchange library provides overloaded versions of the IDatabase.StringIncrementAsync and IDatabase.StringDecrementAsync methods to perform these operations and return the resulting value that is stored in the cache. Följande kodavsnitt illustrerar hur du använder dessa metoder:The following code snippet illustrates how to use these methods:

    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, som hämtar värdet som har associerats med en nyckel och ändrar det till ett nytt värde.GETSET, which retrieves the value that's associated with a key and changes it to a new value. StackExchange-biblioteket gör den här åtgärden tillgänglig via metoden IDatabase.StringGetSetAsync.The StackExchange library makes this operation available through the IDatabase.StringGetSetAsync method. I kodfragmentet nedan visas ett exempel på den här metoden.The code snippet below shows an example of this method. Den här koden returnerar det aktuella värdet som har associerats med nyckeln data:counter från föregående exempel.This code returns the current value that's associated with the key "data:counter" from the previous example. Den återställer sedan värdet för den här nyckeln till noll, och allt ingår i samma åtgärd:Then it resets the value for this key back to zero, all as part of the same operation:

    ConnectionMultiplexer redisHostConnection = ...;
    IDatabase cache = redisHostConnection.GetDatabase();
    ...
    string oldValue = await cache.StringGetSetAsync("data:counter", 0);
    
  • MGET och MSET, som kan returnera och ändra en uppsättning strängvärden som en enda åtgärd.MGET and MSET, which can return or change a set of string values as a single operation. Metoderna IDatabase.StringGetAsync och IDatabase.StringSetAsync överlagras för att stödja den här funktionen, vilket visas i följande exempel:The IDatabase.StringGetAsync and IDatabase.StringSetAsync methods are overloaded to support this functionality, as shown in the following example:

    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);
    
    

Du kan också kombinera flera åtgärder i en enda Redis-transaktion. Det beskrivs i avsnittet Redis-transaktioner och -batchar tidigare i den här artikeln.You can also combine multiple operations into a single Redis transaction as described in the Redis transactions and batches section earlier in this article. StackExchange-biblioteket erbjuder funktioner för transaktioner via gränssnittet ITransaction.The StackExchange library provides support for transactions through the ITransaction interface.

Du skapar ett objekt av typen ITransaction med hjälp av metoden IDatabase.CreateTransaction.You create an ITransaction object by using the IDatabase.CreateTransaction method. Du kan anropa kommandon för transaktionen genom att använda de metoder som tillhandahålls av objektet ITransaction.You invoke commands to the transaction by using the methods provided by the ITransaction object.

Gränssnittet ITransaction ger åtkomst till en uppsättning metoder som liknar de som nås via gränssnittet IDatabase, förutom att alla metoder är asynkrona.The ITransaction interface provides access to a set of methods that's similar to those accessed by the IDatabase interface, except that all the methods are asynchronous. Det innebär att de endast utföras när metoden ITransaction.Execute har anropats.This means that they are only performed when the ITransaction.Execute method is invoked. Värdet som returneras av metoden ITransaction.Execute visar om transaktionen skapades (true) eller inte skapades (false).The value that's returned by the ITransaction.Execute method indicates whether the transaction was created successfully (true) or if it failed (false).

I följande kodavsnitt visas ett exempel som ökar och minskar två räknare i samma transaktion:The following code snippet shows an example that increments and decrements two counters as part of the same transaction:

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);

Kom ihåg att Redis-transaktioner skiljer sig från transaktioner i relationsdatabaser.Remember that Redis transactions are unlike transactions in relational databases. Metoden Execute köar helt enkelt alla kommandon som utgör den transaktion som ska köras. Om något av dem är felaktigt stoppas transaktionen.The Execute method simply queues all the commands that comprise the transaction to be run, and if any of them is malformed then the transaction is stopped. När alla kommandon har kunnat ställas i kö körs varje kommando asynkront.If all the commands have been queued successfully, each command runs asynchronously.

Om ett kommando misslyckas fortsätter de övriga att bearbetas.If any command fails, the others still continue processing. Om du behöver verifiera att ett kommando har slutförts måste du hämta resultatet med hjälp av egenskapen Result (resultat) för motsvarande aktivitet, så som visas i exemplet ovan.If you need to verify that a command has completed successfully, you must fetch the results of the command by using the Result property of the corresponding task, as shown in the example above. När egenskapen Result (resultat) läses blockeras anropstråden tills uppgiften har slutförts.Reading the Result property will block the calling thread until the task has completed.

Mer information finns i transaktioner i Redis.For more information, see Transactions in Redis.

När du utför batchåtgärder kan du använda gränssnittet IBatch i StackExchange-biblioteket.When performing batch operations, you can use the IBatch interface of the StackExchange library. Det här gränssnittet ger åtkomst till en uppsättning metoder som liknar de som nås via gränssnittet IDatabase, förutom att alla metoder är asynkrona.This interface provides access to a set of methods similar to those accessed by the IDatabase interface, except that all the methods are asynchronous.

Du skapar objekt av typen IBatch med hjälp av metoden IDatabase.CreateBatch. Du kör sedan batchen med hjälp av metoden IBatch.Execute, som visas i följande exempel.You create an IBatch object by using the IDatabase.CreateBatch method, and then run the batch by using the IBatch.Execute method, as shown in the following example. Den här koden anger bara ett strängvärde, ökar och minskar samma räknare som användes i föregående exempel. Resultatet visas sedan:This code simply sets a string value, increments and decrements the same counters used in the previous example, and displays the results:

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);

Det är viktigt att förstå den här skillnaden jämfört med en transaktion: om ett kommando i en batch misslyckas därför att det är felaktigt kanske övriga kommandon ändå körs.It is important to understand that unlike a transaction, if a command in a batch fails because it is malformed, the other commands might still run. Metoden IBatch.Execute ger inte någon indikation på om processen slutfördes eller inte.The IBatch.Execute method does not return any indication of success or failure.

Utföra fire-and-forget-cacheåtgärderPerform fire and forget cache operations

Redis stöder fire-and-forget-åtgärder (starta och glöm) med hjälp av kommandoflaggor.Redis supports fire and forget operations by using command flags. Det här betyder att klienten endast initierar en åtgärd och inte har något intresse av resultatet och inte väntar på att kommandot ska slutföras.In this situation, the client simply initiates an operation but has no interest in the result and does not wait for the command to be completed. I exemplet nedan ser du hur du utför INCR-kommandot som fire-and-forget-åtgärd:The example below shows how to perform the INCR command as a fire and forget operation:

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

Ange nycklar med automatisk sluttidSpecify automatically expiring keys

När du sparar ett objekt i ett Redis-cacheminne anger du en bortre tidsgräns där objektet tas bort från cachen automatiskt.When you store an item in a Redis cache, you can specify a timeout after which the item will be automatically removed from the cache. Du kan också fråga hur mycket mer tid en nyckel har innan den upphör med hjälp av kommandot TTL.You can also query how much more time a key has before it expires by using the TTL command. Det här kommandot är tillgängligt för StackExchange-program via metoden IDatabase.KeyTimeToLive.This command is available to StackExchange applications by using the IDatabase.KeyTimeToLive method.

I följande kodavsnitt ser du hur du ställer in en förfallotid på 20 sekunder för en nyckel och sedan frågar om den återstående livslängden för nyckeln:The following code snippet shows how to set an expiration time of 20 seconds on a key, and query the remaining lifetime of the key:

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");

Du kan också ange förfallotiden till ett visst datum och en viss tid genom att använda kommandot EXPIRE. Det är tillgängligt i StackExchange-biblioteket som metoden KeyExpireAsync:You can also set the expiration time to a specific date and time by using the EXPIRE command, which is available in the StackExchange library as the KeyExpireAsync method:

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));
...

Tips

Du kan manuellt ta bort ett objekt från cacheminnet med hjälp av kommandot DEL. Det är tillgängligt via StackExchange-biblioteket som metoden IDatabase.KeyDeleteAsync.You can manually remove an item from the cache by using the DEL command, which is available through the StackExchange library as the IDatabase.KeyDeleteAsync method.

Använda taggar för att korskorrelera cachade objektUse tags to cross-correlate cached items

En Redis-uppsättning är en samling av flera objekt som delar en enda nyckel.A Redis set is a collection of multiple items that share a single key. Du kan skapa en uppsättning med hjälp av kommandot SADD (uppsättning, lägg till).You can create a set by using the SADD command. Du kan hämta objekten i en uppsättning med hjälp av kommandot SMEMBERS (uppsättning, medlemmar).You can retrieve the items in a set by using the SMEMBERS command. StackExchange-biblioteket implementerar SADD-kommandot med metoden IDatabase.SetAddAsync och SMEMBERS-kommandot med metoden IDatabase.SetMembersAsync.The StackExchange library implements the SADD command with the IDatabase.SetAddAsync method, and the SMEMBERS command with the IDatabase.SetMembersAsync method.

Du kan också kombinera befintliga uppsättningar och skapa nya uppsättningar med hjälp av kommandona SDIFF (uppsättning, skillnad), SINTRING (uppsättning, skärning) och SUNION (uppsättning, union).You can also combine existing sets to create new sets by using the SDIFF (set difference), SINTER (set intersection), and SUNION (set union) commands. StackExchange-biblioteket kombinerar dessa åtgärder i metoden IDatabase.SetCombineAsync.The StackExchange library unifies these operations in the IDatabase.SetCombineAsync method. Den första parametern för den här metoden anger den uppsättningsåtgärd som ska utföras.The first parameter to this method specifies the set operation to perform.

I följande kodavsnitt ser du hur uppsättningar kan vara användbara för att snabbt lagra och hämta samlingar med relaterade objekt.The following code snippets show how sets can be useful for quickly storing and retrieving collections of related items. Den här koden använder typen BlogPost som beskrevs i avsnittet Implementera Redis-cacheklientprogram tidigare i den här artikeln.This code uses the BlogPost type that was described in the section Implement Redis Cache Client Applications earlier in this article.

Ett BlogPost objekt innehåller fyra fält — : ett ID, en rubrik, ett rangordnings Poäng och en samling taggar.A BlogPost object contains four fields—an ID, a title, a ranking score, and a collection of tags. I det första kodfragmentet nedan visas exempeldata som har använts för att fylla i en C#-lista över BlogPost-objekt:The first code snippet below shows the sample data that's used for populating a C# list of BlogPost objects:

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
}

Du kan lagra taggar för varje BlogPost-objekt som en uppsättning i ett Redis-cacheminne och associera varje uppsättning med ID:t för BlogPost.You can store the tags for each BlogPost object as a set in a Redis cache and associate each set with the ID of the BlogPost. Det gör att ett program snabbt kan hitta alla taggar som hör till ett visst blogginlägg.This enables an application to quickly find all the tags that belong to a specific blog post. Om du vill söka i motsatt riktning och hitta alla blogginlägg som delar en viss tagg kan du skapa en annan uppsättning som innehåller bloggposterna som har referens till tagg-ID:t i nyckeln:To enable searching in the opposite direction and find all blog posts that share a specific tag, you can create another set that holds the blog posts referencing the tag ID in the key:

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);
    }
}

Med dessa strukturer kan du utföra många vanliga frågor mycket effektivt.These structures enable you to perform many common queries very efficiently. Du kan exempelvis söka efter och visa alla taggar för blogginlägget 1 så här:For example, you can find and display all of the tags for blog post 1 like this:

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

Du hittar alla taggar som är gemensamma för blogginlägg 1 och blogginlägg 2 genom att utföra en SINTRING-åtgärd (uppsättning, skärning) så här:You can find all tags that are common to blog post 1 and blog post 2 by performing a set intersection operation, as follows:

// 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);
}

Och du också hitta alla blogginlägg som innehåller en viss tagg:And you can find all blog posts that contain a specific tag:

// 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);
}

Söka efter nyligen använda objektFind recently accessed items

En vanlig åtgärd som krävs för många program är att hitta nyligen använda objekt.A common task required of many applications is to find the most recently accessed items. En blogg vill kanske visa information om vilka blogginlägg som har lästs senast.For example, a blogging site might want to display information about the most recently read blog posts.

Du kan implementera den här funktionen med en Redis-lista.You can implement this functionality by using a Redis list. Ett Redis-listan innehåller flera objekt som delar samma nyckel.A Redis list contains multiple items that share the same key. Listan fungerar som en dubbelsidig kö.The list acts as a double-ended queue. Du kan skicka objekt till valfri ände av listan med hjälp av kommandona LPUSH (skicka åt vänster) och RPUSH (skicka åt höger).You can push items to either end of the list by using the LPUSH (left push) and RPUSH (right push) commands. Du kan hämta objekt från valfri ände av listan med hjälp av kommandona LPOP (hämta från vänster) och RPOP (hämta från höger).You can retrieve items from either end of the list by using the LPOP and RPOP commands. Du kan också returnera en uppsättning element med hjälp av kommandona LRANGE (vänster intervall) och RRANGE (höger intervall).You can also return a set of elements by using the LRANGE and RRANGE commands.

I kodavsnitten ser du hur du kan utföra dessa åtgärder genom att använda StackExchange-biblioteket.The code snippets below show how you can perform these operations by using the StackExchange library. I den här koden använder vi typen BlogPost från föregående exempel.This code uses the BlogPost type from the previous examples. När ett blogginlägg läses av en användare skickar metoden IDatabase.ListLeftPushAsync namnet på blogginlägget till en lista som är kopplad till nyckeln blog:recent_posts i Redis-cacheminnet.As a blog post is read by a user, the IDatabase.ListLeftPushAsync method pushes the title of the blog post onto a list that's associated with the key "blog:recent_posts" in the Redis cache.

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

Allteftersom användare läser fler blogginlägg skickas namnen på inläggen till samma lista.As more blog posts are read, their titles are pushed onto the same list. Listan sorteras efter den sekvens i vilken namnen har lagts till.The list is ordered by the sequence in which the titles have been added. De senast lästa blogg inläggen är till vänster i listan.The most recently read blog posts are toward the left end of the list. (Om samma blogginlägg läses mer än en gång får den flera poster i listan.)(If the same blog post is read more than once, it will have multiple entries in the list.)

Du kan visa namnen på de senast lästa inläggen med metoden IDatabase.ListRange.You can display the titles of the most recently read posts by using the IDatabase.ListRange method. Den här metoden tar den nyckel som innehåller listan, en startpunkt och en slutpunkt.This method takes the key that contains the list, a starting point, and an ending point. Följande kod hämtar namnen på de 10 blogginläggen längst till vänster i listan (objekt från 0 till 9):The following code retrieves the titles of the 10 blog posts (items from 0 to 9) at the left-most end of the list:

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

Observera att metoden ListRangeAsync inte ta bort objekt från listan.Note that the ListRangeAsync method does not remove items from the list. Om du vill göra det kan du använda metoderna IDatabase.ListLeftPopAsync och IDatabase.ListRightPopAsync.To do this, you can use the IDatabase.ListLeftPopAsync and IDatabase.ListRightPopAsync methods.

Om du vill förhindra att listan växer i all oändlighet kan du regelbundet gallra bort objekt genom att ta bort delar av listan.To prevent the list from growing indefinitely, you can periodically cull items by trimming the list. Kodfragmentet nedan visar hur du tar bort alla objekt från listan utom de fem längst till vänster:The code snippet below shows you how to remove all but the five left-most items from the list:

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

Sortera objekten i ordningsföljdImplement a leader board

Standardinställningen är att objekten inte ligger i någon viss ordning.By default, the items in a set are not held in any specific order. Du kan skapa en ordnad uppsättning med hjälp av kommandot ZADD (sorterad uppsättning, lägg till) (metoden IDatabase.SortedSetAdd i StackExchange-biblioteket).You can create an ordered set by using the ZADD command (the IDatabase.SortedSetAdd method in the StackExchange library). Objekten sorteras med hjälp av ett numeriskt värde som kallas poäng. Det tillhandahålls som parameter i kommandot.The items are ordered by using a numeric value called a score, which is provided as a parameter to the command.

Följande kodavsnitt lägger till namnet på ett blogginlägg i en sorterad lista.The following code snippet adds the title of a blog post to an ordered list. I det här exemplet har varje blogginlägget även ett poängfält med blogginläggets rangordning.In this example, each blog post also has a score field that contains the ranking of the blog post.

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);

Du kan hämta namn på blogginlägg och poäng i stigande ordning med metoden IDatabase.SortedSetRangeByRankWithScores:You can retrieve the blog post titles and scores in ascending score order by using the IDatabase.SortedSetRangeByRankWithScores method:

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

Anteckning

I StackExchange-biblioteket finns också metoden IDatabase.SortedSetRangeByRankAsync, som returnerar data i poängordning men som inte returnerar poängen.The StackExchange library also provides the IDatabase.SortedSetRangeByRankAsync method, which returns the data in score order, but does not return the scores.

Du kan också hämta objekt i fallande ordning efter resultat och begränsa antalet objekt som returneras genom att ange ytterligare parametrar i metoden IDatabase.SortedSetRangeByRankWithScoresAsync.You can also retrieve items in descending order of scores, and limit the number of items that are returned by providing additional parameters to the IDatabase.SortedSetRangeByRankWithScoresAsync method. I nästa exempel visas namn och poäng för de 10 översta blogginläggen i rangordningen:The next example displays the titles and scores of the top 10 ranked blog posts:

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

I nästa exempel används metoden IDatabase.SortedSetRangeByScoreWithScoresAsync, som begränsar vilka objekt som returneras till de som faller inom ett visst poängintervall:The next example uses the IDatabase.SortedSetRangeByScoreWithScoresAsync method, which you can use to limit the items that are returned to those that fall within a given score range:

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

Meddelande med hjälp av kanalerMessage by using channels

Förutom att den fungerar som cacheminne tillhandahåller Redis-servern meddelanden via en mekanism med hög kapacitet för utgivare/prenumerant.Apart from acting as a data cache, a Redis server provides messaging through a high-performance publisher/subscriber mechanism. Klientprogram kan prenumerera på en kanal, och andra program och tjänster kan publicera meddelanden på kanalen.Client applications can subscribe to a channel, and other applications or services can publish messages to the channel. De prenumererande programmen får sedan dessa meddelanden och kan bearbeta dem.Subscribing applications will then receive these messages and can process them.

Redis tillhandahåller kommandot SUBSCRIBE (prenumerera) som klientprogram använder för att prenumerera på kanaler.Redis provides the SUBSCRIBE command for client applications to use to subscribe to channels. Det här kommandot förväntar sig namnet på en eller flera kanaler på vilka programmet ska ta emot meddelanden.This command expects the name of one or more channels on which the application will accept messages. StackExchange-biblioteket innehåller gränssnittet ISubscription, vilket gör det möjligt för .NET Framework-program att prenumerera på och publicera till kanaler.The StackExchange library includes the ISubscription interface, which enables a .NET Framework application to subscribe and publish to channels.

Du skapar ett ISubscription-objekt med hjälp av metoden GetSubscriber för anslutningen till Redis-servern.You create an ISubscription object by using the GetSubscriber method of the connection to the Redis server. Du lyssnar sedan efter meddelanden på en kanal med hjälp av metoden SubscribeAsync för objektet.Then you listen for messages on a channel by using the SubscribeAsync method of this object. Följande kodexempel visar hur du prenumererar på en kanal med namnet messages:blogPosts.The following code example shows how to subscribe to a channel named "messages:blogPosts":

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

Den första parametern i metoden Subscribe är namnet på kanalen.The first parameter to the Subscribe method is the name of the channel. Det här namnet följer samma konventioner som används av nycklar i cacheminnet.This name follows the same conventions that are used by keys in the cache. Namnet kan innehålla alla typer av binära data, men vi rekommenderar relativt korta, beskrivande strängar för att säkerställa prestanda och underhåll.The name can contain any binary data, although it is advisable to use relatively short, meaningful strings to help ensure good performance and maintainability.

Observera också att namnområdet som används av kanaler är skilt från det som används av nycklar.Note also that the namespace used by channels is separate from that used by keys. Det innebär att du kan ha kanaler och nycklar med samma namn, även om det kan göra programkoden svårare att underhålla.This means you can have channels and keys that have the same name, although this may make your application code more difficult to maintain.

Den andra parametern är en åtgärdsdelegering.The second parameter is an Action delegate. Det här ombudet körs asynkront när ett nytt meddelande visas på kanalen.This delegate runs asynchronously whenever a new message appears on the channel. Det här exemplet visar bara meddelandet på konsolen (meddelandet innehåller namnet på ett blogginlägg).This example simply displays the message on the console (the message will contain the title of a blog post).

Om du vill publicera en kanal kan ett program använda Redis-kommandot PUBLISH (publicera).To publish to a channel, an application can use the Redis PUBLISH command. I StackExchange-bibliotek finns metoden IServer.PublishAsync för att utföra den här åtgärden.The StackExchange library provides the IServer.PublishAsync method to perform this operation. Nästa kodfragmentet visar hur du publicerar ett meddelande på kanalen messages:blogPosts:The next code snippet shows how to publish a message to the "messages:blogPosts" channel:

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

Det finns flera punkter du bör känna till om mekanismen för publicera/prenumerera:There are several points you should understand about the publish/subscribe mechanism:

  • Flera prenumeranter kan prenumerera på samma kanal och de tar emot de meddelanden som publiceras på kanalen.Multiple subscribers can subscribe to the same channel, and they will all receive the messages that are published to that channel.
  • Prenumeranter får endast meddelanden som publicerades efter det att de började prenumerera.Subscribers only receive messages that have been published after they have subscribed. Kanaler har ingen buffert. När ett meddelande har publicerats skickar Redis-infrastrukturen meddelandet till varje prenumerant och tar sedan bort det.Channels are not buffered, and once a message is published, the Redis infrastructure pushes the message to each subscriber and then removes it.
  • Standardinställningen är att meddelanden tas emot av prenumeranterna i den ordning de skickas.By default, messages are received by subscribers in the order in which they are sent. I ett system med hög aktivitet, med ett stort antal meddelanden och många prenumeranter och utgivare, kan garanterad sekventiell leverans av meddelanden ge sämre prestanda i systemet.In a highly active system with a large number of messages and many subscribers and publishers, guaranteed sequential delivery of messages can slow performance of the system. Om varje meddelande är fristående och ordningen oviktigt kan du aktivera samtidig bearbetning i Redis-systemet. Det kan förbättra svarstiden.If each message is independent and the order is unimportant, you can enable concurrent processing by the Redis system, which can help to improve responsiveness. Du kan åstadkomma det här i StackExchange-klienten genom att ställa in PreserveAsyncOrder för anslutningen som används av prenumeranten till false (falskt):You can achieve this in a StackExchange client by setting the PreserveAsyncOrder of the connection used by the subscriber to false:
ConnectionMultiplexer redisHostConnection = ...;
redisHostConnection.PreserveAsyncOrder = false;
ISubscriber subscriber = redisHostConnection.GetSubscriber();

Överväganden kring serialiseringSerialization considerations

När du väljer serialiseringsformat behöver du överväga kompromisserna mellan prestanda, samverkan, versionshantering, kompabilitet med befintliga system, datakomprimering och minnesanvändning.When you choose a serialization format, consider tradeoffs between performance, interoperability, versioning, compatibility with existing systems, data compression, and memory overhead. Kom ihåg att mått kan variera mycket beroende på kontext när du utvärderar prestanda.When you are evaluating performance, remember that benchmarks are highly dependent on context. De återspeglar kanske inte den faktiska arbetsbelastningen och räknar kanske inte med nyare bibliotek och versioner.They may not reflect your actual workload, and may not consider newer libraries or versions. Det finns ingen typ av serialisering som är den snabbaste för alla scenarier.There is no single "fastest" serializer for all scenarios.

Några alternativ att överväga är:Some options to consider include:

  • Protocol Buffers (även kallat Protobuf) är ett serialiseringsformat utvecklat av Google för effektivt serialisera strukturerade data.Protocol Buffers (also called protobuf) is a serialization format developed by Google for serializing structured data efficiently. Den använder starkt skrivna definitionsfiler för att definiera meddelande strukturer.It uses strongly typed definition files to define message structures. Dessa definitionsfiler kompileras sedan till språkspecifik kod för serialisering och avserialisering av meddelanden.These definition files are then compiled to language-specific code for serializing and deserializing messages. Protobuf kan användas via befintliga RPC-mekanismer. Det kan också generera en RPC-tjänst.Protobuf can be used over existing RPC mechanisms, or it can generate an RPC service.

  • Apache Thrift använder ett liknande tillvägagångssätt, med starkt typifierade definitionsfiler och ett kompileringssteg för att generera kod för serialisering och RPC-tjänster.Apache Thrift uses a similar approach, with strongly typed definition files and a compilation step to generate the serialization code and RPC services.

  • Apache Avro ger liknande funktionalitet som Protocol Buffers och Thrift, men det finns inget kompileringssteg.Apache Avro provides similar functionality to Protocol Buffers and Thrift, but there is no compilation step. I stället innehåller serialiserade data alltid ett schema som beskriver strukturen.Instead, serialized data always includes a schema that describes the structure.

  • JSON är en öppen standard med textfält som kan läsas av människor.JSON is an open standard that uses human-readable text fields. Det fungerar med många olika plattformar.It has broad cross-platform support. Meddelandescheman används inte av JSON.JSON does not use message schemas. Ledningseffektiviteten är inte särskilt god eftersom det är ett textbaserat format.Being a text-based format, it is not very efficient over the wire. I vissa fall kanske du dock returnerar cachelagrade objekt direkt till en klient via HTTP. Då kan du om du lagrar JSON spara kostnaden för att avserialisera från ett annat format och sedan serialisera till JSON.In some cases, however, you may be returning cached items directly to a client via HTTP, in which case storing JSON could save the cost of deserializing from another format and then serializing to JSON.

  • BSON är en binärt serialiseringsformat vars struktur liknar den i JSON.BSON is a binary serialization format that uses a structure similar to JSON. BSON har utformats för att vara kompakt, enkelt att läsa av och för att gå snabbt att serialisera och deserialisera, i förhållande till JSON.BSON was designed to be lightweight, easy to scan, and fast to serialize and deserialize, relative to JSON. Nyttolasterna är jämförbara i storlek med JSON.Payloads are comparable in size to JSON. Beroende på data kan en BSON-nyttolast vara mindre eller större än en JSON-nyttolast.Depending on the data, a BSON payload may be smaller or larger than a JSON payload. BSON har vissa typer av ytterligare datatyper som inte är tillgängliga i JSON, främst BinData (för bytematriser) och Date.BSON has some additional data types that are not available in JSON, notably BinData (for byte arrays) and Date.

  • MessagePack är ett binärt serialiseringsformat som är utformat för att vara kompakt för smidig överföring.MessagePack is a binary serialization format that is designed to be compact for transmission over the wire. Det finns inga meddelandescheman eller typkontroll för meddelanden.There are no message schemas or message type checking.

  • Bond är ett ramverk för flera plattformar, för att jobba med schematiserade data.Bond is a cross-platform framework for working with schematized data. Det har funktioner för serialisering och deserialisering över olika språk.It supports cross-language serialization and deserialization. Några av de främsta skillnaderna från andra system i listan är funktioner för arv, typalias och generisk typ.Notable differences from other systems listed here are support for inheritance, type aliases, and generics.

  • gRPC är ett RPC-system med öppen källkod som utvecklats av Google.gRPC is an open-source RPC system developed by Google. Standardinställningen är att det använder Protocol Buffers som definitionsspråk och underliggande filutbytesformat för meddelanden.By default, it uses Protocol Buffers as its definition language and underlying message interchange format.

Följande mönster kan också vara relevanta för ditt scenario när du implementerar cachelagring i dina program:The following patterns might also be relevant to your scenario when you implement caching in your applications:

  • Cache-aside-mönster: det här mönstret beskriver hur du på begäran läser in data i ett cacheminne från ett datalager.Cache-aside pattern: This pattern describes how to load data on demand into a cache from a data store. Det här mönstret hjälper också till att upprätthålla konsekvens mellan data i cacheminnet och data i den ursprungliga datalagringen.This pattern also helps to maintain consistency between data that's held in the cache and the data in the original data store.

  • Sharding-mönster (horisontell partitionering)innehåller information om hur du använder horisontell partitionering för att förbättra skalbarheten vid lagring av och åtkomst till stora mängder data.The Sharding pattern provides information about implementing horizontal partitioning to help improve scalability when storing and accessing large volumes of data.

Mer informationMore information