Speicherstände

*Dieser Inhalt wurde mit KI (Beta) übersetzt und kann Fehler enthalten. Um diese Seite auf Englisch zu sehen, klicke hier.

MemoryStoreService ist ein Hochleistungs- und niedrige Latenz-Datendienst, der schnellen In-Memory-Datenspeicher bietet, der von allen Servern in einer Live-Sitzung zugänglich ist. Speicherstände eignen sich für häufige und ephemerale Daten, die sich schnell ändern und nicht dauerhaft sein müssen, weil sie schneller zugänglich sind und beim Erreichen der maximalen Lebensdauer verschwinden.Für Daten, die über Sitzungen hinweg bestehen müssen, verwende Datenspeicher.

Datenstrukturen

Anstatt direkten Zugriff auf rohe Daten, haben Speicherstände drei primitive Datenstrukturen, die über Server hinweg für eine schnelle Verarbeitung geteilt werden: sortierte Karte, Warteschlange und Hash-Karte.Jede Datenstruktur passt gut zu bestimmten Anwendungsfällen:

  • Fähigkeitsbasiertes Matchmaking - Speichere Benutzerinformationen wie Stufein einer gemeinsamen Warteschlange zwischen Servern und nutze Lobby-Server, um das Matchmaking periodisch durchzuführen.
  • Cross-Server-Handel und Auktionen - Aktiviere universellen Handel zwischen verschiedenen Servern, wo Benutzer auf Artikel mit sich verändernden Echtzeitpreisen bieten können, mit einer sortierten Karte von Schlüssel-Wert-Paaren.
  • Globale Ranglisten - Speichern und aktualisieren Sie Benutzerbewertungen auf einer gemeinsamen Rangliste innerhalb einer sortierten Karte .
  • Gemeinsame Inventare - Speichere Inventarartikel und Statistiken in einer gemeinsamen Hash-Karte , wo Benutzer Inventarartikel gleichzeitig miteinander nutzen können.
  • Cache für dauerhafte Daten - Synchronisiere und kopiere deine dauerhaften Daten in einen Datenspeicher in eine Speichermap, die als Cache fungieren und die Erfüllungdeines Erlebnisses verbessern kann.

Im Allgemeinen, wenn Sie auf Daten zugreifen müssen, die auf einer bestimmten Schlüsselbasis basieren, verwenden Sie eine Hash-Karte.Wenn du diese Daten bestellen musst, verwende eine sortierte Karte.Wenn du deine Daten in einer bestimmten Reihenfolge verarbeiten musst, verwende eine Warteschlange.

Grenzen und Quoten

Um die Skalierbarkeit und Erfüllungaufrechtzuerhalten, verfügen Speicherstände über Datenverbrauchsgrenzen für die Speichergröße, API-Anfragen und die Datenstrukturgröße.

Speicherstände haben eine Räumungspolitik basierend auf Ablaufzeit, auch bekannt als Zeit zum Leben (TTL).Gegenstände werden nach Ablauf ihrer Laufzeit entfernt, und die Speicherplatzkapazität wird für neue Einträge freigegeben.Wenn du das Speicherlimit erreicht, scheitern alle nachfolgenden Schreibanfragen, bis die Elemente ablaufen oder du sie manuell löschst.

Speichergrößenquote

Die Speicherquote beschränkt die gesamte Menge an Speicher, die ein Erlebnis verbrauchen kann.Es ist kein festgelegter Wert.Stattdessen ändert es sich im Laufe der Zeit abhängig von der Anzahl der Benutzer im Erlebnis gemäß der folgenden Formel: 64KB + 1KB * [Anzahl der Benutzer] .Die Quote gilt auf der Erfahrungsebene statt auf der Stufe.

Wenn Benutzer der Erlebnisbeitreten, ist die zusätzliche Speicherquote sofort verfügbar.Wenn Benutzer die Erlebnisverlassen, reduziert sich die Quote nicht sofort.Es gibt eine Rückverfolgungsperiode von acht Tagen, bevor die Quote auf einen niedrigeren Wert neu bewertet wird.

Nachdem deine Erfahrung die Speichergrößenquote erreicht hat, scheitern alle API-Anfragen, die die Speichergröße erhöhen, immer.Anfragen, die die Speichergröße verringern oder nicht ändern, scheitern immer noch.

Mit dem Observability-Dashboard kannst du die Speichergrößenquote deiner Erfahrung in Echtzeit mit der Speicherverwendung -Tabelle anzeigen.

API-Anforderungslimits

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

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

  • MemoryStoreSortedMap:GetRangeAsync()

    Verbraucht Einheiten basierend auf der Anzahl der zurückgegebenen Artikel.Wenn diese Methode beispielsweise 10 Elemente zurückgibt, gilt der Anruf als 10 Anforderungseinheiten.Wenn es eine leere Antwort zurückgibt, zählt es als eine Anforderungseinheit.

  • MemoryStoreQueue:ReadAsync()

    Verbraucht Einheiten basierend auf der Anzahl der zurückgegebenen Artikel, genau wie MemoryStoreSortedMap:GetRangeAsync(), verbraucht aber jede zweite Sekunde eine zusätzliche Einheit beim Lesen.Geben Sie die maximale Lesedauer mit dem waitTimeout -Parameter an.

  • MemoryStoreHashMap:UpdateAsync()

    Verbraucht mindestens zwei Einheiten.

  • MemoryStoreHashMap:ListItemsAsync()

    Verbraucht [Anzahl der gescannten Partitionen] + [Zurückgegebene Artikel] Einheiten.

Die Anforderungskuota wird auch auf der Erfahrungsebene anstelle des Stufeangewendet.Dies bietet Flexibilität, die Anfragen unter den Servern zu verteilen, solange die Gesamtanforderungsrate nicht die Quote überschreitet.Wenn du die Quote überschreitest, erhältst du eine Fehlerantwort, wenn der Dienst deine Anfragen drosselt.

Mit der Beobachtbarkeits-Funktion, die verfügbar ist, kannst du die Anforderungs-Einheiten-Quote deiner Erfahrung in Echtzeit anzeigen.

Datenstrukturgrößenbegrenzungen

Für eine einzige sortierte Karte oder Warteschlange gelten die folgenden Größen- und Artikelgrenzen:

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

Pro-Teilungsgrenzen

Siehe pro Partitionengrenzen.

Best Practices

Um Ihr Speicherverbrauchsmuster optimal zu halten und die Grenzen zu vermeiden, folgen Sie diesen Best Practices:

  • Entferne verarbeitete Elemente.: Konsistent aufräumen von gelesenen Elementen mit der MemoryStoreQueue:RemoveAsync()-Methode für Warteschlangen und MemoryStoreSortedMap:RemoveAsync() für sortierte Karten kann Speicher freigeben und die Datenstruktur auf dem neuesten Stand halten.

  • Leg die Verfallszeit auf die kleinste Zeitspanne fest, die beim Hinzufügen von Daten möglich ist. Obwohl die Standard-Verfallszeit für beide MemoryStoreQueue:AddAsync() und MemoryStoreSortedMap:SetAsync() 45 Tage beträgt, kann die Einstellung der kürzestmöglichen Zeit automatisch alte Daten löschen, um zu verhindern, dass sie Ihre Speicherplatzkapazität ausfüllen.

    • Lagere keine große Menge an Daten mit einer langen Laufzeit, da es die Gefahr birgt, deine Speicherquote zu überschreiten und möglicherweise Probleme zu verursachen, die dein gesamtes Erlebnis unterbrechen können.
    • Lösche immer explizit unnötige Elemente oder lege eine kurze Elementablaufzeit fest.
    • Im Allgemeinen solltest du explizite Löschung verwenden, um die Freigabe von Speicher und Artikelablauf als Sicherheitsmechanismus zu verwenden, um unbenutzte Gegenstände für einen längeren Zeitraum Speicher zu belegen.

  • Halte nur notwendige Werte in der Speicher.

    Zum Beispiel für ein Auktionshaus-Erlebnis musst du nur den höchsten Bieten aufrechterhalten.Du kannst MemoryStoreSortedMap:UpdateAsync() auf einen Schlüssel verwenden, um den höchsten Angebotspreis beizubehalten, anstatt alle Angebote in deiner Datenstruktur zu halten.

  • Verwende exponentialen Rückgang, um zu helfen, unter den API-Anforderungsgrenzen zu bleiben.

    Wenn du beispielsweise eine DataUpdateConflict erhältst, könntest du nach zwei Sekunden, dann vier, acht usw. erneut versuchen.anstatt ständig Anfragen an MemoryStoreService zu senden, um die richtige Antwort zu erhalten.

  • Teile riesige Datenstrukturen in mehrere kleinere Strukturen durch Sharding.

    Es ist oft einfacher, Daten in kleineren Strukturen zu verwalten, als alles in einer großen Datenstruktur zu speichern.Dieser Ansatz kann auch helfen, die Verwendung und die Rategrenzen zu vermeiden.Wenn du zum Beispiel eine sortierte Karte hast, die Präfixe für ihre Schlüssel verwendet, betrachte es, jedes Präfix in seine eigene sortierte Karte zu trennen.Für ein besonders beliebtes Erlebnis könnten Sie Benutzer sogar in mehrere Karten aufteilen, basierend auf den letzten Ziffern ihrer Benutzer-IDs.

  • Komprimiere gespeicherte Werte.

    Zum Beispiel, betrachte die Verwendung des LZW-Algorithmus, um die gespeicherte Wertegröße zu reduzieren.

Beobachtbarkeit

Das Observability-Dashboard liefert Einsicht und Analysen für die Überwachung und Fehlerbehebung der Nutzung deines Speicherlagers.Mit Echtzeit-Aktualisierungsdiagrammen zu verschiedenen Aspekten der Speicherverwendung und API-Anfragen kannst du das Speicherverbrauchsmuster deiner Erlebnisverfolgen, die derzeit zugewiesenen Quoten anzeigen, den API-Status überwachen und mögliche Probleme für die Leistungsoptimierung identifizieren.

Die folgende Tabelle listet und beschreibt alle Statuscodes von API-Antworten, die auf den Observability-Dashboards Anzahl der Anfragen nach Status und Anfragen durch API x Status verfügbar sind.Für weitere Informationen darüber, wie diese Fehler behoben werden, siehe Fehlerbehebung.Für die spezifische Quote oder das Limit, zu dem ein Fehler gehört, siehe Grenzen und Quoten.

CodesBeschreibung
ErfolgErfolg.
DatenstrukturgedächtnisüberlimitÜberschreitet die Datenstruktur-Speichergrößenbegrenzung (100MB).
DatenaktualisierungskonfliktKonflikt aufgrund gleichzeitiger Update.
Zugriff verweigertNicht autorisiert, auf Erfahrungsdaten zuzugreifen. Diese Anfrage verbraucht keine Anforderungseinheiten oder nutzt keine Quote.
Interner FehlerInterner Fehler.
Unzulässige AnfrageDie Anfrage hat keine erforderlichen Informationen oder enthält fehlerhafte Informationen.
Datenstrukturartikel über LimitÜberschreitet das Limit der Datenstrukturlevel-Artikelanzahl (1M).
Kein Item gefundenKein Artikel gefunden in MemoryStoreQueue:ReadAsync() oder MemoryStoreSortedMap:UpdateAsync(). ReadAsync() Umfragen alle 2 Sekunden und kehrt diesen Statuscode zurück, bis es Artikel in der Warteschlange findet.
Datenstrukturanfragen über LimitÜberschreitet das Datenstrukturlevel-Anforderungslimit (100.000 Anforderungen pro Minute).
Partitionanfragen über LimitÜberschreitet das Partitionsanforderungs-Limit.
Gesamtanfragen über LimitÜberschreitet das Limit der Anforderungseinheit auf Universumebene.
Gesamtspeicher über LimitÜberschreitet die Speicherquote auf Universumebene.
Artikelwertgröße zu großWertgröße überschreitet Limit (32KB).

Die folgende Tabelle listet Zustandscodes von der Clientseite auf, die derzeit nicht auf dem Observability-Dashboard verfügbar sind.

CodesBeschreibung
Interner FehlerInterner Fehler.
Unveröffentlichter OrtDu musst diesen Ort veröffentlichen, um MemoryStoreService zu verwenden.
Ungültiger Client-ZugriffMemoryStoreService muss vom Server ausgerufen werden.
Unzulässige VerfallszeitDie Feldzeit "Verfall" muss zwischen 0 und 3.888.000 liegen.
Unzulässige AnfrageWert kann nicht in json konvertiert werden.
Unzulässige AnfrageEs ist nicht möglich, sortKey in eine gültige Zahl oder Stringumzuwandeln.
TransformCallbackFehlgeschlagenFehler beim Aufruf der Transformations-Callback-Funktion.
Anfrage gedrosseltKürzliche Speicheranfragen von MemoryStores erreichten ein oder mehrere Grenzen.
AktualisierungskonfliktMaximale Anzahl an Wiederholungen überschritten.

Fehlersuche

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

FehlerFehlersuche-Optionen
Datenstrukturanfragen über Limit / Partitionsanfragen über Limit

  • Füge einen lokalen Cache hinzu, indem du Informationen in eine andere Variable speicherst und nach einem bestimmten Zeitintervall, wie z. B. 30 Sekunden, überprüfst.:
  • Verwenden Sie die Anfrageanzahl nach Status Grafik, um zu überprüfen, dass Sie mehr Erfolg -Antworten als NoItemFounds erhalten.Begrenze die Anzahl der Male, in denen du MemoryStoreService mit einer fehlgeschlagenen Anfrage triffst.:
    • Implementiere eine kurze Verzögerung zwischen Anfragen.: Folgen Sie den Best Practices, einschließlich:

    • Zerlegen Sie Ihre Datenstrukturen, wenn Sie eine erhebliche Menge von DataStructureRequestsOverLimit / PartitionRequestsOverLimit Antworten erhalten.:
    • Implementiere einen exponentiellen Rückgang für die Suche nach einer vernünftigen Anforderungsrate zum senden.
Gesamtanfragen über Limit
Datenstrukturartikel über Limit
Datenstrukturgedächtnisüberlimit
Gesamtspeicher über Limit
Datenaktualisierungskonflikt
  • Implementiere eine kurze Verzögerung zwischen Anfragen, um zu vermeiden, dass mehrere Anfragen gleichzeitig denselben Schlüssel aktualisieren.:
  • Für sortierte Karten verwende die Rückruffunktion auf der MemoryStoreSortedMap:UpdateAsync(), um eine Anfrage nach einer bestimmten Anzahl von Versuchen abzubrechen, wie das folgende Codebeispiel zeigt:
    • Example of Aborting Request
    local MemoryStoreService = game:GetService("MemoryStoreService")

    local map = MemoryStoreService:GetSortedMap("AuctionItems")

    

    function placeBid(itemKey, bidAmount)

        map:UpdateAsync(itemKey, function(item)

            item = item or { highestBid = 0 }

            if item.highestBid < bidAmount then

                item.highestBid = bidAmount

                return item

            end

            print("item is "..item.highestBid)

            return nil

        end, 1000)

    end

    

    placeBid("MyItem", 50)

    placeBid("MyItem", 40)

    print("done")
  • Untersuche, ob du MemoryStoreService effizient aufrufst, um Konflikte zu vermeiden.Idealerweise solltest du keine übermäßigen Anfragen senden.:
  • Entfernen Sie Knoten konsequent, sobald sie mit der Methode MemoryStoreQueue:RemoveAsync() für Warteschlangen und MemoryStoreSortedMap:RemoveAsync() für sortierte Karten gelesen wurden.
Interner Fehler
Unzulässige Anfrage
  • Stellen Sie sicher, dass Sie korrekte und gültige Parameter in Ihrer Anfrage enthalten. Beispiele für ungültige Parameter sind:
    • Eine leere Zeichenfolge
    • Eine Zeichenfolge, die die Längenbegrenzung überschreitet
Artikelwertgröße zu groß
  • Zerteile oder spalte den Artikelwert in mehrere Schlüssel auf.
    • Um gruppierte Schlüssel zu organisieren, ordne sie alphabetisch an, indem du ihnen einen prefix hinzufügst.
  • Verschlüsseln oder Komprimieren gespeicherter Werte.

Testen und debuggen im Studio

Die Daten in MemoryStoreService sind zwischen Studio und Produktion isoliert, so dass das Ändern der Daten in Studio nicht die Produktionsverhalten beeinflusst.Das bedeutet, dass Ihre API-Aufrufe aus Studio keine Produktionsdaten zugreifen, so dass Sie Speicherstände und neue Funktionen sicher testen können, bevor Sie in die Produktion gehen.

Studio-Tests haben die gleichen Grenzen und Quoten wie die Produktion.Für Quoten, die basierend auf der Anzahl der Benutzer berechnet werden, kann die resultierende Quote sehr gering sein, da du der einzige Benutzer für Studio-Tests bist.Wenn Sie von Studio aus testen, können Sie auch eine leicht höhere Latenz und eine erhöhte Fehlerrate im Vergleich zur Verwendung in der Produktion bemerken, die durch einige zusätzliche Überprüfungen verursacht werden, um den Zugriff und die Berechtigungen zu überprüfen.

Für Informationen darüber, wie du einen Speicherstand auf lebenden Erlebnissen oder beim Testen im Studio debuggst, verwende Entwickler-Konsole.