一、前言
1、什么是点赞
点赞相信大家都不陌生，在B站，点赞是UP主们跟粉丝之间的特殊羁绊。B 站的点赞系统提供了对视频、动态、专栏、评论、弹幕等多种实体维度的点赞、点踩以及其余配套的数据查询的能力。
稿件点赞（类推动态、专栏、评论等也具备该功能）
总获赞数
点赞记录
2、点赞服务需要提供哪些系统能力
业务能力:以 “稿件” 为例，点赞服务需要提供对某个稿件点赞（取消点赞）、点踩（取消点踩）查询是否对 单个 或者 一批稿件 点过赞（踩） - 即点赞状态查询查询某个稿件的点赞数查询某个用户的点赞列表查询某个稿件的点赞人列表查询用户收到的总点赞数平台能力：点赞作为一个与社区实体共存的服务，中台化、平台化也是点赞服务需要具备的能力提供业务快速接入的能力（配置级别）数据存储上（缓存、DB），具备数据隔离存储的能力（多租户）容灾能力：作为被用户强感知的站内功能，需要考虑到各种情况下的系统容灾。例如当：存储不可用例如当DB不可用时，需要依托缓存尽可能提供服务。同理当缓存不可用时，DB也需要保证自己不宕机的情况下尽可能提供服务。消息队列不可用当消息队列不可用时，依托B站自研的railgun，通过RPC调用的方式自动降级机房灾难切换机房数据同步延迟比如点赞就遇到过因为Tidb的数据同步问题（断流、延迟）导致的点赞计数同步延迟问题。当然还有其他比如 下游依赖宕机、点赞消息堆积 以及其他未知问题
3、系统需要承载哪些压力
1.流量压力
全局流量压力：全站点赞状态查询、点赞数查询等【读流量】超过300k，点赞、点踩等【写流量】超过15K针对写流量，为了保证数据写入性能，我们在写入【点赞数】数据的时候，在内存中做了部分聚合写入，比如聚合10s内的点赞数，一次性写入。如此可大量减少数据库的IO次数。同时数据库的写入我们也做了全面的异步化处理，保证了数据库能以合理的速率处理写入请求。另外为了保证点赞状态的正确性，且同时让程序拥有自我纠错的能力，我们在每一次更新点赞状态之前，都会取出老的点赞状态作为更新依据。例如：如果当前是取消点赞，那么需要数据库中已有点赞状态。单点流量（热点）压力：热门事件、稿件等带来的系统热点问题，包括DB热点、缓存热点当一个稿件成为超级热门的时候，大量的流量就会涌入到存储的单个分片上，造成读写热点问题。此时需要有热点识别机制来识别该热点，并将数据缓存至本地，并设置合理的TTL。例如，UP主 【杰威尔音乐】发布第一个稿件的时候就是一次典型热点事件。
2.数据存储压力
点赞数据存储超过千亿级别如何高效的利用存储介质存放这些数据才能既满足业务需求，也能最大程度节省成本，也是一个点赞服务正在努力改造的工程 - KV化存储
3.面对未知灾难
DB宕机、redis集群抖动、机房故障、网络故障等针对前言中提到的点赞的平台能力、系统压力与容灾，我会在下文中作出更加详细的介绍。
二、点赞整体系统架构简介
为了在提供上述能力的前提下经受住流量、存储、容灾三大压力，点赞目前的系统实现方式如下：
1、系统架构简介
