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

感觉不太好做笔记？

先hold住原文章：https://mp.weixin.qq.com/s/ko7pbQSqvqOo0E2iiDyXJg?search_click_id=8336944276716588509-1734447949292-6303540397ai：https://www.doubao.com/chat/522700184786434

（一）背景

  1. 评论重要性

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

  2. 面临问题

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

（二）架构设计

  1. 现有架构问题

    1. 依赖 Redis 缓存和 TiDB 存储，大评论区查询排序索引时，Redis 缓存 miss 回源 TiDB 查询耗时久，影响 TiDB 吞吐量和性能。

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

  2. 多级存储架构

    1. 基于泰山 KV 存储（Taishan）搭建，核心思路：

      • 将排序索引存储从 “结构化” 转 “非结构化”

      • 查询从 “SQL” 转 “NoSQL”

      • 用 “写场景复杂度” 换 “读场景性能”。

    2. 包含 Redis Cluster、TiDB Cluster、Taishan Cluster 等组件，各组件在评论读写流程中有不同作用。

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

  1. 发评论（reply - interface）

    1. 流程从用户发评论开始，通过reply - interface进入系统。

    2. 发评论操作会经过消息队列（MQ），并由reply - job处理。

    3. batch processor会将处理后的结果批量写入存储。

  2. 存储机制

    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进行处理。

      • 有重试队列用于处理写失败情况，并且有流量控制机制，包括优先级、路由规则、控制策略和自动降级等。

  3. 数据流向和处理

    1. 数据在不同存储层级之间通过binlog、bring和logic processor等机制进行交互和处理。

    2. 图中还展示了评论系统中的数据一致性保障机制，包括实时对账和离线对账系统。

    3. 流量控制机制用于确保系统在高负载情况下的稳定性，包括优先级设置、路由规则、控制策略和自动降级等功能。

（三）存储设计

  1. 存储模型

    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 作为唯一事实表，同步全量和捕获增量数据转换为下游索引表，实现业务解耦，但带来理解维护成本和一致性难题，不过整体优势大于劣势。

  2. 数据类型

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

（四）数据一致性

  1. 数据同步问题

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

  2. 解决措施

    1. 重试队列：解决写失败问题，将失败请求异步重试，但引入队列可能导致写并发数据竞争和乱序问题。

    2. 版本号机制：每次评论数据变更版本号递增，CAS 写操作时比对 binlog 和 Taishan 数据版本号，不一致则丢弃过期数据。

    3. 对账系统：根据 CAP 理论，系统无法完全保证一致性，引入重试、CAS 和版本号机制后仍可能有不一致，通过实时对账（TiDB Binlog 事件驱动，延迟队列消费对比数据并修复）和离线对账（利用数仓离线数据 T + 1 对比）确保最终一致性。

（五）降级策略

  1. 降级需求与策略对比

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

  2. 对冲策略

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

\

上一页Feed 流系统的架构设计方案下一页如何设计一个规则引擎？

最后更新于