Speicherstände

MemoryStoreService ist ein hochskalierbarer und hochverfügbarer Datendienst, der schnellen In-Memory-Datenspeicher in allen Servern einer Live-Sitzung zugänglich macht. Memory-Stores sind für häufige und ephemerale Daten geeignet, die sich schnell ändern und nicht dauerhaft sein müssen, da sie schneller auf Z

Datenstrukturen

Statt direkt auf raw data zuzugreifen, haben memory-stores drei primitive datenstrukturen, die auf den servern für eine schnelle verarbeitung geteilt werden: sortierte map , queue und hash map. Jede datenstruktur ist ein guter eignung für bestimmte anwendungsfälle:

• Fähigkeitenbasiertes Matchmaking - Speichern Sie Benutzerinformationen, z. B. Stufe, in einer gemeinsamen Warteschlange zwischen Servern und verwenden Sie Lobby-Server, um das Matchmaking periodisch zu aktivieren.
• Cross-Server-Handel und Auktionen - Aktivieren Sie den universellen Handel zwischen verschiedenen Servern, bei dem Benutzer mit Echtzeit-Preisen auf Items mit sich verändernden Preisen und mit einer sortierten Karte von Schlüsselwertenpaaren bieten können.
• Globale Bestenlisten - Speichere und aktualisiere Benutzer-Ranglisten in einer gemeinsamen Bestenliste innerhalb einer sortierten Karte .
• Gemeinsame Inventare - Speichern Sie Inventarartikel und Statistiken in einer gemeinsamen Hash-Karte , in der Benutzer Inventarartikel gleichzeitig miteinander verwenden können.
• Cache für bestehende Daten - Synchronisieren und kopieren Sie Ihre bestehenden Daten in einem Daten-Store in einen Speicher-Store Hash-Map , der alsCache fungiert und die ErfüllungIhres Erlebnisses verbessern kann.

Im Allgemeinen, wenn Sie auf bestimmte Daten zugreifen müssen, verwenden Sie eine HasMap. Wenn Sie diese Daten in einer bestimmten Reihenfolge benötigen, verwenden Sie eine sortierte Map. Wenn Sie Ihre Daten in einer bestimmten Reihenfolge verarbeiten müssen, verwenden Sie eine Warteschlange.

Beschränkungen und Quoten

Um die Skalierbarkeit und Erfüllungzu gewährleisten, haben Speicherplätze Datenverwendungs quoten für die Speichergröße, API-Anfragen und die Datenstrukturgröße.

Speicherstores haben eine Räumungspolitik basierend auf der Verfallszeit, auch bekannt als Zeit zum Leben (TTL). Es werden Gegenstände eviziert, nachdem sie abgelaufen sind, und der Speicherquelle wird für neue Einträge freigegeben. Wenn Sie das Speicherlimit erreichen, fallen alle folgenden Schreibanfragen fehl, bis Gegenstände abgelaufen sind, oder Sie manuell löschen.

Speichergröße-Quote

Die Speicherquote begrenzt die Gesamtmenge des Speichers, die ein Erlebnis verbrauchen kann. Es ist keine feste Werte. Stattdessen ändert sich die Menge des Speichers im Laufe der Zeit, abhängig von der Anzahl der Benutzer im Erlebnis entsprechend der folgenden Formel: 64KB + 1KB * [Anzahl der Benutzer] . Die Quote gilt auf der Erlebnis-Ebene, nicht auf der Stufe.

Wenn Benutzer dem Erlebnis beitreten, ist die zusätzliche Speicherquote sofort verfügbar. Wenn Benutzer das Erlebnis verlassen, reduziert sich die Quote nicht sofort. Es gibt eine Rückverfolgungszeit von acht Tagen, bevor die Quote auf einen niedrigeren Wert zurückgeprüft wird.

Nachdem Ihre Erfahrung die Größenbegrenzung für den Speicher erreicht, scheitern alle API-Anfragen, die die Speichergröße erhöhen. Anfragen, die die Speichergröße ändern oder nicht ändern, haben immer noch Erfolg.

Mit dem Observability-Dashboard können Sie die Größenmenge der Erinnerung in Echtzeit mit der Memory-Verwendung-Diagramm anzeigen.

API-Anfrage-Beschränkungen

Für API-Anforderungslimits gibt es eine Anforderungseinheit quota, die für alle MemoryStoreService API-Aufrufe gilt. Die Quote beträgt 1000 + 100 * [Anzahl der gleichzeitigen Benutzer] Anforderungseinheiten pro Minute.

Die meisten API-Aufrufe verbrauchen nur eine Anfrage, mit einigen Ausnahmen:

• MemoryStoreSortedMap:GetRangeAsync()

  Verbraucht Einheiten basierend auf der Anzahl der zurückgegebenen Elemente. Zum Beispiel, wenn diese Methode 10 Elemente zurückgibt, zählt die Aufrufe als 10 Anfrage-Einheiten. Wenn sie eine leere Antwort zurückgibt, zählt sie als eine Anfrage-Einheit.

• MemoryStoreQueue:ReadAsync()

  Verbraucht Einheiten basierend auf der Anzahl der zurückgegebenen Elemente, wie MemoryStoreSortedMap:GetRangeAsync() , aber verbraucht eine zusätzliche Einheit jede zwei Sekunden beim Lesen. Spezifizieren Sie die maximale Lesedauer mit dem waitTimeout-Parameter.

• MemoryStoreHashMap:UpdateAsync()

  Verbraucht mindestens zwei Einheiten.

• MemoryStoreHashMap:ListItemsAsync()

  Verbraucht [Anzahl der Partitionen gescannt] + [ge返回的项目] Einheiten.

Die Anforderungen auf der Erfahrungsebene werden auch auf der Server-Ebene angewendet, nicht auf der Stufe. Dies bietet Flexibilität, um die Anforderungen auf mehrere Server zu verteilen, solange die Gesamtanfrage Rate nicht die Quote überschreitet. Wenn Sie die Quote überschreiten, erhalten Sie eine Fehlerantwort, wenn der Service Ihre Anfragen blockiert.

Mit der Verfügbarkeit der Beobachtbarkeit-Funktion können Sie die Anforderungseinheit-Quote Ihres Erlebnisses in Echtzeit anzeigen.

Datenstrukturgrößenlimit

Für eine einzelne sortierte Karte oder Warteschlange gelten die folgenden Größen- und Item-Count-Begrenzungen:

• Maximale Anzahl von Artikeln: 1,000,000
• Maximale Gesamtgröße (einschließlich Schlüssel für sortierte Karte): 100 MB

Per-Partition-Beschränkungen

Siehe Per-Partition Limits.

Best Practices

Um Ihre Erinnerungs-Verwendungsmuster zu optimieren und das Treffen der Grenzen zu vermeiden, folgen Sie diesen Best Practices:

• Entfernte verarbeitete Elemente. Konsistent saubere gelesene Elemente mit der Methode MemoryStoreQueue:RemoveAsync() für Warteschlange und MemoryStoreSortedMap:RemoveAsync() für sortierte Tabellen, um die Erinnerungsstruktur auf dem neuesten Stand zu halten.

• Setzen Sie die Verfallszeit auf das kleinste Zeitfenster, wenn Sie Daten hinzufügen. Obwohl die Standard-Verfallszeit 45 Tage für beide MemoryStoreQueue:AddAsync() und MemoryStoreSortedMap:SetAsync() ist, kann die kürzeste verfügbare Zeit automatisch alte Daten löschen, um zu verhindern, dass sie Ihren Speicherverbrauch quellen.

  • Lagere keine große Menge an Daten mit einer langen Verfallszeit, da dies deine Erinnerungsquote überschreiten und potenziell Probleme verursachen kann, die dein gesamtes Erlebnis beeinträchtigen.
  • Löschen Sie immer ausdrücklich nicht benötigte Elemente oder setzen Sie eine kurze Item-Expiration.
  • Im Allgemeinen solltest du die explizite Löschung verwenden, um Erinnerungen und Gegenstände auszulöschen, als Sicherheitsmechanismus, um unbenutzte Gegenstände für eine längere Zeit zu besetzen.

• Halte nur die nötigen Werte in der Speicher.

  Zum Beispiel für ein Auktionshaus-Erlebnis musst du nur den höchsten Bid aufrechterhalten. Du kannst MemoryStoreQueue:UpdateAsync() auf einem Schlüssel verwenden, um den höchsten Bid zu behalten, anstatt alle Bids in deiner Datenstruktur zu halten.

• Verwende exponentielle Rückgänge, um bei der API-Anforderungsgrenze zu bleiben.

  Zum Beispiel, wenn Sie eine DataUpdateConflict erhalten, versuchen Sie es nach zwei Sekunden, dann vier, acht usw. anstatt ständig Anfragen an Class.MemoryStoreService zu senden, um die richtige Antwort zu erhalten.

• Teile riesige Datenstrukturen in mehrere kleinere Strukturen auf, indem Sie sie mit Segmentieren aufteilen.

  Es ist oft einfacher, Daten in kleineren Strukturen zu verwalten, als alles in einer großen Datenstruktur zu speichern. Dieser Ansatz kann auch dazu beitragen, Verwendungslimits zu vermeiden. Zum Beispiel, wenn Sie eine sortierte Karte haben, die Präfixe für ihre Schlüssel verwendet, können Sie jeden Präfix in seine eigene sortierte Karte aufteilen. Für ein besonders beliebtes Erlebnis können Sie sogar Benutzer in mehrere Karten basierend auf den letzten Zahlen

• Komprimierte gespeicherte Werte.

  Zum Beispiel, berücksichtigen Sie die Verwendung der LZW Algorithmus, um die Größe des gespeicherten Werte zu reduzieren.

Observierbarkeit

Das Observability-Dashboard bietet Insights und Analysen für die Überwachung und Fehlerbehebung Ihrer Erinnerungsstores. Mit Echtzeit-Updates auf verschiedenen Aspekten Ihrer Erinnerungsstores und API-Anfragen können Sie die Erinnerungsnutzungsmuster Ihres Erlebnisses verfolgen, die zugewiesenen Quoten anzeigen, den API-Status überwachen und potenzielle Probleme für die Leistungsoptimierung identifizieren.

Die folgende Tabelle listet und beschreibt alle Status-Codes von API-Antworten, die auf der Request Count by Status und Requests by API x Status-Charts verfügbar sind. Weitere Informationen darüber, wie diese Fehler behoben werden, finden Sie unter Troubleshooting. Für die spezifische Quote oder Limit, zu dem ein Fehler gehört, siehe 2> Limits and Quotas

Die folgende Tabelle listet die Codes der Client-Seite, die derzeit nicht auf dem Observability-Dashboard verfügbar sind.

Problemlösung

Die folgende Tabelle listet und beschreibt die empfohlene Lösung für jeden Codes:

Testen und Debuggen in Studio

Die Daten in MemoryStoreService sind zwischen Studio und der Produktion isoliert, sodass die Änderung der Daten in Studio die Produktionsleistung nicht beeinflusst. Dies bedeutet, dass Ihre API-Aufrufe aus Studio keine Produktionsdaten zugreifen, so dass Sie sicher testen können, bevor Sie in die Produktion gehen.

Studio-Tests haben die gleichen Beschränkungen und Quoten wie die Produktion. Für Quoten, die basierend auf der Anzahl der Benutzer berechnet werden, kann die resultierende Quote sehr klein sein, da Sie der einzige Benutzer für Studio-Tests sind. Wenn Sie von Studio testen, bemerken Sie möglicherweise etwas höhere Latenz und erhöhte Fehlerraten im Vergleich zu der Verwendung in der Produktion aufgrund von einigen zusätzlichen Checks, die ausgeführt werden, um den

Für Informationen darüber, wie man einen Speicher auf Live-Erlebnissen oder beim Testen im Studio debuggt, verwende Entwicklerkonsole.