B站业务网 - 点赞QQ资料卡平台
B站（哔哩哔哩）的点赞系统是UP主与粉丝之间互动的重要纽带，涵盖了对视频、动态、专栏、评论和弹幕等多种实体维度的点赞、点踩及数据查询功能，以下是关于该点赞系统的详细介绍：
一、系统能力
基本操作
点赞/取消点赞：用户可对特定稿件进行点赞或取消点赞操作。
点踩/取消点踩：用户可对特定稿件进行点踩或取消点踩操作。
数据查询
点赞状态查询：查询用户是否对单个或一批稿件点过赞或点踩。
点赞数查询：查询特定稿件的总点赞数。
点赞列表查询：查询某个用户的点赞列表。
点赞人列表查询：查询某稿件的所有点赞用户。
用户总点赞数：查询用户收到的总点赞数。
平台能力
中台化与平台化：提供业务快速接入的能力，支持多租户数据隔离存储。
容灾能力：具备在各种情况下的系统容灾能力，确保服务连续性。
二、系统架构
流量路由层
- 决定流量应该去往哪个机房，以优化网络性能和负载均衡。
业务网关层
- 统一鉴权、反黑灰产等流量筛选，确保系统安全和稳定。
3. 点赞服务层（thumbup-service）
- 提供统一的RPC接口，处理点赞相关请求。
4. 异步任务层（thumbup-job）
- 处理后台任务，如数据同步、缓存更新等。
数据层
- 包括数据库（DB）、键值存储（KV）和缓存（Redis），用于存储点赞记录和计数。
三、存储层设计
三层数据存储
第一层存储（DB层）：使用TiDB作为分布式数据库，负责持久化保存点赞记录和计数。
第二层存储（缓存层）：基于Redis实现CacheAside模式，提升读写性能。
第三层存储（本地缓存）：应对缓存热点问题，利用最小堆算法统计最频繁访问的数据并存储在本地内存中。
四、系统优化与思考
可靠性与成本控制
- 选择合适的存储介质与数据存储形态，最小化存储成本的同时满足业务需求。
- 从关系型数据库（TiDB）+缓存（Redis）逐渐过渡至KV形数据库（TaiShan）+缓存（Redis），提高可靠性。
容灾设计
- DB设计上两地机房互为灾备，通过db-proxy切换读写流量。
- Redis集群跨机房部署，通过异步任务消费TiDB的binLog维护两地缓存一致性。
五、相关问题与解答
Q1: B站点赞系统如何处理高并发场景下的点赞请求？
A1: B站在面对高并发场景时，采取了多种措施来保证系统的稳定性和响应速度，通过在内存中进行部分聚合写入，例如聚合10秒内的点赞数一次性写入，减少了数据库的IO次数，数据库写入进行了全面的异步化处理，确保数据库能以合理的速率处理写入请求，还采用了热点识别机制，将热门数据缓存至本地，并设置合理的TTL，以应对单点流量压力。
Q2: 如果DB不可用，B站点赞系统如何保证服务的连续性？
A2: 如果DB不可用，B站点赞系统会依托缓存尽可能提供服务，由于采用了CacheAside模式和本地缓存策略，即使在DB故障的情况下，也能通过读取缓存中的数据来维持基本的点赞服务功能，系统设计了两地机房互为灾备的方案，当一个机房的DB发生故障时，可以通过db-proxy切换到另一个机房继续提供服务，从而保证了服务的连续性。
