【笔记】B站评论系统的多级存储架构

感觉不太好做笔记？
先hold住原文章：https://mp.weixin.qq.com/s/ko7pbQSqvqOo0E2iiDyXJg?search_click_id=8336944276716588509-1734447949292-6303540397ai：https://www.doubao.com/chat/522700184786434

（一）背景

评论重要性
1. 是 B 站生态关键部分，涵盖 UP 主与用户互动、平台内容推荐优化、社区文化建设和用户情感满足。评论区与弹幕结合是平台标志性特色，对平台运营和用户粘性至关重要。
面临问题
1. 社会热点事件时读写流量剧增影响业务，缓存命中率高，TiDB 单点故障会致评论服务不可用，需可靠容灾和自动降级能力。

（二）架构设计

现有架构问题
1. 依赖 Redis 缓存和 TiDB 存储，大评论区查询排序索引时，Redis 缓存 miss 回源 TiDB 查询耗时久，影响 TiDB 吞吐量和性能。
2. 为了避免 TiDB 故障导致评论服务不可用，Bers希望建立一套新的存储系统，解决 TiDB 单点故障问题。该系统不仅为业务提供容灾能力和自动降级通道，还能在大流量查询场景下提供更优的查询性能，从而提升整体评论服务的稳定性。
多级存储架构
1. 基于泰山 KV 存储（Taishan）搭建，核心思路：
  - 将排序索引存储从 “结构化” 转 “非结构化”
  - 查询从 “SQL” 转 “NoSQL”
  - 用 “写场景复杂度” 换 “读场景性能”。
2. 包含 Redis Cluster、TiDB Cluster、Taishan Cluster 等组件，各组件在评论读写流程中有不同作用。

评论系统架构的流程图解释：

发评论（reply - interface）
1. 流程从用户发评论开始，通过reply - interface进入系统。
2. 发评论操作会经过消息队列（MQ），并由reply - job处理。
3. batch processor会将处理后的结果批量写入存储。
存储机制
1. 一级存储（Redis Cluster）
  - 包括评论区（subject）、评论物料（content）和排序索引存储（sorted set）。
  - 当有读评论操作时，首先会检查是否命中缓存。
  - 如果命中缓存，则直接返回结果；如果未命中，则进入下一步处理。
2. 二级存储（TiDB Cluster）
  - 包括评论主题（subject）、评论物料（content）、根评论（parent reply）、子评论（child reply）、排序索引（sorted index）、热度序（hotness order）、点赞序（like order）和时间序（time order）。
  - 当一级存储未命中时，会从二级存储中获取数据。
  - 数据在二级存储中通过binlog和logic processor进行处理，同时有实时对账和离线对账系统保证数据一致性。
3. 三级存储（Taishan Cluster）
  - 用于存储评论相关数据，包括评论主题、评论物料、根评论、子评论等。
  - 数据在三级存储中通过bring操作进行写入，并通过logic logic processor进行处理。
  - 有重试队列用于处理写失败情况，并且有流量控制机制，包括优先级、路由规则、控制策略和自动降级等。
数据流向和处理
1. 数据在不同存储层级之间通过binlog、bring和logic processor等机制进行交互和处理。
2. 图中还展示了评论系统中的数据一致性保障机制，包括实时对账和离线对账系统。
3. 流量控制机制用于确保系统在高负载情况下的稳定性，包括优先级设置、路由规则、控制策略和自动降级等功能。

（三）存储设计

存储模型
1. 抽象数据模型
  抽象数据模型
  TiDB 模型
  Taishan 模型
  说明
  Index
  Secondary Index
  Sorted Set
  排序索引，例如点赞序、时间序的排序索引
  KV
  Primary Key & Row
  Key-Value
  包含元数据、内容等必要的评论物料
2. 模型实现思路
  - 以点赞序前 10 条评论为例，先通过排序索引召回评论 ID，再用推荐算法重排，最后根据 ID 获取评论详情。
  - 利用不同底层存储结构优化查询等场景，使用 Redis 或 Memcache 构建 KV 模型提升查询性能，Redis Sorted Set 构建 Index 模型支持增量更新和高效分页查询。关键词搜索场景可用 ElasticSearch 作为检索索引。基于 KV 作为唯一事实表，同步全量和捕获增量数据转换为下游索引表，实现业务解耦，但带来理解维护成本和一致性难题，不过整体优势大于劣势。
数据类型
1. 从 SQL 转向 NoSQL，因 NoSQL 数据模型灵活，有更高优化潜力，如 Taishan 查询 Redis Sorted Set 和 KV 性能高。Taishan 相比 TiDB 不支持 ACID 事务和二级索引等，功能更精简。TiDB 基于 MVCC 机制，热门评论区频繁更新点赞数时排序索引历史版本多影响性能，Taishan 无 MVCC 查询排序索引性能更优。TiDB 不直接支持自定义分片策略，Taishan 支持哈希标签可确保同一评论区评论在同一分片，批量查询降低扇出度，热点场景可打散请求优化性能。以时间序和点赞序为例列举了 Taishan 数据模型。

（四）数据一致性

数据同步问题
1. 从 TiDB 到 Taishan 数据同步需自行实现，面临数据丢失、写入失败等问题。
解决措施
1. 重试队列：解决写失败问题，将失败请求异步重试，但引入队列可能导致写并发数据竞争和乱序问题。
2. 版本号机制：每次评论数据变更版本号递增，CAS 写操作时比对 binlog 和 Taishan 数据版本号，不一致则丢弃过期数据。
3. 对账系统：根据 CAP 理论，系统无法完全保证一致性，引入重试、CAS 和版本号机制后仍可能有不一致，通过实时对账（TiDB Binlog 事件驱动，延迟队列消费对比数据并修复）和离线对账（利用数仓离线数据 T + 1 对比）确保最终一致性。

（五）降级策略

降级需求与策略对比
1. 评论业务可用性要求高，设计降级策略有串行（简单但耗时长易整体超时）和并行（耗时短但多一倍请求浪费资源）方式，均不完美。
对冲策略
1. 选择 “对冲策略”，主节点请求超时后发备份请求到次节点，根据主次节点耗时特性设延迟阈值平衡响应时间和资源消耗。实际根据业务场景设 TiDB 和 Taishan 主次关系，如数据实时性敏感、查询轻量场景 TiDB 为主，Taishan 为次；数据实时性要求低、大 SQL 查询场景 Taishan 为主，TiDB 为次。TiDB 底层 TiKV 节点宕机时自动降级到 Taishan，评论业务未受影响。

最后更新于2个月前

（一）背景

评论重要性

是 B 站生态关键部分，涵盖 UP 主与用户互动、平台内容推荐优化、社区文化建设和用户情感满足。评论区与弹幕结合是平台标志性特色，对平台运营和用户粘性至关重要。

面临问题

社会热点事件时读写流量剧增影响业务，缓存命中率高，TiDB 单点故障会致评论服务不可用，需可靠容灾和自动降级能力。

（二）架构设计

现有架构问题

依赖 Redis 缓存和 TiDB 存储，大评论区查询排序索引时，Redis 缓存 miss 回源 TiDB 查询耗时久，影响 TiDB 吞吐量和性能。
为了避免 TiDB 故障导致评论服务不可用，Bers希望建立一套新的存储系统，解决 TiDB 单点故障问题。该系统不仅为业务提供容灾能力和自动降级通道，还能在大流量查询场景下提供更优的查询性能，从而提升整体评论服务的稳定性。

多级存储架构

基于泰山 KV 存储（Taishan）搭建，核心思路：
- 将排序索引存储从 “结构化” 转 “非结构化”
- 查询从 “SQL” 转 “NoSQL”
- 用 “写场景复杂度” 换 “读场景性能”。
包含 Redis Cluster、TiDB Cluster、Taishan Cluster 等组件，各组件在评论读写流程中有不同作用。

评论系统架构的流程图解释：

发评论（reply - interface）

流程从用户发评论开始，通过reply - interface进入系统。
发评论操作会经过消息队列（MQ），并由reply - job处理。
batch processor会将处理后的结果批量写入存储。

存储机制

一级存储（Redis Cluster）
- 包括评论区（subject）、评论物料（content）和排序索引存储（sorted set）。
- 当有读评论操作时，首先会检查是否命中缓存。
- 如果命中缓存，则直接返回结果；如果未命中，则进入下一步处理。
二级存储（TiDB Cluster）
- 包括评论主题（subject）、评论物料（content）、根评论（parent reply）、子评论（child reply）、排序索引（sorted index）、热度序（hotness order）、点赞序（like order）和时间序（time order）。
- 当一级存储未命中时，会从二级存储中获取数据。
- 数据在二级存储中通过binlog和logic processor进行处理，同时有实时对账和离线对账系统保证数据一致性。
三级存储（Taishan Cluster）
- 用于存储评论相关数据，包括评论主题、评论物料、根评论、子评论等。
- 数据在三级存储中通过bring操作进行写入，并通过logic logic processor进行处理。
- 有重试队列用于处理写失败情况，并且有流量控制机制，包括优先级、路由规则、控制策略和自动降级等。

数据流向和处理

数据在不同存储层级之间通过binlog、bring和logic processor等机制进行交互和处理。
图中还展示了评论系统中的数据一致性保障机制，包括实时对账和离线对账系统。
流量控制机制用于确保系统在高负载情况下的稳定性，包括优先级设置、路由规则、控制策略和自动降级等功能。

（三）存储设计

存储模型

抽象数据模型
抽象数据模型
TiDB 模型
Taishan 模型
说明
Index
Secondary Index
Sorted Set
排序索引，例如点赞序、时间序的排序索引
KV
Primary Key & Row
Key-Value
包含元数据、内容等必要的评论物料
模型实现思路
- 以点赞序前 10 条评论为例，先通过排序索引召回评论 ID，再用推荐算法重排，最后根据 ID 获取评论详情。
- 利用不同底层存储结构优化查询等场景，使用 Redis 或 Memcache 构建 KV 模型提升查询性能，Redis Sorted Set 构建 Index 模型支持增量更新和高效分页查询。关键词搜索场景可用 ElasticSearch 作为检索索引。基于 KV 作为唯一事实表，同步全量和捕获增量数据转换为下游索引表，实现业务解耦，但带来理解维护成本和一致性难题，不过整体优势大于劣势。

数据类型

从 SQL 转向 NoSQL，因 NoSQL 数据模型灵活，有更高优化潜力，如 Taishan 查询 Redis Sorted Set 和 KV 性能高。Taishan 相比 TiDB 不支持 ACID 事务和二级索引等，功能更精简。TiDB 基于 MVCC 机制，热门评论区频繁更新点赞数时排序索引历史版本多影响性能，Taishan 无 MVCC 查询排序索引性能更优。TiDB 不直接支持自定义分片策略，Taishan 支持哈希标签可确保同一评论区评论在同一分片，批量查询降低扇出度，热点场景可打散请求优化性能。以时间序和点赞序为例列举了 Taishan 数据模型。

（四）数据一致性

数据同步问题

从 TiDB 到 Taishan 数据同步需自行实现，面临数据丢失、写入失败等问题。

解决措施

重试队列：解决写失败问题，将失败请求异步重试，但引入队列可能导致写并发数据竞争和乱序问题。
版本号机制：每次评论数据变更版本号递增，CAS 写操作时比对 binlog 和 Taishan 数据版本号，不一致则丢弃过期数据。
对账系统：根据 CAP 理论，系统无法完全保证一致性，引入重试、CAS 和版本号机制后仍可能有不一致，通过实时对账（TiDB Binlog 事件驱动，延迟队列消费对比数据并修复）和离线对账（利用数仓离线数据 T + 1 对比）确保最终一致性。

（五）降级策略

降级需求与策略对比

评论业务可用性要求高，设计降级策略有串行（简单但耗时长易整体超时）和并行（耗时短但多一倍请求浪费资源）方式，均不完美。

对冲策略

选择 “对冲策略”，主节点请求超时后发备份请求到次节点，根据主次节点耗时特性设延迟阈值平衡响应时间和资源消耗。实际根据业务场景设 TiDB 和 Taishan 主次关系，如数据实时性敏感、查询轻量场景 TiDB 为主，Taishan 为次；数据实时性要求低、大 SQL 查询场景 Taishan 为主，TiDB 为次。TiDB 底层 TiKV 节点宕机时自动降级到 Taishan，评论业务未受影响。