Bellek depoları

MemoryStoreService, canlı bir oturumda tüm sunuculardan erişilebilen hızlı bellek içi veri depolama sağlayan yüksek verimli ve düşük gecikmeli bir veri hizmetidir. Bellek Depoları, sık ve geçici veriler için uygundur; çünkü bu veriler hızla değişir ve kalıcı olmaları gerekmez, çünkü erişim açısından daha hızlıdırlar ve maksimum ömre ulaştıklarında kaybolurlar. Oturumlar arasında kalıcı olması gereken veriler için veri depolarını kullanın.

Veri yapıları

Ham verilere doğrudan erişmek yerine, bellek depoları hızlı işleme için sunucular arasında paylaşılan üç temel veri yapısına sahiptir: sıralı harita, kuyruk ve hash harita. Her veri yapısı belirli kullanım durumları için iyi bir uyum sağlar:

• Yetenek bazlı eşleştirme - Kullanıcı bilgilerini, örneğin yetenek seviyesini, sunucular arasında paylaşılan bir kuyrukta saklayın ve eşleştirmeyi periyodik olarak yürütmek için lobideki sunucuları kullanın.
• Sunucular arası ticaret ve açık artırma - Kullanıcıların gerçek zamanlı değişen fiyatlarla öğelere teklif verebileceği, farklı sunucular arasında evrensel ticareti etkinleştirin; bu, anahtar-değer çiftlerinin sıralı haritası ile yapılır.
• Küresel liderlik tabloları - Kullanıcı sıralamalarını paylaşılan bir liderlik tablosunda sıralı harita içinde saklayın ve güncelleyin.
• Paylaşılan envanterler - Kullanıcıların birbirleriyle eşzamanlı olarak envanter öğelerini kullanabileceği bir paylaşılan hash harita içinde envanter öğelerini ve istatistiklerini saklayın.
• Kalıcı Veriler için Önbellek - Kalıcı verilerinizi bir veri deposunda senkronize edin ve kopyalayın, böylece bir bellek deposu hash haritası olarak önbellek işlevi görebilir ve oyununuzun performansını artırabilir.

Genel olarak, belirli bir anahtara dayalı verilere erişmeniz gerekiyorsa, bir hash harita kullanın. Verinin sıralı olmasını istiyorsanız, bir sıralı harita kullanın. Verilerinizi belirli bir sırada işlemek istiyorsanız, bir kuyruk kullanın.

Sınırlamalar ve kotalar

Ölçeklenebilirliği ve sistem performansını korumak için, bellek depolarının bellek boyutu, API istekleri ve veri yapısı boyutu için veri kullanımı kotaları vardır.

Bellek depoları, son kullanma süresine dayalı bir tahliye politikası uygular; bu, yaşam süresi (TTL) olarak da bilinir. Öğeler süresi dolduğunda tahliye edilir ve bellek kotası yeni girişler için serbest bırakılır. Bellek sınırına ulaştığınızda, bellek kullanımını artıran istekler, bellek serbest bırakılana veya kotanızı artırana kadar başarısız olur. Seçenekler için bellek kotası tükenmesinden kurtulma bölümüne bakın.

Bellek boyutu kotası

Bellek kotası, bir oyunun tüketebileceği toplam bellek miktarını sınırlar. Bu sabit bir değer değildir; bunun yerine, oyundaki kullanıcı sayısına bağlı olarak zamanla değişir ve formül 64 KB + 1.2 KB * [kullanıcı sayısı] ile hesaplanır. Kota, sunucu düzeyinde değil, oyun düzeyinde uygulanır.

Kullanıcılar oyuna katıldığında, ek bellek kotası hemen kullanılabilir hale gelir. Kullanıcılar oyundan ayrıldığında, kota hemen düşmez. Kotanın daha düşük bir değere yeniden değerlendirilmesi için sekiz günlük bir geri izleme süresi vardır.

Oyununuza ait bellek boyutu kotasına ulaştığınızda, bellek boyutunu artıran herhangi bir API isteği her zaman başarısız olur. Bellek boyutunu azaltan veya değiştirmeyen istekler ise yine de başarılı olur.

Gözetim panosuyla, oyununuzun bellek boyutu kotasını gerçek zamanlı olarak Bellek Kullanımı grafiği ile görüntüleyebilirsiniz.

API istek sınırları

Bir istek birimi kotası, tüm MemoryStoreService API çağrılarına uygulanır. Bu kota, 1000 + 120 * [eşzamanlı kullanıcı sayısı] istek birimi olarak belirlenmiştir.

Çoğu API çağrısı yalnızca bir istek birimi tüketir, birkaç istisna dışında:

• MemoryStoreSortedMap:GetRangeAsync()

  Döndürülen öğe sayısına göre birim tüketir. Örneğin, bu yöntem 10 öğe döndürürse, çağrı 10 istek birimi olarak sayılır. Eğer boş bir yanıt dönerse, bu bir istek birimi olarak sayılır.

• MemoryStoreQueue:ReadAsync()

  Döndürülen öğe sayısına göre birim tüketir, MemoryStoreSortedMap:GetRangeAsync() ile aynı şekilde, ancak okuma sırasında her iki saniyede bir ek birim tüketir. Maksimum okuma süresini waitTimeout parametresi ile belirtin.

• MemoryStoreHashMap:UpdateAsync()

  En az iki birim tüketir.

• MemoryStoreHashMap:ListItemsAsync()

  [tarayıcı bölümleri] + [döndürülen öğeler] birim tüketir.

İstek kotası, sunucu düzeyinde değil, oyun düzeyinde de uygulanır. Bu, toplam istek oranı kotayı aşmadığı sürece sunucular arasında istekleri dağıtma esnekliği sağlar. Kota aşıldığında, isteklerinizi kısıtladığında bir hata yanıtı alırsınız.

Gözetim özelliği ile, oyununuzun istek birimi kotasını gerçek zamanlı olarak görüntüleyebilirsiniz.

Veri yapısı boyutu sınırları

Tek bir sıralı harita veya kuyruk için aşağıdaki boyut ve öğe sayısı sınırları geçerlidir:

• Maksimum öğe sayısı: 1,000,000
• Maksimum toplam boyut (sıralı harita için anahtarlar dahil): 100 MB

Bölüm başına sınırlar

Oyun düzeyindeki istek birimi kotası dışında, bellek depoları her bölüme istek sınırları uygular; bu, tüm oyunlar için hizmetin kararlılığını koruyan bir güvenlik önlemidir. Bu sınırlar, oyununuzun tahsis edilen bir kotası değildir ve oyununuzun ulaşabileceği verimlilikte sert bir tavan değildir. Aşağıdaki değerler tahminidir. Roblox arka uçta yapılandırılmıştır ve değişebilir, bu nedenle bunları sabit sayılar olarak tasarlamayın.

Her istek, öğeyi tutan bölüm sınırına sayılır; veri yapısı ne olursa olsun. Şu anda, tek bir bölüm için yaklaşık 30,000 istek birimi/dakika sınırına ulaşmayı bekleyebilirsiniz, bu nedenle bu oranı oldukça altında kalmaya çalışın. Bir veri yapısının ne kadar sınır tükettiği, öğelerinin nasıl dağıtıldığına bağlıdır:

• Sıralı haritalar ve kuyruklar, her biri tek bir bölümde yer alır, bu nedenle bu veri yapılarına yapılan her istek aynı bölüm sınırına sayılır.
• Hash haritaları, öğelerini birçok bölüme yayar, bu nedenle birçok öğe anahtarı arasında dağıtılan trafik, herhangi bir bölümün sınırına nadiren yaklaşır.

Hash haritalarının her öğe anahtarı için yaklaşık 5,000 yazma istek birimi/dakika ve 15,000 okuma istek birimi/dakika ek bir sınırı vardır. Bu anahtar başına sınır, bölüm başına sınırın üzerine uygulanır, bu nedenle sık erişilen bir anahtar her ikisini de aşabilir. Anahtar başına sınır yalnızca tek anahtar işlemlerine uygulanır: okuma sınırı MemoryStoreHashMap:GetAsync(), yazma sınırı MemoryStoreHashMap:SetAsync() ve MemoryStoreHashMap:RemoveAsync() için geçerlidir ve MemoryStoreHashMap:UpdateAsync() hem okuma hem de yazma sınırlarına karşı sayılır. MemoryStoreHashMap:ListItemsAsync() bölümleri tarar, bu nedenle yalnızca bölüm başına sınır buna uygulanır.

Eğer sıralama veya ilk giren ilk çıkar işlevselliğine ihtiyacınız yoksa, genellikle bir hash harita en iyi seçimdir çünkü yükü bölümler arasında yayabilir.

İstekler bir bölüm veya anahtar başına sınırı aştığında, hizmet bunları kısıtlar ve PartitionRequestsOverLimit durum kodunu döndürür; bunu gözetim panosuyla izleyebilirsiniz.

Bir veri yapısının veya bir öğe anahtarının yüksek, sürekli bir istek oranı almasını bekliyorsanız, shard yaparak yükü daha fazla bölüme veya anahtara yayabilirsiniz. Okuma ve yazmaları, anahtar başına sınırlar içinde kalmak için birden fazla öğe anahtarı arasında eşit şekilde dağıtın. Ayrıca, sunucuda değerleri önbelleğe alarak ve bir süre sonra yeniden kontrol ederek, mümkün olduğunda istekleri toplu halde yaparak ve kısıtlama yanıtları aldığınızda üstel geri çekilme uygulayarak istek oranını azaltabilirsiniz.

Bellek kotası tükenmesinden kurtulma

Eğer oyununuz TotalMemoryOverLimit hataları alıyorsa, gözetim panosundaki Bellek Kullanımı grafiğini kontrol edin. Bellek kullanımını artıran yazmaları yeniden başlatmak için, gereksiz öğeleri silin, öğelerin süresinin dolmasını bekleyin veya aşağıdaki seçeneklerden birini kullanın.

Açık Bulut ile bellek depolarını temizleme

Eğer saklanan verilere artık ihtiyacınız yoksa, seçilen kapsam için evrende tüm bellek deposu veri yapılarını asenkron olarak temizlemek için Açık Bulut Bellek Depolarını Temizle uç noktasını kullanın.

Bellek depolarını temizlemek için:

1. Bellek depolarını temizleme izinlerine sahip bir API anahtarı oluşturun ve hedef evrenin temizleme işleminin durumunu alın.
2. API anahtarını x-api-key başlığında kullanarak https://apis.roblox.com/cloud/v2/universes/{universe_id}/memory-store:flush adresine POST isteği gönderin. {universe_id} kısmını oyununuzun evren ID'si ile değiştirin. scope sorgu parametresini üretim verisi için LIVE veya Stüdyo verisi için TEST olarak ayarlayın. scope'u atladığınızda, uç nokta LIVE kullanır.
3. done değeri true olana kadar temizleme isteği tarafından döndürülen işlemi kontrol etmek için Bellek Deposu Temizleme İşlemini Al kullanın ve bir error kontrol edin. Anket yaparken aynı kapsamı kullanın. Döndürülen path zaten cloud/v2 içerdiğinden, başka bir önek eklemeden https://apis.roblox.com/{path} adresinde anket yapın.

Stüdyo ve üretim bellek depoları izole edilmiştir. Bir kapsamı temizlemek diğerini temizlemez. Gereksiz verileri temizledikten sonra, bellek kullanımının tekrar kotaya ulaşmasını önlemek için en iyi uygulamaları takip edin; örneğin, daha kısa son kullanma süreleri ve açık silme işlemleri.

Kapasiteyi Artırma ile Genişletilmiş Hizmetler

Eğer oyununuz verileri korumak ve varsayılan kotanın izin verdiğinden daha fazla depolama kullanmak istiyorsa, bellek depoları için Genişletilmiş Hizmetleri etkinleştirin. Genişletilmiş Hizmetler, bellek deposu depolama ve istekleri varsayılan kotaların ötesinde ödemenizi sağlar.

Başlamak için, uygunluk gereksinimlerini karşılayın, hesap bilgilerini ve bir ödeme yöntemi ekleyin, ardından Yaratıcı Kontrol Paneli üzerinden oyununuzu seçin. Genişletilmiş Hizmetler altında, bellek depolarını etkinleştirin ve ihtiyaç duyduğunuz kaynaklar için aylık bütçeler belirleyin. Ayrıntılar için Bir hizmeti etkinleştirin ve Hizmet fiyatlandırması sayfalarına bakın.

Genişletilmiş Hizmetler, kullanım bütçenizi aştığınızda hizmeti kısıtlar. Kullanımı ve faturayı izleyin ve gereksiz verileri kaldırmaya devam edin.

En iyi uygulamalar

Bellek kullanım deseninizi optimal tutmak ve sınırlara ulaşmaktan kaçınmak için bu en iyi uygulamaları takip edin:

• İşlenmiş öğeleri kaldırın. MemoryStoreQueue:RemoveAsync() yöntemi ile kuyruklar için ve MemoryStoreSortedMap:RemoveAsync() ile sıralı haritalar için okunan öğeleri sürekli temizlemek, belleği serbest bırakabilir ve veri yapısını güncel tutabilir.

• Veri eklerken son kullanma süresini mümkün olan en kısa zaman dilimine ayarlayın. MemoryStoreQueue:AddAsync() ve MemoryStoreSortedMap:SetAsync() için varsayılan son kullanma süresi 45 gündür; ancak mümkün olan en kısa süreyi ayarlamak, eski verilerin otomatik olarak temizlenmesini sağlayarak bellek kullanım kotanızı doldurmalarını önleyebilir.

  • Uzun bir son kullanma süresi ile büyük miktarda veri saklamaktan kaçının, çünkü bu bellek kotanızı aşma riski taşır ve bu da oyununuzun tamamını bozabilecek sorunlara yol açabilir.
  • Her zaman ya gereksiz öğeleri açıkça silin ya da kısa bir öğe son kullanma süresi belirleyin.
  • Genel olarak, belleği serbest bırakmak için açık silme kullanmalısınız ve kullanılmayan öğelerin uzun süre bellek kaplamasını önlemek için öğe son kullanma süresini bir güvenlik mekanizması olarak kullanmalısınız.

• Bellekte yalnızca gerekli değerleri tutun.

  Örneğin, bir açık artırma evi oyunu için yalnızca en yüksek teklifi korumanız gerekir. Tüm teklifleri veri yapınızda tutmak yerine, en yüksek teklifi korumak için bir anahtar üzerinde MemoryStoreSortedMap:UpdateAsync() kullanabilirsiniz.

• API istek sınırlarının altında kalmanıza yardımcı olmak için üstel geri çekilme kullanın.

  Örneğin, bir DataUpdateConflict hatası alırsanız, iki saniye sonra yeniden deneyebilir, ardından dört, sekiz vb. şeklinde devam edebilirsiniz; sürekli olarak MemoryStoreService'e doğru yanıt almak için istek göndermek yerine.

• Devasa veri yapılarını sharding ile birden fazla daha küçük yapıya ayırın.

  Verileri daha küçük yapılarda yönetmek genellikle daha kolaydır; her şeyi tek bir büyük veri yapısında saklamak yerine. Bu yaklaşım, kullanım ve oran sınırlarını aşmaktan kaçınmanıza da yardımcı olabilir. Örneğin, anahtarları için önekler kullanan bir sıralı haritanız varsa, her öneki kendi sıralı haritasına ayırmayı düşünün. Özellikle popüler bir oyun için, kullanıcıları kullanıcı ID'lerinin son rakamlarına göre birden fazla haritaya ayırmayı bile düşünebilirsiniz.

• Hash haritalarında sık erişilen anahtarları birden fazla anahtar kopyası ile shard yapın.

• Saklanan değerleri sıkıştırın.

  Örneğin, saklanan değer boyutunu azaltmak için LZW algoritmasını kullanmayı düşünün.

• Genişletilmiş Hizmetlere kaydolun.

  Varsayılan kotaların ötesinde depolama veya istek kullanımı için bellek depoları için Genişletilmiş Hizmetleri etkinleştirin.

Gözetim

Gözetim Panosu, bellek deposu kullanımınızı izlemek ve sorun gidermek için içgörüler ve analizler sağlar. Bellek kullanımınızın ve API isteklerinizin farklı yönleri hakkında gerçek zamanlı güncellenen grafiklerle, oyununuzun bellek kullanım desenini takip edebilir, mevcut tahsis edilen kotaları görüntüleyebilir, API durumunu izleyebilir ve performans optimizasyonu için potansiyel sorunları belirleyebilirsiniz.

Aşağıdaki tablo, Gözetim Panosu'ndaki Duruma Göre İstek Sayısı ve API x Duruma Göre İstekler grafiklerinde mevcut olan API yanıtlarının tüm durum kodlarını listeler ve açıklar. Bu hataları nasıl çözeceğiniz hakkında daha fazla bilgi için Sorun Giderme bölümüne bakın. Bir hatanın ilgili olduğu belirli kota veya sınır için Sınırlamalar ve Kotalar bölümüne bakın.

Aşağıdaki tablo, şu anda Gözetim Panosu'nda mevcut olmayan istemci tarafı durum kodlarını listeler.

Sorun Giderme

Aşağıdaki tablo, her yanıt durum kodu için önerilen çözümü listeler ve açıklar:

Stüdyoda test etme ve hata ayıklama

MemoryStoreService içindeki veriler, Stüdyo ve üretim arasında izole edilmiştir, bu nedenle Stüdyoda verileri değiştirmek üretim davranışını etkilemez. Bu, Stüdyodan yaptığınız API çağrılarının üretim verilerine erişmediği anlamına gelir; böylece bellek depolarını ve yeni özellikleri üretime geçmeden önce güvenle test edebilirsiniz.

Stüdyo testi, üretimle aynı sınırlara ve kotalara sahiptir. Kullanıcı sayısına bağlı olarak hesaplanan kotalar için, sonuçta oluşan kota çok küçük olabilir, çünkü Stüdyo testi için tek kullanıcı sizsiniz. Stüdyodan test yaparken, ayrıca bazı ek kontrollerin erişim ve izinleri doğrulamak için gerçekleştirildiğinden, üretimdeki kullanıma kıyasla biraz daha yüksek gecikme ve artan hata oranları da fark edebilirsiniz.

Canlı oyunlarda veya stüdyoda bir bellek deposunu nasıl hata ayıklayacağınız hakkında bilgi için Geliştirici Konsolu sayfasını kullanın.