MemoryStoreService 是一種高速度和低延遲的數據服務，可提供快速的內存數據存取，可以從所有服務器在實時會作業中存取。 內存存檔 適用於快速變更的數據，不需要持續時間，因為它們是快速存取的，並且在最大
數據結構
而不是直接存取原始資料，記憶體存儲有三種原始資料結構在服務器間共享：排序地圖、排隊和哈希地圖。每種資料結構都適合某些使用案例：
- 基於技能的匹配 - 保存用戶信息，例如技能等級，在共用 排隊 中服務器間，並使用大廳服務器來定期執行匹配。
- 跨服務器交易和拍賣 - 啟用在不同服務器之間的通用交易，用戶可以在實時變更價格的物品，以及具有排序的鑰匙值對的地圖。
- 全球排行榜 - 在排序地圖內的共用排行榜內儲存和更新用戶排名。
- 共享道具欄 - 在共享的 哈希地圖 中，用戶可以與其他用戶一起使用道具欄項目。
- 為持久資料建立儲存池 - 將持久資料同步到資料存取池中，以便在內存存取池中執行 哈希地圖 ，以提高您的體驗履約。
一般來說，如果您需要存取特定鍵的數據，請使用哈希表。 如果您需要要求數據的排序，請使用排序表。 如果您需要處理您的數據以特定順序，請使用排隊表。
限制和額度
為了維持可以擴展的系統性能和記憶體存取履約，記憶體有資料使用率對記憶體大小、API 請求和資料結構大小。
記憶體儲存有一個基於時間的驅逐政策，也稱為時間到 (TTL) 。項目在到期後會被驅逐，並且記憶體儲存的空間將被清除以便新增項目。當您達到記憶體上限時，所有的寫入請求都會失敗直到項目到期或您手動刪除它們。
記憶體大小限制
記憶體資源限制體驗可以消耗的總記憶量。它不是固定值。相反，它會隨著體驗中的用戶數量而改變。這是按照以下方式變化的： 64KB + 1KB * [用戶數量] 。記憶體資源對體驗層級而不是服務器等級進行變化。
當用戶加入體驗時，額外的記憶體資源可立即使用。當用戶離開體驗時，資源不會立即減少。有八天的追蹤期，之後資源將會重新評估至更低值。
您的體驗擊中記憶體容量上限時，任何增加記憶體容量的 API 請求都會失敗。減少或不變更記憶體容量的請求仍然成功。
使用 可視化 面板，您可以在實時檢視您的體驗內存大小 quota 的圖表。
API 請求限制
對於 API 請求限制，有 請求單位 額外資源可應用於所有 MemoryStoreService API 呼叫。資源是每分鐘 1000 + 100 * [number of concurrent users] 個要求單位。
大多數 API 呼叫只消耗一個要求單位，但有幾個例外：
MemoryStoreSortedMap:GetRangeAsync()
以返回的項目數量為基礎消耗單位。例如，如果此方法返回 10 個項目，呼叫將計為 10 個請求單位。如果返回空白回應，將計為單個請求單位。
根據返回的項目數量來消耗單位，就像 MemoryStoreSortedMap:GetRangeAsync() ，但在閱取時每兩秒消耗一個額外的單位。指定 waitTimeout 參數來指定最大閱取時間。
MemoryStoreHashMap:UpdateAsync()
消耗最少兩個單位。
MemoryStoreHashMap:ListItemsAsync()
消耗 [分區掃描數量] + [返回的項目] 單位。
請注意，請在體驗級別而不是服務器等級別上設定請求數量上限。這樣可以在服務器之間允許請求，並且不會超過總請求率。如果您超過總請求率，您將收到錯誤回應。
有了 可觀察性 功能，您可以在實時檢視您的體驗的請求單位額。
資料結構大小限制
對於單個排序的地圖或佇列，以下尺寸和項目數量限制適用：
- 最大物品數量：1,000,000
- 最大總尺寸 (包括排序地圖的鑰匙)：100 MB
分區限制
請參閱 分區限制。
最佳實踐
要保持您的記憶使用模式最佳，並避免擊中限制，請遵循這些最佳習慣：
移除處理的項目。 一致地清除排隊中的閱取項目使用 MemoryStoreQueue:RemoveAsync() 方法為排隊清除 和 MemoryStoreSortedMap:RemoveAsync() 排序的地圖可以免費的資料結構。
在添加資料時設定過期時間為最小時間框架。 雖然預設過期時間為 45 天，但設定最短的時間框架可以自動清理舊資料，以防止它們填滿您的記憶體使用率。
- 不要存儲大量資料，因為它會導致超出您的記憶體資源，並可能導致潛在導致您的整個體驗中損壞。
- 必須要明確刪除不需要的項目，或設定一個短項目的過期時間。
- 一般來說，您應該使用明確的刪除來釋放記憶體和物品過期作為安全機制，以防止未使用的項目佔用記憶體，以及延長時間內未使用的項目。
只保留必要值在記憶體中。
舉例來說，對於拍賣屋體驗，您只需要維持最高價格。您可以使用 MemoryStoreQueue:UpdateAsync() 在一個鑰匙上來保持最高價格，而不是保持所有潛在的價格在您的資料結構中。
使用 指數減法背包 來幫助您保持在 API 請求限制之下。
舉例來說，如果您收到 DataUpdateConflict，您可以在兩秒後嘗試，然後在四，八，等等發送請求給 MemoryStoreService 以取得正確的回應。
將巨大資料結構分割成 碎片 。
管理資料通常比儲存在一個大的資料結構中更容易。這種方法可以幫助避免使用和僅率限制。例如，如果您有使用條件和僅率限制的排序圖，請考慮將每個條件分開到自己的排序圖。對於一個特別受歡迎的體驗，您甚至可以將用戶分成多個地圖，基於用戶的ID。
壓縮已儲存的值。
舉例來說，請考慮使用 LZW 算法來減少存儲值的大小。
可視性
可視性大盤 提供監視和分析您記憶體使用的內容。 使用記憶體使用率和 API 請求的實時更新圖表，您可以跟蹤您的記憶體使用率、查看目前할당的資源、監視 API 狀態和識別潛在的性能優化機會。
下表列出並描述所有 API 回應可用在監視性儀表板的 請求數據按狀態 和 請求按 API 圖表。有關解決這些錯誤的更多資訊，請參閱 排查 。有關特定錯誤的資料上限或限制，請參閱 1>限制1> 。
| 狀態代碼 | 說明 |
|---|---|
| 成功 | 成功。 |
| 資料結構記憶體超限 | 超出資料結構等級記憶體容量限制(100MB)。 |
| 資料更新矛盾 | 因雙重更新而發生衝突。 |
| 沒有權限 | 沒有權限存取體驗資料。這個請求不會消耗請求單位或使用額度。 |
| 內部錯誤 | 內部錯誤。 |
| 無效的請求 | 請求沒有所需信息或有不正確的信息。 |
| 資料結構項目超限 | 超出資料結構等級項目數量限制(1M)。 |
| 找不到項目 | 找不到 MemoryStoreQueue:ReadAsync() 或 MemoryStoreSortedMap:UpdateAsync() 。 ReadAsync() 每 2 秒進行調查，直到它在排隊中找到項目。 |
| 資料結構請求限制 | 超出資料結構等級請求單位限制 (每分鐘 100,000 請求單位). |
| 分區請求超限 | 超出區域請求單位限制。 |
| 總共請求限制 | 超出宇宙級請求單位限制。 |
| 總記憶體容量上限 | 超出宇宙級別記憶體 quota。 |
| 項目值太大 | 值尺寸超出限制 (32KB)。 |
下表列出來自客戶端的狀態代碼，目前並非在可視性儀表板上可用。
| 狀態代碼 | 說明 |
|---|---|
| 內部錯誤 | 內部錯誤。 |
| 未發佈的地方 | 您必須發布此地方才能使用 MemoryStoreService。 |
| 無效的客戶端存取 | 必須從服務伺服器呼叫 MemoryStoreService。 |
| 無效的過期時間 | 「過期」時間必須在 0 和 3,888,000 之間。 |
| 無效的請求 | 無法將值轉換為 JSON。 |
| 無效的請求 | 無法將 sortKey 轉換為有效的數字或字串。 |
| 變形回歸失敗 | 無法召喚變身回潮函數。 |
| 請求限制 | 最近的 MemoryStores 請求擊中一個或多個限制。 |
| 更新矛盾 | 超出最多重試次數的上限。 |
排障
下表列出並描述每個狀態代碼的建議解決方案：
| 錯誤 | 排障選項 |
|---|---|
| DataStructureCommands / 區域限制 |
|
| 總共請求限制 | |
| 資料結構項目超限 |
|
| 資料結構記憶體超限 | |
| 總記憶體容量上限 | |
| 資料更新矛盾 | 在要求之間實現一個短 |
| 內部錯誤 |
0> bug 報告0> ，描述您的體驗的宇宙 ID。 |
| 無效的請求 |
|
| 項目值太大 |
|
在 Studio 測試和調試
資料在 MemoryStoreService 中之間是 Studio 和生產中隔絕的，因此在 Studio 中變更資料對生產行為沒有影響。這意味著 Studio 的 API 從 Studio 不會存取生產資料，因此您可以安全地測試記憶體存取和新功能，然後進入生產。
Studio 測試具有與生產相同的 限制和額外配額。對於基於用戶數量的測試結果，結果將因為您是 Studio 測試的唯一用戶而變得非常小，因為您是 Studio 測試的唯一用戶。當從 Studio 測試時，您可能也會發現額外的延遲和更高的錯誤率，這是因為有一些額外的檢查被執行來確認存取權限。
有關在現實體驗中調試記憶體儲存或在測試室測試時的資訊，請使用 開發者控制器。