ข้อมูลหลักAPI

Rate limiting

ขีดจำกัดอัตราฝั่งเซิร์ฟเวอร์แบบอะตอมมิก GCRA ในคำสั่งเดียว หรือ limiter ที่ตั้งชื่อด้วย sliding window, token bucket หรือ leaky bucket ไม่ต้องใช้ Lua

คำสั่งอะตอมมิกต่อคำขอ
1
อัลกอริทึม
4
สคริปต์ Lua
0
ขั้นที่ 1 จาก 5
อนุญาต

10 คำขอต่อนาทีสำหรับผู้ใช้ 42 คำตอบบอกว่าอนุญาต ขีดจำกัด และเหลืออีกเท่าใด

เซสชันตัวอย่างplaying
# อนุญาต
hotkv> GCRA.LIMIT ratelimit:user:42 60000 10
1) (integer) 0
2) (integer) 10
3) (integer) 9
4) (integer) -1
5) (integer) 6000

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

ปัญหา

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

HotKV จัดการอย่างไร

GCRA.LIMIT ตัดสินและบันทึกในขั้นเดียว ไคลเอนต์ที่เข้ามาพร้อมกันจึงผ่านบนสถานะเดียวกันทั้งคู่ไม่ได้ และขีดจำกัดเติมกลับอย่างราบรื่นแทนที่จะรีเซ็ตที่ขอบของหน้าต่าง สำหรับขีดจำกัดที่คุณจัดการตามชื่อ RATELIMIT.CREATE ตั้ง limiter แบบ sliding window, token bucket หรือ leaky bucket พร้อมสถิติของสิ่งที่อนุญาตและปฏิเสธ

ทีละขั้นตอน

เกิดอะไรขึ้นบ้าง ทีละคำสั่ง

  1. 01

    อนุญาต

    10 คำขอต่อนาทีสำหรับผู้ใช้ 42 คำตอบบอกว่าอนุญาต ขีดจำกัด และเหลืออีกเท่าใด

    GCRA.LIMIT ratelimit:user:42 60000 10
  2. 02

    burst จากบอต

    สแครปเปอร์ใช้โควตา burst จนหมด แล้วถูกบอกว่าต้องรอนานเท่าใด คำขอที่ถูกปฏิเสธไม่เปลี่ยนแปลงอะไร

    GCRA.LIMIT ratelimit:bot:7 60000 10
  3. 03

    Limiter ที่ตั้งชื่อสำหรับแผน

    ลูกค้าแผนฟรีได้ 100 คำขอต่อนาทีบน sliding window

    RATELIMIT.CREATE free_plan 100 60000 ALGO sliding_window
  4. 04

    คำขอที่มีน้ำหนัก

    เอนด์พอยต์ส่งออกใช้ 20 หน่วย จึงใช้โควตามากกว่า

    RATELIMIT.CHECK free_plan customer:881 COST 20
  5. 05

    ดูว่า limiter ทำอะไร

    การตั้งค่า คีย์ที่ติดตามอยู่ และยอดรวมของคำขอที่อนุญาตและปฏิเสธ

    RATELIMIT.STATS free_plan
เหมาะกับงานแบบไหน

สถานการณ์จริง

API สาธารณะ

คีย์ API แต่ละตัวได้ขีดจำกัดตามแผน พร้อม burst สำหรับไคลเอนต์ที่ทำตัวดี และ Retry-After ที่แม่นยำสำหรับที่เหลือ

ฟอร์มล็อกอินและสมัครสมาชิก

จำกัดจำนวนครั้งที่ลองต่อ IP และต่อบัญชีเพื่อชะลอ credential stuffing

การเรียกขาออก

การเรียก API ของพาร์ตเนอร์หรือผู้ให้บริการ LLM ถูกคุมให้อยู่ใต้โควตาข้ามทุกเวิร์กเกอร์ในกลุ่ม

อยู่ในตัว

สิ่งที่คุณได้รับ

GCRA ในคำสั่งเดียว

เติมกลับอย่างราบรื่นพร้อม burst ตรวจและอัปเดตแบบอะตอมมิก และเวลาลองใหม่เมื่อถูกปฏิเสธ

GCRA.LIMITGCRA.RESET

Limiter ที่ตั้งชื่อ

Sliding window, token bucket หรือ leaky bucket สร้างครั้งเดียวและตรวจต่อคีย์

RATELIMIT.CREATERATELIMIT.CHECK

คำขอที่มีน้ำหนัก

การเรียกที่แพงนับเป็นหลายคำขอได้ GCRA.LIMIT รับค่านับ และ RATELIMIT.CHECK รับ COST

COST

สถิติ

ยอดรวมที่อนุญาตและปฏิเสธต่อ limiter

RATELIMIT.STATS
ข้อมูลอ้างอิง:GCRA.LIMITRATELIMIT.CREATERATELIMIT.CHECK

คำถามที่พบบ่อย

ต้องใช้สคริปต์ Lua สำหรับ rate limiting ไหม

ไม่ต้อง ทั้ง GCRA.LIMIT และ RATELIMIT.CHECK ทำการตรวจทั้งหมดเป็นคำสั่งอะตอมมิกเดียว

ควรใช้อย่างไหน

GCRA.LIMIT ไม่ต้องตั้งค่าและใช้ได้ในทุกแผน limiter ที่ตั้งชื่อ RATELIMIT.* เพิ่มตัวเลือกอัลกอริทึมและสถิติ และอยู่ในแผน Performance และ Scale

คำขอที่ถูกปฏิเสธมีต้นทุนเท่าใด

ไม่มีเลย การเรียก GCRA ที่ถูกปฏิเสธไม่เปลี่ยน limiter ไคลเอนต์ที่ลองใหม่จึงไม่ถูกลงโทษเพิ่ม

กรณีใช้งานที่เกี่ยวข้อง

การปฏิบัติการ LLM

การกำกับดูแลต้นทุน LLM

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

สำรวจ
เว็บและมือถือ

การจัดการเซสชัน

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

สำรวจ
ฟินเทค

การตรวจจับการฉ้อโกงแบบเรียลไทม์

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

สำรวจ

ลองกับเวิร์กโหลดของคุณเอง

HotKV ใช้โปรโตคอลของ Redis คุณจึงชี้ไคลเอนต์ที่มีอยู่มาที่ HotKV แล้วรันคำสั่งเดียวกันนี้ได้

ขอสิทธิ์เข้าใช้งานก่อนใครถัดไป: ลีดเดอร์บอร์ด