简易评论系统设计

评论系统是互联网社区网站的重要组成部分，对增强用户参与度、提高网站活跃度等方面都具有重要价值。

一个简易的评论系统（在线社区平台）通常包含以下功能

用户评论：用户可以对某个产品、主题进行评论，包括文字评论。
评论展示：所有用户的评论将会在产品或服务页面下方展示，其他用户可以查看。
1. 评论的展示有多种组织方式，参考《评论系统的几种展示结构和存储设计》，本文主要针对常见的二级嵌套评论的组织形式。
评论回复：用户可以对其他用户的评论进行回复，形成互动。
评论审核：为了防止恶意评论或者垃圾信息，系统需要有审核机制，对用户的评论进行审核。
评论排序：用户可以根据时间、评分等因素对评论进行排序。

基于前面的需求分析，一个简易的评论系统，一般会包含三个实体：

Comment-BFF： BFF层，用于接收和处理来自C端用户的请求（包括读、写评论），并返回结果。如果是写操作，会通过MQ来进行削峰填谷，由Comment-Service作为MQ消费者，进行真正的写动作。
Comment-Service： 评论数据的核心逻辑处理服务，
- 消费Kafka中用户的写入消息，写入MySQL，并缓存到Redis中，方便用户的快速读取。
- 当Cache Miss时，处理用户的读请求，从MySQL中读取数据，更新缓存，并返回给用户。
Comment-Admin：评论的管理服务，（置顶、删除、检索等）。

仅列出与评论相关的关键字段

字段名	数据类型	描述
post_id	BIGINT	帖子ID，主键
user_id	BIGINT	发帖用户ID，外键，引用User表的user_id
title	VARCHAR	帖子标题
content	TEXT	帖子内容
post_time	DATETIME	发帖时间
comment_count	INT	评论总数
root_comment_count	INT	根评论总数
status	ENUM	帖子状态，如'NORMAL'，'PINNED'（置顶），'HIDDEN'（隐藏），'FILTERED'（过滤）等
created_time	DATETIME	创建时间
updated_time	DATETIME	更新时间
deleted_time	DATETIME	删除时间

字段名	数据类型	描述
comment_id	BIGINT	评论ID，主键
user_id	BIGINT	评论用户ID，外键，引用User表的user_id
post_id	BIGINT	所评论的帖子ID，外键，引用Post表的post_id
parent_comment_id	BIGINT	父评论ID，如果是一级评论，此字段为NULL
reply_to_comment_id	BIGINT	被回复的评论ID，如果是一级评论，此字段为NULL
reply_to_user_id	BIGINT	被回复的用户ID，如果是一级评论，此字段为NULL
content	TEXT	评论内容
comment_time	DATETIME	评论时间
status	ENUM	评论状态，如'NORMAL'，'HIDDEN'（隐藏），'FILTERED'（过滤）等
created_time	DATETIME	创建时间
updated_time	DATETIME	更新时间
deleted_time	DATETIME	删除时间

reply_to_comment_id和reply_to_user_id 只有当当前评论是对二级评论的回复是时为非NULL，因为我们的评论系统是二级嵌套结构，因此被回复的评论和当前评论在组织形式上是同级的，而非父子结构。

热门数据缓存：对于访问频率高的数据，如热门帖子的评论，可以将其缓存到内存中，如使用Redis等内存数据库。当用户请求这些数据时，可以直接从缓存中获取，而不需要查询数据库。
分页缓存：对于评论列表的分页查询，可以将每页的数据缓存到内存中。当用户请求某一页的数据时，可以直接从缓存中获取，而不需要查询数据库。
延迟写入：对于写操作，如用户发表评论，可以先将数据写入缓存，然后异步地将数据写入数据库。这样可以提高写操作的响应速度。
缓存预热：在系统启动或者在低峰期，可以预先将可能被访问的数据加载到缓存中，这样在高峰期可以直接从缓存中获取数据。

当单表存储的数据量级过大时，会影响查询性能，可以进行一定的分表。

评论通常不会脱离帖子本身存在，因此评论表可以根据post_id哈希值将数据分布到多个表中。

将读操作和写操作分发到不同的数据库服务器上。例如，可以设置一台数据库服务器专门处理写操作，其他服务器处理读操作。这样可以提高系统的并发处理能力。