B站评论系统的多级存储架构

1.  背景

评论是 B站生态的重要组成部分，涵盖了 UP 主与用户的互动、平台内容的推荐与优化、社区文化建设以及用户情感满足。B站的评论区不仅是用户互动的核心场所，也是平台运营和用户粘性的关键因素之一，尤其是在与弹幕结合的情况下，成为平台的标志性特色。

在社会热点事件发生时，评论区的读写流量会急剧增加，直接影响业务运行，对用户体验、内容创作和社区文化等多个方面产生负面影响，所以评论服务的稳定性至关重要。

评论系统对缓存命中率要求非常高，一旦发生缓存失效，大量请求会直接访问 TiDB，如果 TiDB 出现问题，将导致评论服务不可用。所以评论需要构建一套可靠的容灾系统，并具备自动降级能力，以提升评论服务的整体稳定性。

2. 架构设计

评论系统架构主要依赖 Redis 缓存和 TiDB 存储，列表接口中依赖多种排序索引，如点赞序、时间序、热度序等，这些索引通过 Redis 的 Sorted Set 数据结构进行存储。

在大评论区中查询这些排序索引，当 Redis 缓存 miss 时需要回源 TiDB 查询，因数据量过大、查询耗时较长，慢查询会占用大量 CPU 和内存，进而导致其他查询的延迟或阻塞，严重影响整个 TiDB 的吞吐量和性能。例如查询点赞序排序索引：

SELECT id FROM reply WHERE ... ORDER BY like_count DESC LIMIT m,n

为了避免 TiDB 故障导致评论服务不可用，我们希望建立一套新的存储系统，解决 TiDB 单点故障问题。该系统不仅为业务提供容灾能力和自动降级通道，还能在大流量查询场景下提供更优的查询性能，从而提升整体评论服务的稳定性。

基于 B站自研的泰山 KV 存储（Taishan），我们搭建了「多级存储架构」，整体设计方案的核心思路包括：

• 将排序索引的存储从「结构化」转为「非结构化」

• 将排序索引查询从「SQL」转换为性能更高的「NoSQL」

• 通过「写场景的复杂度」来换取「更优的读场景性能」

3. 存储设计

 存储模型

在评论的业务场景中，我们抽象了两种数据模型：排序索引（Index）、评论物料（KV）