Live Broadcast Duration Statistics Design Plan

Live Stream Duration Statistics Design Proposal

Business Overview

Process: Accumulate the total online time for an entire live stream, allowing users to leave and re‑enter multiple times.

Trigger conditions:

• Record an “enter” event when a user joins the live room.
• Record an “exit” event when a user leaves the live room.

Problem: Business feedback indicates that the live‑stream duration statistics are inaccurate.

Root‑cause analysis:

• Message delivery:

• Multiple consumers processing simultaneously:

• Normal case: 1 enters, 1 exits; 2 enters, 2 exits.

• Abnormal case: Rapid repeated entry/exit may produce a sequence such as 1 enters, 2 enters, 1 exits, 2 exits; if the consumer processes “2 enters” after “1 exits”, then when handling “2 exits” the system has not yet received “2 enters”, resulting in incorrect participation time and inaccurate real‑time attendance.

Solution: Lock operations per user to ensure that each user’s statistics are processed serially, and when a user leaves the live room, verify that the leave time is later than the entry time.

---

Implementation Logic

• User entry/exit data are split into individual user events via commonProducer (each entry or exit becomes a separate message). These messages are sent through an MQ to consumers for asynchronous processing.

• RocketMQ consumers receive messages from the queue and handle user entry/exit events. For each user, a distributed lock is applied so that the user’s entry and exit operations are serialized. (Idempotency and ordering cannot be guaranteed under extreme conditions).

• User entry logic:

  • Check whether the live stream has ended; if so, ignore the entry event.
  • Cache the user’s “entry time” in Redis (using two Redis keys: one for online status, one for the actual entry timestamp).
  • Update the user’s room‑detail record in the database.

• User exit logic:

  • Update the user’s leave‑time detail record (liveUserDetailService.updateOrSaveDetail()).
  • Verify that the leave time is not earlier than the entry time; if abnormal, log a warning.
  • If the exit is normal, delete the user’s online‑status entry from Redis.
  • Perform related statistics (e.g., cumulative participation duration, trend analysis) and emit an exit event to other business modules.

Sequence diagram:

(diagram omitted)

---

Source Code Review

(section intentionally left blank)

---

Extreme‑Case Handling

In extreme scenarios, message retries, API re‑submissions, etc., can cause out‑of‑order or non‑idempotent consumption, making it impossible to guarantee consistency when the consumer processes messages concurrently.

Approach:

• Include a version field in the callback’s parent class; increment this field (e.g., 1, 2, 3, 4; odd numbers denote entry, even numbers denote exit) to store a SequenceId.

• Set up a message handler in Redis; sample code:

// Redis handler example (pseudo‑code)
String key = "stream:user:" + userId + ":seq";
Long seq = redis.incr(key); // increment sequence
// further processing...

Note: Redis operations alone cannot guarantee atomicity; additional locking is required.

---

Originally written by Li Wei (李唯_) and published in Chinese on 后端技术栈全书 (Full-Stack Backend Engineering). Translated and adapted for DriftSeas with permission.