Design and Implementation of Bilibili Live Ranking System

The ranking system is a core component of Bilibili's live streaming platform, appearing in many scenarios such as gift rewards, interactive games, host PK, and user popularity lists. It motivates hosts to improve performance, encourages viewers to engage, and provides a bridge between the platform, hosts, and audience.

Business Overview – The system supports various ranking dimensions (host, user, item, room, guild, etc.), scopes (global, region, activity, session), and time granularities (hourly, daily, weekly, monthly, quarterly, yearly). Flexible configuration allows each business need to create new rankings quickly via the management console.

System Introduction – Rankings are identified by a generated rank_id and stored persistently in MySQL while scores are cached in Redis using sorted sets (zset). The type_id field encodes selected dimensions (e.g., timestamp, host UID) and the item_id represents the ranked entity.

Configuration – Users create a new ranking by selecting scoring dimensions and time buckets. The system automatically composes the type_id string (e.g., "1711900800_110000260") based on the configured dimensions and the event timestamp.

MySQL Storage

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榜单数据表';

Redis Cache – Ranking lists are cached as zsets whose keys combine rank_id and type_id . This enables fast read/write and TTL control for each sub‑ranking.

Update Flow – When an event occurs, the behavior system publishes a message to a MQ. The ranking service consumes the message, calculates the final score (including optional sub‑score), and updates the corresponding MySQL row and Redis zset. Automated scoring can trigger multiple rankings simultaneously, with retry and idempotency safeguards.

Performance Challenges – Write spikes from interactive events (likes, comments) and large‑scale activities can overload storage. Solutions include a "slow queue" that aggregates writes before persisting, and degradation strategies that skip scoring for low‑priority events during peak load.

Read Performance – Most reads hit Redis. Hot rooms are protected by a second‑level in‑memory cache (CDN SDK, hotspot detector, or manual hot‑room configuration) to relieve pressure on individual Redis nodes.

Future Plans – Refine architecture layers, improve real‑time scoring consistency, adopt more suitable storage technologies, and enhance observability and log management to reduce noise and improve operational efficiency.