Azure Managed Redis-klientbibliotek

Azure Managed Redis baseras på det populära minnesinterna datalagret Redis. Redis-klienter för många programmeringsspråk har åtkomst till Azure Managed Redis. Varje klientbibliotek har ett eget API som anropar Redis-servern med Hjälp av Redis-kommandon, men klientbiblioteken är byggda för att kommunicera med alla Redis-servrar.

Varje klientbibliotek har en egen referensdokumentation. Biblioteken innehåller också länkar för att få support via klientbibliotekets utvecklarcommunity. Azure Managed Redis-teamet äger inte utvecklingen eller stödet för några klientbibliotek.

Följande rekommendationer baseras på popularitet och om det finns en aktiv onlinecommunity för att stödja och besvara dina frågor. Vi rekommenderar att du endast använder den senaste tillgängliga versionen och att du uppgraderar regelbundet när nya versioner blir tillgängliga. Dessa bibliotek är under aktiv utveckling och nya versioner lanseras ofta med förbättringar av tillförlitlighet och prestanda.

Välja rätt klientbibliotek baserat på klustringsprincipen

Azure Managed Redis stöder enterprise-klustringsprincipen och OSS-klustringsprincipen. Mer information finns här (lägg till länk till information om klustringsprinciper).

Alla klientbibliotek fungerar med redis-instansen med enterprise-klustringsprincipen. Men om du använder OSS-klustringsprincipen kontrollerar du att det klientbibliotek som du väljer stöder anslutning till klustrade Redis-instanser.

Blockerade kommandon

Microsoft hanterar konfigurationen och hanteringen av Azure Managed Redis-instanser, vilket inaktiverar följande kommandon som standard. Mer information om blockerade kommandon finns i kompatibilitet med klusterhanteringskommandon

Kommandon med flera tangenter

Eftersom AMR-instanserna använder en klustrad konfiguration kan du stöta på CROSSSLOT felmeddelanden för kommandon som hanterar flera nycklar. Beteendet varierar beroende på vilken klustringsprincip som används. Om du använder OSS-klustringsprincipen kräver kommandon med flera nycklar att alla nycklar mappas till samma hash-plats.

Du kan också se CROSSSLOT fel med klustringsprincipen för företag. Endast följande flernyckelkommandon tillåts mellan platser med Enterprise-klustring: DEL, MSET, MGET, EXISTS, UNLINKoch TOUCH.

I Active-Active databaser kan skrivkommandon med flera nycklar (DEL, , MSETUNLINK) bara köras på nycklar som finns i samma fack. Följande kommandon med flera nycklar tillåts dock på flera platser i Active-Active databaser: MGET, EXISTSoch TOUCH. Mer information finns i Databaskluster.

Kommandon blockerade för företagsklusterpolicy

• KLUSTERINFORMATION
• KLUSTERHJÄLP
• KLUSTER NYCKELPLATS
• KLUSTERNODER
• KLUSTERFACK

Kommandon blockerade för aktiv geo-replikering

• FLUSHALL
• FLUSHDB

Klientbiblioteksspecifik vägledning

Mer information om klientbiblioteksspecifika metodtips finns i följande länkar:

• StackExchange.Redis (.NET)
• Sallad (Java)
• Jedis (Java)
• Redisson (Java)
• Node.js
• PHP
• HiRedisCluster

Redisson (Java)

Vi rekommenderar att du använder redisson 3.14.1 eller senare. Äldre versioner innehåller kända problem med anslutningsläckage som orsakar problem efter redundansväxlingar. Övervaka Redisson-ändringsloggen för att identifiera andra kända problem som kan påverka funktioner som används av ditt program. Mer information finns i CHANGELOG och Vanliga frågor och svar om Redisson.

Övriga anteckningar:

• Redisson använder som standard strategin "läsa från replik", till skillnad från vissa andra klienter. Om du vill ändra den här standardinställningen ändrar du konfigurationsinställningen "readMode".
• Redisson använder en strategi för anslutningspooler med konfigurerbara minimi- och maxinställningar, och de standardinställda minimivärdena är stora. De stora standardinställningarna kan bidra till aggressiva återanslutningsmönster eller "anslutningsstormar". Du kan minska denna risk genom att använda färre anslutningar, eftersom du effektivt kan skicka kommandon, eller uppsättningar av kommandon, via några få anslutningar.
• Redisson har en standard timeout för inaktiv anslutning på 10 sekunder, vilket leder till mer stängning och återöppning av anslutningar än idealiskt.

Här följer en rekommenderad baslinjekonfiguration för klusterläge som du kan redigera efter behov:

clusterServersConfig:
  idleConnectionTimeout: 30000
  connectTimeout: 15000
  timeout: 5000
  retryAttempts: 3
  retryInterval: 3000
  checkLockSyncedSlaves: false
  failedSlaveReconnectionInterval: 15000
  failedSlaveCheckInterval: 60000
  subscriptionsPerConnection: 5
  clientName: "redisson"
  loadBalancer: !<org.redisson.connection.balancer.RoundRobinLoadBalancer> {}
  subscriptionConnectionMinimumIdleSize: 1
  subscriptionConnectionPoolSize: 50
  slaveConnectionMinimumIdleSize: 2
  slaveConnectionPoolSize: 24
  masterConnectionMinimumIdleSize: 2
  masterConnectionPoolSize: 24
  readMode: "MASTER"
  subscriptionMode: "MASTER"
  nodeAddresses:
  - "redis://mycacheaddress:10000"
  scanInterval: 1000
  pingConnectionInterval: 60000
  keepAlive: false
  tcpNoDelay: true

En artikel om Redissons stöd för JCache som lagringsplats för HTTP-sessionstillstånd i IBM Liberty på Azure finns i Använda Java EE JCache med Open Liberty eller WebSphere Liberty i ett AKS-kluster (Azure Kubernetes Service).

Så här använder du klientbibliotek

Förutom referensdokumentationen hittar du självstudier som visar hur du kommer igång med Azure Managed Redis med olika språk och cacheklienter.

Mer information om hur du använder några av dessa klientbibliotek i självstudier finns i följande artiklar:

• Koda en .NET Framework-app
• Programmera ett .NET Core-program
• Koda en ASP.NET-webbapp
• Koda en ASP.NET Core-webbapp
• Koda en Java-app
• Koda en Node.js-app
• Koda en Python-app

Nästa steg

• Vanliga frågor och svar om Azure Managed Redis-utveckling
• Metodtips för utveckling