หน้าต่างเลื่อนด้วยเซตเรียงลำดับใน Redis
นำตัวจำกัดอัตราการส่งคำขอแบบหน้าต่างเลื่อนกระจายไปใช้ด้วยเซตเรียงลำดับของ Redis การดำเนินการแบบอะตอมิก และการหมดอายุอัตโนมัติของรายการเก่า
หน้าต่างเลื่อนด้วยเซตเรียงลำดับใน Redis เป็นบทเรียน API Rate Limiting & Scalability Patterns ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน API Rate Limiting & Scalability Patterns และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส API Rate Limiting & Scalability Patterns มีบทเรียนทั้งหมด 4 บทเรียน
บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ
From Theory to Production
You understand the sliding window log and counter conceptually. Now build one that works across many servers using Redis sorted sets, the most common production technique for accurate distributed rate limiting.
Why Sorted Sets
A Redis sorted set (ZSET) stores members ranked by a numeric score. By using the request timestamp as the score, we get an ordered log of recent requests we can trim and count efficiently.
One Key Per Client
Each client gets a key like rl:user123. Every incoming request adds a member to that client's sorted set, scored by the current timestamp in milliseconds.
ZADD rl:user123 1700000000123 1700000000123Trimming the Window
Before counting, remove entries older than the window. If the window is 60 seconds, delete everything with a score below now - 60000. This keeps only the requests inside the current sliding window.
ZREMRANGEBYSCORE rl:user123 0 (now-60000)Counting Requests
After trimming, the cardinality of the set is the number of requests in the window. Compare it against the limit to allow or deny.
ZCARD rl:user123Atomicity Matters
Doing trim, add, and count as separate commands creates a race condition under concurrency. Wrap them in a single Lua script so Redis executes them atomically per client.
The Lua Script
A Lua script run with EVAL performs all steps in one atomic operation, returning whether the request is allowed. No two requests can interleave mid-check.
redis.call('ZREMRANGEBYSCORE', KEYS[1], 0, ARGV[1])
local count = redis.call('ZCARD', KEYS[1])
if count < tonumber(ARGV[3]) then
redis.call('ZADD', KEYS[1], ARGV[2], ARGV[2])
return 1
end
return 0Setting Expiry
Always set a TTL on the key (a bit longer than the window) so abandoned clients do not leak memory. Idle keys expire automatically.
EXPIRE rl:user123 120Accuracy vs Memory
This approach is highly accurate because it tracks every request timestamp, but memory grows with request volume per window. For very high-traffic clients, the sliding window counter approximation uses far less memory.
Handling Many Nodes
Because all API nodes talk to the same Redis, the limit is enforced globally regardless of which node handles a request. Use a Redis cluster or replica setup for availability, mindful that replication lag can slightly relax limits.
Failure Modes
Decide what happens if Redis is unreachable: fail open (allow traffic, risk overload) or fail closed (block traffic, risk outage). Most public APIs fail open with a local fallback limiter.
Quick Check
Test your understanding of the Redis sliding window.
Recap
You built a distributed sliding window:
- Store request timestamps in a Redis sorted set, one key per client.
- Trim old entries with
ZREMRANGEBYSCORE, count withZCARD. - Wrap trim/count/add in a Lua script for atomicity.
- Set a TTL to free memory, and decide fail-open vs fail-closed for Redis outages.
เรียนรู้ API Rate Limiting & Scalability Patterns ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 12
- บทเรียน
- 48
คำถามที่พบบ่อย
บทเรียน “หน้าต่างเลื่อนด้วยเซตเรียงลำดับใน Redis” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “หน้าต่างเลื่อนด้วยเซตเรียงลำดับใน Redis” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส API Rate Limiting & Scalability Patterns ให้อัปเกรดเป็น CoddyKit PRO คอร์ส API Rate Limiting & Scalability Patterns มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “หน้าต่างเลื่อนด้วยเซตเรียงลำดับใน Redis”
นำตัวจำกัดอัตราการส่งคำขอแบบหน้าต่างเลื่อนกระจายไปใช้ด้วยเซตเรียงลำดับของ Redis การดำเนินการแบบอะตอมิก และการหมดอายุอัตโนมัติของรายการเก่า คุณปฏิบัติ API Rate Limiting & Scalability Patterns ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน API Rate Limiting & Scalability Patterns หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน API Rate Limiting & Scalability Patterns บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน
บทเรียน “หน้าต่างเลื่อนด้วยเซตเรียงลำดับใน Redis” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน API Rate Limiting & Scalability Patterns นี้ได้ไหม
ได้ บทเรียน API Rate Limiting & Scalability Patterns ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การใช้งานบันทึกหน้าต่างเลื่อน
- กลยุทธ์ตัวนับหน้าต่างเลื่อน
- การเปรียบเทียบอัลกอริทึมและข้อแลกเปลี่ยน
- หน้าต่างเลื่อนด้วยเซตเรียงลำดับใน Redis