รหัสข้อผิดพลาดและขีดจำกัดของ 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 อาจถูกควบคุมโดยการใช้งานในประสบการณ์ (และในทางกลับกัน) ดู ควบคุมขีดจำกัดอัตรา สำหรับแนวทางเพิ่มเติม

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('ตัวแปรสภาพแวดล้อม API_KEY ไม่ได้ตั้งค่า');
}

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(`\nกำลังประมวลผลรายการ: ${path}`);

            const currentData = await getEntry(path);

            currentData.value.currency += 10;

            const payload = { value: currentData.value };

            const updateResponse = await updateEntry(path, payload);

            console.log(`สถานะ: ${updateResponse.status}`);
            console.log(`การตอบสนอง: ${await updateResponse.text()}`);
        }
    } catch (error) {
        console.error('เกิดข้อผิดพลาดระหว่างการดำเนินการ:', error);
    }
})();

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

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

ขีดจำกัดเหล่านี้ สามารถกำหนดค่าได้โดยผู้สร้าง โดยใช้ API SetRateLimitForRequestType() โดยใช้ API นี้ ผู้สร้างสามารถกำหนดขีดจำกัดอัตรา data stores ของตนเองสำหรับแต่ละประเภทคำขอ

ขีดจำกัดอัตรา เริ่มต้น ต่อไปนี้จะใช้หากไม่มีการเรียก API:

data stores มาตรฐาน

data stores ที่จัดเรียง

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

Data stores จำกัดปริมาณข้อมูลที่สามารถใช้ต่อรายการ

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

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

ขีดจำกัดเมตาดาต้า

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

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

ข้อจำกัดด้านการส่งข้อมูลต่อคีย์ช่วยให้ประสิทธิภาพการทำงานในเซิร์ฟเวอร์ 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 วันที่กำลังดำเนินการลบ จนกว่าพวกเขาจะถูกลบอย่างถาวร