MemoryStoreService to usługa danych o dużej przepustowości i niskiej opóźnieniu, która zapewnia szybkie przechowywanie danych w pamięci dostępne z wszystkich serwerów w sesjana żywo. Pamięci są odpowiednie dla częstych i ephemeralnych danych, które szybko zm
結構數據
Zamiast bezpośrednio uzyskać dostęp do danych surowych, struktury danych pamięci mają trzy podstawowe struktury danych dzielone na serwerach do szybkiego przetwarzania: sortowana mapa, kolejka i Hash mapa. Każda struktura danych jest dobrym wyborem dla pewnych przypadków użycia:
- Matchmaking oparty na umiejętnościach - Zapisz informacje o użytkowniku, takie jak poziom umiejętności, w wspólnym kolejce pomiędzy serwerami i użyj serwerów lobby do prawidłowego przeprowadzania matchmaking'u.
- Krosstrading i aukcje serwera - Włącz uniwersalny handel między różnymi serwerami, gdzie użytkownicy mogą zaoferować przedmioty z całkowicie zmieniającymi się cenami w czasie rzeczywistym z wykorzystaniem sortowanej mapy z parami kluczowych.
- Globalne tabela wyników: - Przechowywanie i aktualizacja wyników użytkowników na globalnej tabeli wyników w ramach sortowanej mapy .
- Udostępnione inventarie - Zapisywaj przedmioty ekwipunku i statystyki w udostępnionym hasz mapie , gdzie użytkownicy mogą wykorzystywać przedmioty ekwipunku równocześnie z innymi.
- Cache for Persistent Data - Synchronizuj i kopiuj swoje trwałe dane w magazynie danych do pamięci w mapie hash , która może działać jako kopia i poprawić wykonywanieswojego doświadczenia.
ogólnerzecz biorąc, jeśli musisz uzyskać dostęp do danych opartych na określonym kluczu, użyj mapy hasz. Jeśli potrzebujesz tych danych w określonej kolejności, użyj sortowanej mapy. Jeśli potrzebujesz przetworzyć te dane w określonej kolejności, użyj kolejki.
Ograniczenia i kwoty
Aby zachować skalowalność i wykonywaniesystemu, wymagania dotyczące użycia pamięci dla rozmiaru pamięci, wniosków API i rozmiaru struktury danych są dostępne w plikach cookie.
Przechowywanie pamięci ma politykę wykluczenia w oparciu o czas wygasania, również znany jako czas życia (TTL). Przedmioty są wykluczone po wygasaniu, a limit pamięci jest uwolniony dla nowych wpisów. Gdy dotykasz limitu pamięci, wszystkie następne wysyłania wpisów zakończą się, dopóki przedmioty nie wygasną lub nie usuniesz ich ręcznie.
Quoty rozmiarów pamięci
Limit ilości pamięci, jaki może zużyć doświadczenie, jest stały. Nie jest to stałe wartość. Zamiast tego zmienia się on w czasie w zależności od liczby użytkowników w doświadczeniu według następującej formuły: 64KB + 1KB * [number użytkowników] . Limit obowiązuje na poziomie doświadczenia, a nie na poziomie serwera.
Gdy użytkownicy doświadczenia dołączą, dostępna jest natychmiastowa quota pamięci. Gdy użytkownicy opuścają doświadczenie, quota nie zostanie natychmiastowo zmniejszona. Istnieje okres śledzenia o ośmiu dni przed ponowną oceną quota do niższej wartości.
Po dotarciu twojego doświadczenia do limitu rozmiaru pamięci, wszystkie prośby API, które zwiększają rozmiar pamięci, zawsze kończą się niepowodzeniem. Prośby, które zmniejszają lub nie zmieniają rozmiaru pamięci, nadal zakończą się sukcesem.
Z użyciem dashboardu widoczności, możesz zobaczyć rozmiar pamięci swojego doświadczenia w czasie rzeczywistym za pomocą diagramu użycia pamięci.
Ograniczenia wymagań API
W przypadku ograniczeń API istnieje quota jednostka wniosku , która stosuje się do wszystkich wezwania API MemoryStoreService. Quota wynosi 1000 + 100 * [number of concurrent users] wnioski jednostki na minutę.
Większość wezwań API zużywa tylko jedną jednostkę wymiaru, z kilku wyjątków:
MemoryStoreSortedMap:GetRangeAsync()
Konsumuje jednostki w zależności od liczby zwróconych pozycji. Na przykład, jeśli ten metodzwracający liczby 10 pozycji, to konsumpcja liczona jest jako 10 jednostek wymagań. Jeśli zwraca pustą odpowiedź, to konsumpcja jest jedną jednostkę wymagań.
Konsumuje jednostki w zależności od liczby zwróconych pozycji, tak jak MemoryStoreSortedMap:GetRangeAsync(), ale konsumuje dodatkową jednostkę co 2 sekundy podczas czytania. Wprowadź czas czytania maksymalny z parametrem waitTimeout.
MemoryStoreHashMap:UpdateAsync()
Konsumuje minimum dwóch jednostek.
MemoryStoreHashMap:ListItemsAsync()
Konsumuje [liczba podziałek skanowanych] + [przedmioty zwrócone] jednostki.
Quoty wniosków są również stosowane na poziomie doświadczenia, a nie na poziomie serwera. Dzięki temu możliwe jest przypisanie wniosków na serwerach, o ile całkowita liczba wniosków nie przekracza limitu. Jeśli przekroczysz limit, otrzymasz odpowiedź błędu, gdy szybkość usługi przekracza limit.
Z funkcją dostępności dostępną, możesz wyświetlić quota jednostki wniosku swojego doświadczenia w czasie rzeczywistym.
Limitowanie rozmiarów struktury danych
Dla pojedynczej sortowanej mapy lub kolejki obowiązują następujące limity rozmiarów i liczby pozycji:
- Maksymalna liczba pozycji: 1,000,000
- Maksymalna wielkość całkowita (w tym klucze do sortowanej mapy): 100 MB
Ograniczenia perymentarne
Zobacz Ograniczenia perymentarne.
Najlepsze praktyki
Aby utrzymać wzór użycia pamięci i uniknąć trafienia w ograniczenia, postępuj zgodnie z tych najlepszych praktyk:
Usuń przetarte pozy. Ciągle czyszcząc czytane pozy używając metody MemoryStoreQueue:RemoveAsync() dla kolejek i MemoryStoreSortedMap:RemoveAsync() dla sortowanych map można uwolnić pamięć i utrzymać strukturę danych na bieżąco.
Ustaw czas wygasania na najmniejszy czas ramy czasowej możliwego przy dodawaniu danych. Meskie ustawienia czasu wygasania domyślnie trwają 45 dni dla obu MemoryStoreQueue:AddAsync() i MemoryStoreSortedMap:SetAsync(), ustawiając najkrótszy czas można automatycznie usunąć starych danych, aby zapobiec
- Nie przechowuj dużej ilości danych z długą datą ważności, ponieważ ryzykuje to przekroczenie twojego limitu pamięci i potencjalnie powoduje problemy, które mogą przerwać całe twoje doświadczenie.
- Zawsze albo wyraźnie usuń niepotrzebne przedmioty lub ustaw krótką ewentualność przedmiotu.
- Ogólnie rzecz biorąc, powinieneś używać wyraźnego usuwania, aby uwolnić pamięć i wygaszenie przedmiotu jako mechanizm bezpieczeństwa, aby zapobiec nieużytym przedmiotom zajmowanie pamięci przez dłuższy okres czasu.
Zachowuj tylko wymaganą wartość w pamięci.
Na przykład, dla doświadczenia aukcyjnego domu, musisz tylko utrzymać najwyższą ofertę. Możesz użyć MemoryStoreQueue:UpdateAsync() na jednym kluczu, aby utrzymać najwyższą ofertę, zamiast utrzymywania wszystkich ofert w swojej strukturze danych.
Użyj klauzury backoff, aby pomóc pozostać poniżej limitów wniosków API.
Na przykład, jeśli otrzymasz DataUpdateConflict, możesz spróbować ponownie po dwóch sekundach, a potem czterech, osiem itp. zamiast wysyłania stale żądań do 2>Class.MemoryStoreService2>, aby uzyskać poprawną odpowiedź.
Podziel duże struktury danych na wiele mniejszych przez dzielenie się .
O wiele łatwiej jest zarządzać danymi w mniejszych strukturach, zamiast przechowywania wszystkiego w jednej wielkiej strukturze danych. Ten podejście może również pomóc uniknąć ograniczeń użycia i stawki. Na przykład, jeśli masz sortowaną mapę, która używa prefixów dla swoich kluczy, rozważ z分离 każdego prefixu na jego własną sortowaną mapę.
Kompresja przechowywanych wartości.
Na przykład, rozważ algorytmu LZW, aby zmniejszyć rozmiar zapisu.
Obserwowalność
Dashboard Obszoności zapewnia wgląd i analitykę do monitorowania i rozwiązywania problemów z użyciem pamięci. Dzięki rzeczywistym aktualizacjom wykresów na różnych aspektach użycia pamięci i prośb API możesz śledzić wzór użycia pamięci Twojego doświadczenia, wyświetlić bieżące przydzielone kwoty i monitorować statusAPI, a następnie zidentyfikować pot
Poniższy tabela listuje i opisuje wszystkie kody statusu dostępne na obserwowalnym dashboardzie liczby żądań według statusu i wnioski API x Status . Dla więcej informacji na temat rozwiązania tych błędów, zobacz Troubleshooting . Dla określonego limitu lub ograniczenia, które dot
| Kod stanu | Opis |
|---|---|
| Sucess | Sucess. |
| Ograniczenie pamięci danych | Przekracza limit wielkości pamięci struktury danych (100 MB). |
| Konflikt aktualizacji danych | Konflikt z powodu równoczesnej aktualizacja. |
| DostępZakazany | Nieupoważniono do uzyskania danych doświadczenia. Ten wniosek nie konsumuje jednostek wymagań lub używa quota. |
| Wewnętrzny błąd | Wewnętrzny błąd. |
| Nieprawidłowy wniosek | Prośba nie ma wymaganymi informacjami lub ma nieprawidłowe informacje. |
| Przekroczenie limitu dla DataStructureItemsOverLimit | Przekracza limit liczby poziomów struktury danych (1M). |
| Nie znaleziono elementu | Nie znaleziono żadnego elementu w MemoryStoreQueue:ReadAsync() lub MemoryStoreSortedMap:UpdateAsync(). ReadAsync() ankiety co 2 sekundy i zwraca ten kod statusu, aż znajdzie przedmioty w kolejce. |
| Limit danych | Przekracza limit poziomu wymaganego interfejsu danych (100 000 jednostek wymagań na minutę). |
| Osiągnięto limit zapytań o podzielenie | Przekracza limit jednostki wnętrza podziału. |
| Ogólny limit wysyłanych prośb | Przekracza limit jednostki wysokiego poziomu wymagań. |
| Ogólny limit pamięci | Przekracza limit pamięci na poziomie wszechświata. |
| Zbyt duży rozmiar przedmiotu | Wielkość wartości przekracza limit (32KB). |
Poniższy tabela wymienia kody ze strony klienta, które są obecnie niedostępne na Dashboardzie widoczności.
| Kod stanu | Opis |
|---|---|
| Wewnętrzny błąd | Wewnętrzny błąd. |
| NieopublikowanyMiejsce | Musisz opublikować to miejsce, aby użyć MemoryStoreService. |
| Nieprawidłowy dostęp klienta | MemoryStoreService musi być wezwany z serwera. |
| Nieprawidłowy czas wygasania | Czas ważności pola 'expiry' musi być pomiędzy 0 i 3,888,000. |
| Nieprawidłowy wniosek | Nie można zmienić wartości na JSON. |
| Nieprawidłowy wniosek | Nie można przekonać klucza sortowania na ważną liczbę lub ciąg. |
| Nie powiodło się przetworzyć | Nie udało się zaimplementować funkcji zwrotu transformacji. |
| Zakręcony wniosek | Ostatnie wyspywania MemoryStores uderzyły jeden lub więcej ograniczeń. |
| Aktualizacja konfliktu | Przekroczono maksymalną liczbę prób. |
Rozwiązywanie problemów
Poniższy tabela wymienia i opisuje rekomendowany rozwiązań dla każdego kodu statusu odpowiedzi:
| Błąd | Opcje rozwiązywania problemów |
|---|---|
| DataStructureCommands / PartitionCommands |
|
| Ogólny limit wysyłanych prośb | |
| Przekroczenie limitu dla DataStructureItemsOverLimit |
|
| Ograniczenie pamięci danych | |
| Ogólny limit pamięci | |
| Konflikt aktualizacji danych | Wdrożenie krótkiego opóźnienia między wysyłanymi prośbami, aby uniknąć wielu prośb aktualizacji tego samego klucza w tym samym czasie. Dla sortowane mapy, użyj funkcji zwrotu Class.MemoryStoreQueue: |
| Wewnętrzny błąd |
Zapisz zgłoszenie o błąd, opisujące problem z Twoim doświadczeniem Universe ID. |
| Nieprawidłowy wniosek |
|
| Zbyt duży rozmiar przedmiotu |
|
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 wezwania API z Studio nie mają wpływu na zachowanie produkcji, co pozwala na bezpieczne testowanie magazynów pamięci i nowych funkcji przed wdrożeniem do produkcji.
Testy Studio mają te same ograniczenia i quoty co produkcja. Dla quoty obliczanej na liczbę użytkowników wynikająca z wyników testu może być bardzo mała, ponieważ jesteś jedynym użytkownikiem Studio testowania. Podczas testowania z Studio można również zauważyć nieco wyższą latencję i wysokie szybkości błędu w porównaniu do użycia w produkcji ze wzglę
Dla informacji o tym, jak debugować magazyn pamięci w czasie rzeczywistych doświadczeń lub podczas testów w studio, użyj Konsoli Rozwoju.