Design and Implementation of Bilibili Live Ranking System

The article introduces the positioning and business value of Bilibili's live ranking system, explaining how various ranking lists (e.g., streamer popularity, user contributions, gift rewards) motivate both streamers and viewers, improve platform engagement, and guide rational consumption.

It provides an overview of the system's product architecture, showing a high‑level diagram of the ranking service within the live platform.

The system is described in detail, covering the types of rankings (by role, scope, time granularity, and custom lanes) and the need for a flexible, configurable component to support diverse business scenarios.

Ranking Configuration

New rankings are created via a management console. Each ranking receives an immutable rank_id that serves as the primary identifier for all read/write operations.

Basic Configuration

The service stores ranking data in MySQL for persistence and uses Redis KV (specifically Redis zset ) for caching member scores. Cache TTLs and ranking length limits are tuned to balance traffic pressure and memory usage. Different MySQL and Redis clusters can be assigned per ranking based on QPS requirements.

Score Precision and Sorting

Score values are split into integer and fractional parts to support secondary sorting (e.g., fan badge level). Three sorting modes are supported:

Ascending time order: integer part = input score, fractional part = (999999999 - ts) truncated.

Descending time order: integer part = input score, fractional part = ts truncated.

Custom order: integer part = input score, fractional part = custom subscore .

When scores are equal, Redis orders members by binary lexical order of the member key.

Dimension Configuration

Before a ranking goes live, dimensions (e.g., streamer, session ID) and time granularity are configured. Selecting dimensions creates horizontal sub‑rankings; selecting a time dimension creates vertical sub‑rankings (daily, weekly, monthly, etc.). The article suggests caching the start/end timestamps of natural time windows to avoid repeated calculations.

Automated Scoring

Automated scoring triggers updates when specific events occur. The system centralizes upstream MQ message consumption via a behavior service, which then calls ranking RPC interfaces. Not all business scenarios use automated scoring; some require explicit score calculation and manual RPC calls.

Filter Rules

A generic filter module allows configuring partition‑level or item‑level filters (e.g., only certain live rooms or gifts contribute to a ranking). Special hooks can be added for bespoke business logic.

Data Storage

The ranking data model uses MySQL tables with fields such as id , rank_id , type_id , item_id , and score . The type_id encodes selected dimensions, e.g., "${anchor_time}_${streamer_uid}" . Example table definition:

CREATE TABLE `some_rank` (

`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',

`rank_id` int(11) NOT NULL DEFAULT '0' COMMENT '榜单ID',

`type_id` varchar(100) NOT NULL DEFAULT '' COMMENT '子榜标识',

`item_id` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT '榜单成员标识',

`score` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT '榜单成员积分',

// ......

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='xxx榜单数据表';

When a scoring request arrives, the payload includes rank_id , item_id , score , and a dimensions object. Example JSON:

{

"rank_id": 12345, //榜单ID

"item_id": 110000653, //成员UID

"score": 1980, //本次加分

"dimensions": {

"ruid": 110000260, //主播UID

"timestamp": 1713165315 //行为时间戳

// 其他维度参数

}

// 其他必传参数

}

The system computes type_id from the timestamp and selected dimensions (e.g., 1711900800_110000260 for a monthly ranking) and stores the row using rank_id , type_id , and item_id as a composite primary key.

Redis Caching

Ranking keys in Redis are built from rank_id and type_id , ensuring that reads and writes target the correct time‑slice.

Ranking Updates

A flow diagram (omitted) illustrates the scoring pipeline, including retry mechanisms for failed updates and idempotency safeguards against duplicate MQ consumption.

Business Challenges

High read/write traffic, especially during popular events, demands robust performance. Write bottlenecks arise from massive interactive events (likes, comments). To mitigate, a “slow queue” aggregates similar writes before persisting, reducing storage pressure. For spikes (e.g., large contests), degradation strategies skip ranking updates for non‑critical events.

Read pressure on Redis nodes is alleviated by a secondary in‑memory cache for hot rooms, CDN‑based hot‑room SDK detection, and manual hot‑room designation.

Current Architecture

A simplified internal diagram (omitted) shows the overall component layout.

Future Plans

Improve code quality and modularity.

Log governance to reduce noise and storage.

Storage governance: automate archival of stale data, clarify cluster isolation, and provide visual monitoring.

Redesign the ranking core with clearer domain boundaries, better real‑time processing, and more scientific storage choices.