评论系统和可用性设计

转载自stormspirit，原文链接：评论系统和可用性设计

存储设计

数据表设计

先看一张 b 站的评论图：

如上图所示，主评论下面有子评论，子评论之间也可以互相评论，并且评论之间是通过赞数进行排序的。

数据表设计：

如上图，评论系统分为三张表。

comment_subject

评论主题表。一个主题可能是一个视频稿件、一篇文章等。分成了 50 张表。自增 id 做主键。

obj_id 是主题 id， obj_type 是主题类型。

另外还保存了一些计数字段，比如评论总数等。这样做是为了避免每次需要统计总数时都要做一次 select count(*) ，这样效率很低，所以直接每次新增评论的时候就把相应字段 +1 即可。

comment_index

评论索引表。主要存的是评论的 id 与评论主题的对应关系，以及该评论的一些相关信息，比如是不是根评论、评论楼层，评论总数等。分成了 200 张表。使用自增 id 做主键，主键 id 就是评论 id。

root 是该评论的根评论 id，比如上面评论图红框里的就是根评论。不为 0 就是回复的评论，为 0 就是根评论。

parent 是这个评论的父评论，也就是它是回复哪条评论的，如果为 0 那这个评论就是根评论。

其他的都是一些统计信息等等。

comment_content

评论内容表。主要存的是评论实际内容。分成了 200 张表。

它直接使用 comment_id（对应的就是 comment_index 表的 id ）作为主键，这样的好处是：

• 表都有主键，即 cluster index，是物理组织形式存放的，comment_content 没有 id，是为了减少一次二级索引查找，直接基于主键检索，同时 comment_id 在写入要尽可能的顺序自增。

  意思是从 comment_index 表里捞出来一堆 comment_id ，那就可以直接通过这些 comment_id 作为主键去查询 comment_content 表了。如果 content 表还有自己的自增主键的话，那么通过 comment_id 去查必然需要先查到自己的主键 id ，然后再通过 id 去查到这一行数据，多了一步操作。

• 索引、内容分离，方便 mysql datapage 缓存更多的 row，如果和 content 耦合，会导致更大的 IO。长远来看 content 信息可以直接使用 KV storage 存储。比如 Rocks DB 等。

这也是一种 「索引内容分离」 的设计思想。

写数据

事务更新 comment_subject，comment_index，comment_content 三张表，其中 content 属于非强制需要一致性考虑的。可以先写入 content，之后事务更新其他表。即便 content 先成功，后续失败仅仅存在一条 ghost 数据。

读数据

基于 obj_id + obj_type 在 comment_index 表找到根评论列表，比如：

select id from comment_index where obj_id = 'x' and obj_type = 'y' and root = 0 ORDER BY floor;

对于二级的子楼层，由于一般只查询 3 层子楼层：

select id from comment_index where parent/root in (上面查询出来的 id) and floor <= 3 order by floor;

之后根据 comment_index 的 id 字段捞出 comment_content 的评论内容。

因为产品形态上只存在 「二级列表」，因此只需要迭代查询两次即可。对于嵌套层次多的，产品上，可以通过二次点击支持。

这种迭代查询的方式也可以直接用图数据库来实现，可能更好，比如 DGraph、HugeGraph 类似的图存储思路。

总结

主题一张表，评论索引与评论内容分开两张表来存，表里有一些统计字段，避免每次都重新统计。内容表的主键直接使用评论 id，避免使用评论 id 查询还需要回表。评论内容可以使用 kv 数据库。写入时可以先写评论内容表，评论索引表和主题表用一个事务更新。

缓存设计

comment_subject_cache

对应主题的缓存，value 使用 protobuf 序列化的方式存入。

comment_index_cache

使用 redis sortedset 进行索引的缓存。key 是主题 id + 主题 type + 排序方式， member 就是评论 id，score 就是根据各种要素排序的得分。这样就可以根据某个主题查询，得到排序过后的评论 id 列表。然后就可以通过评论 id 列表去批量查询评论内容了。

提示

索引即数据的组织顺序，而非数据内容。参考过百度的贴吧，他们使用自己研发的拉链存储来组织索引，我认为 mysql 作为主力存储，利用 redis 来做加速完全足够，因为 cache miss 的构建，我们前面讲过使用 kafka 的消费者中处理，预加载少量数据，通过增量加载的方式逐渐预热填充缓存，而 redis sortedset skiplist 的实现，可以做到 O(logN) + O(M) 的时间复杂度，效率很高。

sorted set 是要增量追加的，因此必须判定 key 存在，才能 zdd。

comment_content_cache

对应评论内容数据，使用 protobuf 序列化的方式存入。

缓存使用增量加载 + lazy 加载模式，也就是在查询第一页的时候会将后两页评论数据也一起加载进缓存。可以使用 kafka 进行缓存的异步构建。

可用性设计

缓存穿透

singleflight

对于热门的主题，如果存在缓存穿透的情况，会导致大量的同进程、跨进程的数据回源到存储层，可能会引起存储过载的情况，如何只交给同进程内，一个人去做加载存储？

使用归并回源的思路 singleflight，singleflight 的原理可以看这篇文章 Go并发编程(十二) Singleflight。

同进程只交给一个人去获取 mysql 数据，然后批量返回。

同时这个租约 owner 投递一个 kafka 消息，做该 key 的 cache build 的操作。这样可以大大减少查询 mysql 的压力，以及大量透穿导致的密集写 kafka 的问题（如果不这么做那么会有很多的进程向 kafka 发送 cache rebuild 的指令，然后它们都会去 mysql 里查询数据写缓存）。

更进一步的，后续连续的请求，仍然可能会短时 cache miss，我们可以在进程内设置一个过期时间为 5 秒的 short-lived flag，标记最近有一个人投递了同一个 key 的 cache rebuild 的消息，如果有这个 flag ，那么相同的 kafka 消息直接 drop 而不会再去查 mysql 构建缓存，这样 mysql 的压力更小。

再进一步，可以在 comment-job 内存里设置一个过期时间很短的比如 5 秒的 LRU cache， 有一个线程去 mysql 里查到了数据就更新这个缓存，然后其他的线程直接从这个缓存里拿数据即可，这样就不用重复去 mysql 里查了，同样减少了对 mysql 的查询压力。

一般不需要使用分布式锁，实现起来太复杂而且很容易出错。

热点

流量热点是因为突然热门的主题，被高频次的访问，因为底层的 cache 设计，一般是按照主题 key 进行一致性 hash 来进行分片，但是热点 key 一定命中某一个节点，这时候 remote cache 可能会变为瓶颈，因此做 cache 的升级 local cache 是有必要的，我们一般使用「单进程自适应发现热点」的思路，附加一个短时的 ttl local cache，可以在进程内吞掉大量的读请求。

在内存中使用 hashmap 统计每个 key 的访问频次，这里可以使用滑动窗口统计（如下图），即每个窗口中，维护一个 hashmap，之后统计所有未过期的 bucket，汇总所有 key 的数据。

之后使用小顶堆计算 TopK 的数据，自动进行热点识别。把 TopK 的 key 统一 load 到本地缓存。