รหัสข้อผิดพลาดและขีดจำกัดของ Data store

คำขอที่คุณทำไปยัง data stores อาจล้มเหลวเนื่องจากการเชื่อมต่อที่ไม่ดีหรือปัญหาอื่น ๆ เพื่อจัดการกับข้อผิดพลาดและส่งคืนข้อความที่มีรหัสข้อผิดพลาด ให้ห่อฟังก์ชัน data store ใน pcall()

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

การอ้างอิงรหัสข้อผิดพลาด

รหัสข้อผิดพลาดของเซิร์ฟเวอร์

ขีดจำกัด

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

• ตั้งค่า
• ตั้งค่าแบบสั่ง
• รับ
• รับแบบสั่ง

คำขอในคิวจะถูกจัดการตามลำดับที่ได้รับ ฟังก์ชันที่เรียกยังคงหยุดชะงักตราบเท่าที่คำขอยังคงอยู่ในคิว หากคีย์ data store ถูกจำกัด คำขอจะถูกวางในคิวแต่จะถูกข้ามในชั่วคราว

แต่ละคิวมีขีดจำกัด 30 คำขอ เมื่อถึงขีดจำกัดของคิว คำขอจะล้มเหลวด้วยรหัสข้อผิดพลาดในช่วง 301-306 ซึ่งบ่งชี้ว่าคำขอถูกละทิ้งทั้งหมด

ขีดจำกัดการเข้าถึง

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

ขีดจำกัดประสบการณ์

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

• UpdateAsync() จะใช้จากงบประมาณการอ่านและเขียน คำขอเดียวจะลดทั้งสองขีดจำกัด
• เซิร์ฟเวอร์เกมและ Open Cloud แชร์ งบประมาณ การจราจรของ Open Cloud สามารถถูกจำกัดโดยการใช้งานภายในประสบการณ์ (และในทางกลับกัน) โปรดดู Control rate limits สำหรับข้อมูลเพิ่มเติม

data stores แบบมาตรฐาน

data stores แบบสั่ง

ควบคุมขีดจำกัดอัตรา

เนื่องจากคำขอ Open Cloud และเซิร์ฟเวอร์เกมถูกแชร์ จึงสำคัญที่จะควบคุมว่าความสามารถในการใช้ชีวิตแต่ละด้านมีอย่างไร

เซิร์ฟเวอร์เกม

เซิร์ฟเวอร์แต่ละตัวมีขีดจำกัดที่สร้างขึ้นตามที่ได้อธิบายไว้ข้างต้น ใช้การรวมกันของ SetRateLimitForRequestType() และ GetRequestBudgetForRequestType() เพื่อรักษาการควบคุมที่ละเอียดยิ่งขึ้นในการมีส่วนร่วมของเซิร์ฟเวอร์แต่ละตัวต่อขีดจำกัดรวม

Open Cloud

คำร้องของ Open Cloud จำเป็นต้องมีการแก้ไขปัญหาการจำกัดอัตรา เราขอแนะนำแนวทางหนึ่งในวิธีการต่อไปนี้:

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

ตัวอย่างโค้ด Node.js ต่อไปนี้ประกอบด้วยการใช้งานที่อ้างถึง

const apiKey = process.env.API_KEY;
if (!apiKey) {
    throw new Error('The API_KEY environment variable is not set.');
}

const apiHeaderKey = 'x-api-key';

const universeId = '';
const dataStoreId = 'Inventory';

const baseUrl = 'https://apis.roblox.com/cloud/v2/';

// --- การกำหนดค่าการจำกัดอัตราต่อการดำเนินการ (คำขอต่อหนึ่งนาที) ---
const LIST_RATE_PER_MIN = 60;
const GET_RATE_PER_MIN = 120;
const UPDATE_RATE_PER_MIN = 60;

// เวลารอสูงสุดต่อการดำเนินการ: 60 / (คำขอต่อหนึ่งนาที) วินาที.
const LIST_INTERVAL_MS = (60 / LIST_RATE_PER_MIN) * 1000;
const GET_INTERVAL_MS = (60 / GET_RATE_PER_MIN) * 1000;
const UPDATE_INTERVAL_MS = (60 / UPDATE_RATE_PER_MIN) * 1000;

const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

// ทำการร้องขอแล้วรอเวลาในการดำเนินการนี้ก่อนจะส่งคืน
async function throttledFetch(url, options, intervalMs) {
    const response = await fetch(url, options);
    await sleep(intervalMs);
    return response;
}

async function listEntries(universe, dataStore) {
    const listPath = `universes/${universe}/data-stores/${dataStore}/entries`;
    const url = baseUrl + listPath;
    const response = await throttledFetch(url, {
        headers: { [apiHeaderKey]: apiKey }
    }, LIST_INTERVAL_MS);
    return response.json();
}

async function getEntry(path) {
    const url = baseUrl + path;
    const response = await throttledFetch(url, {
        headers: { [apiHeaderKey]: apiKey }
    }, GET_INTERVAL_MS);
    return response.json();
}

async function updateEntry(path, payload) {
    const url = baseUrl + path;
    const response = await throttledFetch(url, {
        method: 'PATCH',
        headers: {
            [apiHeaderKey]: apiKey,
            'Content-Type': 'application/json'
        },
        body: JSON.stringify(payload) // เนื้อหาต้องเป็นสตริง
    }, UPDATE_INTERVAL_MS);
    return response;
}

(async () => {
    try {
        const entries = await listEntries(universeId, dataStoreId);

        for (const entry of entries.dataStoreEntries) {
            const path = entry.path;
            console.log(`\nProcessing entry: ${path}`);

            const currentData = await getEntry(path);

            currentData.value.currency += 10;

            const payload = { value: currentData.value };

            const updateResponse = await updateEntry(path, payload);

            console.log(`Status: ${updateResponse.status}`);
            console.log(`Response: ${await updateResponse.text()}`);
        }
    } catch (error) {
        console.error('An error occurred during execution:', error);
    }
})();

ขีดจำกัดของเซิร์ฟเวอร์

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

ระบบจัดการนี้สามารถ กำหนดค่าโดยสร้าง โดยใช้ SetRateLimitForRequestType() API ซึ่งเป็น API ที่สร้างขึ้นเพื่อให้สามารถกำหนดค่าให้มีขีดจำกัดการเข้าถึงในแต่ละประเภทคำขอ

ขีดจำกัดอัตราเริ่มต้น เหล่านี้ จะมีผลบังคับใช้หาก API ไม่ถูกเรียกใช้:

data stores แบบมาตรฐาน

data stores แบบสั่ง

ขีดจำกัดข้อมูล

data stores จะจำกัดปริมาณข้อมูลที่สามารถใช้ได้ต่อการเข้าถึง

ชื่อ data store, ชื่อคีย์, และ scope จะต้องมีความยาวต่ำกว่าความยาวตัวอักษรที่กำหนด ใช้ string.len() เพื่อตรวจสอบความยาวของพวกเขา

ข้อมูล (ค่า) จะถูกเก็บไว้เป็นสตริงโดยไม่คำนึงถึงประเภทเริ่มต้นของมัน คุณสามารถตรวจสอบขนาดของข้อมูลได้โดยใช้ฟังก์ชัน JSONEncode() ซึ่งจะแปลงข้อมูล Luau เป็นตาราง JSON ที่ serialize

ขีดจำกัด Metadata

ขีดจำกัดในการกำหนดจำนวนตัวอักษรใน metadata ที่ผู้ใช้กำหนด

ขีดจำกัดการผ่าน

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

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

ขีดจำกัดการจัดเก็บ

เพื่อให้การจัดเก็บมีเสถียรภาพและขยายตัวได้ Data Store จะใช้ขีดจำกัดในระดับเกมต่อการใช้งานการจัดเก็บของคุณ

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

ขีดจำกัดการจัดเก็บจะคำนวณโดยใช้สูตรต่อไปนี้ Total latest version storage limit = 500 MB + 1 MB × lifetime user count.

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

เฉพาะเวอร์ชันล่าสุดของแต่ละคีย์เท่านั้นที่นับรวมในการใช้งานการจัดเก็บของคุณ คีย์ที่ถูกลบและเวอร์ชันที่ถูกแทนที่ แม้ว่ายังสามารถเข้าถึงได้ผ่าน API เวอร์ชันในระยะเวลาเก็บรักษาของพวกเขา จะไม่นับรวมในการใช้งานการจัดเก็บของคุณ อย่างไรก็ตาม Data Store ที่ถูกลบผ่านวิธีการ Open Cloud DeleteDataStore ยังคงนับรวมในการใช้งานการจัดเก็บในระยะเวลา 30 วันหลังจากการลบ จนกว่าพวกเขาจะถูกลบถาวร