0Pricing
Redis Caching & Messaging (Pub/Sub, Streams) · บทเรียน

การติดตามความล่าช้าของกลุ่มผู้ใช้ข้อมูล

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

การติดตามความล่าช้าของกลุ่มผู้ใช้ข้อมูล เป็นบทเรียน Redis Caching & Messaging (Pub/Sub, Streams) ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Redis Caching & Messaging (Pub/Sub, Streams) และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Redis Caching & Messaging (Pub/Sub, Streams) มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

Why Monitor Lag?

In a healthy pipeline, consumers keep up with producers. When they fall behind, lag builds up: unread or unacknowledged entries pile in the stream. Monitoring lag lets you scale consumers before backlogs become outages.

Inspecting the Stream

XINFO STREAM gives a high-level view: length, last generated ID, and the number of consumer groups attached.

XINFO STREAM orders

Inspecting Groups

XINFO GROUPS lists each group with its last-delivered-id, the count of pending entries, and (in recent Redis) a lag field showing how many entries the group has not yet read.

XINFO GROUPS orders

Understanding Lag

The lag value is the number of entries between the group's last-delivered-id and the stream's last entry. A steadily rising lag means producers outpace consumers.

Per-Consumer Detail

XINFO CONSUMERS drills into a single group, showing each consumer's pending count and idle time. A consumer with high idle time and many pending entries is likely stuck or dead.

XINFO CONSUMERS orders workers

Summarizing Pending

XPENDING with just the key and group gives a summary: total pending, the lowest and highest pending IDs, and a per-consumer breakdown.

XPENDING orders workers

Detailed Pending

The extended form lists individual pending entries with their idle time and delivery count, helping you find messages that keep failing.

XPENDING orders workers - + 10

Spotting Poison Messages

A high delivery count on a pending entry signals a poison message: one that repeatedly fails and gets re-delivered. Route it to a dead-letter stream after a threshold.

XADD dead-letter * original_id 1716900000-0 reason "max retries"

Alerting Thresholds

Turn metrics into alerts: warn when group lag exceeds a budget, or when any consumer's idle time crosses a limit while holding pending entries. Sample these via XINFO from a monitoring job.

Reacting to Lag

When lag climbs, add consumers to the group to parallelize processing, optimize the per-message work, or increase the trim cap so the buffer can absorb spikes. Each consumer in a group gets a disjoint slice of new entries.

A Monitoring Loop

A simple monitor periodically calls XINFO GROUPS, extracts lag and pending, and emits the values to your metrics system for dashboards and alerts.

while true; do redis-cli XINFO GROUPS orders; sleep 10; done

Quick Check

Test your understanding of lag monitoring.

Recap

You learned to monitor consumer group health using XINFO STREAM/GROUPS/CONSUMERS for lag and idle time, and XPENDING for pending detail and delivery counts. Use these signals to detect poison messages, set alert thresholds, and scale consumers before backlogs grow.

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

บทเรียน “การติดตามความล่าช้าของกลุ่มผู้ใช้ข้อมูล” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การติดตามความล่าช้าของกลุ่มผู้ใช้ข้อมูล” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Redis Caching & Messaging (Pub/Sub, Streams) ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Redis Caching & Messaging (Pub/Sub, Streams) มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การติดตามความล่าช้าของกลุ่มผู้ใช้ข้อมูล”

ตรวจสอบสถานะของกลุ่มผู้ใช้ข้อมูลด้วย XINFO และ XPENDING เพื่อวัดความล่าช้า ค้นหาผู้ใช้ข้อมูลที่ติดขัด และรักษาการประมวลผลสตรีมให้ดำเนินต่อไปตามแผน คุณปฏิบัติ Redis Caching & Messaging (Pub/Sub, Streams) ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Redis Caching & Messaging (Pub/Sub, Streams) หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Redis Caching & Messaging (Pub/Sub, Streams) บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “การติดตามความล่าช้าของกลุ่มผู้ใช้ข้อมูล” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Redis Caching & Messaging (Pub/Sub, Streams) นี้ได้ไหม

ได้ บทเรียน Redis Caching & Messaging (Pub/Sub, Streams) ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. บทนำสู่กลุ่มผู้ใช้
  2. การใช้งานตรรกะของกลุ่มผู้ใช้
  3. การจัดการข้อความค้างและความล้มเหลว
  4. การติดตามความล่าช้าของกลุ่มผู้ใช้ข้อมูล
← กลับไปที่ Redis Caching & Messaging (Pub/Sub, Streams)