Design and Implementation of Bilibili Live Ranking System

The ranking system is a core component of Bilibili's live streaming platform, covering various scenarios such as live gifts, interactions, paid games, events, and streamer rankings, and it drives both streamer motivation and audience engagement.

Business value is highlighted by its ability to incentivize higher-quality performances, increase viewer participation, and support healthy consumption while preventing over‑commercialization.

System Overview : The system uses MySQL for persistent storage and Redis (zset) for caching leaderboard scores, with configurable TTLs and length limits to balance product needs and memory pressure.

Configuration : Rankings are defined via a management console, automatically generating a unique rank ID. Dimensions (e.g., streamer, session, custom) and time granularity (day, week, month) can be selected to create sub‑rankings, and automated scoring is triggered by specific events.

Dimension & Scoring Logic : Scores are split into integer and fractional parts to support secondary ordering (e.g., fan badge level). Three scoring strategies are supported: forward time order, reverse time order, and custom sub‑score.

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 '榜单成员积分', -- ... other fields ... ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='xxx榜单数据表';

When a scoring request arrives, the system calculates a type_id based on selected dimensions and the event timestamp, for example:

{ "rank_id": 12345, "item_id": 110000653, "score": 1980, "dimensions": { "ruid": 110000260, "timestamp": 1713165315 } }

The calculated type_id (e.g., "1711900800_110000260") together with rank_id and item_id forms the primary key for storage.

Automation & Filtering : Automated scoring reacts to behavior events via a centralized behavior system, reducing per‑service MQ subscription overhead. Filtering rules allow scoring only for specific partitions, items, or events.

Performance Challenges : Write bottlenecks arise from high‑frequency interaction events and large‑scale events; a slow‑queue aggregates writes before persisting. Read bottlenecks in hot rooms are mitigated by secondary in‑memory caches, CDN‑based hot‑room detection, and manual hot‑room configuration.

Future Architecture : Plans include clearer domain boundaries, improved real‑time consistency, better storage selection, and enhanced logging and data governance.