如何用MySQL来实现评论系统

为什么我不用mongodb

1. 社区成熟度不如MySQLredis
2. 需要学习的东西很多迁移扩容片建集群
3. redis > mongodb

架构设计

使用MySQL进行存储的话就必须要用到Redis来做缓存后台admin需要接通ES来进行查询comment-service通过异步来进行写Redis和MySQL评论数据MySQL和ES通过Canal进行binlog同步。

缓存模式

首先我们需要预读我们读第一页的时候也需要把第二页的内容加载出来。读第二页的时候我们预先读第三页这样可以避免大量的cache miss。

但是这里有一个致命的问题就是当缓存抖动的时候会触发大量的cache rebuild因为我们使用了预加载容易造成OOM(内存溢出)。因此我们需要使用消息队列来进行逻辑异步化对于当前请求只返回MySQL中的部分数据即可。

写的逻辑

至于写的操作我们要穿透到存储层因此最好使用消息队列异步削峰。例如我的评论发布出去了用户过100ms才看到评论这是无所谓的。

存储设计

comment_subject表

id	int	主键
obj_id	int	对象id
obj_type	int	对象类型
member_id	int	作者id
count	int	评论总数
root_count	int	跟评总数
all_count	int	评论+回复总数
state	int	状态 0正常 1隐藏
attrs	int	属性 0置顶 1不置顶
create_time+update_time	datatime	创建时间修改时间

obj_id+obj_type把评论系统设计成中台。 一般是指搭建一个灵活快速应对变化的架构快速实现前端提的需求避免重复建设达到提高工作效率目的。

obj_id+obj_type形成了一个业务键比如微博发帖发视频你可以发视频你也可以发文章评论系统设计成中台。

comment_index

id	int	主键id
obj_id	int	对象id
obj_type	int	对象类型
member_id	int	发表者id
root	int	根评论id不为0是回复评论
parent	int	父评论id为0是root评论
floor	int	评论楼层
count	int	评论总数
root_count	int	根评论总数
like	int	点赞数
hate	int	点踩数
state	int	状态0正常1隐藏
attrs	int	属性
create_time	datetime	创建时间
update_time	datetime	修改时间

parent父评论id其实就是记录是否是回复评论。

comment_content表

comment_id	int	主键
at_member_ids	varchar	对象id
ip	int	对象类型
platform	int	发表者id
device	varchar	跟评论id不为0是回复评论
message	varchar	评论内容
meta	varchar	评论元数据背景字体
create_time	datetime	创建时间
update_time	datetime	修改时间

index是索引表content是内容表。

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

数据读取基于obj_id + obj_type在comment_index表找到评论列表where root=0 order by floor。之后根据comment_index的id字段捞出comment_content的评论内容。对于二级的子楼层where parent/root in(id...)。

为什么要把index和content分成两个表

comment_index评论楼层的索引表实际并不包含内容。comment_content评论内容的表包含评论的具体内容。其中comment_index的id字段和comment_content是1对1的关系这里面包含了几种设计思想。

• 表都有主键comment_content没有id是为了减少一次二级索引查找直接基于主键检索同时comment_id在写入要尽可能的顺序自增。
• 索引内容分离方便mysql_datapage缓存更多的row如果和content耦合会导致更大的IO。长远来看content信息可以直接使用KV storage存储。

缓存设计

comment_subject_cache【string】

key	string	oid_type
value	int	subject marshal string
expire	duration	24h

comment_index_cache【sorted set】

key	string	cache keyoid_type_sort其中sort为排序方式0楼层1回复数量
member	int	comment_id评论id
score	double	楼层号回复数量排序得分
expire	duration	8h

comment_content_cache

key	string	comment_id
value	int	content
expire	duration	24h

comment_subject_cache对应主题的缓存value使用protobuf序列化的方式存入这样调用rpc的时候速度可以更块一点。

comment_index_cache使用redis sorted set进行索引的缓存索引即数据的组织顺序而非数据内容。通过预加载少量数据通过增量加载的方式逐渐预热填充缓存而redis sorted set skiplist的实现可以做到O(logN) + O(M)的时间复杂度效率很高

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

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

增量加载(目标表仅更新源数据表中变化的内容)+lazy加载(延迟加载种将资源标识为非阻塞非关键资源并仅在需要时加载它们的策略)

可用性设计

其实就是各种缓存问题消息队列消息等问题。

如果这个key是热点的key的话可以使用本地缓存+分布式缓存。

那么如何统计是否是热点呢

这里我们就移步到我们的下一篇文章了谢谢大家。