MemoryStoreService ist ein Hochdurchsatz- und latenzarmer Datenservice, der schnellen Zugriff auf im Arbeitsspeicher gespeicherte Daten von allen Servern in einer Live-Sitzung bietet. Speicher für Daten sind geeignet für häufige und flüchtige Daten, die sich schnell ändern und nicht dauerhaft sein müssen, da sie schneller zugänglich sind und verschwinden, wenn die maximale Lebensdauer erreicht ist. Für Daten, die über Sitzungen hinweg bestehen bleiben müssen, verwenden Sie Datenbanken.
Datenstrukturen
Anstatt direkt auf Rohdaten zuzugreifen, verfügen Speicher für Daten über drei primitive Datenstrukturen, die serverübergreifend für eine schnelle Verarbeitung geteilt werden: sortierte Karte, Warteschlange und Hash-Karte. Jede Datenstruktur eignet sich gut für bestimmte Anwendungsfälle:
- Fähigkeitsbasiertes Matchmaking - Speichern Sie Benutzerinformationen, wie z.B. Fähigkeitslevel, in einer gemeinsamen Warteschlange zwischen Servern und verwenden Sie Lobby-Server, um das Matchmaking regelmäßig durchzuführen.
- Serverübergreifender Handel und Auktionen - Ermöglichen Sie universellen Handel zwischen verschiedenen Servern, bei dem Benutzer auf Artikel mit sich in Echtzeit ändernden Preisen bieten können, mit einer sortierten Karte von Schlüssel-Wert-Paaren.
- Globale Bestenlisten - Speichern und aktualisieren Sie Benutzer-Rankings auf einer gemeinsamen Bestenliste innerhalb einer sortierten Karte.
- Geteilte Inventare - Speichern Sie Inventarartikel und Statistiken in einer gemeinsamen Hash-Karte, in der Benutzer Inventarartikel gleichzeitig nutzen können.
- Cache für persistente Daten - Synchronisieren und kopieren Sie Ihre persistenten Daten in einer Datenbank in eine Speicher für Daten Hash-Karte, die als Cache fungieren kann und die Leistung Ihres Spiels verbessert.
Im Allgemeinen, wenn Sie auf Daten basierend auf einem bestimmten Schlüssel zugreifen müssen, verwenden Sie eine Hash-Karte. Wenn Sie möchten, dass diese Daten geordnet sind, verwenden Sie eine sortierte Karte. Wenn Sie Ihre Daten in einer bestimmten Reihenfolge verarbeiten müssen, verwenden Sie eine Warteschlange.
Grenzen und Quoten
Um die Skalierbarkeit und Systemleistung aufrechtzuerhalten, haben Speicher für Daten Nutzungsquoten für die Speicherkapazität, API-Anfragen und die Größe der Datenstruktur.
Speicher für Daten haben eine Räumungspolitik basierend auf der Ablaufzeit, auch bekannt als Lebensdauer (TTL). Artikel werden nach Ablauf ihrer Frist geräumt, und der Speicherplatz wird für neue Einträge freigegeben. Wenn Sie das Speicherkontingent erreichen, schlagen Anfragen, die den Speicherbedarf erhöhen, fehl, bis Sie Speicher freigeben oder Ihr Kontingent erhöhen. Siehe Wiederherstellen von Speicherquotenerschöpfung für Optionen.
Speicherkapazitätsquote
Die Speicherkapazitätsquote begrenzt die Gesamtmenge an Speicher, die ein Spiel verbrauchen kann. Es handelt sich nicht um einen festen Wert; stattdessen ändert er sich im Laufe der Zeit abhängig von der Anzahl der Benutzer im Spiel gemäß der Formel 64 KB + 1,2 KB * [Anzahl der Benutzer]. Die Quote gilt auf Spielebene und nicht auf Serverebene.
Wenn Benutzer dem Spiel beitreten, ist das zusätzliche Speicherkontingent sofort verfügbar. Wenn Benutzer das Spiel verlassen, wird das Kontingent nicht sofort reduziert. Es gibt eine Rückverfolgbarkeitsperiode von acht Tagen, bevor das Kontingent auf einen niedrigeren Wert neu bewertet wird.
Nachdem Ihr Spiel das Speicherkapazitätskontingent erreicht hat, schlagen alle API-Anfragen, die die Speicherkapazität erhöhen, fehl. Anfragen, die die Speicherkapazität verringern oder nicht ändern, sind weiterhin erfolgreich.
Mit dem Beobachtungs- Dashboard können Sie die Speicherkapazitätsquote Ihres Spiels in Echtzeit mit dem Diagramm Speichernutzung anzeigen.
API-Anfragegrenzen
Eine Anfrageeinheit-Quote gilt für alle MemoryStoreService API-Aufrufe. Diese Quote beträgt 1000 + 120 * [Anzahl der gleichzeitigen Benutzer] Anfrageeinheiten pro Minute.
Die meisten API-Aufrufe verbrauchen nur eine Anfrageeinheit, mit einigen Ausnahmen:
MemoryStoreSortedMap:GetRangeAsync()
Verbraucht Einheiten basierend auf der Anzahl der zurückgegebenen Artikel. Wenn diese Methode beispielsweise 10 Artikel zurückgibt, zählt der Aufruf als 10 Anfrageeinheiten. Wenn sie eine leere Antwort zurückgibt, zählt sie als eine Anfrageeinheit.
Verbraucht Einheiten basierend auf der Anzahl der zurückgegebenen Artikel, genau wie MemoryStoreSortedMap:GetRangeAsync(), verbraucht jedoch alle zwei Sekunden eine zusätzliche Einheit während des Lesens. Geben Sie die maximale Lesezeit mit dem Parameter waitTimeout an.
MemoryStoreHashMap:UpdateAsync()
Verbraucht mindestens zwei Einheiten.
MemoryStoreHashMap:ListItemsAsync()
Verbraucht [Anzahl der gescannten Partitionen] + [zurückgegebene Artikel] Einheiten.
Die Anfragenquote gilt ebenfalls auf Spielebene und nicht auf Serverebene. Dies bietet Flexibilität, um die Anfragen zwischen Servern zu verteilen, solange die gesamte Anfragequote nicht überschritten wird. Wenn Sie die Quote überschreiten, erhalten Sie eine Fehlermeldung, wenn der Dienst Ihre Anfragen drosselt.
Mit der verfügbaren Beobachtungs- Funktion können Sie die Anfrageeinheitenquote Ihres Spiels in Echtzeit anzeigen.
Größenbeschränkungen der Datenstruktur
Für eine einzelne sortierte Karte oder Warteschlange gelten die folgenden Größen- und Artikelanzahlgrenzen:
- Maximale Anzahl von Artikeln: 1.000.000
- Maximale Gesamtgröße (einschließlich Schlüssel für die sortierte Karte): 100 MB
Pro-Partition-Grenzen
Zusätzlich zur Anfrageeinheitquote auf Spielebene wenden Speicher für Daten Anfragegrenzen auf jede Partition an, um die Stabilität des Dienstes für alle Spiele zu schützen. Diese Grenzen sind kein Kontingent, das Ihrem Spiel zugewiesen ist, und sie sind kein harter Deckel für den Durchsatz, den Ihr Spiel erreichen kann. Die folgenden Werte sind Schätzungen. Sie sind im Roblox-Backend konfiguriert und können sich ändern, also entwerfen Sie nicht gegen sie als feste Zahlen.
Jede Anfrage zählt zur Grenze der Partition, die den Artikel enthält, unabhängig von der Datenstruktur. Derzeit können Sie erwarten, dass die Drosselung bei etwa 30.000 Anfrageeinheiten pro Minute für eine einzelne Partition beginnt, also zielen Sie darauf ab, deutlich unter dieser Rate zu bleiben. Wie viel von diesem Limit eine Datenstruktur verbraucht, hängt davon ab, wie ihre Artikel verteilt sind:
- Sortierte Karten und Warteschlangen befinden sich jeweils auf einer einzelnen Partition, sodass jede Anfrage an eine dieser Datenstrukturen zur gleichen Partitiongrenze zählt.
- Hash-Karten verteilen ihre Artikel über viele Partitionen, sodass der Datenverkehr, der sich über viele Artikel-Schlüssel verteilt, selten die Grenze einer einzelnen Partition erreicht.
Hash-Karten haben eine zusätzliche Grenze von etwa 5.000 Schreibanfrageeinheiten pro Minute und 15.000 Leseanfrageeinheiten pro Minute für jeden Artikel-Schlüssel. Diese pro-Schlüssel-Grenze gilt zusätzlich zur pro-Partition-Grenze, sodass ein häufig zugänglicher Schlüssel entweder die eine oder die andere erreichen kann. Die pro-Schlüssel-Grenze gilt nur für Einzel-Schlüssel-Operationen: Die Lesegrenze gilt für MemoryStoreHashMap:GetAsync(), die Schreibgrenze gilt für MemoryStoreHashMap:SetAsync() und MemoryStoreHashMap:RemoveAsync(), und MemoryStoreHashMap:UpdateAsync() zählt sowohl gegen die Lese- als auch die Schreibgrenzen. MemoryStoreHashMap:ListItemsAsync() scannt Partitionen anstelle eines einzelnen Schlüssels, sodass nur die pro-Partition-Grenze für sie gilt.
Wenn Sie keine Sortierung oder FIFO-Funktionalität benötigen, ist eine Hash-Karte normalerweise die beste Wahl, da sie die Last über Partitionen verteilen kann.
Wenn Anfragen eine Partition oder pro-Schlüssel-Grenze überschreiten, drosselt der Dienst sie und gibt einen Statuscode PartitionRequestsOverLimit zurück, den Sie mit dem Beobachtungs- Dashboard überwachen können.
Wenn Sie erwarten, dass eine Datenstruktur oder ein Artikel-Schlüssel eine hohe, nachhaltige Anfragequote erhält, sharden Sie sie, damit die Last über mehr Partitionen oder Schlüssel verteilt wird. Verteilen Sie Lese- und Schreibvorgänge gleichmäßig über mehrere Artikel-Schlüssel, um innerhalb der pro-Schlüssel-Grenzen zu bleiben. Sie können auch die Anfragequote reduzieren, indem Sie Werte auf dem Server zwischenspeichern und sie nach einem Intervall erneut überprüfen, Anfragen wo möglich bündeln und exponentielle Rückoff anwenden, wenn Sie Drosselungsantworten erhalten.
Wir bemühen uns, so transparent wie möglich über die Ratenlimits zu sein, aber zusätzliche, nicht dokumentierte Limits könnten gelten, einschließlich für DDoS-Schutz und Dienststabilität. Stellen Sie immer sicher, dass Ihr Spiel Drosselungsantworten behandelt. Siehe Fehlerbehebung für Anleitungen.
Wenn Sie ein nicht dokumentiertes Ratenlimit erreichen, das Ihren Anwendungsfall blockiert (oder Sie höhere Limits wünschen), hinterlassen Sie Feedback, in dem Sie Ihre Bedürfnisse im Entwicklerforum erklären.
Wiederherstellen von Speicherquotenerschöpfung
Wenn Ihr Spiel TotalMemoryOverLimit Fehler erhält, überprüfen Sie das Diagramm Speichernutzung im Beobachtungs-Dashboard. Um Schreibvorgänge, die den Speicherbedarf erhöhen, wieder aufzunehmen, löschen Sie nicht benötigte Artikel, warten Sie, bis Artikel ablaufen, oder verwenden Sie eine der folgenden Optionen.
Speicher für Daten mit Open Cloud leeren
Wenn Sie die gespeicherten Daten nicht mehr benötigen, verwenden Sie den Open Cloud Speicher für Daten leeren Endpunkt, um alle Speicher für Daten-Datenstrukturen in einem Universum asynchron zu löschen.
Ein Leeren löscht alle Warteschlangen, sortierten Karten und Hash-Karten im ausgewählten Geltungsbereich, nicht nur eine einzelne Datenstruktur. Dies umfasst Daten, die Live-Funktionen wie Matchmaking oder Handel möglicherweise noch benötigen. Leeren Sie nur, wenn Ihr Spiel ohne diese Daten betrieben werden kann.
Um Speicher für Daten zu leeren:
- Erstellen Sie einen API-Schlüssel mit Berechtigungen zum Leeren von Speichern für Daten und zum Abrufen des Status der Leereoperation für das Zieluniversum.
- Senden Sie eine POST Anfrage an https://apis.roblox.test1709.icu/cloud/v2/universes/{universe_id}/memory-store:flush mit dem API-Schlüssel im x-api-key Header. Ersetzen Sie {universe_id} durch die Universum-ID Ihres Spiels. Setzen Sie den scope Abfrageparameter auf LIVE für Produktionsdaten oder TEST für Studiendaten. Wenn Sie scope weglassen, verwendet der Endpunkt LIVE.
- Verwenden Sie Get Memory Store Flush Operation, um die von der Leereanfrage zurückgegebene Operation zu überwachen, bis done true ist, und überprüfen Sie auf einen error. Verwenden Sie denselben Geltungsbereich beim Abfragen. Der zurückgegebene path enthält bereits cloud/v2, also fragen Sie bei https://apis.roblox.test1709.icu/{path} ab, ohne ein weiteres Präfix hinzuzufügen.
Studio- und Produktionsspeicher für Daten sind isoliert. Das Leeren eines Geltungsbereichs löscht nicht den anderen. Nachdem Sie nicht benötigte Daten gelöscht haben, befolgen Sie die Best Practices, wie kürzere Ablaufzeiten und explizite Löschungen, um zu verhindern, dass die Speichernutzung erneut das Kontingent erreicht.
Kapazität erhöhen mit erweiterten Diensten
Wenn Ihr Spiel die Daten behalten und mehr Speicher verwenden muss, als das Standardkontingent zulässt, aktivieren Sie Erweiterte Dienste für Speicher für Daten. Erweiterte Dienste ermöglichen es Ihnen, für Speicher für Daten-Speicher und Anfragen über die Standardquoten hinaus zu zahlen.
Um zu beginnen, erfüllen Sie die Berechtigungsvoraussetzungen, fügen Sie Kontodaten und eine Zahlungsmethode hinzu und wählen Sie dann Ihr Spiel im Creator Dashboard aus. Aktivieren Sie unter Erweiterte Dienste die Speicher für Daten und setzen Sie monatliche Budgets für die benötigten Ressourcen. Siehe Einen Dienst aktivieren und Preise für Dienste für Details.
Erweiterte Dienste drosseln den Dienst, wenn die Nutzung Ihr Budget überschreitet. Überwachen Sie die Nutzung und Abrechnung und fahren Sie fort, nicht benötigte Daten zu entfernen.
Best Practices
Um Ihr Muster der Speichernutzung optimal zu halten und zu vermeiden, dass Sie die Grenzen überschreiten, befolgen Sie diese Best Practices:
Entfernen Sie verarbeitete Artikel. Durch konsequentes Aufräumen von gelesenen Artikeln mit der Methode MemoryStoreQueue:RemoveAsync() für Warteschlangen und MemoryStoreSortedMap:RemoveAsync() für sortierte Karten können Sie Speicher freigeben und die Datenstruktur aktuell halten.
Setzen Sie die Ablaufzeit auf den kleinsten möglichen Zeitraum, wenn Sie Daten hinzufügen. Obwohl die Standardablaufzeit für sowohl MemoryStoreQueue:AddAsync() als auch MemoryStoreSortedMap:SetAsync() 45 Tage beträgt, kann das Setzen der kürzest möglichen Zeit automatisch alte Daten aufräumen, um zu verhindern, dass sie Ihr Speicherkontingent füllen.
- Speichern Sie keine große Menge an Daten mit einer langen Ablaufzeit, da dies das Risiko birgt, Ihr Speicherkontingent zu überschreiten und potenziell Probleme zu verursachen, die Ihr gesamtes Spiel brechen können.
- Löschen Sie immer entweder explizit nicht benötigte Artikel oder setzen Sie eine kurze Artikelablaufzeit.
- Im Allgemeinen sollten Sie explizite Löschungen verwenden, um Speicher freizugeben, und die Artikelablaufzeit als Sicherheitsmechanismus, um zu verhindern, dass ungenutzte Artikel über einen längeren Zeitraum Speicher belegen.
Halten Sie nur notwendige Werte im Speicher.
Zum Beispiel, für ein Auktionshaus-Spiel müssen Sie nur das höchste Gebot aufrechterhalten. Sie können MemoryStoreSortedMap:UpdateAsync() für einen Schlüssel verwenden, um das höchste Gebot zu halten, anstatt alle Gebote in Ihrer Datenstruktur zu speichern.
Verwenden Sie exponentielle Rückoff, um unter den API-Anfragegrenzen zu bleiben.
Wenn Sie beispielsweise eine DataUpdateConflict erhalten, könnten Sie nach zwei Sekunden erneut versuchen, dann vier, acht usw., anstatt ständig Anfragen an MemoryStoreService zu senden, um die richtige Antwort zu erhalten.
Teilen Sie riesige Datenstrukturen in mehrere kleinere auf, indem Sie sharden.
Es ist oft einfacher, Daten in kleineren Strukturen zu verwalten, als alles in einer großen Datenstruktur zu speichern. Dieser Ansatz kann auch helfen, Nutzungs- und Ratenlimits zu vermeiden. Wenn Sie beispielsweise eine sortierte Karte haben, die Präfixe für ihre Schlüssel verwendet, sollten Sie in Betracht ziehen, jedes Präfix in seine eigene sortierte Karte zu trennen. Für ein besonders beliebtes Spiel könnten Sie sogar Benutzer in mehrere Karten basierend auf den letzten Ziffern ihrer Benutzer-IDs aufteilen.
Sharden häufig zugängliche Schlüssel in Hash-Karten mit mehreren Kopien des Schlüssels, um die Last zu verteilen.
Komprimieren Sie gespeicherte Werte.
Erwägen Sie beispielsweise die Verwendung des LZW Algorithmus, um die Größe der gespeicherten Werte zu reduzieren.
Melden Sie sich für erweiterte Dienste an.
Für Speicher- oder Anfrageverwendungen, die über die Standardquoten hinausgehen, aktivieren Sie erweiterte Dienste für Speicher für Daten.
Beobachtbarkeit
Das Beobachtungs-Dashboard bietet Einblicke und Analysen zur Überwachung und Fehlerbehebung Ihrer Speichernutzung. Mit in Echtzeit aktualisierten Diagrammen zu verschiedenen Aspekten Ihrer Speichernutzung und API-Anfragen können Sie das Muster der Speichernutzung Ihres Spiels verfolgen, die aktuellen zugewiesenen Quoten anzeigen, den API-Status überwachen und potenzielle Probleme zur Leistungsoptimierung identifizieren.
Die folgende Tabelle listet und beschreibt alle Statuscodes der API-Antworten, die auf den Diagrammen Anzahl der Anfragen nach Status und Anfragen nach API x Status im Beobachtungs-Dashboard verfügbar sind. Für weitere Informationen zur Behebung dieser Fehler siehe Fehlerbehebung. Für das spezifische Kontingent oder Limit, auf das sich ein Fehler bezieht, siehe Grenzen und Quoten.
| Statuscode | Beschreibung |
|---|---|
| Erfolg | Erfolg. |
| DataStructureMemoryOverLimit | Überschreitet das Speichergrößenlimit auf Datenstrukturebene (100 MB). |
| DataUpdateConflict | Konflikt aufgrund gleichzeitiger Aktualisierung. |
| ZugriffVerweigert | Unbefugt, auf Spieldaten zuzugreifen. Diese Anfrage verbraucht keine Anfrageeinheiten oder nutzt das Kontingent. |
| InternerFehler | Interner Fehler. |
| UngültigeAnfrage | Die Anfrage enthält nicht die erforderlichen Informationen oder hat fehlerhafte Informationen. |
| DataStructureItemsOverLimit | Überschreitet das Limit der Artikelanzahl auf Datenstrukturebene (1M). |
| KeinArtikelGefunden | Kein Artikel in MemoryStoreQueue:ReadAsync() oder MemoryStoreSortedMap:UpdateAsync() gefunden. ReadAsync() fragt alle 2 Sekunden ab und gibt diesen Statuscode zurück, bis Artikel in der Warteschlange gefunden werden. |
| DataStructureRequestsOverLimit | Überschreitet das Limit der Anfrageeinheiten auf Datenstrukturebene (100.000 Anfrageeinheiten pro Minute). |
| PartitionRequestsOverLimit | Überschreitet ein Pro-Partition- oder Pro-Schlüssel-Anfrageeinheitenlimit. |
| TotalRequestsOverLimit | Überschreitet das universelle Anfrageeinheitenlimit. |
| TotalMemoryOverLimit | Überschreitet das universelle Speicherkontingent. |
| ItemValueSizeTooLarge | Wertgröße überschreitet das Limit (32 KB). |
Die folgende Tabelle listet Statuscodes von der Client-Seite auf, die derzeit nicht im Beobachtungs-Dashboard verfügbar sind.
| Statuscode | Beschreibung |
|---|---|
| InternerFehler | Interner Fehler. |
| UnveröffentlichtesPlatz | Sie müssen diesen Platz veröffentlichen, um MemoryStoreService zu verwenden. |
| UngültigerClientZugriff | MemoryStoreService muss vom Server aufgerufen werden. |
| UngültigeAblaufzeit | Das Feld 'Ablauf' muss zwischen 0 und 3.888.000 liegen. |
| UngültigeAnfrage | Wert kann nicht in JSON konvertiert werden. |
| UngültigeAnfrage | Sortierschlüssel kann nicht in eine gültige Zahl oder Zeichenfolge konvertiert werden. |
| TransformCallbackFailed | Fehler beim Aufrufen der Transformations-Callback-Funktion. |
| AnfrageGedrosselt | Neueste Anfragen an Speicher für Daten haben eines oder mehrere Limits erreicht. |
| AktualisierungsKonflikt | Maximale Anzahl an Wiederholungen überschritten. |
Fehlerbehebung
Die folgende Tabelle listet und beschreibt die empfohlenen Lösungen für jeden Antwortstatuscode:
| Fehler | Fehlerbehebungsoptionen |
|---|---|
| DataStructureRequestsOverLimit / PartitionRequestsOverLimit |
|
| TotalRequestsOverLimit | |
| DataStructureItemsOverLimit |
|
| DataStructureMemoryOverLimit | |
| TotalMemoryOverLimit |
|
| DataUpdateConflict |
Beispiel für das Abbrechen einer Anfrage |
| Interner Fehler |
|
| Ungültige Anfrage |
|
| ItemValueSizeTooLarge |
|
Testen und Debuggen im Studio
Die Daten in MemoryStoreService sind zwischen Studio und Produktion isoliert, sodass Änderungen an den Daten im Studio das Produktionsverhalten nicht beeinflussen. Das bedeutet, dass Ihre API-Aufrufe aus dem Studio nicht auf Produktionsdaten zugreifen, was es Ihnen ermöglicht, Speicher für Daten und neue Funktionen sicher zu testen, bevor Sie in die Produktion gehen.
Das Testen im Studio hat die gleichen Grenzen und Quoten wie die Produktion. Für Quoten, die auf der Anzahl der Benutzer basieren, kann das resultierende Kontingent sehr klein sein, da Sie der einzige Benutzer für das Studio-Testen sind. Wenn Sie aus dem Studio testen, können Sie auch eine leicht höhere Latenz und erhöhte Fehlerquoten im Vergleich zur Nutzung in der Produktion feststellen, da einige zusätzliche Überprüfungen durchgeführt werden, um den Zugriff und die Berechtigungen zu überprüfen.
Für Informationen, wie Sie einen Speicher für Daten in Live-Spielen oder beim Testen im Studio debuggen können, verwenden Sie die Entwicklerkonsole.