หน่วยความจำ

MemoryStoreService เป็นบริการข้อมูลที่มีความสามารถในการประมวลผลสูงและมีความหน่วงต่ำ ซึ่งให้การเก็บข้อมูลในหน่วยความจำที่รวดเร็วและสามารถเข้าถึงได้จากเซิร์ฟเวอร์ทั้งหมดในเซสชันที่ใช้งานอยู่ Memory Stores เหมาะสำหรับข้อมูลที่มีการเปลี่ยนแปลงบ่อยและชั่วคราวซึ่งไม่จำเป็นต้องมีความทนทาน เนื่องจากเข้าถึงได้เร็วกว่าและจะหายไปเมื่อถึงอายุการใช้งานสูงสุด สำหรับข้อมูลที่ต้องการให้คงอยู่ระหว่างเซสชัน ให้ใช้ data stores.

โครงสร้างข้อมูล

แทนที่จะเข้าถึงข้อมูลดิบโดยตรง, memory stores มีโครงสร้างข้อมูลพื้นฐานสามประเภทที่แชร์กันระหว่างเซิร์ฟเวอร์เพื่อการประมวลผลที่รวดเร็ว: sorted map, queue, และ hash map. โครงสร้างข้อมูลแต่ละประเภทเหมาะสำหรับกรณีการใช้งานที่เฉพาะเจาะจง:

• การจับคู่ตามทักษะ - บันทึกข้อมูลผู้ใช้ เช่น ระดับทักษะ ใน queue ที่แชร์กันระหว่างเซิร์ฟเวอร์ และใช้เซิร์ฟเวอร์ล็อบบี้เพื่อทำการจับคู่เป็นระยะๆ
• การซื้อขายและการประมูลข้ามเซิร์ฟเวอร์ - เปิดใช้งานการซื้อขายทั่วไประหว่างเซิร์ฟเวอร์ที่แตกต่างกัน ซึ่งผู้ใช้สามารถเสนอราคาสำหรับรายการที่มีราคาเปลี่ยนแปลงแบบเรียลไทม์ โดยใช้ sorted map ของคู่คีย์-ค่า
• กระดานผู้นำระดับโลก - เก็บและอัปเดตอันดับผู้ใช้ในกระดานผู้นำที่แชร์กันภายใน sorted map
• สินค้าคงคลังที่แชร์กัน - บันทึกสินค้าคงคลังและสถิติใน hash map ที่แชร์กัน ซึ่งผู้ใช้สามารถใช้สินค้าคงคลังร่วมกันได้
• แคชสำหรับข้อมูลที่คงอยู่ - ซิงค์และคัดลอกข้อมูลที่คงอยู่ใน data store ไปยัง hash map ของ memory store ที่สามารถทำหน้าที่เป็นแคชและปรับปรุงประสิทธิภาพของเกมของคุณ

โดยทั่วไป หากคุณต้องการเข้าถึงข้อมูลตามคีย์เฉพาะ ให้ใช้ hash map หากคุณต้องการให้ข้อมูลนั้นมีการจัดเรียง ให้ใช้ sorted map หากคุณต้องการประมวลผลข้อมูลของคุณในลำดับเฉพาะ ให้ใช้ queue

ข้อจำกัดและโควต้า

เพื่อรักษาความสามารถในการขยายตัวและประสิทธิภาพของระบบ, memory stores มีโควต้าการใช้งานข้อมูลสำหรับขนาดหน่วยความจำ, การเรียก API, และขนาดของโครงสร้างข้อมูล

Memory stores มีนโยบายการลบข้อมูลตามเวลาหมดอายุ ซึ่งเรียกอีกอย่างว่าเวลาในการมีชีวิต (TTL) รายการจะถูกลบออกหลังจากหมดอายุ และโควต้าหน่วยความจำจะถูกปล่อยให้สำหรับรายการใหม่ เมื่อคุณถึงขีดจำกัดหน่วยความจำ คำขอที่เพิ่มการใช้งานหน่วยความจำจะล้มเหลวจนกว่าคุณจะปล่อยหน่วยความจำหรือเพิ่มโควต้า ดู Recover from memory quota exhaustion สำหรับตัวเลือก

โควต้าขนาดหน่วยความจำ

โควต้าหน่วยความจำจำกัดปริมาณหน่วยความจำทั้งหมดที่เกมสามารถใช้ได้ มันไม่ใช่ค่าคงที่ แต่จะเปลี่ยนแปลงไปตามจำนวนผู้ใช้ในเกมตามสูตร 64 KB + 1.2 KB * [number of users] โควต้าจะใช้ในระดับเกมแทนที่จะเป็นระดับเซิร์ฟเวอร์

เมื่อผู้ใช้เข้าร่วมเกม โควต้าหน่วยความจำเพิ่มเติมจะพร้อมใช้งานทันที เมื่อผู้ใช้ออกจากเกม โควต้าจะไม่ลดลงทันที จะมีระยะเวลาการติดตามเป็นเวลาแปดวันก่อนที่โควต้าจะประเมินค่าใหม่เป็นค่าที่ต่ำกว่า

หลังจากเกมของคุณถึงโควต้าขนาดหน่วยความจำ คำขอ API ใดๆ ที่เพิ่มขนาดหน่วยความจำจะล้มเหลวเสมอ คำขอที่ลดหรือไม่เปลี่ยนแปลงขนาดหน่วยความจำยังคงสำเร็จ

ด้วย observability แดชบอร์ด คุณสามารถดูโควต้าขนาดหน่วยความจำของเกมของคุณแบบเรียลไทม์โดยใช้แผนภูมิ Memory Usage

ข้อจำกัดการเรียก API

โควต้า request unit จะใช้กับการเรียก API ทั้งหมดของ MemoryStoreService โควต้านี้คือ 1000 + 120 * [number of concurrent users] request units ต่อหนึ่งนาที

การเรียก API ส่วนใหญ่จะใช้เพียงหนึ่ง request unit โดยมีข้อยกเว้นบางประการ:

• MemoryStoreSortedMap:GetRangeAsync()

  ใช้หน่วยตามจำนวนรายการที่ส่งคืน ตัวอย่างเช่น หากวิธีนี้ส่งคืน 10 รายการ การเรียกจะนับเป็น 10 request units หากส่งคืนการตอบสนองว่าง จะนับเป็นหนึ่ง request unit

• MemoryStoreQueue:ReadAsync()

  ใช้หน่วยตามจำนวนรายการที่ส่งคืน เช่นเดียวกับ MemoryStoreSortedMap:GetRangeAsync() แต่ใช้หน่วยเพิ่มเติมทุกสองวินาทีในขณะที่อ่าน กำหนดเวลาการอ่านสูงสุดด้วยพารามิเตอร์ waitTimeout

• MemoryStoreHashMap:UpdateAsync()

  ใช้หน่วยขั้นต่ำสองหน่วย

• MemoryStoreHashMap:ListItemsAsync()

  ใช้ [number of partitions scanned] + [items returned] units

โควต้าคำขอยังใช้ในระดับเกมแทนที่จะเป็นระดับเซิร์ฟเวอร์ ซึ่งให้ความยืดหยุ่นในการจัดสรรคำขอระหว่างเซิร์ฟเวอร์ตราบใดที่อัตราคำขอรวมไม่เกินโควต้า หากคุณเกินโควต้า คุณจะได้รับการตอบสนองข้อผิดพลาดเมื่อบริการจำกัดคำขอของคุณ

ด้วยฟีเจอร์ observability ที่มีอยู่ คุณสามารถดูโควต้า request unit ของเกมของคุณแบบเรียลไทม์

ข้อจำกัดขนาดโครงสร้างข้อมูล

สำหรับ sorted map หรือ queue เดียว ข้อจำกัดขนาดและจำนวนรายการต่อไปนี้จะใช้:

• จำนวนรายการสูงสุด: 1,000,000
• ขนาดรวมสูงสุด (รวมถึงคีย์สำหรับ sorted map): 100 MB

ข้อจำกัดต่อพาร์ติชัน

นอกเหนือจาก request unit quota ในระดับเกม, memory stores จะใช้ข้อจำกัดการเรียกต่อแต่ละพาร์ติชันเป็นมาตรการป้องกันที่ปกป้องความเสถียรของบริการสำหรับเกมทั้งหมด ข้อจำกัดเหล่านี้ไม่ใช่โควต้าที่เกมของคุณได้รับการจัดสรร และไม่ใช่เพดานที่แข็งแกร่งสำหรับอัตราการส่งข้อมูลที่เกมของคุณสามารถทำได้ ค่าต่อไปนี้เป็นการประมาณการ พวกเขาถูกกำหนดค่าในแบ็กเอนด์ของ Roblox และอาจเปลี่ยนแปลงได้ ดังนั้นอย่าออกแบบตามค่าคงที่เหล่านี้

ทุกคำขอนับเป็นส่วนหนึ่งของข้อจำกัดของ พาร์ติชัน ที่ถือรายการ ไม่ว่าจะเป็นโครงสร้างข้อมูลใดก็ตาม คุณสามารถคาดหวังว่าการจำกัดจะเริ่มต้นที่ประมาณ 30,000 request units ต่อหนึ่งนาที สำหรับพาร์ติชันเดียว ดังนั้นควรพยายามอยู่ต่ำกว่าระดับนั้น ขนาดของข้อจำกัดที่โครงสร้างข้อมูลใช้ขึ้นอยู่กับการกระจายของรายการ:

• Sorted maps และ queues จะอยู่ในพาร์ติชันเดียว ดังนั้นทุกคำขอไปยังโครงสร้างข้อมูลเหล่านี้จะนับเป็นข้อจำกัดของพาร์ติชันเดียวกัน
• Hash maps จะกระจายรายการของพวกเขาไปยังหลายพาร์ติชัน ดังนั้นการจราจรที่กระจายไปยังหลายคีย์รายการจึงไม่ค่อยเข้าใกล้ข้อจำกัดของพาร์ติชันใดพาร์ติชันหนึ่ง

Hash maps มีข้อจำกัดเพิ่มเติมในแต่ละคีย์รายการประมาณ 5,000 write request units ต่อหนึ่งนาที และ 15,000 read request units ต่อหนึ่งนาที ข้อจำกัดต่อคีย์นี้ใช้เพิ่มเติมจากข้อจำกัดต่อพาร์ติชัน ดังนั้นคีย์ที่เข้าถึงบ่อยอาจโดนทั้งสอง ข้อจำกัดต่อคีย์ใช้เฉพาะกับการดำเนินการแบบคีย์เดียว: ข้อจำกัดการอ่านใช้กับ MemoryStoreHashMap:GetAsync(), ข้อจำกัดการเขียนใช้กับ MemoryStoreHashMap:SetAsync() และ MemoryStoreHashMap:RemoveAsync(), และ MemoryStoreHashMap:UpdateAsync() จะนับทั้งข้อจำกัดการอ่านและการเขียน MemoryStoreHashMap:ListItemsAsync() จะสแกนพาร์ติชันแทนที่จะเป็นคีย์เดียว ดังนั้นจะใช้เฉพาะข้อจำกัดต่อพาร์ติชันกับมัน

หากคุณไม่ต้องการการจัดเรียงหรือฟังก์ชันการทำงานแบบเข้ามาก่อนออกไป, hash map มักจะเป็นตัวเลือกที่ดีที่สุดเพราะสามารถกระจายโหลดไปยังพาร์ติชันต่างๆ

เมื่อคำขอเกินข้อจำกัดของพาร์ติชันหรือข้อจำกัดต่อคีย์ บริการจะจำกัดคำขอและส่งคืนรหัสสถานะ PartitionRequestsOverLimit ซึ่งคุณสามารถติดตามได้ด้วยแดชบอร์ด observability

หากคุณคาดว่าโครงสร้างข้อมูลหรือคีย์รายการจะได้รับอัตราคำขอที่สูงและต่อเนื่อง, shard เพื่อให้โหลดกระจายไปยังพาร์ติชันหรือคีย์มากขึ้น กระจายการอ่านและการเขียนอย่างสม่ำเสมอไปยังหลายคีย์รายการเพื่อให้คงอยู่ภายในข้อจำกัดต่อคีย์ คุณยังสามารถลดอัตราคำขอโดยการแคชค่าบนเซิร์ฟเวอร์และตรวจสอบอีกครั้งหลังจากช่วงเวลา, การจัดกลุ่มคำขอเมื่อเป็นไปได้, และใช้ exponential backoff เมื่อคุณได้รับการตอบสนองการจำกัด

ฟื้นฟูจากการหมดโควต้าหน่วยความจำ

หากเกมของคุณได้รับข้อผิดพลาด TotalMemoryOverLimit ให้ตรวจสอบแผนภูมิ Memory Usage ใน observability dashboard. เพื่อกลับมาเขียนที่เพิ่มการใช้งานหน่วยความจำ ให้ลบรายการที่ไม่จำเป็น, รอให้รายการหมดอายุ, หรือใช้หนึ่งในตัวเลือกต่อไปนี้

ล้างหน่วยความจำด้วย Open Cloud

หากคุณไม่ต้องการข้อมูลที่เก็บไว้แล้ว ให้ใช้ Open Cloud Flush Memory Store endpoint เพื่อล้างข้อมูลโครงสร้างหน่วยความจำทั้งหมดในจักรวาลสำหรับขอบเขตที่เลือก

ในการล้างหน่วยความจำ:

1. สร้าง API key ที่มีสิทธิ์ในการล้างหน่วยความจำและรับสถานะการดำเนินการล้างสำหรับจักรวาลเป้าหมาย
2. ส่งคำขอ POST ไปยัง https://apis.roblox.com/cloud/v2/universes/{universe_id}/memory-store:flush โดยมี API key ในส่วนหัว x-api-key แทนที่ {universe_id} ด้วย ID จักรวาลของเกมของคุณ ตั้งค่าพารามิเตอร์ query scope เป็น LIVE สำหรับข้อมูลการผลิตหรือ TEST สำหรับข้อมูล Studio หากคุณละเว้น scope, endpoint จะใช้ LIVE
3. ใช้ Get Memory Store Flush Operation เพื่อตรวจสอบการดำเนินการที่ส่งคืนโดยคำขอล้างจนกว่า done จะเป็น true และตรวจสอบสำหรับ error ใช้ขอบเขตเดียวกันเมื่อทำการตรวจสอบ การตอบกลับ path จะรวม cloud/v2 อยู่แล้ว ดังนั้นให้ตรวจสอบที่ https://apis.roblox.com/{path} โดยไม่ต้องเพิ่มคำนำหน้าอีก

หน่วยความจำใน Studio และการผลิตจะถูก แยกออก การล้างขอบเขตหนึ่งจะไม่ลบอีกขอบเขตหนึ่ง หลังจากลบข้อมูลที่ไม่จำเป็นแล้ว ให้ปฏิบัติตาม แนวทางปฏิบัติที่ดีที่สุด เช่น เวลาหมดอายุที่สั้นลงและการลบอย่างชัดเจน เพื่อป้องกันไม่ให้การใช้งานหน่วยความจำถึงโควต้าอีกครั้ง

เพิ่มความจุด้วย Extended Services

หากเกมของคุณต้องการเก็บข้อมูลและใช้พื้นที่เก็บข้อมูลมากกว่าที่โควต้าดีฟอลต์อนุญาต ให้เปิดใช้งาน Extended Services สำหรับ memory stores Extended Services ช่วยให้คุณจ่ายสำหรับพื้นที่เก็บข้อมูลและคำขอของ memory store ที่เกินโควต้าดีฟอลต์

ในการเริ่มต้น ให้ตรงตาม ข้อกำหนดคุณสมบัติ, เพิ่มรายละเอียดบัญชีและวิธีการชำระเงิน จากนั้นเลือกเกมของคุณใน Creator Dashboard. ภายใต้ Extended Services, เปิดใช้งาน memory stores และตั้งงบประมาณรายเดือนสำหรับทรัพยากรที่คุณต้องการ ดู Enable a service และ Service pricing สำหรับรายละเอียด

Extended Services จะจำกัดบริการหากการใช้งานเกินงบประมาณของคุณ ตรวจสอบการใช้งานและการเรียกเก็บเงิน และดำเนินการ ลบข้อมูลที่ไม่จำเป็น

แนวทางปฏิบัติที่ดีที่สุด

เพื่อให้รูปแบบการใช้งานหน่วยความจำของคุณอยู่ในระดับที่เหมาะสมและหลีกเลี่ยงการถึง ข้อจำกัด ให้ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดเหล่านี้:

• ลบรายการที่ประมวลผลแล้ว การทำความสะอาดรายการที่อ่านอย่างสม่ำเสมอโดยใช้วิธี MemoryStoreQueue:RemoveAsync() สำหรับ queues และ MemoryStoreSortedMap:RemoveAsync() สำหรับ sorted maps สามารถปล่อยหน่วยความจำและทำให้โครงสร้างข้อมูลทันสมัย

• ตั้งเวลาในการหมดอายุให้สั้นที่สุดเท่าที่จะเป็นไปได้เมื่อเพิ่มข้อมูล แม้ว่าเวลาหมดอายุเริ่มต้นจะเป็น 45 วันสำหรับทั้ง MemoryStoreQueue:AddAsync() และ MemoryStoreSortedMap:SetAsync() การตั้งค่าเวลาที่สั้นที่สุดสามารถทำให้ข้อมูลเก่าถูกลบออกโดยอัตโนมัติเพื่อป้องกันไม่ให้เติมโควต้าการใช้งานหน่วยความจำของคุณ

  • อย่าเก็บข้อมูลจำนวนมากที่มีเวลาหมดอายุยาว เนื่องจากมีความเสี่ยงที่จะเกินโควต้าหน่วยความจำของคุณและอาจทำให้เกิดปัญหาที่อาจทำให้เกมของคุณเสียหาย
  • ควรลบรายการที่ไม่จำเป็นอย่างชัดเจนหรือกำหนดเวลาหมดอายุให้สั้น
  • โดยทั่วไป คุณควรใช้การลบอย่างชัดเจนเพื่อปล่อยหน่วยความจำและการหมดอายุของรายการเป็นกลไกความปลอดภัยเพื่อป้องกันไม่ให้รายการที่ไม่ได้ใช้งานใช้หน่วยความจำเป็นระยะเวลานาน

• เก็บเฉพาะค่าที่จำเป็นในหน่วยความจำ

  ตัวอย่างเช่น สำหรับเกมบ้านประมูล คุณเพียงต้องรักษาการเสนอราคาสูงสุด คุณสามารถใช้ MemoryStoreSortedMap:UpdateAsync() บนคีย์หนึ่งเพื่อรักษาการเสนอราคาสูงสุดแทนที่จะเก็บการเสนอราคาทั้งหมดในโครงสร้างข้อมูลของคุณ

• ใช้ exponential backoff เพื่อช่วยให้คุณอยู่ต่ำกว่าข้อจำกัดการเรียก API

  ตัวอย่างเช่น หากคุณได้รับ DataUpdateConflict คุณอาจลองใหม่หลังจากสองวินาที จากนั้นสี่ แปด ฯลฯ แทนที่จะส่งคำขอไปยัง MemoryStoreService อย่างต่อเนื่องเพื่อให้ได้การตอบสนองที่ถูกต้อง

• แบ่งโครงสร้างข้อมูลขนาดใหญ่เป็นหลายโครงสร้างขนาดเล็กโดย sharding

  มักจะจัดการข้อมูลในโครงสร้างขนาดเล็กได้ง่ายกว่าการเก็บทุกอย่างในโครงสร้างข้อมูลขนาดใหญ่เพียงโครงสร้างเดียว วิธีนี้ยังช่วยหลีกเลี่ยงการใช้งานและข้อจำกัดอัตรา ตัวอย่างเช่น หากคุณมี sorted map ที่ใช้คีย์ที่มีพรีฟิก ให้พิจารณาแยกแต่ละพรีฟิกออกเป็น sorted map ของตัวเอง สำหรับเกมที่มีความนิยมสูง คุณอาจแยกผู้ใช้เป็นหลายแผนที่ตามหลักฐานสุดท้ายของ ID ผู้ใช้ของพวกเขา

• Shard คีย์ที่เข้าถึงบ่อยใน hash maps โดยใช้สำเนาหลายชุดของคีย์เพื่อกระจายโหลด

• บีบอัดค่าที่เก็บไว้

  ตัวอย่างเช่น พิจารณาใช้ LZW อัลกอริธึมเพื่อลดขนาดค่าที่เก็บไว้

• ลงทะเบียนใน Extended Services

  สำหรับการจัดเก็บหรือการใช้งานคำขอที่เกินโควต้าดีฟอลต์, เปิดใช้งาน Extended Services สำหรับ memory stores

การสังเกต

Observability Dashboard ให้ข้อมูลเชิงลึกและการวิเคราะห์สำหรับการติดตามและแก้ไขปัญหาการใช้งานหน่วยความจำของคุณ ด้วยแผนภูมิที่อัปเดตแบบเรียลไทม์ในด้านต่างๆ ของการใช้งานหน่วยความจำและการเรียก API คุณสามารถติดตามรูปแบบการใช้งานหน่วยความจำของเกมของคุณ, ดูโควต้าที่จัดสรรในปัจจุบัน, ติดตามสถานะ API, และระบุปัญหาที่อาจเกิดขึ้นเพื่อการปรับปรุงประสิทธิภาพ

ตารางต่อไปนี้แสดงและอธิบายรหัสสถานะทั้งหมดของการตอบสนอง API ที่มีอยู่ในแผนภูมิ Request Count by Status และ Requests by API x Status ของ Observability Dashboard สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการแก้ไขข้อผิดพลาดเหล่านี้ ดู Troubleshooting สำหรับโควต้าหรือข้อจำกัดเฉพาะที่ข้อผิดพลาดเกี่ยวข้อง ดู Limits and Quotas

ตารางต่อไปนี้แสดงรหัสสถานะจากฝั่งลูกค้า ซึ่งขณะนี้ไม่สามารถใช้ได้ใน Observability Dashboard

การแก้ไขปัญหา

ตารางต่อไปนี้แสดงและอธิบายวิธีแก้ไขที่แนะนำสำหรับรหัสสถานะการตอบสนองแต่ละรหัส:

ทดสอบและแก้ไขใน Studio

ข้อมูลใน MemoryStoreService จะถูกแยกออกระหว่าง Studio และการผลิต ดังนั้นการเปลี่ยนแปลงข้อมูลใน Studio จะไม่ส่งผลต่อพฤติกรรมการผลิต ซึ่งหมายความว่าการเรียก API ของคุณจาก Studio จะไม่เข้าถึงข้อมูลการผลิต ทำให้คุณสามารถทดสอบ memory stores และฟีเจอร์ใหม่ได้อย่างปลอดภัยก่อนที่จะไปยังการผลิต

การทดสอบใน Studio มี ข้อจำกัดและโควต้า เช่นเดียวกับการผลิต สำหรับโควต้าที่คำนวณตามจำนวนผู้ใช้ โควต้าที่ได้อาจมีขนาดเล็กมากเนื่องจากคุณเป็นผู้ใช้เพียงคนเดียวสำหรับการทดสอบใน Studio เมื่อทดสอบจาก Studio คุณอาจสังเกตเห็นความหน่วงที่สูงขึ้นเล็กน้อยและอัตราข้อผิดพลาดที่สูงขึ้นเมื่อเปรียบเทียบกับการใช้งานในการผลิตเนื่องจากมีการตรวจสอบเพิ่มเติมที่ดำเนินการเพื่อยืนยันการเข้าถึงและสิทธิ์

สำหรับข้อมูลเกี่ยวกับวิธีการแก้ไขปัญหาหน่วยความจำในเกมสดหรือเมื่อทดสอบใน Studio ใช้ Developer Console.