Pamięciowe magazyny

*Ta zawartość została przetłumaczona przy użyciu narzędzi AI (w wersji beta) i może zawierać błędy. Aby wyświetlić tę stronę w języku angielskim, kliknij tutaj.

MemoryStoreService to usługa danych o wysokiej przepustowości i niskim opóźnieniu, która zapewnia szybkie przechowywanie danych w pamięci dostępne ze wszystkich serwerów w aktywnej sesji. Pamięciowe magazyny są odpowiednie dla częstych i efemerycznych danych, które szybko się zmieniają i nie muszą być trwałe, ponieważ są szybsze w dostępie i znikają po osiągnięciu maksymalnego czasu życia. W przypadku danych, które muszą być trwałe między sesjami, użyj magazynów danych.

Struktury danych

Zamiast bezpośrednio uzyskiwać dostęp do surowych danych, pamięciowe magazyny mają trzy podstawowe struktury danych współdzielone między serwerami w celu szybkiego przetwarzania: posortowana mapa, kolejka i mapa haszująca. Każda struktura danych jest dobrze dopasowana do określonych przypadków użycia:

  • Dopasowywanie oparte na umiejętnościach - Zapisz informacje o użytkownikach, takie jak poziom umiejętności, w współdzielonej kolejce między serwerami i użyj serwerów lobby do okresowego przeprowadzania dopasowań.
  • Handel i aukcje między serwerami - Umożliw uniwersalny handel między różnymi serwerami, gdzie użytkownicy mogą licytować przedmioty z cenami zmieniającymi się w czasie rzeczywistym, z posortowaną mapą par klucz-wartość.
  • Globalne rankingi - Przechowuj i aktualizuj rankingi użytkowników na współdzielonej tablicy wyników w posortowanej mapie.
  • Wspólne inwentarze - Zapisz przedmioty inwentarza i statystyki w współdzielonej mapie haszującej, gdzie użytkownicy mogą jednocześnie korzystać z przedmiotów inwentarza.
  • Cache dla danych trwałych - Synchronizuj i kopiuj swoje trwałe dane w magazynie danych do pamięciowej mapy haszującej, która może działać jako cache i poprawić wydajność twojej gry.

Ogólnie, jeśli potrzebujesz uzyskać dostęp do danych na podstawie konkretnego klucza, użyj mapy haszującej. Jeśli potrzebujesz, aby te dane były uporządkowane, użyj posortowanej mapy. Jeśli potrzebujesz przetwarzać swoje dane w określonej kolejności, użyj kolejki.

Limity i kwoty

Aby utrzymać skalowalność i wydajność systemu, pamięciowe magazyny mają kwoty użycia danych dla rozmiaru pamięci, żądań API i rozmiaru struktury danych.

Pamięciowe magazyny mają politykę usuwania opartą na czasie wygaśnięcia, znaną również jako czas życia (TTL). Przedmioty są usuwane po wygaśnięciu, a kwota pamięci jest zwalniana dla nowych wpisów. Gdy osiągniesz limit pamięci, wszystkie kolejne żądania zapisu nie powiodą się, aż przedmioty wygaśnie lub ręcznie je usuniesz.

Kwota rozmiaru pamięci

Kwota pamięci ogranicza całkowitą ilość pamięci, którą gra może zużywać. Nie jest to stała wartość; zamiast tego zmienia się w czasie w zależności od liczby użytkowników w grze zgodnie z formułą 64 KB + 1.2 KB * [liczba użytkowników]. Kwota dotyczy poziomu gry, a nie poziomu serwera.

Gdy użytkownicy dołączają do gry, dodatkowa kwota pamięci jest dostępna natychmiast. Gdy użytkownicy opuszczają grę, kwota nie zmniejsza się natychmiast. Istnieje okres śledzenia wynoszący osiem dni, zanim kwota zostanie ponownie oceniona na niższą wartość.

Po osiągnięciu limitu rozmiaru pamięci w twojej grze, wszelkie żądania API, które zwiększają rozmiar pamięci, zawsze się nie powiodą. Żądania, które zmniejszają lub nie zmieniają rozmiaru pamięci, nadal będą się powodzić.

Dzięki pulpitowi obserwowalności możesz w czasie rzeczywistym przeglądać kwotę rozmiaru pamięci swojej gry za pomocą wykresu Użycie pamięci.

Limity żądań API

Kwota jednostek żądań dotyczy wszystkich wywołań API MemoryStoreService. Ta kwota wynosi 1000 + 120 * [liczba jednoczesnych użytkowników] jednostek żądań na minutę.

Większość wywołań API zużywa tylko jedną jednostkę żądania, z kilkoma wyjątkami:

  • MemoryStoreSortedMap:GetRangeAsync()

    Zużywa jednostki w zależności od liczby zwróconych przedmiotów. Na przykład, jeśli ta metoda zwraca 10 przedmiotów, wywołanie liczy się jako 10 jednostek żądań. Jeśli zwraca pustą odpowiedź, liczy się jako jedna jednostka żądania.

  • MemoryStoreQueue:ReadAsync()

    Zużywa jednostki w zależności od liczby zwróconych przedmiotów, podobnie jak MemoryStoreSortedMap:GetRangeAsync(), ale zużywa dodatkową jednostkę co dwie sekundy podczas odczytu. Określ maksymalny czas odczytu za pomocą parametru waitTimeout.

  • MemoryStoreHashMap:UpdateAsync()

    Zużywa minimum dwie jednostki.

  • MemoryStoreHashMap:ListItemsAsync()

    Zużywa [liczba partycji skanowanych] + [przedmioty zwrócone] jednostek.

Kwota żądań jest również stosowana na poziomie gry, a nie na poziomie serwera. Zapewnia to elastyczność w alokacji żądań między serwerami, o ile całkowita szybkość żądań nie przekracza kwoty. Jeśli przekroczysz kwotę, otrzymasz odpowiedź o błędzie, gdy usługa ograniczy twoje żądania.

Dzięki funkcji obserwowalności możesz w czasie rzeczywistym przeglądać kwotę jednostek żądań swojej gry.

Limity rozmiaru struktury danych

Dla pojedynczej posortowanej mapy lub kolejki obowiązują następujące limity rozmiaru i liczby przedmiotów:

  • Maksymalna liczba przedmiotów: 1,000,000
  • Maksymalny całkowity rozmiar (w tym klucze dla posortowanej mapy): 100 MB

Limity na partycję

Zobacz limity na partycję.

Najlepsze praktyki

Aby utrzymać optymalny wzór użycia pamięci i uniknąć osiągnięcia limitów, stosuj się do tych najlepszych praktyk:

  • Usuwaj przetworzone przedmioty. Regularne czyszczenie odczytanych przedmiotów za pomocą metody MemoryStoreQueue:RemoveAsync() dla kolejek i MemoryStoreSortedMap:RemoveAsync() dla posortowanych map może zwolnić pamięć i utrzymać strukturę danych na bieżąco.

  • Ustaw czas wygaśnięcia na jak najkrótszy czas podczas dodawania danych. Chociaż domyślny czas wygaśnięcia wynosi 45 dni zarówno dla MemoryStoreQueue:AddAsync(), jak i MemoryStoreSortedMap:SetAsync(), ustawienie najkrótszego możliwego czasu może automatycznie oczyścić stare dane, aby zapobiec ich zapełnieniu twojej kwoty użycia pamięci.

    • Nie przechowuj dużej ilości danych z długim czasem wygaśnięcia, ponieważ ryzykujesz przekroczenie swojej kwoty pamięci i potencjalnie spowodowanie problemów, które mogą zniszczyć całą twoją grę.
    • Zawsze albo jawnie usuwaj niepotrzebne przedmioty, albo ustaw krótki czas wygaśnięcia przedmiotu.
    • Ogólnie rzecz biorąc, powinieneś używać jawnego usuwania do zwalniania pamięci, a wygaśnięcia przedmiotów jako mechanizmu zabezpieczającego, aby zapobiec zajmowaniu pamięci przez nieużywane przedmioty przez dłuższy czas.

  • Przechowuj w pamięci tylko niezbędne wartości.

    Na przykład, w grze o aukcjach, musisz tylko utrzymywać najwyższą ofertę. Możesz użyć MemoryStoreSortedMap:UpdateAsync() na jednym kluczu, aby utrzymać najwyższą ofertę, zamiast przechowywać wszystkie oferty w swojej strukturze danych.

  • Użyj ekspansywnego opóźnienia, aby pomóc pozostać poniżej limitów żądań API.

    Na przykład, jeśli otrzymasz DataUpdateConflict, możesz spróbować ponownie po dwóch sekundach, potem czterech, ośmiu itd., zamiast ciągle wysyłać żądania do MemoryStoreService, aby uzyskać poprawną odpowiedź.

  • Podziel ogromne struktury danych na mniejsze, stosując sharding.

    Często łatwiej jest zarządzać danymi w mniejszych strukturach niż przechowywać wszystko w jednej dużej strukturze danych. To podejście może również pomóc uniknąć limitów użycia i szybkości. Na przykład, jeśli masz posortowaną mapę, która używa prefiksów dla swoich kluczy, rozważ oddzielenie każdego prefiksu do własnej posortowanej mapy. W przypadku szczególnie popularnej gry możesz nawet podzielić użytkowników na wiele map w oparciu o ostatnie cyfry ich identyfikatorów użytkowników.

  • Shard często dostępne klucze w mapach haszujących z wieloma kopiami klucza, aby rozłożyć obciążenie.

  • Kompresuj przechowywane wartości.

    Na przykład, rozważ użycie algorytmu LZW do zmniejszenia rozmiaru przechowywanych wartości.

  • Zapisz się do Rozszerzonych Usług.

    Możesz zwiększyć swoje limity przechowywania i żądań, przystępując do Rozszerzonych Usług.

Obserwowalność

Pulpit Obserwowalności zapewnia wgląd i analizy do monitorowania i rozwiązywania problemów z użyciem twojego magazynu pamięci. Dzięki wykresom aktualizowanym w czasie rzeczywistym na różnych aspektach użycia pamięci i żądań API możesz śledzić wzór użycia pamięci swojej gry, przeglądać aktualnie przydzielone kwoty, monitorować status API i identyfikować potencjalne problemy w celu optymalizacji wydajności.

Poniższa tabela wymienia i opisuje wszystkie kody statusu odpowiedzi API dostępne na wykresach Liczba żądań według statusu i Żądania według API x Status na Pulpicie Obserwowalności. Aby uzyskać więcej informacji na temat rozwiązywania tych błędów, zobacz Rozwiązywanie problemów. Aby uzyskać szczegółową kwotę lub limit, do którego odnosi się błąd, zobacz Limity i kwoty.

Kod statusuOpis
SukcesSukces.
DataStructureMemoryOverLimitPrzekracza limit rozmiaru pamięci na poziomie struktury danych (100 MB).
DataUpdateConflictKonflikt z powodu równoczesnej aktualizacji.
AccessDeniedBrak uprawnień do dostępu do danych gry. To żądanie nie zużywa jednostek żądań ani nie wykorzystuje kwoty.
Błąd wewnętrznyBłąd wewnętrzny.
InvalidRequestŻądanie nie zawiera wymaganych informacji lub zawiera błędne informacje.
DataStructureItemsOverLimitPrzekracza limit liczby przedmiotów na poziomie struktury danych (1M).
NoItemFoundNie znaleziono przedmiotu w MemoryStoreQueue:ReadAsync() lub MemoryStoreSortedMap:UpdateAsync(). ReadAsync() sprawdza co 2 sekundy i zwraca ten kod statusu, aż znajdzie przedmioty w kolejce.
DataStructureRequestsOverLimitPrzekracza limit jednostek żądań na poziomie struktury danych (100,000 jednostek żądań na minutę).
PartitionRequestsOverLimitPrzekracza limit jednostek żądań na partycję.
TotalRequestsOverLimitPrzekracza limit jednostek żądań na poziomie uniwersum.
TotalMemoryOverLimitPrzekracza limit kwoty pamięci na poziomie uniwersum.
ItemValueSizeTooLargeRozmiar wartości przekracza limit (32 KB).

Poniższa tabela wymienia kody statusu z strony klienta, które obecnie nie są dostępne na Pulpicie Obserwowalności.

Kod statusuOpis
Błąd wewnętrznyBłąd wewnętrzny.
UnpublishedPlaceMusisz opublikować to miejsce, aby używać MemoryStoreService.
InvalidClientAccessMemoryStoreService musi być wywoływane z serwera.
InvalidExpirationTimePole 'expiration' musi być między 0 a 3,888,000.
InvalidRequestNie można przekonwertować wartości na json.
InvalidRequestNie można przekonwertować sortKey na prawidłową liczbę lub ciąg.
TransformCallbackFailedNie udało się wywołać funkcji zwrotnej transformacji.
RequestThrottledOstatnie żądania MemoryStores osiągnęły jeden lub więcej limitów.
UpdateConflictPrzekroczono maksymalną liczbę prób.

Rozwiązywanie problemów

Poniższa tabela wymienia i opisuje zalecane rozwiązanie dla każdego kodu statusu odpowiedzi:

BłądOpcje rozwiązywania problemów
DataStructureRequestsOverLimit / PartitionRequestsOverLimit
  • Dodaj lokalną pamięć podręczną, zapisując informacje do innej zmiennej i ponownie sprawdzając po pewnym czasie, na przykład 30 sekund.
  • Użyj wykresu Liczba żądań według statusu, aby zweryfikować, że otrzymujesz więcej odpowiedzi Sukces niż NoItemFound. Ogranicz liczbę razy, kiedy uderzasz w MemoryStoreService z nieudanym żądaniem.
  • Wprowadź krótki czas opóźnienia między żądaniami.
  • Stosuj się do najlepszych praktyk, w tym:
    • Shardowanie swoich struktur danych, jeśli otrzymujesz znaczną liczbę odpowiedzi DataStructureRequestsOverLimit/PartitionRequestsOverLimit.
    • Shardowanie kluczy mapy haszującej, jeśli otrzymujesz znaczną liczbę odpowiedzi PartitionRequestsOverLimit na wywołania mapy haszującej.
    • Zmniejszenie lub grupowanie wywołań do konkretnych struktur danych lub kluczy mapy haszującej, jeśli widzisz odpowiedzi PartitionRequestsOverLimit.
    • Wprowadzenie ekspansywnego opóźnienia, aby znaleźć rozsądny wskaźnik żądań do wysłania.
TotalRequestsOverLimit
DataStructureItemsOverLimit
DataStructureMemoryOverLimit
TotalMemoryOverLimit
DataUpdateConflict
  • Wprowadź krótki czas opóźnienia między żądaniami, aby uniknąć wielu żądań aktualizujących ten sam klucz w tym samym czasie.
  • Dla posortowanych map użyj funkcji zwrotnej w metodzie MemoryStoreSortedMap:UpdateAsync(), aby przerwać żądanie po pewnej liczbie prób, jak pokazuje poniższy przykład kodu:
    • Przykład przerywania żądania
    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("przedmiot to "..item.highestBid)

            return nil

        end, 1000)

    end

    

    placeBid("MyItem", 50)

    placeBid("MyItem", 40)

    print("gotowe")
  • Sprawdź, czy wywołujesz MemoryStoreService w sposób efektywny, aby uniknąć konfliktów. Idealnie, nie powinieneś nadmiernie wysyłać żądań.
  • Regularnie usuwaj przedmioty po ich odczycie, używając metody MemoryStoreQueue:RemoveAsync() dla kolejek i MemoryStoreSortedMap:RemoveAsync() dla posortowanych map.
Błąd wewnętrzny
InvalidRequest
  • Upewnij się, że zawierasz poprawne i ważne parametry w swoim żądaniu. Przykłady nieprawidłowych parametrów obejmują:
    • Pusty ciąg
    • Ciąg, który przekracza limit długości
ItemValueSizeTooLarge
  • Sharduj lub podziel wartość przedmiotu na wiele kluczy.
    • Aby zorganizować grupowane klucze, posortuj je alfabetycznie, dodając prefix do klucza.
  • Kodowanie lub kompresowanie przechowywanych wartości.

Testowanie i debugowanie w Studio

Dane w MemoryStoreService są izolowane między Studio a produkcją, więc zmiana danych w Studio nie wpływa na zachowanie produkcji. Oznacza to, że twoje wywołania API z Studio nie uzyskują dostępu do danych produkcyjnych, co pozwala na bezpieczne testowanie pamięciowych magazynów i nowych funkcji przed przejściem do produkcji.

Testowanie w Studio ma te same limity i kwoty co produkcja. W przypadku kwot obliczanych na podstawie liczby użytkowników, wynikowa kwota może być bardzo mała, ponieważ jesteś jedynym użytkownikiem podczas testowania w Studio. Podczas testowania z poziomu Studio możesz również zauważyć nieco wyższe opóźnienia i podwyższone wskaźniki błędów w porównaniu do użycia w produkcji z powodu dodatkowych kontroli, które są wykonywane w celu weryfikacji dostępu i uprawnień.

Aby uzyskać informacje na temat debugowania magazynu pamięci w grach na żywo lub podczas testowania w studio, użyj Konsoli dewelopera.

©2026 Roblox Corporation. Nazwa Roblox, logo Roblox oraz hasło „Powering Imagination” należą do naszych zarejestrowanych i niezarejestrowanych znaków towarowych na terenie Stanów Zjednoczonych oraz w innych krajach.
Warunki·Prywatność·Dostępność·Wsparcie
Polski